特開 2024-81674 デュアルエンドのメディア・インテリジェンス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024081674

(43)【公開日】2024-06-18

(54)【発明の名称】デュアルエンドのメディア・インテリジェンス

(51)【国際特許分類】

   G10L 19/00 20130101AFI20240611BHJP

   G10L 19/008 20130101ALI20240611BHJP

   H04S 7/00 20060101ALN20240611BHJP

【ＦＩ】

G10L19/00 330B

G10L19/008

H04S7/00 300

【審査請求】有

【請求項の数】4

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2024038518

(22)【出願日】2024-03-13

(62)【分割の表示】P 2021532235の分割

【原出願日】2019-12-10

(31)【優先権主張番号】PCT/CN2018/120923

(32)【優先日】2018-12-13

(33)【優先権主張国・地域又は機関】CN

(31)【優先権主張番号】62/792,997

(32)【優先日】2019-01-16

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】19157080.3

(32)【優先日】2019-02-14

(33)【優先権主張国・地域又は機関】EP

(71)【出願人】

【識別番号】507236292

【氏名又は名称】ドルビー ラボラトリーズ ライセンシング コーポレイション

(71)【出願人】

【識別番号】510185767

【氏名又は名称】ドルビー・インターナショナル・アーベー

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】バイ，イエンニーン

(72)【発明者】

【氏名】ジェラード，マーク ウィリアム

(72)【発明者】

【氏名】ハン，リチャード

(72)【発明者】

【氏名】ヴォルタース，マルティン

(57)【要約】      （修正有）

【課題】オーディオ・コンテンツをビットストリームに符号化する方法及びオーディオ・コンテンツをビットストリームからデコードする方法を提供する。
【解決手段】オーディオ・コンテンツおよび該オーディオ・コンテンツについての分類を示す分類情報を含むビットストリームからオーディオ・コンテンツをデコードする方法であって、ビットストリームを受信し、オーディオ・コンテンツ及び分類情報をデコードし、前記分類情報に基づいて、デコードされたオーディオ・コンテンツの後処理を実行するための後処理モードを選択することを含む。後処理モードを選択することは、分類情報に基づいて、デコードされたオーディオ・コンテンツの後処理のための一つまたは複数の制御重みを計算する。
【選択図】図１１

【特許請求の範囲】

【請求項1】

エンコーダにおいてエンコードされたビットストリームからオーディオ・コンテンツをデコードする方法であって、前記ビットストリームはオーディオ・コンテンツと該オーディオ・コンテンツについての分類情報とを含み、前記分類情報は、前記オーディオ・コンテンツのコンテンツ型を示し、前記分類情報は、一つまたは複数の信頼値を含み、それぞれの信頼値は、それぞれのコンテンツ型に関連付けられ、前記オーディオ・コンテンツが該それぞれのコンテンツ型である確からしさの指標を与えるものであり、当該方法は、デコーダによって実行され：
前記エンコーダからの前記ビットストリームを受領する段階と；
前記オーディオ・コンテンツおよび前記分類情報をデコードする段階と；
前記分類情報に基づいて、デコードされたオーディオ・コンテンツの後処理を実行するための後処理モードを選択する段階と；
前記分類情報に基づいて、前記デコードされたオーディオ・コンテンツの前記後処理のための一つまたは複数の制御重みを計算する段階であって、前記制御重みは前記信頼値に基づいて計算される、段階とを含む、
方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、オーディオ・コンテンツをビットストリームに符号化する方法およびオーディオ・コンテンツをビットストリームからデコードする方法に関する。本開示は、特に、オーディオ・コンテンツのコンテンツ型を示す分類情報がビットストリームにおいて伝送されるような方法に関する。

【背景技術】

【0002】

オーディオ信号後処理の知覚される恩恵は、オーディオ信号処理アルゴリズムが処理されているコンテンツを認識している場合に改善できる。たとえば、ダイアログ向上器によるダイアログの正確な検出は、現在のオーディオ・フレームにおける、ダイアログの、測定された高い信頼度がある場合に改善される。また、音楽の音色を維持するために、音楽コンテンツの存在下では仮想化器が無効にされてもよく、あるいは発話の音色を維持するために、映画においてダイアログの存在下では、音楽を音色マッチさせるように設計された動的等化器（たとえばドルビー（登録商標）ボリューム・インテリジェント・イコライザー）が無効にされてもよい。

【0003】

典型的には、ユーザーは、再生装置上で最良の設定を得るために「映画」または「音楽」のようなプロファイルを切り換えることを要求されることがあるが、これは、多くのユーザーが認識していない、または快適でないことがありうる高度な設定またはUIにアクセスすることを必要とすることが多い。

【0004】

この問題に取り組むための一つのアプローチは、コンテンツ解析ツール（たとえば、ドルビーのメディア・インテリジェンス）を使用して、ある種のコンテンツ型がオーディオ・ストリーム中にあることがどのくらい確からしいかを決定するためにオーディオ信号中の特徴を検出することであろう。

【0005】

映画や音楽を含む多様なコンテンツを再生できる携帯電話のような現在の再生装置は、コンテンツ解析ツール（たとえば、ドルビーのメディア・インテリジェンス）を使用して、オーディオ・ストリーム中のある種のコンテンツ型の存在についての信頼値を決定することができる。コンテンツ解析ツールは、「音楽」、「発話」または「背景効果音」の存在に関する信頼値（信頼スコア）を返すことができる。次いで、それらの信頼値が組み合わせて使用されて、アルゴリズム操縦重みを返すことができ、この重みは、ある種の後処理特徴（たとえば、その強度）を制御するために使用することができる。

【0006】

上述の方法は、デコーダ内またはPCMオーディオ・データを取り込む別個の後処理ライブラリ内で実行できる「シングルエンド」解決策である。このシングルエンド実装は、後処理アルゴリズムを操縦することに効果的でありうるが、再生装置にかなりの計算量を追加し、よって、コンテンツ解析のリアルタイム性は、再生装置上で手に入れられる機能に制限されうる。

【0007】

よって、オーディオ・コンテンツのコンテンツを意識した処理のための改善された方法および装置が必要とされている。

【発明の概要】

【課題を解決するための手段】

【0008】

本開示は、それぞれの独立請求項の特徴を有する、オーディオ・コンテンツをエンコードする方法およびオーディオ・コンテンツをデコードする方法を提供する。

【0009】

本開示のある側面は、オーディオ・コンテンツをエンコードする方法に関する。この方法は、オーディオ・コンテンツのコンテンツ解析を実行することを含んでいてもよい。コンテンツ解析は、たとえば、ドルビーのメディア・インテリジェンス・ツールを適用することによって実行されてもよい。また、コンテンツ解析は、複数の連続する窓のそれぞれについて実行されてもよく、各窓は、所定数の連続する（オーディオ）フレームを含む。ここで、コンテンツ解析は、オーディオ・コンテンツ内の決定可能な特徴に基づいた確からしさ／信頼性の一つまたは複数の計算に基づいていてもよい。これらの計算は動的であってもよく、特定の確からしさを増幅または逆増幅するように調整できる。より一般的な用語では、コンテンツ解析は適応的であってもよく、および／または所定のオーディオ・コンテンツを使用して事前にトレーニングされていてもよい。コンテンツ解析は、待ち時間を減らすために先読みバッファを使ってもよい。追加的または代替的に、コンテンツ解析のために必要とされる処理時間を受け入れるために、エンコード待ち時間が導入されてもよい。また、コンテンツ解析は、複数のパス（pass）で実行されてもよい。この方法は、さらに、コンテンツ解析（の結果）に基づいてオーディオ・コンテンツのコンテンツ型を示す分類情報を生成することを含んでいてもよい。分類情報の生成は、オーディオ・コンテンツ内のシーン遷移の検出（またはシーン遷移の手動指示）にも基づいてもよい。たとえば、分類情報に含まれる信頼値の変化レートは、シーン遷移が検出／指示される場合には、より高くてもよい（すなわち、定常状態におけるよりも大きい）。この方法は、オーディオ・コンテンツおよび分類情報、たとえば、信頼値をビットストリームにエンコードすることをさらに含んでいてもよい。エンコードされたオーディオ・コンテンツおよびエンコードされた分類情報は、多重化されてもよい。この方法は、ビットストリームを出力することをさらに含んでいてもよい。

【0010】

本開示のコンテキストにおいて、オーディオ・コンテンツの「コンテンツ型」とは、再生装置で再生することができ、かつ、そのコンテンツ型の一つまたは複数のオーディオ特性によって人間の耳によって区別することができるコンテンツ型を意味する。たとえば、音楽は、異なるオーディオ周波数帯域幅、種々の周波数にわたるオーディオ信号の異なるパワー分布、異なるトーン持続時間、基本および優勢周波数の異なる型および数などに関わるため、発話またはノイズと区別することができる。

【0011】

エンコーダ側でコンテンツ解析を実行し、結果として得られた分類情報をビットストリーム中にエンコードすることにより、デコーダに対する計算負荷が大幅に緩和できる。さらに、エンコーダの優れた計算能力が、より複雑でより正確なコンテンツ解析を実行するために使用できる。エンコーダとデコーダの異なる計算能力に対応することとは別に、提案される方法は、デコードされたオーディオのオーディオ後処理における付加的な柔軟性をデコーダ側に提供する。たとえば、後処理は、デコーダを実装する装置の装置型および／またはユーザーの個人的な選好に従ってカスタマイズされてもよい。

【0012】

いくつかの実施形態では、コンテンツ解析は、少なくとも部分的には、オーディオ・コンテンツについてのメタデータに基づいてもよい。それにより、たとえば、コンテンツ作成者による、コンテンツ解析に対する追加的な制御が提供される。同時に、適切なメタデータを提供することにより、コンテンツ解析の精度が改善できる。

【0013】

本開示の別の側面は、オーディオ・コンテンツをエンコードするさらなる方法に関する。この方法は、オーディオ・コンテンツのコンテンツ型に関連するユーザー入力を受領することを含んでいてもよい。ユーザー入力は、たとえば、手動ラベルまたは手動信頼値を含んでいてもよい。この方法はさらに、ユーザー入力に基づいてオーディオ・コンテンツのコンテンツ型を示す分類情報を生成することを含んでいてもよい。この方法は、オーディオ・コンテンツおよび分類情報をビットストリーム中にエンコードすることをさらに含んでいてもよい。たとえば、ラベルまたは信頼値は、ビットストリームにおいてエンコードされてもよい。この方法は、ビットストリームを出力することをさらに含んでいてもよい。この方法により、たとえば、コンテンツ作成者による、コンテンツ解析に対する追加的な制御が提供される。

【0014】

いくつかの実施形態では、ユーザー入力は、オーディオ・コンテンツが所与のコンテンツ型であることを示すラベルの一つまたは複数と、一つまたは複数の信頼値とを含んでいてもよく、各信頼値は、それぞれのコンテンツ型に関連付けられ、オーディオ・コンテンツがそれぞれのコンテンツ型である確からしさの指標を与える。それにより、エンコーダのユーザーは、デコーダ側で実行される後処理に対する追加的な制御を与えられることができる。これは、たとえば、コンテンツ作成者の芸術的意図が後処理によって保存されることを保証することを可能にする。

【0015】

本開示の別の側面は、オーディオ・コンテンツをエンコードするさらなる方法に関する。オーディオ・コンテンツは、オーディオ・プログラムの一部として、オーディオ・コンテンツのストリームにおいて提供されてもよい。この方法は、オーディオ・コンテンツのサービス型（たとえば、オーディオ・プログラム型）を示すサービス型指示を受領することを含んでいてもよい。サービス型は、たとえば、音楽サービスまたはニュース（ニュースキャスト）サービス／チャネルであってもよい。この方法は、サービス型指示に少なくとも部分的に基づいて、オーディオ・コンテンツのコンテンツ解析を実行することをさらに含んでいてもよい。この方法は、さらに、コンテンツ解析（の結果）に基づいてオーディオ・コンテンツのコンテンツ型を示す分類情報を生成することを含んでいてもよい。分類情報の例としての信頼値は、オーディオ・コンテンツと一緒に、コンテンツ作成者によって直接提供されてもよい。たとえばコンテンツ作成者によって提供される信頼値等を考慮に入れるか否かは、サービス型指示に依存してもよい。この方法は、オーディオ・コンテンツおよび分類情報をビットストリーム中にエンコードすることをさらに含んでいてもよい。この方法は、ビットストリームを出力することをさらに含んでいてもよい。

【0016】

サービス型指示を考慮することにより、エンコーダはコンテンツ解析を実行することにおいて支援されることができる。さらに、エンコーダ側のユーザーは、デコーダ側のオーディオ後処理に対する追加的な制御が与えられることができ、それは、たとえば、コンテンツ作成者の芸術的意図が後処理によって保存されることを保証することを可能にする。

【0017】

いくつかの実施形態では、本方法は、サービス型指示に基づいて、オーディオ・コンテンツのサービス型が音楽サービスであるかどうかを判定することをさらに含んでいてもよい。この方法は、さらに、オーディオ・コンテンツのサービス型が音楽サービスであるとの判定に応答して、オーディオ・コンテンツのコンテンツ型が音楽コンテンツであることを示す分類情報（コンテンツ型「音楽」）を生成することを含んでいてもよい。これは、コンテンツ型「音楽」についての信頼値を可能な最大値（たとえば、1）に設定し、他の任意の信頼値をゼロに設定することに相当する。

【0018】

いくつかの実施形態では、この方法は、サービス型指示に基づいて、オーディオ・コンテンツのサービス型がニュースキャスト・サービスであるかどうかを判定することをさらに含んでいてもよい。この方法は、さらに、オーディオ・コンテンツのサービス型がニュースキャスト・サービスであるという判定に応答して、オーディオ・コンテンツが発話コンテンツであることを示す可能性がより高いように、コンテンツ解析を適応させることを含んでいてもよい。これは、コンテンツ解析の結果における発話コンテンツ（コンテンツ型「発話」）についての確からしさ／信頼度を高めるために、コンテンツ解析の一つまたは複数の計算（計算アルゴリズム）を適応させること、および／または、発話コンテンツ以外のコンテンツ型についての確からしさ／信頼度を減少させるために、コンテンツ解析の前記一つまたは複数の計算を適応させることによって、達成されうる。

【0019】

いくつかの実施形態では、サービス型指示は、フレーム毎に提供されてもよい。本開示の別の側面は、オーディオ・コンテンツをエンコードするさらなる方法に関する。オーディオ・コンテンツは、ファイルごとに提供されてもよい。この方法は、ファイルごとに実行されてもよい。ファイルは、それぞれのオーディオ・コンテンツについてのメタデータを含んでいてもよい。メタデータは、マーカー、ラベル、タグなどを含んでいてもよい。この方法は、少なくとも部分的にはオーディオ・コンテンツについてのメタデータに基づいてオーディオ・コンテンツのコンテンツ解析を実行することを含んでいてもよい。この方法は、さらに、コンテンツ解析（の結果）に基づいてオーディオ・コンテンツのコンテンツ型を示す分類情報を生成することを含んでいてもよい。この方法は、オーディオ・コンテンツおよび分類情報をビットストリームにエンコードすることをさらに含んでいてもよい。この方法は、ビットストリームを出力することをさらに含んでいてもよい。

【0020】

ファイル・メタデータを考慮することにより、エンコーダはコンテンツ解析を実行することにおいて支援されることができる。さらに、エンコーダ側のユーザーは、デコーダ側のオーディオ後処理に対する追加的な制御を与えられることができ、そのことは、たとえば、コンテンツ作成者の芸術的意図が後処理によって保存されることを保証することを可能にする。

【0021】

いくつかの実施形態では、メタデータは、ファイルのファイル・コンテンツ型を示すファイル・コンテンツ型指示を含んでいてもよい。ファイル・コンテンツ型は、音楽ファイル（ファイル・コンテンツ型「音楽ファイル」）、ニュースキャスト・ファイル／クリップ（ファイル・コンテンツ型「ニュースキャスト・ファイル」）、または動的（非静的または混合ソース）コンテンツを含むファイル（たとえば、発話のあるシーンと音楽／歌シーンとの間で頻繁に、たとえば数分に1回、遷移する、映画のミュージカル・ジャンル；ファイル・コンテンツ型「動的コンテンツ」）であってもよい。ファイル・コンテンツ型は、ファイル全体について同じ（一様）であってもよいし、またはファイルの部分間で変化してもよい。次いで、コンテンツ解析は、少なくとも部分的にはファイル・コンテンツ型指示に基づいてもよい。

【0022】

いくつかの実施形態では、この方法は、ファイル・コンテンツ型指示に基づいて、ファイルのファイル・コンテンツ型が音楽ファイルであるかどうかを判定することをさらに含んでいてもよい。この方法は、さらに、ファイルのファイル・コンテンツ型が音楽ファイルであるという判定に応答して、オーディオ・コンテンツのコンテンツ型が音楽コンテンツであることを示す分類情報を生成することを含んでいてもよい。

【0023】

いくつかの実施形態では、この方法は、ファイル・コンテンツ型指示に基づいて、ファイルのファイル・コンテンツ型がニュースキャスト・ファイルであるかどうかを判定することをさらに含んでいてもよい。この方法は、さらに、ファイルのファイル・コンテンツ型がニュースキャスト・ファイルであるという判定に応答して、オーディオ・コンテンツが発話コンテンツであることを示す可能性がより高いようにコンテンツ解析を適応させることを含んでいてもよい。これは、コンテンツ解析における発話コンテンツについての確からしさ／信頼度を高めるよう、コンテンツ解析の一つまたは複数の計算（計算アルゴリズム）を適応させること、および／または、発話コンテンツ以外のコンテンツ型についての確からしさ／信頼度を減らすよう、前記一つまたは複数の計算を適応させることによって達成されてもよい。

【0024】

いくつかの実施形態では、この方法は、ファイル・コンテンツ型指示に基づいて、ファイルのファイル・コンテンツ型が動的コンテンツであるかどうかを判定することをさらに含んでいてもよい。この方法は、さらに、ファイルのファイル・コンテンツ型が動的コンテンツであるという判定に応答して、異なるコンテンツ型間のより高い遷移レートを許容するようにコンテンツ解析を適応させることを含んでいてもよい。たとえば、コンテンツ型は、コンテンツ型間で、たとえば、音楽と非音楽の間で、より頻繁に（すなわち、定常状態の場合よりも頻繁に）遷移することを許容されてもよい。さらに、分類情報の平滑化（時間平滑化）は、動的コンテンツ（すなわち、動的ファイル・コンテンツについては無効にされてもよい。

【0025】

いくつかの実施形態では、上記の側面または実施形態のいずれかによる方法では、分類情報は、一つまたは複数の信頼値を含んでいてもよい。各信頼値（confidence value）は、それぞれのコンテンツ型に関連していてもよく、オーディオ・コンテンツがそれぞれのコンテンツ型である確からしさ（likelihood）の指示を与えてもよい。

【0026】

いくつかの実施形態では、上記の側面または実施形態のいずれかによる方法において、コンテンツ型は、音楽コンテンツ、発話コンテンツ、または効果（たとえば、背景効果）コンテンツのうちの一つまたは複数を含んでいてもよい。コンテンツ型は、さらに、群衆のノイズ／歓声を含んでいてもよい。

【0027】

いくつかの実施形態では、上記の側面または実施形態のいずれかによる方法は、オーディオ・コンテンツ内のシーン遷移の指示をビットストリーム中にエンコードすることをさらに含んでいてもよい。シーン遷移の指示は一つまたは複数のシーン・リセット・フラグを含んでいてもよく、そのそれぞれがそれぞれのシーン遷移を示す。シーン遷移は、エンコーダで検出されてもよく、あるいはたとえばコンテンツ作成者によって外部から提供されてもよい。前者の場合、この方法は、オーディオ・コンテンツ内のシーン遷移を検出するステップを含み、後者の場合、オーディオ・コンテンツ内のシーン遷移の（手動）指示を受領するステップを含むことになろう。ビットストリームにおいてシーン遷移を示すことによって、シーン遷移をまたぐ不適切な後処理の結果として生じうるデコーダ側での可聴アーチファクトが回避できる。

【0028】

いくつかの実施形態では、上記の側面または実施形態のいずれかによる方法は、エンコードする前に、分類情報の平滑化（時間平滑化）をさらに含んでいてもよい。たとえば、信頼値が経時的に平滑化されてもよい。平滑化は、制御入力／メタデータに従い、動的（非静的）としてフラグ付けされたオーディオ・コンテンツについては、状況に依存して、たとえばシーン遷移時には、無効にされてもよい。分類情報を平滑化することにより、デコーダ側のオーディオ後処理の安定性／連続性が改善できる。

【0029】

いくつかの実施形態では、上記の側面または実施形態のいずれかによる方法は、エンコードする前に分類情報を量子化することをさらに含んでいてもよい。たとえば、信頼値が量子化されてもよい。それにより、ビットストリームにおいて分類情報を伝送するために必要とされる帯域幅を減らすことができる。

【0030】

いくつかの実施形態では、上記の側面または実施形態のいずれかによる方法は、分類情報を、ビットストリームのパケット内の特定のデータ・フィールドに符号化することをさらに含んでいてもよい。ビットストリームは、たとえば、AC-4（ドルビー（登録商標）AC-4）ビットストリームであってもよい。特定のデータ・フィールドは、メディア・インテリジェンス（Media Intelligence、MI）データ・フィールドであってもよい。MIデータ・フィールドは、以下のフィールド：b_mi_data_present、music_confidence、speech_confidence、effects_confidence、b_prog_switch、b_more_mi_data_present、more_mi_dataのうちの任意のもの、一部のもの、または全部を含んでいてもよい。

【0031】

本開示の別の側面は、オーディオ・コンテンツおよび該オーディオ・コンテンツについての分類情報を含むビットストリームからオーディオ・コンテンツをデコードする方法に関する。分類情報は、オーディオ・コンテンツのコンテンツ分類を示してもよい。コンテンツ分類は、コンテンツ解析と、任意的には、たとえばオーディオ・コンテンツのコンテンツ型に関連するユーザー入力とに基づいてもよい（ここで、コンテンツ解析とユーザーによる入力提供はいずれもエンコーダで実行される）。この方法は、ビットストリームを受領することを含んでいてもよい。この方法は、さらに、オーディオ・コンテンツおよび分類情報をデコードすることを含んでいてもよい。この方法は、さらに、分類情報に基づいて、デコードされたオーディオ・コンテンツの後処理を実行するための後処理モードを選択することを含んでいてもよい。換言すれば、デコード方法は、分類情報に基づいて、デコードされたオーディオ・コンテンツの後処理を選択してもよい。

【0032】

デコーダに分類情報を提供することで、デコーダはコンテンツ解析をしないですむようになり、デコーダに対する計算負荷を大幅に緩和する。さらに、分類情報に基づいて好適な後処理モードを決定することができる、さらなる柔軟性がデコーダに与えられる。その際、装置型やユーザーの選好などの追加的な情報が考慮されてもよい。

【0033】

いくつかの実施形態では、デコード方法は、分類情報に基づいて、デコードされたオーディオ・コンテンツの後処理のための一つまたは複数の制御重みを計算することをさらに含んでいてもよい。

【0034】

いくつかの実施形態では、後処理モードの選択は、ユーザー入力にさらに基づいてもよい。

【0035】

いくつかの実施形態では、オーディオ・コンテンツは、チャネル・ベースである。たとえば、オーディオ・コンテンツは、2チャネル以上のオーディオ・コンテンツであってもよい。デコードされたオーディオ・コンテンツの後処理は、チャネル・ベースのオーディオ・コンテンツをアップミックスして、アップミックスされたチャネル・ベースのオーディオ・コンテンツにすることを含んでいてもよい。たとえば、2チャネル・ベースのオーディオ・コンテンツが、5.1チャネル、7.1チャネルまたは9.1チャネルのオーディオ・コンテンツにアップミックスされてもよい。この方法は、アップミックスされたチャネル・ベースのオーディオ・コンテンツに仮想化器を適用して、所望の数のチャネルのスピーカー・アレイのための仮想化のための仮想化されたアップミックスされたチャネル・ベースのオーディオ・コンテンツを得ることをさらに含んでいてもよい。たとえば、仮想化は、アップミックスされた5.1チャネル、7.1チャネル、または9.1チャネルのオーディオ・コンテンツを、たとえばヘッドフォンのような2チャネルのスピーカー・アレイに提供してもよい。しかしながら、仮想化は、アップミックスされた5.1チャネル・オーディオ・コンテンツを2チャネルまたは5.1チャネルのスピーカー・アレイに、アップミックスされた7.1チャネル・オーディオ・コンテンツを2チャネル、5.1チャネルまたは7.1チャネルのスピーカー・アレイに、アップミックスされた9.1チャネル・オーディオ・コンテンツを2チャネル、5.1チャネル、7.1チャネルまたは9.1チャネルのスピーカー・アレイに提供してもよい。

【0036】

いくつかの実施形態では、この方法は、分類情報に基づいて、デコードされたオーディオ・コンテンツの後処理のための一つまたは複数の制御重みを計算するステップをさらに含んでいてもよい。

【0037】

いくつかの実施形態では、分類情報（デコーダによって受領されたビットストリームにおいてエンコードされている）は、一つまたは複数の信頼値を含んでいてもよく、各信頼値は、それぞれのコンテンツ型に関連付けられており、オーディオ・コンテンツがそのそれぞれのコンテンツ型である確からしさの指標を与える。制御重みは信頼値に基づいて計算されてもよい。

【0038】

いくつかの実施形態では、この方法は、仮想化器の出力をスピーカー・アレイにルーティングし、分類情報に基づいてアップミキサーおよび仮想化器のためのそれぞれの制御重みを計算することをさらに含んでいてもよい。

【0039】

いくつかの実施形態では、この方法は、仮想化器を適用した後、チャネル・ベースのオーディオ・コンテンツおよび仮想化されたアップミックスされたオーディオ・コンテンツにクロスフェーダーを適用し、クロスフェーダーの出力をスピーカー・アレイにルーティングすることをさらに含んでいてもよい。この実施形態では、この方法は、分類情報に基づいてアップミキサーおよびクロスフェーダーのためのそれぞれの制御重みを計算することをさらに含んでいてもよい。

【0040】

いくつかの実施形態では、制御重みは、アップミキサー、クロスフェーダーまたは仮想化器以外のモジュールを制御するためのものであってもよい。同様に、制御重みを計算するいくつかの代替的な方法が可能である。制御重みの数および型、ならびにそれらの計算方法に関する実施形態は、本開示の以下の他の側面に関連して以下に記載される。しかしながら、これらの実施形態は、本開示の以下の側面に限定されるものではなく、本稿に開示されるオーディオ・コンテンツをデコードする任意の方法に適用できる。

【0041】

本開示の別の側面は、オーディオ・コンテンツおよび該オーディオ・コンテンツについての分類情報を含むビットストリームからオーディオ・コンテンツをデコードするさらなる方法に関する。分類情報は、オーディオ・コンテンツのコンテンツ分類を示してもよい。この方法は、ビットストリームを受領することを含んでいてもよい。この方法は、さらに、オーディオ・コンテンツおよび分類情報をデコードすることを含んでいてもよい。この方法は、さらに、分類情報に基づいて、デコードされたオーディオ・コンテンツの後処理のための一つまたは複数の制御重みを計算することを含んでいてもよい。制御重みは、後処理アルゴリズム／モジュール用の制御重みであってもよく、アルゴリズム操縦重みと称されてもよい。制御重みは、それぞれの後処理アルゴリズムの強度を制御することができる。

【0042】

いくつかの実施形態では、分類情報は一つまたは複数の信頼値を含んでいてもよく、各信頼値はそれぞれのコンテンツ型に関連付けられ、オーディオ・コンテンツがそのそれぞれのコンテンツ型である確からしさの指標を与える。制御重みは信頼値に基づいて計算されてもよい。

【0043】

いくつかの実施形態において、制御重みは、デコードされたオーディオ・コンテンツの後処理のためのそれぞれのモジュール（アルゴリズム）についての制御重みであってもよい。後処理のためのモジュール（アルゴリズム）は、たとえば：（インテリジェント／動的）等化器、（適応的）仮想化器、サラウンド処理モジュール、ダイアログ向上器、アップミキサー、およびクロスフェーダーのうちの一つまたは複数を含んでいてもよい。

【0044】

いくつかの実施形態では、制御重みは、等化器のための制御重み、仮想化器のための制御重み、サラウンドプロセッサのための制御重み、ダイアログ向上器のための制御重み、アップミキサーのための制御重み、およびクロスフェーダーのための制御重みのうちの一つまたは複数を含んでいてもよい。等化器は、たとえば、インテリジェント等化器（intelligent equalizer、IEQ）であってもよい。仮想化器は、たとえば、適応的仮想化器であってもよい。

【0045】

いくつかの実施形態では、制御重みの計算は、デコードを実行する装置の装置型に依存してもよい。言い換えれば、計算は、エンドポイントに固有であってもよいし、パーソナル化されていてもよい。たとえば、デコーダ側は、後処理のための一組のエンドポイント固有のプロセス／モジュール／アルゴリズムを実装してもよく、これらのプロセス／モジュール／アルゴリズムのためのパラメータ（制御重み）が、エンドポイント固有の仕方で信頼値に基づいて決定されてもよい。それにより、オーディオ後処理を実行する際に、それぞれの装置の個別の能力を考慮することができる。たとえば、モバイル装置およびサウンドバー装置によって異なる後処理が適用されることができる。

【0046】

いくつかの実施形態では、制御重みの計算は、ユーザー入力にさらに基づいてもよい。ユーザー入力は、信頼値に基づく計算をオーバーライドまたは部分的にオーバーライドしてもよい。たとえば、ユーザーが望むならば発話に仮想化が適用されてもよく、あるいはユーザーが望むならば、ステレオ拡張、アップミキシング、および／または仮想化がPCユーザーのために適用されてもよい。

【0047】

いくつかの実施形態では、制御重みの計算は、オーディオ・コンテンツのチャネルの数にさらに基づいてもよい。また、制御重みの計算は、一つまたは複数のビットストリーム・パラメータ（たとえば、ビットストリームによって運ばれ、ビットストリームから抽出可能なパラメータ）にさらに基づいていてもよい。

【0048】

いくつかの実施形態では、この方法は、オーディオ・コンテンツのコンテンツ解析を実行して、一つまたは複数の追加的な信頼値（たとえば、エンコーダ側によって考慮されていないコンテンツ型についての信頼値）を決定することを含んでいてもよい。このコンテンツ解析は、エンコーダ側に関して上述したのと同じ仕方で進行してもよい。次いで、制御重みの計算は、一つまたは複数の追加的な信頼値にさらに基づいてもよい。

【0049】

いくつかの実施形態では、制御重みは、仮想化器のための制御重みを含んでいてもよい。仮想化器についての制御重みは、分類情報がオーディオ・コンテンツのコンテンツ型が音楽である、または音楽である可能性が高いことを示す場合には、仮想化器が無効にされるように、計算されてもよい。これは、たとえば、音楽についての信頼値が所与の閾値を超える場合に当てはまりうる。それにより、音楽的な音色が保存できる。

【0050】

いくつかの実施形態では、仮想化器のための制御重みは、仮想化器の係数が素通しと完全な仮想化との間でスケールするように計算されてもよい。たとえば、仮想化器についての制御重みは、1－music_confidence*{1－max[effects_confidence,speech_confidence]^2}として計算されうる。

【0051】

いくつかの実施形態では、仮想化器についての制御重みは、オーディオ・コンテンツにおけるチャネルの数（すなわち、チャネル・カウント）または他のビットストリーム・パラメータ（単数または複数）にさらに依存してもよい（たとえば、それに基づいて決定されてもよい）。たとえば、仮想化のための制御重み（重み付け因子）は、ステレオ・コンテンツについて、信頼値に基づいて決定されるだけであってもよく、ステレオ・コンテンツ以外のすべてのマルチチャネル・コンテンツには（すなわち、2を超えるチャネル数については）固定の制御重み（たとえば、1に等しい）が適用されてもよい。

【0052】

いくつかの実施形態では、制御重みは、ダイアログ向上器のための制御重みを含んでいてもよい。ダイアログ向上器についての制御重みは、分類情報が、オーディオ・コンテンツのコンテンツ型が発話である、または発話である可能性が高いことを示している場合、ダイアログ向上器によるダイアログ向上が有効にされる／向上されるように、計算されてもよい。これは、たとえば、発話についての信頼値が所与の閾値を超える場合に当てはまりうる。それにより、ダイアログ向上は、実際にそれが有益なオーディオ・コンテンツのセクションに制約されることができ、同時に、計算能力を節約することができる。

【0053】

いくつかの実施形態では、制御重みは、動的等化器のための制御重みを含んでいてもよい。動的等化器のための制御重みは、分類情報がオーディオ・コンテンツのコンテンツ型が発話である、または発話である可能性が高いことを示している場合、動的等化器が無効にされるように計算されてもよい。これは、たとえば、発話についての信頼値が所与の閾値を超える場合に当てはまりうる。それにより、発話の音色の望ましくない変更が回避できる。

【0054】

いくつかの実施形態では、この方法は、制御重みの平滑化（時間平滑化）をさらに含んでいてもよい。平滑化は、制御入力／メタデータなどに従い、動的（非静的）としてフラグ付けされたオーディオ・コンテンツについては、状況に依存して、たとえばシーン遷移においては無効にされてもよい。制御重みを平滑化することにより、オーディオ後処理の安定性／連続性が改善できる。

【0055】

いくつかの実施形態では、制御重みの平滑化は、平滑化される特定の制御重みに依存してもよい。すなわち、平滑化は、少なくとも2つの制御重みの間で異なっていてもよい。たとえば、ダイアログ向上器制御重みについては平滑化が全くないか、ほんのわずかである、および／または仮想化器制御重みについてのより強力な平滑化があるといったことがありうる。

【0056】

いくつかの実施形態では、制御重みの平滑化は、デコードを実行する装置の装置型に依存してもよい。たとえば、携帯電話とTVセットの間で仮想化器制御重みの平滑化が異なっていてもよい。

【0057】

いくつかの実施形態では、この方法は、制御重みの連続性（たとえば、安定性）を増すために、制御重みに非線形マッピング関数を適用することをさらに含んでいてもよい。これは、制御重みの定義域範囲の境界に近い値を像範囲の境界のより近くにマッピングするマッピング関数（たとえばシグモイド関数など）を制御重みに適用することに関わってもよい。それにより、オーディオ後処理の安定性／連続性がさらに改善できる。

【0058】

本開示の別の側面は、2チャネル・オーディオ・コンテンツおよび該2チャネル・オーディオ・コンテンツについての分類情報を含むビットストリームからオーディオ・コンテンツをデコードする方法に関する。ビットストリームは、たとえばAC-4ビットストリームであってもよい。分類情報は、2チャネル・オーディオ・コンテンツのコンテンツ分類を示してもよい。この方法は、ビットストリームを受領することを含んでいてもよい。この方法は、さらに、2チャネル・オーディオ・コンテンツおよび分類情報をデコードすることを含んでいてもよい。この方法は、2チャネル・オーディオ・コンテンツをアップミックスして、アップミックスされた5.1チャネル・オーディオ・コンテンツにすることをさらに含んでいてもよい。この方法は、2チャネル・スピーカー・アレイのための5.1仮想化のために、アップミックスされた5.1チャネル・オーディオ・コンテンツに仮想化器を適用することをさらに含んでいてもよい。この方法は、さらに、2チャネル・オーディオ・コンテンツと仮想化されたアップミックスされた5.1チャネル・オーディオ・コンテンツとにクロスフェーダーを適用することを含んでいてもよい。この方法は、さらに、クロスフェーダーの出力を2チャネル・スピーカー・アレイにルーティングすることを含んでいてもよい。ここで、この方法は、分類情報に基づいて、仮想化器および／またはクロスフェーダーについてのそれぞれの制御重みを計算することを含んでいてもよい。仮想化器およびクロスフェーダーは、それぞれの制御重みの制御下で動作することができる。

【0059】

本開示の別の側面は、2チャネル・オーディオ・コンテンツおよび該2チャネル・オーディオ・コンテンツの分類情報を含むビットストリームからオーディオ・コンテンツをデコードするさらなる方法に関する。ビットストリームは、たとえばAC-4ビットストリームであってもよい。分類情報は、2チャネル・オーディオ・コンテンツのコンテンツ分類を示してもよい。この方法は、ビットストリームを受領することを含んでいてもよい。この方法は、さらに、2チャネル・オーディオ・コンテンツおよび分類情報をデコードすることを含んでいてもよい。この方法は、2チャネル・オーディオ・コンテンツをアップミックスして、アップミックスされた5.1チャネル・オーディオ・コンテンツにするために、2チャネル・オーディオ・コンテンツにアップミキサーを適用することをさらに含んでいてもよい。この方法は、5チャネル・スピーカー・アレイの5.1仮想化のために、アップミックスされた5.1チャネル・オーディオ・コンテンツに仮想化器を適用することをさらに含んでいてもよい。この方法は、さらに、仮想化器の出力を5チャネル・スピーカー・アレイにルーティングすることを含んでいてもよい。ここで、この方法は、分類情報に基づいて、アップミキサーおよび／または仮想化器についてのそれぞれの制御重みを計算することを含んでいてもよい。アップミキサーおよび仮想化器は、それぞれの制御重みの制御下で動作してもよい。アップミキサーについての制御重みは、アップミックス重みに関係していてもよい。

【0060】

別の側面は、プロセッサのための命令を記憶しているメモリに結合されたプロセッサを含む装置（たとえば、エンコーダまたはデコーダ）に関する。プロセッサは、上記の諸側面およびそれらの実施形態のいずれかに従って方法を実施するように適応されてもよい。さらなる側面は、命令を含むコンピュータ・プログラムであって、プロセッサに、上記の側面のいずれかおよびそれらの実施形態に従って方法を実行するように該命令を実行させるコンピュータ・プログラムと、該コンピュータ・プログラムを記憶しているそれぞれのコンピュータ読み取り可能な記憶媒体とに関する。

【図面の簡単な説明】

【0061】

本開示の例示的な実施形態は、添付の図面を参照して以下に説明される。ここで、同様の参照番号は、同様の要素または類似の要素を示す。

【図1】本開示の実施形態によるエンコーダ‐デコーダ・システムの例を概略的に示す。

【図2】本開示の実施形態が適用できるビットストリームの例を概略的に示す。

【図3】本開示の実施形態によるオーディオ・コンテンツの分類情報を記憶するためのデータ・フィールドの例を概略的に示す。

【図4】本開示の実施形態によるオーディオ・コンテンツをエンコードする方法の例をフローチャートの形で概略的に示す。

【図5】本開示の実施形態によるオーディオ・コンテンツのコンテンツ解析の一例を概略的に示す。

【図6】本開示の実施形態によるオーディオ・コンテンツをエンコードする方法の別の例をフローチャートの形で概略的に示す。

【図7】本開示の実施形態によるオーディオ・コンテンツをエンコードする方法の別の例をフローチャートの形で概略的に示す。

【図8】本開示の実施形態によるオーディオ・コンテンツのコンテンツ解析の別の例を概略的に示す。

【図9】本開示の実施形態によるオーディオ・コンテンツをエンコードする方法のさらに別の例をフローチャートの形で概略的に示す。

【図10】本開示の実施形態によるオーディオ・コンテンツのコンテンツ解析のさらに別の例を概略的に示す。

【図11】本開示の実施形態によるオーディオ・コンテンツをデコードする方法の例をフローチャートの形で概略的に示す。

【図12】本開示の実施形態によるオーディオ・コンテンツをデコードする方法の別の例をフローチャートの形で概略的に示す。

【図13】本開示の実施形態による制御重み計算の例を概略的に示す。

【図14】本開示の実施形態によるオーディオ・コンテンツをデコードする方法の別の例をフローチャートの形で概略的に示す。

【図15】本開示の実施形態によるデコーダにおける制御重みの使用例を概略的に示す。

【図16】本開示の実施形態によるオーディオ・コンテンツをデコードする方法のさらに別の例をフローチャートの形で概略的に示す。

【図17】本開示の実施形態による、デコーダにおける制御重みの使用の別の例を概略的に示す。

【発明を実施するための形態】

【0062】

上述のように、本開示における同一または同様の参照番号は、同一または同様の要素を示し、その繰り返しの説明は、簡潔さの理由から割愛することがある。

【0063】

大まかに言えば、本開示は、コンテンツ解析をオーディオ・デコーダからオーディオ・エンコーダに移転することを提案し、それにより、オーディオ後処理に対するデュアルエンドのアプローチを作り出す。すなわち、コンテンツ解析モジュールの少なくとも一部は、デコーダからエンコーダに移され、オーディオ・ストリーム（ビットストリーム）は、エンコーダ内のコンテンツ解析モジュール（の一部）によって生成される分類情報（たとえば、信頼値、信頼ラベル、または信頼スコア）を運ぶように更新される。重み計算はデコーダに残され、デコーダは、オーディオ・ストリームとともに受領される分類情報に基づいて動作する。

【0064】

上述のスキームを実装するエンコーダ‐デコーダ・システム100の一例が、図1においてブロック図の形で示されている。エンコーダ‐デコーダ・システム100は、（オーディオ）エンコーダ105および（オーディオ）デコーダ115を有する。以下に説明されるエンコーダ105およびデコーダ115のモジュールは、たとえば、それぞれの計算装置のそれぞれのプロセッサによって実装されうることが理解される。

【0065】

エンコーダ105は、コンテンツ解析モジュール120およびマルチプレクサ130を有する。よって、前述のように、コンテンツ解析が今やエンコーダ段の一部である。エンコーダ105は、可能性としては関連するメタデータおよび／またはユーザー入力との関連で、エンコードされるべき入力オーディオ・コンテンツ101を受領する。入力オーディオ・コンテンツ101は、コンテンツ解析モジュール120およびマルチプレクサ130に提供される。コンテンツ解析モジュール120は、オーディオ・コンテンツ101のコンテンツ解析を実行し（たとえば、ドルビーのメディア・インテリジェンス・ツールを適用することによって）、オーディオ・コンテンツについての分類情報125を導出する。分類情報125は、コンテンツ解析によって推定されるように、入力オーディオ・コンテンツ101のコンテンツ型を示す。以下でより詳細に説明されるように、分類情報125は、それぞれのコンテンツ型に関連する一つまたは複数の信頼値（たとえば、「音楽」、「発話」、「背景効果」の信頼値）を含むことができる。いくつかの実施形態では、信頼値は、それよりも高い粒度を有していてもよい。たとえば、分類情報125は、コンテンツ型「音楽」についての信頼値の代わりに、またはそれに加えて、一つまたは複数の音楽ジャンルについての信頼値（たとえば、コンテンツ型「クラシック音楽」、「ロック／ポップ音楽」、「アコースティック音楽」、「電子音楽」などについての信頼値）を含むことができる。いくつかの実施形態では、コンテンツ解析は、さらに、オーディオ・コンテンツについてのメタデータおよび／またはユーザー入力（たとえば、コンテンツ作成者からの制御入力）に基づいてもよい。

【0066】

マルチプレクサ130は、オーディオ・コンテンツおよび分類情報125をビットストリーム110に多重化する。オーディオ・コンテンツは、たとえばAC-4符号化標準に従ってエンコードするなど、既知の音声符号化方法に従ってエンコードされうる。その結果、オーディオ・コンテンツ101および分類情報125はビットストリーム110中にエンコードされると言われてもよく、ビットストリームはオーディオ・コンテンツと、該オーディオ・コンテンツについての関連する分類情報とを含むと言われてもよい。次いで、ビットストリーム110はデコーダ115に提供されてもよい。

【0067】

いくつかの実装では、エンコーダ‐デコーダ・システム100のエンコーダ105におけるコンテンツ解析は、複数の連続する窓のそれぞれについて実行されてもよく、各窓は、所定の数の連続する（オーディオ）フレームを含む。

【0068】

コンテンツ解析は、オーディオ・コンテンツ内の決定可能な特徴に基づいて、それぞれのコンテンツ型の確からしさ／信頼度の一つまたは複数の計算に基づいてもよい。

【0069】

たとえば、コンテンツ解析は、オーディオ・コンテンツの前処理、特徴抽出、および信頼値の計算のステップを含んでいてもよい。前処理は任意的であってもよく、ダウンミックス、再フレーム化、振幅スペクトルの計算などを含んでいてもよい。特徴抽出は、オーディオ・コンテンツから複数の特徴（たとえば、数百の特徴）を抽出／計算してもよい。これらの特徴は、メル周波数ケプストラム係数（Mel-Frequency Cepstral Coefficient、MFCC）、MFCCフラックス、ゼロ交差レート、クロマ、自己相関などを含みうる。最終的に信頼値を与える計算は、たとえば、トレーニングされた機械学習ネットワークによって実行されてもよい。

【0070】

コンテンツ解析のコンテキストにおいて（たとえば、機械学習ネットワークによって）実行される計算は、可変／適応的であってもよい。計算が可変である場合、それらを調整することにより、ある種のコンテンツ型についての選好に従って分類情報を導出することができる。たとえば、（デフォルトの）コンテンツ解析は、所与のオーディオ・コンテンツについて、コンテンツ型「音楽」について0.7の信頼値、コンテンツ型「発話」について0.15の信頼値、コンテンツ型「効果」について0.15の信頼値を返してもよい（この例における信頼値は合計すると1になることに注意）。コンテンツ解析がコンテンツ型「音楽」についていくらかの選好をもつように適応された場合（すなわち、その計算がこの目的に適応されている場合）、適応されたコンテンツ解析／計算は、たとえば、コンテンツ型「音楽」について0.8の信頼値、コンテンツ型「発話」について0.1の信頼値、およびコンテンツ型「効果」について0.1の信頼値を与えてもよい。計算が適応されるさらなる限定しない例が、のちに記載される。

【0071】

さらに、コンテンツ解析（たとえば、機械学習ネットワーク）は、適応的であってもよく、および／またはあらかじめ決定されたオーディオ・コンテンツを使用して事前にトレーニングされていてもよい。たとえば、エンコーダ‐デコーダ・システム100のようなデュアルエンド・システムでは、コンテンツ解析は、特徴ラベル付けの精度を改善するために、経時的にさらに発展させられることができる。進歩は、エンコード・サーバー上の増大した計算能力および／またはコンピュータ・プロセッサ能力の向上を通じてまかなえるようになる増大した複雑さに由来しうる。コンテンツ解析は、特定のコンテンツ型の手動のラベル付けを通じて経時的に改善されてもよい。

【0072】

エンコーダ側のコンテンツ解析は、コンテンツ型決定にかかる待ち時間を減らすために、先読みバッファまたは類似のものを使用してもよい。これは、強力な決定を行なうためにかなり大きなオーディオ・フレームを必要とする、シングルエンドの実装における既知の制限に対処する。たとえば、ダイアログの存在に関する決定を行なうためには、700msのオーディオ・フレームが要求されることがあり、その時点でダイアログの信頼スコアは、発話の開始から700ms遅れており、話された語句の開始が見逃されることがある。追加的または代替的に、コンテンツ解析のために必要とされる処理時間を受け入れるため、エンコード待ち時間が導入されることがある。

【0073】

いくつかの実装では、コンテンツ型決定の精度を改善するために、コンテンツ解析は複数のパス（pass）で実行されてもよい。

【0074】

一般に、分類情報の生成は、オーディオ・コンテンツ内のシーン遷移の検出（またはシーン遷移の手動指示）にも基づいていてもよい。この目的のために、エンコーダ105は、オーディオ・コンテンツ内のそのようなシーン遷移／リセットを検出するための追加のリセット検出器を有していてもよい。コンテンツ解析の信頼値の変化レートに影響を与えるために、手動のラベル付けまたは追加のリセット・シーン検出が使用されてもよい。たとえば、分類情報に含まれる信頼値の変化レートは、シーン遷移が検出／指示される場合（すなわち、定常状態におけるよりも大きい場合）、より高くてもよい。換言すれば、オーディオ・プログラムが変化するとき、信頼値は、オーディオ・プログラムの定常状態におけるよりも速く適応することが許容されてもよい。後処理効果間での可聴な遷移が最小化されることを保証するためである。シーン検出に従って、シーン遷移の指示（たとえば、それぞれがそれぞれのシーン遷移を示す一つまたは複数のリセット・フラグ（シーン遷移フラグ））が、分類情報125（たとえば、信頼値）とともにビットストリーム110にエンコード／多重化されてもよい。

【0075】

エンコーダ‐デコーダ・システム100内のデコーダ115は、デマルチプレクサ160と、重み計算モジュール170と、後処理モジュール180とを有する。デコーダ115によって受領されたビットストリーム110は、デマルチプレクサ160において多重分離され、たとえばAC-4符号化標準に従ったデコードのような既知のオーディオ・デコード方法に従ったデコード後に、分類情報125およびオーディオ・コンテンツが抽出される。結果として、オーディオ・コンテンツおよび分類情報125は、ビットストリーム110からデコードされると言われてもよい。デコードされたオーディオ・コンテンツは、デコードされたオーディオ・コンテンツの後処理を実行する後処理モジュール180に提供される。この目的のために、デコーダ115は、ビットストリーム110から抽出された分類情報125に基づいて、後処理モジュール180のための後処理モードを選択する。より詳細には、ビットストリーム110から抽出された分類情報125は、重み計算モジュール170に提供され、重み計算モジュール170は、分類情報125に基づいて、デコードされたオーディオ・コンテンツの後処理のための一つまたは複数の制御重み175を計算する。各制御重みは、たとえば0から1までの間の数であってもよく、後処理のためのそれぞれのプロセス／モジュール／アルゴリズムの強度を決定してもよい。前記一つまたは複数の制御重み175は、後処理モジュール180に提供される。後処理モジュール180は、デコードされたオーディオ・コンテンツを後処理するために、制御重み175に従って後処理モードを選択／適用することができる。後処理モードを選択することは、いくつかの実施形態では、さらにユーザー入力に基づいていてもよい。選択された後処理モードを使用する、後処理モジュール180によるデコードされたオーディオ・コンテンツの後処理が、デコーダ115によって出力される出力オーディオ信号102を生じうる。

【0076】

計算された一つまたは複数の制御重み175は、後処理モジュール180によって実行される後処理アルゴリズムのための制御重みであってもよく、よって、アルゴリズム操縦重みと称されてもよい。よって、前記一つまたは複数の制御重み175は、後処理モジュール180における後処理アルゴリズムのための操縦を提供することができる。この意味で、制御重み175は、デコードされたオーディオ・コンテンツの後処理のためのそれぞれの（サブ）モジュールのための制御重みであってもよい。たとえば、後処理モジュール180は、（インテリジェント／動的）等化器、（適応）仮想化器、サラウンドプロセッサ、ダイアログ向上器、アップミキサー、および／またはクロスフェーダーなどの一つまたは複数のそれぞれの（サブ）モジュールを含んでいてもよい。制御重み175は、これらの（サブ）モジュールのための制御重みであってもよく、これらの（サブ）モジュールはそれぞれの制御重みの制御の下で動作してもよい。よって、制御重み175は、等化器（たとえばインテリジェント等化器（IEQ））のための制御重み、仮想化器（たとえば適応仮想化器）のための制御重み、サラウンドプロセッサのための制御重み、ダイアログ向上器のための制御重み、アップミキサーのための制御重み、および／またはクロスフェーダーのための制御重みのうちの一つまたは複数を含んでいてもよい。ここで、インテリジェント等化器は、ターゲット・スペクトル・プロファイルを用いて複数の周波数帯域を調整するものと理解される。利得曲線は、インテリジェント等化器が適用されるオーディオ・コンテンツに依存して適応される。

【0077】

エンコーダ105において分類情報125を決定し、それをビットストリーム110の一部としてデコーダ115に提供することは、デコーダ115における計算負荷を削減することができる。さらに、エンコーダのより高い計算能力を利用して、コンテンツ解析をより強力に（たとえば、より正確に）できる。

【0078】

図2は、ビットストリーム110の例示的実装としてAC-4ビットストリームを概略的に示している。ビットストリーム110は複数のフレーム（AC-4フレーム）205を含む。各フレーム205は、同期ワード、フレームワード、生フレーム210（AC-4フレーム）、およびCRCワードを含む。生フレーム210は、目次（table of contents、TOC）フィールドと、TOCフィールドに示されるような複数のサブストリームとを含む。各サブストリームは、オーディオ・データ・フィールド211およびメタデータ・フィールド212を含む。オーディオ・データ・フィールド211はエンコードされたオーディオ・コンテンツを含んでいてもよく、メタデータ・フィールド212は分類情報125を含んでいてもよい。

【0079】

そのようなビットストリーム構造が与えられた場合、分類情報125は、ビットストリームのパケット内の特定のデータ・フィールドにエンコードされうる。図3は、分類情報125を搬送するためのビットストリーム（のフレーム）内のデータ・フィールドの例を概略的に示す。このデータ・フィールドは、MIデータ・フィールドと称されてもよい。データ・フィールドは、複数のサブフィールド310～370を含んでいてもよい。たとえば、データ・フィールドは、分類情報（メディア情報またはメディア・インテリジェンス）がフレームに存在するかどうかを示すb_mi_data_presentフィールド310、コンテンツ型「音楽」についての信頼値を含むmusic_confidenceフィールド320、コンテンツ型「発話」についての信頼値を含むspeech_confidenceフィールド330、コンテンツ型「効果」についての信頼値を含むeffects_confidenceフィールド340、b_prog_switchフィールド350、さらなる分類情報（メディア情報）が存在するかどうかを示すb_more_mi_data_presentフィールド360、およびさらなる分類情報（たとえば、群衆雑音についての信頼値）を含むmore_mi_dataフィールド370のうちの任意のもの、一部または全部を含んでいてもよい。分類情報（たとえば、信頼値）は長期的解析（コンテンツ解析）によって決定されるため、比較的ゆっくりと変化していることがありうる。よって、分類情報は、各パケット／フレームについてエンコードされなくてもよく、たとえば、N≧2としてNフレームのうちの1つにエンコードされるのでもよい。

【0080】

あるいはまた、分類情報125（たとえば、信頼値）は、AC-4ビットストリームの呈示サブストリームにエンコードされてもよい。さらに、ファイルベースのオーディオ・コンテンツの場合、分類情報125（たとえば、信頼値）は各フレームについてエンコードされなくてもよく、ファイル内のすべてのフレームについて有効であるよう、ビットストリームの適切なデータ・フィールドにエンコードされてもよい。

【0081】

図4は、オーディオ・コンテンツをエンコードする方法400の一例を示すフローチャートである。方法400は、たとえば、図1のエンコーダ‐デコーダ・システム100内のエンコーダ105によって実行されてもよい。

【0082】

ステップS410では、オーディオ・コンテンツのコンテンツ解析が実行される。
ステップS420では、オーディオ・コンテンツのコンテンツ型を示す分類情報が、コンテンツ解析（の結果）に基づいて生成される。
ステップS430では、オーディオ・コンテンツおよび分類情報がビットストリームにエンコードされる。
最後に、ステップS440では、ビットストリームが出力される。

【0083】

特に、方法400のステップは、エンコーダ‐デコーダ・システム100について上述した仕方で実行されてもよい。

【0084】

上述のように、分類情報を生成することは、オーディオ・コンテンツにおけるシーン遷移の検出（またはシーン遷移の手動指示）にさらに基づいてもよい。よって、方法400（または後述する方法600、700、または900の任意のもの）は、オーディオ・コンテンツにおけるシーン遷移を検出し（またはオーディオ・コンテンツにおけるシーン遷移の手動指示の入力を受領し）、オーディオ・コンテンツにおけるシーン遷移の指示をビットストリーム中にエンコードすることをさらに含んでいてもよい。

【0085】

次に、図5を参照して、コンテンツ解析（たとえば、エンコーダ105のコンテンツ解析モジュール120によって実行されるコンテンツ解析、または方法400のステップS410で実行されるコンテンツ解析）の詳細を説明する。

【0086】

上述のように、コンテンツ解析は、オーディオ・コンテンツ101のコンテンツ型を示す分類情報125を生成する。本開示のいくつかの実施形態では、分類情報125は、一つまたは複数の信頼値（特徴信頼値、信頼スコア）を含む。これらの信頼値のそれぞれは、それぞれのコンテンツ型に関連付けられ、オーディオ・コンテンツが該それぞれのコンテンツ型である確からしさの指示を与える。これらのコンテンツ型は、音楽コンテンツ、発話コンテンツ、および効果（たとえば、背景効果）コンテンツのうちの一つまたは複数を含むことができる。いくつかの実装では、コンテンツ型は、群衆ノイズコンテンツ（たとえば歓声）をさらに含むことができる。すなわち、分類情報125は、オーディオ・コンテンツがコンテンツ型「音楽」である信頼度（確からしさ）を示す音楽信頼値、オーディオ・コンテンツ101がコンテンツ型「発話」である信頼度（確からしさ）を示す発話信頼値、およびオーディオ・コンテンツ101がコンテンツ型「効果」である信頼度（確からしさ）を示す効果信頼値、また可能性としては、オーディオ・コンテンツ101がコンテンツ型「群衆ノイズ」であることの信頼度（確からしさ）を示す群衆ノイズ信頼値のうちの一つまたは複数を含むことができる。

【0087】

以下では、信頼値が0から1の範囲にはいるように正規化されているとする。ここで、0は、オーディオ・コンテンツがそのそれぞれのコンテンツ型のものである可能性がゼロ（0%）であることを示し、1は、オーディオ・コンテンツがそのそれぞれの可能性のものであることの確実性（完全な確からしさ、100%）を示す。値「0」は、可能性がゼロであることを示す信頼値の値についての限定しない例であり、値「1」は、完全な確からしさを示す信頼値の値についての限定しない例であることが理解される。

【0088】

図5の例では、オーディオ・コンテンツ101のコンテンツ解析は、（生）音楽信頼値125a、（生）発話信頼値125b、および（生）効果信頼値125cを返す。原理的には、これらの生の信頼値125a、125b、125cが直接、分類情報125（の一部）としてビットストリーム110にエンコードされるために使用されることもできる。あるいはまた、分類情報125（すなわち、生の信頼値125a、125b、125c）は、エンコードの前に平滑化（たとえば、時間平滑化）にかけられて、実質的に連続的な信頼値を得ることができる。これは、それぞれ平滑化された信頼値145a、145b、145cを出力するそれぞれの平滑化モジュール140a、140b、140cによって行なうことができる。そこでは、異なる平滑化モジュールは、たとえば、平滑化のために異なるパラメータ／係数を使用して、異なる平滑化を適用することができる。

【0089】

上記に沿って、方法400（または以下に記載される方法600、700、または900の任意のもの）は、多重化／エンコードの前に、分類情報（たとえば、信頼値）を平滑化することをさらに含んでいてもよい。

【0090】

分類情報（たとえば、信頼値）の平滑化は、ある種の状況下では、たとえば平滑化がシーン遷移をまたいで実行される場合、可聴な歪みを生じる可能性がある。よって、平滑化は、状況に依存して、たとえばシーン遷移においては、無効にされてもよい。さらに、以下により詳細に説明されるように、平滑化は、動的（非静的）オーディオ・コンテンツについて、または制御入力またはメタデータに従って、無効化されてもよい。

【0091】

平滑化された音楽信頼値145a、平滑化された発話信頼値145b、および平滑化された効果信頼値145cは、いくつかの実装では、さらに、エンコードする前に量子化されることができる。これは、それぞれ量子化された信頼値155a、155b、155cを出力するそれぞれの量子化器150a、150b、150cで行なうことができる。そこでは、異なる量子化器は、たとえば量子化のために異なるパラメータを使用する、異なる量子化を適用してもよい。

【0092】

上記に沿って、方法400（または以下に記載される方法600、700、または900の任意のもの）は、多重化／エンコードの前に、分類情報（たとえば、信頼値）を量子化することをさらに含んでいてもよい。

【0093】

分類情報125の平滑化は、デコーダにおける後処理の改善された連続性および安定性、よって聴取経験をもたらすことができる。分類情報125を量子化することにより、ビットストリーム110の帯域幅効率を改善することができる。

【0094】

上述したように、エンコーダ105において分類情報125を決定し、それをビットストリーム110の一部としてデコーダ115に提供することは、計算能力の観点から有利でありうる。加えて、そうすることは、オーディオ・ストリームにおいて伝送される信頼値をある種の所望の値に設定することによって、デコーダ側のオーディオ後処理に対する、いくらかのエンコーダ側の制御を許容しうる。たとえば、分類情報を（少なくとも部分的に）エンコーダ側でのユーザー入力に依存するようにすることによって、エンコーダ側のユーザー（たとえば、コンテンツ作成者）は、デコーダ側でのオーディオ後処理に対する制御を与えられることができる。次に、デコーダ側のオーディオ後処理に対するエンコーダ側の追加的な制御を許容するいくつかの例示的な実装について説明する。

【0095】

図6は、ユーザー入力に基づく、デコーダ側のオーディオ後処理のこのようなエンコーダ側制御を許容する、オーディオ・コンテンツをエンコードする方法600の一例をフローチャートの形で概略的に示している。方法600は、たとえば、図1のエンコーダ‐デコーダ・システム100内のエンコーダ105によって実行されてもよい。

【0096】

ステップS610では、ユーザー入力が受領される。ユーザーは、たとえば、コンテンツ作成者であってもよい。ユーザー入力は、オーディオ・コンテンツを、ある種のコンテンツ型に関連するものとしてラベル付けするための手動ラベルを含むことができ、あるいは、たとえば手動の信頼値に関連することができる。

【0097】

ステップS620では、少なくとも部分的にはユーザー入力に基づいて、オーディオ・コンテンツのコンテンツ型を示す分類情報が生成される。たとえば、手動ラベルおよび／または手動信頼値が直接、分類情報として使用できる。オーディオ・コンテンツがある種のコンテンツ型のものとして手動でラベル付けされている場合、そのある種のコンテンツ型についての信頼値は1に設定でき（信頼値が0から1までの間の値をもつとする）、他の信頼値はゼロに設定できる。この場合、コンテンツ解析はバイパスされるであろう。代替的な実装では、コンテンツ解析の出力は、ユーザー入力と一緒に、分類情報を導出するために使用できる。たとえば、最終的な信頼値は、コンテンツ解析において生成された信頼値および手動の信頼値に基づいて計算できる。これは、これらの信頼値を平均すること、または他の任意の好適な組み合わせによって行なってもよい。

【0098】

ステップS630では、オーディオ・コンテンツおよび分類情報がビットストリーム中にエンコードされる。

【0099】

最後に、ステップS640で、ビットストリームが出力される。

【0100】

エンコーダ側でのコンテンツ分類決定を、少なくとも部分的にはオーディオ・コンテンツに関連するメタデータに依存させることによって、追加的なエンコーダ側制御が達成できる。そのようなエンコーダ側処理の2つの例を以下に説明する。第1の例を、図7および図8を参照して説明する。第1の例では、前記オーディオ・コンテンツは、オーディオ・コンテンツのストリーム（たとえば、線形の連続的なストリーム）において、オーディオ・プログラムの一部として、提供される。オーディオ・コンテンツについてのメタデータは、少なくとも、オーディオ・コンテンツの（すなわち、オーディオ・プログラムの）サービス型の指示を含む。よって、サービス型は、オーディオ・プログラム型と称されることもある。サービス型の例は、音楽サービス（たとえば、音楽ストリーミング・サービスまたは音楽放送など）またはニュース（ニュースキャスト）サービス（たとえば、ニュースチャネルのオーディオ成分など）を含みうる。サービス型指示は、フレームベースで提供されてもよく、あるいはオーディオ・ストリームについて同じ（均一／静的）であってもよい。第2の例を、図9および図10を参照して説明する。第2の例では、オーディオ・コンテンツはファイルベースで提供される。各ファイルは、それぞれのオーディオ・コンテンツについてのメタデータを含んでいてもよい。メタデータは、そのファイル（のオーディオ・コンテンツ）のファイル・コンテンツ型を含んでいてもよい。メタデータは、マーカー、ラベル、タグなどをさらに含んでいてもよい。ファイル・コンテンツ型の例は、ファイルが音楽ファイルであることの指示、ファイルがニュース／ニュースキャスト・ファイル（ニュース・クリップ）であることの指示、ファイルが動的（非静的）コンテンツ（たとえば、発話のあるシーンと音楽／歌シーンの間で頻繁に遷移する映画のミュージカル・ジャンルなど）を含むことの指示を含んでいてもよい。ファイル・コンテンツ型は、ファイル全体について同じ（一様／静的）であってもよいし、あるいはファイルの部分間で変化してもよい。第2の例における処理は、ファイルベースであってもよい。ファイル・コンテンツ型を示すメタデータによるファイルの「タグ付け」は、分類情報を導出することにおいてエンコーダを支援すると言える（デコーダ側でのオーディオ後処理に対する追加的な制御をエンコーダ側に提供することに加えて）。

【0101】

ここで、図7を参照する。図7は、オーディオ・プログラムの一部としてオーディオ・コンテンツのストリーム内に提供されるオーディオ・コンテンツをエンコードする方法700をフローチャートの形で示している。この方法700は、分類情報を導出する際にオーディオ・コンテンツのメタデータを考慮に入れる。方法700は、たとえば、図1のエンコーダ‐デコーダ・システム100内のエンコーダ105によって実行されてもよい。

【0102】

ステップS710では、サービス型指示が受領される。上述のように、サービス型指示は、オーディオ・コンテンツのサービス型を示す。
ステップS720では、少なくとも部分的にはサービス型指示に基づいて、オーディオ・コンテンツのコンテンツ解析が実行される。そのようなコンテンツ解析の限定しない例は、図8を参照して以下に記載される。
ステップS730では、オーディオ・コンテンツのコンテンツ型を示す分類情報が、コンテンツ解析（の結果）に基づいて生成される。
ステップS740では、オーディオ・コンテンツおよび分類情報がビットストリーム中にエンコードされる。
最後に、ステップS750で、ビットストリームが出力される。

【0103】

図8は、方法700のステップS720におけるオーディオ・コンテンツのコンテンツ解析の例を概略的に示す。図8の上段810は、音楽サービスの例、すなわち、オーディオ・コンテンツがサービス型「音楽サービス」であることを示すサービス型指示に関するものであり、この場合、「音楽」についての信頼値が1に設定されてもよく、他のコンテンツ型（たとえば、「発話」、「効果」、および、可能性としては「群衆ノイズ」）についての信頼値は0に設定される。すなわち、コンテンツ型「音楽」は分類情報にハードコード化されてもよい。このように、方法700は、サービス型指示に基づいて、オーディオ・コンテンツのサービス型が音楽サービスであるかどうかを判定することを含んでいてもよい。次いで、オーディオ・コンテンツのサービス型が音楽サービスであるとの判定に応答して、分類情報は、オーディオ・コンテンツのコンテンツ型が音楽コンテンツであることを示すように生成されてもよい。

【0104】

図8の下段820は、ニュースサービス、すなわちオーディオ・コンテンツがサービス型「ニュースサービス」（またはニュースキャスト・サービス、ニュースチャネル）であることを示すサービス型指示の例に関する。この場合、コンテンツ解析において用いられる計算は、発話についての明確な選好があり、たとえば音楽についてはより少ない選好があるように適応される（たとえば、コンテンツ解析によって与えられる発話コンテンツ（コンテンツ型「発話」）についての信頼値が増加させられてもよく、音楽コンテンツ（コンテンツ型「音楽」）および可能性としては任意の残りのコンテンツ型についての信頼値が減少させられてもよい）。換言すれば、計算の適応により、コンテンツ型「音楽」という誤った指示の可能性が低減される。このように、方法700は、サービス型指示に基づいて、オーディオ・コンテンツのサービス型がニュースキャスト・サービスであるかどうかを判定することを含んでいてもよい。次いで、オーディオ・コンテンツのサービス型がニュースキャスト・サービスであるという判定に応答して、ステップS720におけるコンテンツ解析は、オーディオ・コンテンツが発話コンテンツであることを示す、より高い可能性を有するように適応されうる。さらに、ステップS720におけるコンテンツ解析は、オーディオ・コンテンツが他の任意のコンテンツ型であることを示す、より低い可能性をもつように適応されてもよい。

【0105】

いくつかの実装では、オーディオ・コンテンツについての一つまたは複数の信頼値は、（たとえば、コンテンツ作成者による）ユーザー入力によって、またはメタデータの一部として、直接提供されることができる。次いで、これらの信頼値が考慮されるかどうかは、サービス型指示に依存してもよい。たとえば、ユーザー入力またはメタデータによって提供される信頼値は、オーディオ・コンテンツのサービス型がある型のものである場合（かつその場合にのみ）、分類情報としてエンコードするために使用できる。いくつかの代替的な実装では、ユーザー入力またはメタデータによって提供される信頼値は、オーディオ・コンテンツのサービス型がある型でない限り、分類情報の一部として使用できる。たとえば、サービス型指示がオーディオ・コンテンツのサービス型が音楽サービスであることを示すのでない限り、ユーザー入力またはメタデータによって提供される信頼値が使用できる。サービス型指示がオーディオ・コンテンツのサービス型が音楽サービスであることを示す場合には、音楽コンテンツについての信頼値は、ユーザー入力またはメタデータによって提供される信頼値にかかわらず、1に設定されてもよい。

【0106】

ここで、図9を参照する。図9は、ファイルベースで提供されるオーディオ・コンテンツをエンコードする方法900をフローチャートの形で示す。よって、方法900は、ファイルベースで実行されてもよい。この方法900は、分類情報を導出する際にオーディオ・コンテンツのファイル・メタデータを考慮に入れる。方法900は、たとえば、図1のエンコーダ‐デコーダ・システム100内のエンコーダ105によって実行されてもよい。

【0107】

ステップS910では、オーディオ・コンテンツのコンテンツ解析が、少なくとも部分的にはオーディオ・コンテンツについての（ファイル）メタデータに基づいて実行される。たとえば、メタデータは、ファイルのファイル・コンテンツ型を示すファイル・コンテンツ型指示を含むことができる。次いで、コンテンツ解析は、少なくとも部分的にはファイル・コンテンツ型指示に基づいてもよい。ファイルのコンテンツ型に少なくとも部分的に基づいたそのようなコンテンツ解析の限定しない例は、図10を参照して以下に記載される。

【0108】

ステップS920では、オーディオ・コンテンツのコンテンツ型を示す分類情報が、コンテンツ解析（の結果）に基づいて生成される。

【0109】

ステップS930では、オーディオ・コンテンツおよび分類情報がビットストリーム中にエンコードされる。

【0110】

最後に、ステップS940で、ビットストリームが出力される。

【0111】

図10は、方法900のステップS910におけるオーディオ・コンテンツのコンテンツ解析の例を概略的に示す。図10の上段1010は、音楽ファイルの例、すなわち、ファイル・コンテンツがファイル・コンテンツ型「音楽」であることを示すファイル・コンテンツ型指示に関するものであり、この場合、コンテンツ型「音楽」は分類情報にハードコードされてもよい。さらに、分類情報は、ファイル全体について一様（静的）であってもよい。よって、方法900は、ファイル・コンテンツ型指示に基づいて、ファイルのファイル・コンテンツ型が音楽ファイルであるかどうかを判定することをさらに含んでいてもよい。次いで、ファイルのファイル・コンテンツ型が音楽ファイルであるとの判定に応答して、分類情報は、オーディオ・コンテンツのコンテンツ型が音楽コンテンツであることを示すよう、生成されうる。

【0112】

図10の中段1020は、ニュース・ファイルの例、すなわち、ファイル・コンテンツがファイル・コンテンツ型「ニュース」であることを示すファイル・コンテンツ型指示に関する。この場合、方法900は、ファイル・コンテンツ型指示に基づいて、ファイルのファイル・コンテンツ型がニュースキャスト・ファイルであるかどうかを判定することをさらに含んでいてもよい。次いで、ファイルのファイル・コンテンツ型がニュースキャスト・ファイルであるという判定に応答して、コンテンツ解析は、オーディオ・コンテンツが発話コンテンツであることを示す、より高い可能性をもつように適応されてもよい。これは、コンテンツ解析における発話コンテンツについての確からしさ／信頼度を高めるよう、コンテンツ解析の一つまたは複数の計算（計算アルゴリズム）を適応することによって、および／または、発話コンテンツ以外のコンテンツ型についての確からしさ／信頼度を下げるよう、前記一つまたは複数の計算を適応することによって達成されてもよい。ここでもまた、分類情報は、ファイル全体について一様（静的）にされてもよい。

【0113】

図10の下段1030は、動的（非静的）ファイルの例（たとえば、発話のあるシーンと音楽／歌シーンとの間で頻繁に遷移する映画のミュージカル・ジャンル）、すなわち、ファイル・コンテンツがファイル・コンテンツ型「動的」であることを示すファイル・コンテンツ型指示に関する。この場合、方法900は、ファイルのファイル・コンテンツ型指示に基づいて、ファイルのファイル・コンテンツ型が動的コンテンツ（すなわち、動的なファイル・コンテンツ）であるかどうかを判定することをさらに含んでいてもよい。次いで、ファイルのファイル・コンテンツ型が動的コンテンツ（すなわち、動的なファイル・コンテンツ）であるとの判定に応答して、コンテンツ解析は、異なるコンテンツ型間のより高い遷移レートを許容するように適応されてもよい。たとえば、コンテンツ型は、コンテンツ型間で、たとえば、音楽と非音楽の間で、より頻繁に（すなわち、定常状態についてよりも頻繁に）遷移することが許容されうる。よって、分類情報は、たとえばファイルの音楽セクションと非音楽セクションとの間で切り換わることが許容されうる。図10の最初の2段1010および1020とは異なり、これは、分類情報がファイル全体について均一（静的）に保たれないことを意味する。

【0114】

また、動的コンテンツ（すなわち、動的ファイル・コンテンツ）は、ファイル内の異なるコンテンツ型のセクション間でシャープな遷移を有することができることも理解される。たとえば、音楽セクションと非音楽セクションとの間には、シャープな遷移が存在しうる。そのような場合、分類情報（たとえば、信頼値）に対して時間平滑化を適用することは意味をなさないことがありうる。いくつかの実装では、よって、分類情報の平滑化（時間平滑化）は、動的コンテンツ（すなわち、動的ファイル・コンテンツ）については無効にされてもよい。

【0115】

次に、オーディオ・コンテンツおよび該オーディオ・コンテンツについての分類情報を含むビットストリームからのオーディオ・コンテンツのデコードに関する実施形態および実装について説明する。分類情報は、オーディオ・コンテンツのコンテンツ分類（コンテンツ型に関する）を示すことが理解される。また、コンテンツ分類は、エンコーダ側で実行されたコンテンツ解析に基づいてもよいことも理解される。

【0116】

図11は、ビットストリームからオーディオ・コンテンツをデコードする一般的な方法1100をフローチャートの形で示す。方法1100は、たとえば、図1のエンコーダ‐デコーダ・システム100内のデコーダ115によって実行されてもよい。

【0117】

ステップS1110では、ビットストリームは、たとえば無線または有線伝送によって、またはビットストリームを記憶する記憶媒体を介して、受領される。
ステップS1120では、オーディオ・コンテンツおよび分類情報がビットストリームからデコードされる。
ステップS1130では、デコードされたオーディオ・コンテンツの（オーディオ）後処理を実行するための後処理モードが、ステップS1120で得られた分類情報に基づいて選択される。いくつかの実装では、後処理モードの選択は、さらにユーザー入力に基づくことができる。

【0118】

さらに、方法1100は、（たとえば、エンコーダ側によって考慮されていないコンテンツ型について）一つまたは複数の追加の信頼値を決定するために、オーディオ・コンテンツのコンテンツ解析を実行することをさらに含んでいてもよい。このコンテンツ解析は、方法400におけるステップS410を参照して上述したのと同じ仕方で進行してもよい。次いで、後処理モードの選択は、さらに該一つまたは複数の追加の信頼値に基づいてもよい。たとえば、デコーダが（レガシー）エンコーダによって考慮されていなかったコンテンツ型についての検出器を含む場合、デコーダは、このコンテンツ型についての信頼値を計算し、後処理モードを選択するために、この信頼値を、分類情報において伝送される任意の信頼値と一緒に使用することができる。

【0119】

図1のコンテキストにおいて上述したように、後処理は、たとえば、（インテリジェント／動的）等化器、（適応）仮想化器、サラウンドプロセッサ、ダイアログ向上器、アップミキサー、またはクロスフェーダーを実装するそれぞれのアルゴリズムのような後処理アルゴリズムを使用して実行されてもよい。よって、後処理を実行するためのモードを選択することは、後処理のためのそれぞれのプロセス／モジュール／アルゴリズムについての一つまたは複数の制御重み（操縦重み、アルゴリズム操縦重み、アルゴリズム制御重み）を決定すること（たとえば、計算すること）に対応すると言える。

【0120】

対応する方法1200は、図12のフローチャートによって示される。ここでもまた、この方法1200は、たとえば、図1のエンコーダ‐デコーダ・システム100内のデコーダ115によって実行されてもよい。ステップS1210およびステップS1220は、それぞれ、方法1100のステップS1110およびステップS1120と同一である。

【0121】

ステップS1230では、ステップS1220で得られた分類情報に基づいて、デコードされたオーディオ・コンテンツの後処理のための一つまたは複数の制御重みが決定される（たとえば、計算される）。

【0122】

制御重み（操縦重み）の代わりに信頼値を送信すること、すなわち、重み計算モジュールをエンコーダに移す代わりにデコーダに残すことは、デコーダにおける計算資源の節約を可能にするだけでなく、重み計算がパーソナル化できる、カスタマイズ可能で柔軟なデコーダを可能にすることもできる。たとえば、重み計算は、装置型および／またはユーザーの個人的な選好に依存することができる。これは、デコードされたオーディオ・コンテンツについてどのオーディオ後処理が実行されるべきかについての具体的な命令をデコーダがエンコーダから受け取る従来のアプローチとは対照的である。

【0123】

すなわち、オーディオ後処理の要件は、デコードされたオーディオ・コンテンツが再生される装置の装置型に依存することがある。たとえば、2つだけのスピーカーをもつモバイル装置（たとえば、携帯電話）のスピーカーによるデコードされたオーディオ・コンテンツの再生は、5つ以上のスピーカーをもつサウンドバー装置によるデコードされたオーディオ・コンテンツの再生とは異なるオーディオ後処理を要求することがある。よって、いくつかの実装では、制御重みの計算は、デコードを実行する装置の装置型に依存する。言い換えれば、計算は、エンドポイントに固有であってもよいし、パーソナル化されていてもよい。たとえば、デコーダ側は、後処理のための一組のエンドポイント固有のプロセス／モジュール／アルゴリズムを実装してもよく、これらのプロセス／モジュール／アルゴリズムのためのパラメータ（制御重み）は、エンドポイント固有の仕方で信頼値に基づいて決定されてもよい。

【0124】

さらに、異なるユーザーは、オーディオ後処理について異なる選好をもつ可能性がある。たとえば、発話は、典型的には仮想化されないが、ユーザーの選好に基づいて、発話の多いオーディオ・コンテンツを仮想化することを決定することができる（すなわち、ユーザーが望むならば、仮想化が発話に適用されてもよい）。別の例として、パーソナルコンピュータでのオーディオ再生については、典型的には、ステレオ拡張、アップミックス、および仮想化はない。しかしながら、ユーザーの選好に依存して、ステレオ拡張、アップミックス、および／または仮想化がこの場合に適用されてもよい（すなわち、ユーザーが望むならば、ステレオ拡張、アップミックス、および／または仮想化がPCユーザーのために適用されてもよい）。よって、いくつかの実装では、制御重みの計算は、さらに、ユーザー選好またはユーザー入力（たとえば、ユーザー選好を示すユーザー入力）に基づく。よって、ユーザー入力は、分類情報ベースの計算をオーバーライドする、または部分的にオーバーライドすることができる。

【0125】

分類情報が、それぞれがそれぞれのコンテンツ型に関連付けられた信頼値（信頼スコア）を含み、上述のように、オーディオ・コンテンツがそれぞれのコンテンツ型である確からしさの指標を与える場合、制御重みは、これらの信頼値に基づいて計算されうる。そのような計算の限定しない例はのちに記載される。

【0126】

さらに、方法1200は、（たとえば、エンコーダ側によって考慮されていないコンテンツ型についての）一つまたは複数の追加の信頼値を決定するために、オーディオ・コンテンツのコンテンツ解析を実行することをさらに含んでいてもよい。このコンテンツ解析は、方法400のステップS410を参照して上述したのと同じ仕方で進行してもよい。次いで、制御重みモードの計算は、前記一つまたは複数の追加の信頼値にさらに基づいてもよい。たとえば、デコーダが、（レガシー）エンコーダによって考慮されていなかったコンテンツ型についての検出器を有する場合、デコーダは、このコンテンツ型についての信頼値を計算し、この信頼値を、制御重みを計算するために、分類情報において伝送される任意の信頼値と一緒に、使用することができる。

【0127】

上述のように、信頼値は、エンコードされるコンテンツを正確かつ安定的に反映するために、デュアルエンドのエンコーダ‐デコーダ・システムにおいてエンコーダ側で平滑化されてもよい。代替的または追加的に、デコーダ側での重み計算は、制御重み（アルゴリズム操縦重み）を決定する際に、さらなる平滑化を提供してもよい。それにより、各後処理アルゴリズムが、可聴な歪みを回避するよう、適切なレベルの連続性を有することが保証できる。たとえば、仮想化器は、空間的像における望ましくない変動を避けるためにゆっくりとした変化を望ことがあるが、一方、ダイアログ向上器は、ダイアログ・フレームには反応されるが非ダイアログ・フレームは任意の誤ったダイアログ向上を最小化することを保証するために速い変化を望むことがありうる。よって、方法1200は、制御重みを平滑化（時間平滑化）するステップをさらに含んでいてもよい。

【0128】

平滑化は、デコードを実行する装置の装置型に依存してもよい。たとえば、モバイル装置（たとえば、携帯電話）のための仮想化器制御重みと、TVセットまたはサウンドバー装置のための仮想化器制御重みとの間には、異なる平滑化が存在しうる。そこでは、平滑化は、平滑化を決定する一組の平滑係数、たとえば平滑化の時定数に関して異なる場合がある。

【0129】

さらに、平滑化は、平滑化される特定の制御重みにも依存しうる。すなわち、平滑化は、少なくとも2つの制御重みの間で異なることがある。たとえば、ダイアログ向上器制御重みについての平滑化は全くまたはほとんどない、および／または仮想化器制御重みについてのより強力な平滑化があることがありうる。

【0130】

最後に、状況によっては平滑化が無効化されてもよいことを注意しておく。上述のように、平滑化は、動的（非静的）としてフラグ付けされたオーディオ・コンテンツについて、あるいはシーン遷移においては、逆効果になることがある。また、制御入力および／またはメタデータに従って平滑化が無効にされてもよい。

【0131】

制御重みの（よってオーディオ後処理の）連続性／安定性を改善するための別のアプローチは、制御重みに非線形マッピングΦを適用することである。制御重みの値は、0から1の範囲であってもよい。非線形マッピングΦは、写像Φ:[0,1]→[0,1]であってもよい。好ましくは、非線形マッピングΦは、制御重みの値範囲（すなわち、[0,1]のような定義域範囲）の境界に近い制御値の値を、マッピングされた値の値範囲（すなわち、[0,1]のような像範囲）のそれぞれの境界に、より近くマッピングする。すなわち、Φは、値0＋ε（ε≪1）を0に近づけるようにマッピングしてもよく、すなわちΦ(0＋ε)＜(0＋ε)であり、値1－εを1に近づけるようにマッピングしてもよく、すなわちΦ(1－ε)＞(1－ε)である。そのような非線形マッピングΦの例は、シグモイド関数である。

【0132】

図13は、上述の考察に従って動作する重み計算モジュール170の例を概略的に示す。以下に説明される重み計算モジュール170は、たとえば、計算装置のプロセッサによって実装されてもよいことが理解される。

【0133】

限定を意図することなく、この実施例の重み計算モジュール170は、インテリジェント／動的等化器のための制御重みおよび仮想化器のための制御重みを決定する。他の制御重みも重み計算モジュール170によって計算されてもよいことが理解される。

【0134】

重み計算モジュール170は、入力として信頼値（すなわち、分類情報125）を受領する。信頼値に基づいて、インテリジェント／動的等化器のための制御重みがブロック1310で計算される。等化は発話の音色を変化させる可能性があり、よって、典型的には、発話については望ましくないので、いくつかの実装では、分類情報（たとえば、信頼値）が、デコードされたオーディオ・コンテンツのコンテンツ型が発話である、または発話である可能性が高いことを示す場合（たとえば、発話信頼値がある閾値を上回る場合）には、等化が無効にされるよう、インテリジェント／動的等化器についての制御重み（等化器制御重み）が計算されうる。任意的に、ブロック1330において、等化器制御重みは平滑化されてもよい。平滑化は、等化器制御重みの平滑化に固有でありうる等化器制御重み平滑係数1335に依存してもよい。最終的に、（平滑化された）等化器制御重み175aが重み計算モジュール170によって出力される。

【0135】

信頼値は、ブロック1320において、仮想化器のための制御重み（仮想化器制御重み）を計算するためにも使用される。仮想化は、音楽的な音色を変化させる可能性があり、よって、典型的には、音楽については望ましくないので、いくつかの実装では、分類情報（たとえば、信頼値）が、デコードされたオーディオ・コンテンツのコンテンツ型が音楽である、または音楽である可能性が高いことを示す場合（たとえば、音楽信頼値がある閾値を超えている場合）は仮想化（スピーカー仮想化）が無効にされるように、仮想化器のための制御重みが計算されてもよい。また、仮想化器のための制御重みは、仮想化器の係数が素通し（処理なし）と完全な仮想化との間でスケールするように計算されてもよい。一例として、仮想化器の制御重みは、音楽信頼値music_confidence、発話信頼値speech_confidence、および効果信頼値effect_confidenceに基づいて、
1－music_confidence*{1－max[effects_confidence,speech_confidence]^2} (式1)
により計算されうる。

【0136】

任意的に、仮想化器制御重みはブロック1340で平滑化されてもよい。平滑化は、仮想化器制御重みの平滑化に固有であってもよい仮想化器制御重み平滑係数1345に依存してもよい。

【0137】

さらに、任意的に、仮想化器制御重みの安定性／連続性を改善するために、ブロック1350において、（平滑化された）仮想化器制御重みは、たとえばシグモイド関数によって増幅されてもよい。それにより、後処理されたオーディオ・コンテンツのレンダリングされた表現における可聴アーチファクトを低減することができる。増幅は、上述の非線形マッピングに従って進行してもよい。

【0138】

最終的に、（平滑化および／または増幅された）仮想化器制御重み175bが、重み計算モジュール170によって出力される。

【0139】

信頼値は、ダイアログ向上器のための制御重み（ダイアログ向上器制御重み；図示せず）を計算するためにも使用できる。ダイアログ向上器は、周波数領域において、ダイアログを含む時間‐周波数タイルを検出してもよい。そして、これらの時間‐周波数タイルが選択的に向上されることができ、それによりダイアログを強調することができる。ダイアログ向上器の主な目的は、ダイアログを強調することであり、ダイアログ向上をダイアログのないコンテンツに適用することは、よくて、計算資源の無駄であるため、分類情報が、オーディオ・コンテンツのコンテンツ型が発話である、または発話である可能性が高いことを示す場合（かつ、その場合にのみ）、ダイアログ向上器によるダイアログ向上が有効にされるように、ダイアログ向上器制御重みが計算されてもよい。これは、たとえば、発話についての信頼値が所与の閾値を超える場合に当てはまりうる。等化器制御重みおよび仮想化器制御重みについてと同様に、ダイアログ向上器制御重みも平滑化および／または増幅の対象となりうる。

【0140】

さらに、信頼値は、サラウンドプロセッサ（サラウンドプロセッサ制御重み；図示せず）、アップミキサー、および／またはクロスフェーダーのための制御重みを計算するために使用できる。

【0141】

図14は、本開示の実施形態による、2つのスピーカーをもつモバイル装置（たとえば、携帯電話）による再生のための2チャネル（たとえばステレオ）オーディオ・コンテンツの特殊な場合における、ビットストリームからオーディオ・コンテンツをデコードする方法1400をフローチャートの形で示す。ビットストリームは、分類情報または2チャネル・オーディオ・コンテンツを含み、分類情報は、2チャネル・オーディオ・コンテンツの（たとえば、コンテンツ型に関する）コンテンツ分類を示すことが理解される。方法1400は、2つのスピーカーをもつモバイル装置のデコーダによって実行されてもよい。このデコーダは、図1のエンコーダ‐デコーダ・システム100におけるデコーダ115と同じ基本構成を有してもよく、たとえば、重み計算および後処理の具体的な実装を備えていてもよい。

【0142】

ステップS1410では、AC-4ビットストリームが受領される。
ステップS1420では、2チャネル・オーディオ・コンテンツおよび分類情報が、ビットストリームからデコード／多重分離される。
ステップS1430では、ステップS1420でデコードされた2チャネル・オーディオ・コンテンツはアップミックスされて、アップミックスされた5.1チャネル・オーディオ・コンテンツにされる。
ステップS1440では、2チャネルのスピーカー・アレイのための5.1仮想化のために、アップミックスされた5.1チャネル・オーディオ・コンテンツに対して仮想化器が適用される。仮想化器は、それぞれの制御重みの制御の下で動作する。仮想化器のための制御重みは、分類情報（たとえば、信頼値）に基づいて計算される。これは、たとえば、図13を参照して上述した仕方で行なうことができる。
ステップS1450では、クロスフェーダーが、2チャネル・オーディオ・コンテンツおよび仮想化されたアップミックスされた5.1チャネル・オーディオ・コンテンツに適用される。クロスフェーダーは、それぞれの制御重みの制御の下で動作する。クロスフェーダーのための制御重みは、分類情報（たとえば信頼値）に基づいて計算される。
最後に、ステップS1460では、クロスフェーダーの出力は、2チャネル・スピーカー・アレイにルーティングされる。

【0143】

図15は、本開示の実施形態による、方法1400を実行しうる2スピーカー・モバイル装置1505のデコーダ1500の例を概略的に示す。以下に説明されるデコーダ1500のモジュールは、たとえば、計算装置のプロセッサによって実装されてもよいことが理解される。

【0144】

デコーダ1500は、ビットストリーム110（たとえば、AC-4ビットストリーム）を受領し、次いで、該ビットストリームはAC-4（モバイル）デコーダ・モジュール1510によってデコード／多重分離される。AC-4（モバイル）デコーダ・モジュール1510は、デコードされた2チャネル・オーディオ・コンテンツ1515およびデコードされた分類情報125を出力する。デコードされた分類情報125は、分類情報125（たとえば、信頼値）に基づいてクロスフェード制御重み1575を計算する仮想化器クロスフェード重み計算モジュール1570に提供される。クロスフェード制御重み1575は、クロスフェード・モジュール1540によって組み合わされる2つの信号の相対重みを決定するパラメータであってもよい。デコードされた2チャネル・オーディオ・コンテンツ1515は、アップミックス・モジュール1520によって2.0チャネルから5.1チャネルにアップミックスされ、該アップミックス・モジュールは、アップミックスされた5.1チャネル・オーディオ・コンテンツ1525を出力する。次いで、ステレオスピーカーのための5.1仮想化が、仮想化モジュール（仮想化器）1530によって、アップミックスされた5.1チャネル・オーディオ・コンテンツ1525に適用される。仮想化モジュールは、仮想化されたアップミックスされた5.1チャネル・オーディオ・コンテンツ1535を出力し、それは、クロスフェード・モジュール1540によってもとのデコードされた2チャネル・オーディオ・コンテンツと組み合わされる。クロスフェード・モジュール1540は、クロスフェード制御重み1575の制御の下で動作し、最終的に、後処理された2チャネル・オーディオ・コンテンツ102を、モバイル装置1505のスピーカーにルーティングするために出力する。

【0145】

図には示されていないが、デコーダ1500は、分類情報125（たとえば、信頼値）に基づいて、仮想化モジュール1530のための仮想化器制御重みを計算するためのモジュールをも含んでいてもよい。さらに、デコーダ1500は、分類情報125（たとえば、信頼値）に基づいて、アップミックス・モジュール1520のためのアップミックス制御重みを計算するためのモジュールを含んでいてもよい。

【0146】

図16は、本開示の実施形態による、たとえばサウンドバー装置の5（またはそれ以上）スピーカー・アレイによる再生のための、2チャネル（たとえばステレオ）のオーディオ・コンテンツの特殊な場合における、ビットストリームからオーディオ・コンテンツをデコードする方法1600をフローチャートの形で示す。ここでも、ビットストリームは、分類情報または2チャネル・オーディオ・コンテンツを含み、分類情報は、2チャネル・オーディオ・コンテンツの（たとえばコンテンツ型に関する）コンテンツ分類を示すことが理解される。方法1600は、たとえば、サウンドバー装置のような、5（またはそれ以上）スピーカー・アレイをもつ装置のデコーダによって実行されてもよい。このデコーダは、図1のエンコーダ‐デコーダ・システム100におけるデコーダ115と同じ基本構成を有してもよく、たとえば、重み計算および後処理の特定の実装を備えていてもよい。

【0147】

ステップS1610では、AC-4ビットストリームが受領される。
ステップS1620では、2チャネル・オーディオ・コンテンツおよび分類情報は、ビットストリームからデコード／多重分離される。
ステップS1630では、2チャネル・オーディオ・コンテンツをアップミックスして、アップミックスされた5.1チャネル・オーディオ・コンテンツにするために、2チャネル・オーディオ・コンテンツにアップミキサーが適用される。アップミキサーは、それぞれの制御重みの制御の下で動作する。アップミキサーのための制御重みは、分類情報（たとえば、信頼値）に基づいて計算される。アップミキサーのための制御重みは、たとえば、アップミックス重みに関連してもよい。
ステップS1640では、5チャネル・スピーカー・アレイのための5.1仮想化のために、アップミックスされた5.1チャネル・オーディオ・コンテンツに対して仮想化器が適用される。仮想化器は、それぞれの制御重みの制御の下で動作する。仮想化器の制御重みは、分類情報（たとえば、信頼値）に基づいて計算される。これは、たとえば、図13を参照して上述した仕方で行なうことができる。
最後に、ステップS1650で、仮想化器の出力は、5チャネル・スピーカー・アレイにルーティングされる。

【0148】

図17は、本開示の実施形態による、方法1600を実行しうるサウンドバー装置1705のデコーダ1700の例を概略的に示す。以下に説明されるデコーダ1700のモジュールは、たとえば、計算装置のプロセッサによって実装されてもよいことが理解される。デコーダ1700は、ビットストリーム110（たとえば、AC-4ビットストリーム）を受領し、該ビットストリームはAC-4（サウンドバー）デコーダ・モジュール1710によってデコード／多重分離される。AC-4（サウンドバー）デコーダ・モジュール1710は、デコードされた2チャネル・オーディオ・コンテンツ1715およびデコードされた分類情報125を出力する。デコードされた分類情報125は、分類情報125（たとえば、信頼値）に基づいてアップミックス制御重み1775を計算するアップミックス重み計算モジュール1770に提供される。アップミックス制御重み1775は、たとえば、アップミックス重みであってもよい。デコードされた2チャネル・オーディオ・コンテンツ1715は、アップミックス・モジュール1720によって2.0チャネルから5.1チャネルにアップミックスされ、該アップミックス・モジュールはアップミックスされた5.1チャネル・オーディオ・コンテンツを出力する。アップミックス・モジュール1720は、アップミックス制御重み1775の制御の下で動作する。たとえば、音楽および発話について、異なるアップミックス（異なるアップミックス制御重みをもつ）が実行されてもよい。次いで、仮想化モジュール（仮想化器）1730は、5チャネル・スピーカー・アレイのための5.1仮想化を、アップミックスされた5.1チャネル・オーディオ・コンテンツ1725に対して適用し、仮想化されたアップミックスされた5.1チャネル・オーディオ・コンテンツを出力する。仮想化されたアップミックスされた5.1チャネル・オーディオ・コンテンツは、最終的に、後処理された5.1チャネル・オーディオ・コンテンツ102として、サウンドバー装置1705のスピーカーへのルーティングのために出力される。

【0149】

図には示されていないが、デコーダ1700は、たとえば、図13を参照して上述した仕方で、分類情報125（たとえば、信頼値）に基づいて、仮想化モジュール1730のための仮想化器制御重みを計算するためのモジュールをも含んでいてもよい。特に、方法1400および1600、ならびに対応するデコーダ1500および1700は、エンドポイント固有のオーディオ後処理についての例である。

【0150】

本発明のさまざまな側面は、以下の箇条書き例示的実施形態（enumerated example embodiment、EEE）から理解されうる。
〔ＥＥＥ１〕
オーディオ・コンテンツをエンコードする方法であって：
オーディオ・コンテンツのコンテンツ解析を実行する段階と；
前記コンテンツ解析に基づいて前記オーディオ・コンテンツのコンテンツ型を示す分類情報を生成する段階と；
前記オーディオ・コンテンツおよび前記分類情報をビットストリーム中にエンコードする段階と；
前記ビットストリームを出力する段階とを含む、
方法。
〔ＥＥＥ２〕
前記コンテンツ解析が、少なくとも部分的には前記オーディオ・コンテンツについてのメタデータに基づく、ＥＥＥ１に記載の方法。
〔ＥＥＥ３〕
オーディオ・コンテンツをエンコードする方法であって：
前記オーディオ・コンテンツのコンテンツ型に関するユーザー入力を受領する段階と；
前記ユーザー入力に基づいて前記オーディオ・コンテンツのコンテンツ型を示す分類情報を生成する段階と；
前記オーディオ・コンテンツおよび前記分類情報をビットストリーム中にエンコードする段階と；
前記ビットストリームを出力する段階とを含む、
方法。
〔ＥＥＥ４〕
前記ユーザー入力が：
前記オーディオ・コンテンツが所与のコンテンツ型であることを示すラベル；および
一つまたは複数の信頼値であって、各信頼値はそれぞれのコンテンツ型に関連付けられ、かつ前記オーディオ・コンテンツが該それぞれのコンテンツ型である確からしさの指示を与える、信頼値
の一つまたは複数を含む、ＥＥＥ３に記載の方法。
〔ＥＥＥ５〕
オーディオ・コンテンツをエンコードする方法であって、前記オーディオ・コンテンツが、オーディオ・プログラムの一部としてオーディオ・コンテンツのストリームにおいて提供され、当該方法が：
前記オーディオ・コンテンツのサービス型を示すサービス型指示を受領する段階と；
少なくとも部分的には前記サービス型指示に基づいて前記オーディオ・コンテンツのコンテンツ解析を実行する段階と；
前記コンテンツ解析に基づいて前記オーディオ・コンテンツのコンテンツ型を示す分類情報を生成する段階と；
前記オーディオ・コンテンツおよび前記分類情報をビットストリーム中にエンコードする段階と；
前記ビットストリームを出力する段階とを含む、
方法。
〔ＥＥＥ６〕
前記オーディオ・コンテンツの前記サービス型が音楽サービスであるかどうかを前記サービス型指示に基づいて判定し；
前記オーディオ・コンテンツの前記サービス型が音楽サービスであるとの判定に応答して、前記オーディオ・コンテンツのコンテンツ型が音楽コンテンツであることを示すように前記分類情報を生成することをさらに含む、
ＥＥＥ５に記載の方法。
〔ＥＥＥ７〕
前記オーディオ・コンテンツの前記サービス型がニュースキャスト・サービスであるかどうかを前記サービス型指示に基づいて判定する段階と；
前記オーディオ・コンテンツの前記サービス型がニュースキャスト・サービスであるとの判定に応答して、前記オーディオ・コンテンツが発話コンテンツであることを示す、より高い可能性を有するように前記コンテンツ解析を適応させる段階とを含む、
ＥＥＥ５または６に記載の方法。
〔ＥＥＥ８〕
前記サービス型指示は、フレームごとに提供される、ＥＥＥ５ないし７のうちいずれか一項に記載の方法。
〔ＥＥＥ９〕
オーディオ・コンテンツをエンコードする方法であって、前記オーディオ・コンテンツはファイルベースで提供され、前記ファイルはそれぞれのオーディオ・コンテンツについてのメタデータを含み、当該方法は：
少なくとも部分的には前記オーディオ・コンテンツについての前記メタデータに基づいて前記オーディオ・コンテンツのコンテンツ解析を実行する段階と；
前記コンテンツ解析に基づいて前記オーディオ・コンテンツのコンテンツ型を示す分類情報を生成する段階と；
前記オーディオ・コンテンツおよび前記分類情報をビットストリーム中にエンコードする段階と；
前記ビットストリームを出力する段階とを含む、
方法。
〔ＥＥＥ１０〕
前記メタデータは、前記ファイルのファイル・コンテンツ型を示すファイル・コンテンツ型指示を含み、
前記コンテンツ解析は、少なくとも部分的には前記ファイル・コンテンツ型指示に基づく、
ＥＥＥ９に記載の方法。
〔ＥＥＥ１１〕
前記ファイルの前記ファイル・コンテンツ型が音楽ファイルであるかどうかを、前記ファイル・コンテンツ型指示に基づいて判定し；
前記ファイルの前記ファイル・コンテンツ型が音楽ファイルであるとの判定に応答して、前記オーディオ・コンテンツの前記コンテンツ型が音楽コンテンツであることを示すように前記分類情報を生成することをさらに含む、
ＥＥＥ１０に記載の方法。
〔ＥＥＥ１２〕
前記ファイルの前記ファイル・コンテンツ型がニュースキャスト・ファイルであるかどうかを、前記ファイル・コンテンツ型指示に基づいて判定し；
前記ファイルの前記ファイル・コンテンツ型がニュースキャスト・ファイルであるとの判定に応答して、前記オーディオ・コンテンツが発話コンテンツであることを示す、よりも高い可能性を有するように前記コンテンツ解析を適応させることをさらに含む、
ＥＥＥ１０または１１に記載の方法。
〔ＥＥＥ１３〕
前記ファイルの前記ファイル・コンテンツ型が動的であるかどうかを、前記ファイル・コンテンツ型指示に基づいて判定し；
前記ファイルの前記ファイル・コンテンツ型が動的コンテンツであるとの判定に応答して、異なるコンテンツ型間の、より高い遷移レートを許容するように前記コンテンツ解析を適応させることをさらに含む、
ＥＥＥ１０ないし１２のうちいずれか一項に記載の方法。
〔ＥＥＥ１４〕
前記分類情報が、一つまたは複数の信頼値を含み、各信頼値はそれぞれのコンテンツ型に関連付けられ、かつ前記オーディオ・コンテンツが該それぞれのコンテンツ型である確からしさの指示を与える、
ＥＥＥ１ないし１３のうちいずれか一項に記載の方法。
〔ＥＥＥ１５〕
前記コンテンツ型は：音楽コンテンツ、オーディオ・コンテンツ、または効果コンテンツの一つまたは複数を含む、ＥＥＥ１ないし１４のうちいずれか一項に記載の方法。
〔ＥＥＥ１６〕
前記オーディオ・コンテンツにおけるシーン遷移の指示を前記ビットストリーム中にエンコードすることをさらに含む、ＥＥＥ１ないし１５のうちいずれか一項に記載の方法。
〔ＥＥＥ１７〕
エンコードする前の前記分類情報の平滑化をさらに含む、
ＥＥＥ１ないし１６のうちいずれか一項に記載の方法。
〔ＥＥＥ１８〕
エンコードする前に前記分類情報を量子化することをさらに含む、
ＥＥＥ１ないし１７のうちいずれか一項に記載の方法。
〔ＥＥＥ１９〕
前記分類情報を、前記ビットストリームのパケット中の特定のデータ・フィールドにエンコードすることをさらに含む、
ＥＥＥ１ないし１８のうちいずれか一項に記載の方法。
〔ＥＥＥ２０〕
オーディオ・コンテンツと該オーディオ・コンテンツについての分類情報とを含むビットストリームからオーディオ・コンテンツをデコードする方法であって、前記分類情報は、前記オーディオ・コンテンツのコンテンツ分類を示し、当該方法は：
前記ビットストリームを受領する段階と；
前記オーディオ・コンテンツおよび前記分類情報をデコードする段階と；
前記分類情報に基づいて、デコードされたオーディオ・コンテンツの後処理を実行するための後処理モードを選択する段階とを含む、
方法。
〔ＥＥＥ２１〕
前記後処理モードの選択は、ユーザー入力にさらに基づく、ＥＥＥ２０に記載の方法。
〔ＥＥＥ２２〕
オーディオ・コンテンツと該オーディオ・コンテンツについての分類情報とを含むビットストリームからオーディオ・コンテンツをデコードする方法であって、前記分類情報は、前記オーディオ・コンテンツのコンテンツ分類を示し、当該方法は：
前記ビットストリームを受領する段階と；
前記オーディオ・コンテンツおよび前記分類情報をデコードする段階と；
前記分類情報に基づいて、デコードされたオーディオ・コンテンツの後処理のための一つまたは複数の制御重みを計算する段階とを含む、
方法。
〔ＥＥＥ２３〕
前記分類情報は、一つまたは複数の信頼値を含み、それぞれの信頼値は、それぞれのコンテンツ型に関連付けられ、前記オーディオ・コンテンツが該それぞれのコンテンツ型である確からしさの指標を与えるものであり；
前記制御重みは、前記信頼値に基づいて計算される、
ＥＥＥ２２に記載の方法。
〔ＥＥＥ２４〕
前記制御重みは、前記デコードされたオーディオ・コンテンツの後処理のためのそれぞれのモジュールのための制御重みである、ＥＥＥ２２または２３に記載の方法。
〔ＥＥＥ２５〕
前記制御重みは、等化器のための制御重み、仮想化器のための制御重み、サラウンドプロセッサのための制御重み、およびダイアログ向上器のための制御重みのうちの一つまたは複数を含む、ＥＥＥ２２ないし２４のうちいずれか一項に記載の方法。
〔ＥＥＥ２６〕
前記制御重みの計算は、前記デコードを実行する装置の装置型に依存する、ＥＥＥ２２ないし２５のうちいずれか一項に記載の方法。
〔ＥＥＥ２７〕
前記制御重みの計算は、ユーザー入力にさらに基づく、ＥＥＥ２２ないし２６のうちいずれか一項に記載の方法。
〔ＥＥＥ２８〕
前記制御重みの計算は、前記オーディオ・コンテンツのチャネル数にさらに基づく、ＥＥＥ２２ないし２７のうちいずれか一項に記載の方法。
〔ＥＥＥ２９〕
前記制御重みは、仮想化器のための制御重みを含み、
前記仮想化器のための制御重みは、前記分類情報が、前記オーディオ・コンテンツの前記コンテンツ型が音楽である、または音楽である可能性が高いことを示す場合に、前記仮想化器が無効にされるように計算される、
ＥＥＥ２２ないし２８のうちいずれか一項に記載の方法。
〔ＥＥＥ３０〕
前記制御重みは、仮想化器のための制御重みを含み、
前記仮想化器のための制御重みは、前記仮想化器の係数が素通しと完全な仮想化との間でスケールするように計算される、
ＥＥＥ２２ないし２９のうちいずれか一項に記載の方法。
〔ＥＥＥ３１〕
前記制御重みは、ダイアログ向上器のための制御重みを含み、
前記ダイアログ向上器のための制御重みは、前記分類情報が、前記オーディオ・コンテンツの前記コンテンツ・タイプが発話である、または発話である可能性が高いことを示す場合に、前記ダイアログ向上器によるダイアログ向上が向上されるように計算される、
ＥＥＥ２２ないし３０のうちいずれか一項に記載の方法。
〔ＥＥＥ３２〕
前記制御重みは、動的等化器のための制御重みを含み、
前記動的等化器のための制御重みは、前記分類情報が、前記オーディオ・コンテンツの前記コンテンツ型が発話である、または発話である可能性が高いことを示す場合に、前記動的等化器が無効にされるように計算される、
ＥＥＥ２２ないし３１のうちいずれか一項に記載の方法。
〔ＥＥＥ３３〕
前記制御重みの平滑化をさらに含む、ＥＥＥ２２ないし３２のうちいずれか一項に記載の方法。
〔ＥＥＥ３４〕
前記制御重みの平滑化は、平滑化される特定の制御重みに依存する、ＥＥＥ３３に記載の方法。
〔ＥＥＥ３５〕
前記制御重みの平滑化は、前記デコードを実行する装置の装置型に依存する、ＥＥＥ３３または３４に記載の方法。
〔ＥＥＥ３６〕
前記制御重みの連続性を増大させるために、前記制御重みに非線形マッピング関数を適用することをさらに含む、ＥＥＥ３３ないし３５のうちいずれか一項に記載の方法。
〔ＥＥＥ３７〕
2チャネル・オーディオ・コンテンツと該2チャネル・オーディオ・コンテンツについての分類情報とを含むビットストリームからオーディオ・コンテンツをデコードする方法であって、前記分類情報は、前記2チャネル・オーディオ・コンテンツのコンテンツ分類を示し、当該方法は：
前記AC-4ビットストリームを受領する段階と；
前記2チャネル・オーディオ・コンテンツおよび前記分類情報をデコードする段階と；
前記2チャネル・オーディオ・コンテンツをアップミックスして、アップミックスされた5.1チャネル・オーディオ・コンテンツにする段階と；
2チャネル・スピーカー・アレイのための5.1仮想化のために、前記アップミックスされた5.1チャネル・オーディオ・コンテンツに仮想化器を適用する段階と；
前記2チャネル・オーディオ・コンテンツおよび前記仮想化されたアップミックスされた5.1チャネル・オーディオ・コンテンツにクロスフェーダーを適用する段階と；
前記クロスフェーダーの出力を前記2チャネル・スピーカー・アレイにルーティングする段階とを含み、
当該方法は、前記分類情報に基づいて前記仮想化器および前記クロスフェーダーのためのそれぞれの制御重みを計算する段階をさらに含む、
方法。
〔ＥＥＥ３８〕
2チャネル・オーディオ・コンテンツと該2チャネル・オーディオ・コンテンツについての分類情報とを含むビットストリームからオーディオ・コンテンツをデコードする方法であって、前記分類情報は、前記2チャネル・オーディオ・コンテンツのコンテンツ分類を示し、当該方法は：
前記ビットストリームを受領する段階と；
前記2チャネル・オーディオ・コンテンツおよび前記分類情報をデコードする段階と；
前記2チャネル・オーディオ・コンテンツをアップミックスして、アップミックスされた5.1チャネル・オーディオ・コンテンツにするよう、前記2チャネル・オーディオ・コンテンツにアップミキサーを適用する段階と；
5チャネル・スピーカー・アレイのための5.1仮想化のために、前記アップミックスされた5.1チャネル・オーディオ・コンテンツに仮想化器を適用する段階と；
前記仮想化器の出力を前記5チャネル・スピーカー・アレイにルーティングする段階とを含み、
当該方法は、前記分類情報に基づいて前記アップミキサーおよび前記仮想化器のためのそれぞれの制御重みを計算する段階をさらに含む、
方法。
〔ＥＥＥ３９〕
オーディオ・コンテンツをエンコードするためのエンコーダであって、当該エンコーダはプロセッサを有し、前記プロセッサは、前記プロセッサのための命令を記憶しているメモリに結合されており、前記プロセッサは、ＥＥＥ１ないし１９のうちいずれか一項に記載の方法を実行するように適応されている、エンコーダ。
〔ＥＥＥ４０〕
オーディオ・コンテンツをデコードするためのデコーダであって、当該デコーダはプロセッサを有し、前記プロセッサは、前記プロセッサのための命令を記憶しているメモリに結合されており、前記プロセッサは、ＥＥＥ２０ないし３８のうちいずれか一項に記載の方法を実行するように適応されている、デコーダ。
〔ＥＥＥ４１〕
命令を含んでいるコンピュータ・プログラムであって、前記命令は、ＥＥＥ１ないし３８のうちいずれか一項に記載の方法を実行するよう前記命令をプロセッサに実行させるものである、コンピュータ・プログラム。
〔ＥＥＥ４２〕
ＥＥＥ４１に記載のコンピュータ・プログラムを記憶しているコンピュータ読み取り可能な記憶媒体。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【手続補正書】

【提出日】2024-04-23

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

オーディオ・コンテンツを処理するための、プロセッサによって実行される方法であって：
前記オーディオ・コンテンツのコンテンツ解析を実行する段階と；
前記コンテンツ解析に基づいて前記オーディオ・コンテンツのコンテンツ型を示す分類情報を生成する段階であって、前記分類情報は前記オーディオ・コンテンツのコンテンツ型を示し、各コンテンツ型は関連付けられた信頼値を有する、段階と；
デコードされたオーディオ・コンテンツを前記分類情報に基づいて後処理するための複数の制御重みを前記分類情報に基づいて決定する段階とを含む、
方法。

【請求項2】

前記オーディオ・コンテンツがチャネル・ベースのオーディオ・コンテンツを含む、請求項１に記載の方法。

【請求項3】

前記制御重みが、所望される数のチャネルのスピーカー・アレイのための仮想化のための仮想化器によって使用されることが意図されている、請求項１に記載の方法。

【請求項4】

少なくとも一つの信頼値がダイアログに関連し、
当該方法がさらに、前記分類情報に基づいてアップミキサーおよび前記仮想化器についてのそれぞれの制御重みを計算することを含む、
請求項３に記載の方法。

【外国語明細書】