IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ドルビー ラボラトリーズ ライセンシング コーポレイションの特許一覧

特許7427715プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ
<>
  • 特許-プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ 図1
  • 特許-プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ 図2
  • 特許-プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ 図3
  • 特許-プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ 図4
  • 特許-プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ 図5
  • 特許-プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ 図6
  • 特許-プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ 図7
  • 特許-プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-01-26
(45)【発行日】2024-02-05
(54)【発明の名称】プログラム情報またはサブストリーム構造メタデータをもつオーディオ・エンコーダおよびデコーダ
(51)【国際特許分類】
   G10L 19/00 20130101AFI20240129BHJP
【FI】
G10L19/00 330B
G10L19/00 312E
【請求項の数】 4
【外国語出願】
(21)【出願番号】P 2022095116
(22)【出願日】2022-06-13
(62)【分割の表示】P 2021065161の分割
【原出願日】2014-06-12
(65)【公開番号】P2022116360
(43)【公開日】2022-08-09
【審査請求日】2022-06-13
(31)【優先権主張番号】61/836,865
(32)【優先日】2013-06-19
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】507236292
【氏名又は名称】ドルビー ラボラトリーズ ライセンシング コーポレイション
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】リードミラー,ジェフリー
(72)【発明者】
【氏名】ワード,マイケル
【審査官】中村 天真
(56)【参考文献】
【文献】特表2013-519918(JP,A)
【文献】特表2008-536193(JP,A)
【文献】特開平11-234068(JP,A)
【文献】米国特許出願公開第2014/0297291(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G10L 19/00-21/18
H04S 1/00- 7/00
IEEE Xplore
(57)【特許請求の範囲】
【請求項1】
非一時的媒体であるバッファ・メモリを有するオーディオ処理ユニットであって、
前記バッファ・メモリは、エンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを記憶するよう構成されており、前記エンコードされたオーディオ・ビットストリームはオーディオ・データおよびメタデータ・コンテナを含み、前記メタデータ・コンテナはダイナミックレンジ圧縮(DRC)メタデータを含む一つまたは複数のメタデータ・ペイロードを含み、前記DRCメタデータはダイナミックレンジ圧縮データと、前記ダイナミックレンジ圧縮データを生成するためにエンコーダによって使用された圧縮プロファイルの指示とを含み、一つの前記圧縮プロファイルが音楽スタンダード圧縮プロファイルであり;
当該オーディオ処理ユニットはさらに、
前記バッファ・メモリに結合され、前記エンコードされたオーディオ・ビットストリームをパースするよう構成されたパーサと;
前記パーサに結合され、前記オーディオ・データの少なくとも一部に対してまたは前記オーディオ・データの前記少なくとも一部をデコードすることによって生成されたデコードされたオーディオ・データに対して、前記DRCデータを使ってダイナミックレンジ圧縮を実行するよう構成されているサブシステムとを有する、
オーディオ処理ユニット。
【請求項2】
オーディオ・デコード方法であって、
一つまたは複数のフレームに分割されているエンコードされたオーディオ・ビットストリームを受領する段階と;
前記エンコードされたオーディオ・ビットストリームからオーディオ・データおよびメタデータのコンテナを抽出する段階であって、前記メタデータのコンテナはダイナミックレンジ圧縮(DRC)メタデータを含む一つまたは複数のメタデータ・ペイロードを含み、前記DRCメタデータはダイナミックレンジ圧縮データと、前記ダイナミックレンジ圧縮データを生成するためにエンコーダによって使用された圧縮プロファイルの指示とを含み、一つの前記圧縮プロファイルが音楽スタンダード圧縮プロファイルである、段階と;
前記オーディオ・データの少なくとも一部に対してまたは前記オーディオ・データの前記少なくとも一部をデコードすることによって生成されたデコードされたオーディオ・データに対して、前記DRCデータを使ってダイナミックレンジ圧縮を実行する段階とを含む、
方法。
【請求項3】
コンピューティング装置上で実行されたときに請求項2に記載の方法段階を実行するための、プロセッサ上での実行のために適応されたソフトウェア・プログラムを有する記憶媒体。
【請求項4】
コンピュータ請求項2に記載の方法を実行させるためのコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願への相互参照
本願は2013年6月19日に出願された米国仮特許出願第61/836,865号の優先権を主張するものである。同出願の内容はここに参照によってその全体において組み込まれる。
【0002】
技術分野
本発明は、オーディオ信号処理に、より詳細には、ビットストリームによって示されるオーディオ・コンテンツに関するサブストリーム構造および/またはプログラム情報を示すメタデータをもつオーディオ・データ・ビットストリームのエンコードおよびデコードに関する。本発明のいくつかの実施形態は、ドルビー・デジタル(AC-3)、ドルビー・デジタル・プラス(向上AC-3またはE-AC-3)またはドルビーEとして知られるフォーマットの一つでのオーディオ・データを生成または復号する。
【背景技術】
【0003】
ドルビー、ドルビー・デジタル、ドルビー・デジタル・プラスおよびドルビーEはドルビー・ラボラトリーズ・ライセンシング・コーポレイションの商標である。ドルビー・ラボラトリーズは、それぞれドルビー・デジタルおよびドルビー・デジタル・プラスとして知られる、AC-3およびE-AC-3の独自の実装を提供している。
【0004】
オーディオ・データ処理ユニットは典型的には盲目的な仕方で動作し、データが受領される前に行なわれたオーディオ・データの処理履歴には注意を払わない。これは、単一のエンティティが多様な目標メディア・レンダリング装置のためにすべてのオーディオ・データ処理およびエンコードを行ない、一方、目標メディア・レンダリング装置がエンコードされたオーディオ・データのすべてのデコードおよびレンダリングを行なう処理枠組みでは機能するかもしれない。しかしながら、この盲目的な処理は、複数のオーディオ処理ユニットが多様なネットワークを通じて分散しているまたは縦続的に(すなわちチェーン式に)配置されておりそれぞれの型のオーディオ処理を最適に実行することが期待される状況ではうまく(または全く)機能しない。たとえば、いくらかのオーディオ・データが高性能メディア・システムのためにエンコードされることがあり、メディア処理チェーンに沿ってモバイル装置に好適な低減された形に変換される必要があることがある。よって、オーディオ処理ユニットは、すでに実行されている型の処理をそのオーディオ・データに対して不必要に実行してしまうことがある。たとえば、ボリューム平準化ユニットは、入力オーディオ・クリップに対して同じまたは同様のボリューム平準化が以前に実行されているか否かに関わりなく、入力オーディオ・クリップに対して処理を実行することがある。結果として、ボリューム平準化ユニットは、必要ないときでさえも平準化を実行することがある。この無用な処理は、オーディオ・データのコンテンツをレンダリングする際に特定の特徴の劣化および/または除去を引き起こすこともある。
【発明の概要】
【課題を解決するための手段】
【0005】
あるクラスの諸実施形態では、本発明は、エンコードされたビットストリームをデコードすることができるオーディオ処理ユニットである。該ビットストリームは、該ビットストリームの少なくとも一つのフレームの少なくとも一つのセグメントにおいてサブストリーム構造メタデータおよび/またはプログラム情報メタデータを(任意的には他のメタデータ、たとえばラウドネス処理状態メタデータも)、前記フレームの少なくとも一つの他のセグメントにおいてオーディオ・データを含む。本稿では、サブストリーム構造メタデータ(substream structure metadata)(または「SSM」)はエンコードされたビットストリーム(またはエンコードされたビットストリームの集合)のメタデータであって、エンコードされたビットストリームのオーディオ・コンテンツのサブストリーム構造を示すものを表わし、「プログラム情報メタデータ(program information metadata)」(または「PIM」)は、少なくとも一つのオーディオ・プログラム(たとえば二つ以上のオーディオ・プログラム)を示すエンコードされたオーディオ・ビットストリームのメタデータであって、少なくとも一つの前記プログラムのオーディオ・コンテンツの少なくとも一つの属性または特性を示すものを表わす(たとえば、プログラムのオーディオ・データに対して実行された処理の型またはパラメータを示すメタデータまたはプログラムのどのチャネルがアクティブなチャネルであるかを示すメタデータ)。
【0006】
典型的な場合(たとえば、エンコードされたビットストリームがAC-3またはE-AC-3ビットストリームである場合)、プログラム情報メタデータ(PIM)は、ビットストリームの他の部分において担持されることが実際上できないプログラム情報を示す。たとえば、PIMは、エンコード(たとえばAC-3またはE-AC-3エンコード)に先立ってPCMオーディオに適用された処理、そのオーディオ・プログラムのどの周波数帯域が特定のオーディオ符号化技法を使ってエンコードされたかおよびビットストリーム中のダイナミックレンジ圧縮(DRC: dynamic range compression)データを生成するために使われた圧縮プロファイルを示してもよい。
【0007】
別のクラスの実施形態では、方法がビットストリームの各フレーム(または少なくともいくつかのフレームのそれぞれ)においてエンコードされたオーディオ・データをSSMおよび/またはPIMと多重化する段階を含む。典型的なデコードでは、デコーダはビットストリームからSSMおよび/またはPIMを抽出し(SSMおよび/またはPIMとオーディオ・データをパースし、多重分離することによることを含む)、オーディオ・データを処理してデコードされたオーディオ・データのストリームを生成する(場合によってはオーディオ・データの適応的な処理も実行する)。いくつかの実施形態では、デコードされたオーディオ・データおよびSSMおよび/またはPIMは、デコーダから、SSMおよび/またはPIMを使ってデコードされたオーディオ・データに適応的な処理を実行するよう構成された後処理器に転送される。
【0008】
あるクラスの実施形態では、本発明のエンコード方法は、エンコードされたオーディオ・データを含むオーディオ・データ・セグメント(たとえば図4に示したフレームのAB0~AB5セグメントまたは図7に示したフレームのセグメントAB0~AB5の全部または一部)と、該オーディオ・データ・セグメントと時分割多重されたメタデータ・セグメント(SSMおよび/またはPIMならびに任意的には他のメタデータをも含む)とを含むエンコードされたオーディオ・ビットストリーム(たとえばAC-3またはE-AC-3ビットストリーム)を生成する。いくつかの実施形態では、各メタデータ・セグメント(本稿では時に「コンテナ」と称される)は、メタデータ・セグメント・ヘッダ(任意的には他の必須のまたは「コア」の要素も)および該メタデータ・セグメント・ヘッダに続く一つまたは複数のメタデータ・ペイロードを含むフォーマットをもつ。SIMはもし存在すれば、メタデータ・ペイロードの一つ(ペイロード・ヘッダによって識別され、典型的には第一の型のフォーマットをもつ)に含められる。PIMはもし存在すれば、メタデータ・ペイロードの別の一つ(ペイロード・ヘッダによって識別され、典型的には第二の型のフォーマットをもつ)に含められる。同様に、他のそれぞれの型のメタデータは(もし存在すれば)、メタデータ・ペイロードの別の一つ(ペイロード・ヘッダによって識別され、典型的にはメタデータのその型に特有のフォーマットをもつ)に含められる。この例示的なフォーマットは、デコード中以外の時に、SSM、PIMおよび他のメタデータへの便利なアクセス(たとえばデコードに続く後処理器によるアクセスまたはエンコードされたビットストリームに対する完全なデコードを実行することなくメタデータを認識するよう構成されているプロセッサによるアクセス)を許容し、ビットストリームのデコード中の(たとえばサブストリーム識別の)便利で効率的な誤り検出および訂正を許容する。たとえば、上記例示的なフォーマットにおけるSSMへのアクセスなしでは、デコーダは、プログラムに関連するサブストリームの正しい数を誤って識別することがありうる。メタデータ・セグメント中のあるメタデータ・ペイロードがSSMを含んでいてもよく、該メタデータ・セグメント中の別のメタデータ・ペイロードがPIMを含んでいてもよく、任意的には、該メタデータ・セグメント中の少なくとも一つの他のメタデータ・ペイロードが他のメタデータ(たとえばラウドネス処理状態メタデータ(loudness processing state metadata)または「LPSM」)をも含んでいてもよい。
【図面の簡単な説明】
【0009】
図1】本発明の方法のある実施形態を実行するよう構成されていてもよいシステムのある実施形態のブロック図である。
図2】本発明のオーディオ処理ユニットの実施形態であるエンコーダのブロック図である。
図3】本発明のオーディオ処理ユニットの実施形態であるデコーダならびにそれに結合された、本発明のオーディオ処理ユニットのもう一つの実施形態である後処理器のブロック図である。
図4】AC-3フレームを、それが分割された諸セグメントを含めて描く図である。
図5】AC-3フレームの同期情報(SI)セグメントを、それが分割された諸セグメントを含めて描く図である。
図6】AC-3フレームのビットストリーム情報(BSI)セグメントを、それが分割された諸セグメントを含めて描く図である。
図7】E-AC-3フレームを、それが分割された諸セグメントを含めて描く図である。
図8】本発明のある実施形態に基づいて生成されたエンコードされたビットストリームのメタデータ・セグメントであって、コンテナ同期語(図8では「コンテナ同期」として同定されている)ならびにバージョンおよびキーID値を含むメタデータ・セグメント・ヘッダと、それに続く複数のメタデータ・ペイロードおよび保護ビットとを含むものの図である。
【発明を実施するための形態】
【0010】
〈記法および命名法〉
請求項を含む本開示を通じて、信号またはデータ「に対して」動作を実行する(たとえば信号またはデータをフィルタリングする、スケーリングする、変換するまたは利得を適用する)という表現は、信号またはデータに対して直接的に、または信号またはデータの処理されたバージョンに対して(たとえば、予備的なフィルタリングまたは前処理を該動作の実行に先立って受けている前記信号のバージョンに対して)該動作を実行することを表わすために広義で使用される。
【0011】
請求項を含む本開示を通じて、「システム」という表現は、装置、システムまたはサブシステムを表わす広義で使用される。たとえば、デコーダを実装するサブシステムは、デコーダ・システムと称されてもよく、そのようなサブシステムを含むシステム(たとえば、複数の入力に応答してX個の出力信号を生成するシステムであって、前記サブシステムが入力のうちのM個を生成し、他のX-M個の入力は外部源から受領されるもの)もデコーダ・システムと称されることがある。
【0012】
請求項を含む本開示を通じて、「プロセッサ」という表現は、データ(たとえばオーディオまたはビデオまたは他の画像データ)に対して動作を実行するよう(たとえばソフトウェアまたはファームウェアを用いて)プログラム可能または他の仕方で構成可能であるシステムまたは装置を表わす広義で使用される。プロセッサの例は、フィールド・プログラム可能なゲート・アレイ(または他の構成可能な集積回路またはチップセット)、オーディオまたは他のサウンド・データに対してパイプライン化された処理を実行するようプログラムされたおよび/または他の仕方で構成されたデジタル信号プロセッサ、プログラム可能な汎用プロセッサもしくはコンピュータおよびプログラム可能なマイクロプロセッサ・チップまたはチップセットを含む。
【0013】
請求項を含む本開示を通じて、「オーディオ・プロセッサ」および「オーディオ処理ユニット」という表現は交換可能に、オーディオ・データを処理するよう構成されたシステムを表わす広義で使用される。オーディオ処理ユニットの例は、エンコーダ(たとえばトランスコーダ)、デコーダ、コーデック、前処理システム、後処理システムおよびビットストリーム処理システム(時にビットストリーム処理ツールと称される)を含むがこれに限られない。
【0014】
請求項を含む本開示を通じて、(エンコードされたオーディオ・ビットストリームの)「メタデータ」という表現は、ビットストリームの対応するオーディオ・データとは別個の異なるデータを指す。
【0015】
請求項を含む本開示を通じて、「サブストリーム構造メタデータ」(または「SSM」)という表現は、エンコードされたビットストリームのオーディオ・コンテンツのサブストリーム構造を示す、エンコードされたオーディオ・ビットストリームの(またはエンコードされたオーディオ・ビットストリームの集合の)メタデータを表わす。
【0016】
請求項を含む本開示を通じて、「プログラム情報メタデータ」(または「PIM」)という表現は、少なくとも一つのオーディオ・プログラム(たとえば二つ以上のオーディオ・プログラム)を示すエンコードされたオーディオ・ビットストリームのメタデータであって、少なくとも一つの前記プログラムのオーディオ・コンテンツの少なくとも一つの属性または特性を示すものを表わす(たとえば、プログラムのオーディオ・データに対して実行された処理の型またはパラメータを示すメタデータまたはプログラムのどのチャネルがアクティブなチャネルであるかを示すメタデータ)。
【0017】
請求項を含む本開示を通じて、「処理状態メタデータ」(たとえば「ラウドネス処理状態メタデータ」という表現におけるような)という表現は、ビットストリームのオーディオ・データに関連付けられた(エンコードされたオーディオ・ビットストリームの)メタデータを指し、対応する(関連する)オーディオ・データの処理状態(たとえばどの型(単数または複数)の処理がそのオーディオ・データに対してすでに実行されているか)を示し、典型的にはそのオーディオ・データの少なくとも一つの特徴または特性をも示す。処理状態メタデータのオーディオ・データとの関連付けは、時間同期的である。このように、現在の(最も最近受領または更新された)処理状態メタデータは、対応するオーディオ・データが同時的に、示される型(単数または複数)のオーディオ・データ処理の結果を含むことを示す。場合によっては、処理状態メタデータは、処理履歴および/または示される型の処理において使われるおよび/または示される型の処理から導出されるパラメータの一部または全部を含んでいてもよい。さらに、処理状態メタデータは、オーディオ・データから計算されたまたは抽出された、対応するオーディオ・データの少なくとも一つの特徴または特性を含んでいてもよい。処理状態メタデータはまた、対応するオーディオ・データのいかなる処理にも関係せず対応するオーディオ・データのいかなる処理から導出されたのでもない他のメタデータを含んでいてもよい。たとえば、サードパーティー・データ、追跡情報、識別子、所有権があるか標準かの情報、ユーザー注釈データ、ユーザー選好データなどが、特定のオーディオ処理ユニットによって加えられて他のオーディオ処理ユニットに渡されてもよい。
【0018】
請求項を含む本開示を通じて、「ラウドネス処理状態メタデータ」(または「LPSM」)という表現は、対応するオーディオ・データのラウドネス処理状態(たとえばどの型(単数または複数)のラウドネス処理がそのオーディオ・データに対してすでに実行されているか)を、典型的にはまた対応するオーディオ・データの少なくとも一つの特徴または特性(たとえばラウドネス)をも示す処理状態メタデータを表わす。ラウドネス処理状態メタデータは、(単独で考えると)ラウドネス処理状態メタデータではないデータ(たとえば他のメタデータ)を含んでいてもよい。
【0019】
請求項を含む本開示を通じて、「チャネル」(または「オーディオ・チャネル」)という表現は、モノフォニック・オーディオ信号を表わす。
【0020】
請求項を含む本開示を通じて、「オーディオ・プログラム」という表現は、一つまたは複数のオーディオ・チャネルおよび任意的には関連するメタデータ(たとえば、所望される空間的オーディオ呈示を記述するメタデータおよび/またはPIMおよび/またはSSMおよび/またはLPSMおよび/またはプログラム境界メタデータ)の集合を表わす。
【0021】
請求項を含む本開示を通じて、「プログラム境界メタデータ」という表現は、少なくとも一つのオーディオ・プログラム(たとえば二つ以上のオーディオ・プログラム)を示すエンコードされたオーディオ・ビットストリームのメタデータを表わし、プログラム境界メタデータは、少なくとも一つの前記オーディオ・プログラムの少なくとも一つの境界(始まりおよび/または終わり)のビットストリーム中の位置を示す。たとえば、(オーディオ・プログラムを示すエンコードされたオーディオ・ビットストリームの)プログラム境界メタデータは、プログラムの先頭の位置(たとえば、ビットストリームのN番目のフレームの始まりまたはビットストリームのN番目のフレームのM番目のサンプル位置)を示すメタデータと、プログラムの末尾の位置(たとえば、ビットストリームのJ番目のフレームの始まりまたはビットストリームのJ番目のフレームのK番目のサンプル位置)を示す追加的なメタデータとを含んでいてもよい。
【0022】
請求項を含む本開示を通じて、「結合する」または「結合される」という用語は、直接的または間接的な接続を意味するために使われる。よって、第一の装置が第二の装置に結合するとき、その接続は、直接接続を通じてであってもよいし、他の装置および接続を介した間接的な接続を通じてであってもよい。
【0023】
〈発明の実施形態の詳細な説明〉
オーディオ・データの典型的なストリームは、オーディオ・コンテンツ(たとえばオーディオ・コンテンツの一つまたは複数のチャネル)と、オーディオ・コンテンツの少なくとも一つの特性を示すメタデータとの両方を含む。たとえば、AC-3ビットストリームでは、聴取環境に送達されるプログラムの音を変える際に使うために特に意図されているいくつかのオーディオ・メタデータ・パラメータがある。そうしたメタデータ・パラメータの一つがDIALNORMパラメータである。これは、オーディオ・プログラムにおけるダイアログの平均レベルを示すために意図されており、オーディオ再生信号レベルを決定するために使われる。
【0024】
異なるオーディオ・プログラム・セグメント(それぞれ異なるDIALNORMパラメータをもつ)のシーケンスを含むビットストリームの再生の間、AC-3デコーダは、各セグメントのDIALNORMパラメータを使って、ある型のラウドネス処理を実行し、セグメントの該シーケンスのダイアログの知覚されるラウドネスが一貫したレベルであるよう、再生レベルまたはラウドネスを修正する。エンコードされたオーディオ項目のシーケンスにおける各エンコードされたオーディオ・セグメント(項目)は、(一般に)異なるDIALNORMパラメータをもち、デコーダは、各項目についてのダイアログの再生レベルまたはラウドネスが同じまたは非常に似通っているように各項目のレベルをスケーリングする。ただし、このことは、再生中に異なる項目に対して異なる量の利得を適用することを必要とすることがある。
【0025】
DIALNORMは典型的にはユーザーによって設定されるのであって、ユーザーによって値が設定されない場合のデフォルトのDIALNORM値はあるものの、自動的に生成されるのではない。たとえば、コンテンツ・クリエーターは、AC-3エンコーダの外部の装置を用いてラウドネス測定を行ない、次いでDIALNORM値を設定するために(オーディオ・プログラムの話されたダイアログのラウドネスを示す)結果をエンコーダに転送してもよい。こうして、DIALNORMパラメータを正しく設定するためにコンテンツ・クリエーターに依拠している。
【0026】
AC-3ビットストリームにおけるDIALNORMパラメータが正しくないことがありうるいくつかの異なる理由がある。第一に、各AC-3エンコーダは、コンテンツ・クリエーターによってDIALNORM値が設定されない場合にビットストリームの生成の間に使われるデフォルトのDIALNORM値をもつ。このデフォルト値は、オーディオの実際のダイアログ・ラウドネス・レベルとは実質的に異なることがありうる。第二に、たとえコンテンツ・クリエーターがラウドネスを測定し、DIALNORM値をしかるべく設定するとしても、推奨されるAC-3ラウドネス測定方法に従わないラウドネス測定アルゴリズムまたはメーターが使用されたことがありえ、正しくないDIALNORM値につながる。第三に、たとえAC-3ビットストリームがコンテンツ・クリエーターによって正しく測定され設定されたDIALNORM値をもって生成されたとしても、ビットストリームの伝送および/または記憶の間に正しくない値に変更されたことがありうる。たとえば、テレビジョン放送アプリケーションでは、AC-3ビットストリームがデコードされ、修正され、次いで正しくないDIALNORMメタデータ情報を使って再エンコードされることはめずらしくない。このように、AC-3ビットストリームに含まれるDIALNORM値は正しくないまたは不正確であることがあり、よって聴取経験の品質に対してマイナスの影響をもつことがある。
【0027】
さらに、DIALNORMパラメータは、対応するオーディオ・データのラウドネス処理状態(たとえば、どんな型(単数または複数)のラウドネス処理がそのオーディオ・データに対して実行されたか)を示さない。(本発明のいくつかの実施形態において提供されるフォーマットでの)ラウドネス処理状態メタデータは、オーディオ・ビットストリームの適応的なラウドネス処理および/またはオーディオ・コンテンツのラウドネス処理状態およびラウドネスの有効性の検証を特に効率的な仕方で容易にするために有用である。
【0028】
本発明はAC-3ビットストリーム、E-AC-3ビットストリームまたはドルビーEビットストリームとの使用に限定されるものではないが、便宜上、そのようなビットストリームを生成、デコードまたは他の仕方で処理する実施形態において記述される。
【0029】
AC-3のエンコードされたビットストリームは、メタデータおよび一ないし六個のチャネルのオーディオ・コンテンツを有する。オーディオ・コンテンツは、知覚的オーディオ符号化を使って圧縮されたオーディオ・データである。メタデータは、聴取環境に送達されるプログラムの音を変える際に使うために意図されているいくつかのオーディオ・メタデータ・パラメータを含む。
【0030】
AC-3エンコードされたオーディオ・ビットストリームの各フレームは、デジタル・オーディオの1536サンプルについてのオーディオ・コンテンツおよびメタデータを含む。48kHzのサンプリング・レートについては、これは32ミリ秒のデジタル・オーディオまたはオーディオの31.25フレーム毎秒のレートを表わす。
【0031】
E-AC-3エンコードされたオーディオ・ビットストリームの各フレームは、フレームが含むオーディオ・データが一、二、三または六ブロックのいずれであるかに依存して、それぞれデジタル・オーディオの256、512、768または1536サンプルについてのオーディオ・コンテンツおよびメタデータを含む。48kHzのサンプリング・レートについては、これはそれぞれ5.333、10.667、16または32ミリ秒のデジタル・オーディオまたはそれぞれオーディオの189.9、93.75、62.5または31.25フレーム毎秒のレートを表わす。
【0032】
図4に示されるように、各AC-3フレームはセクション(セグメント)に分割される。セクションは、(図5に示されるように)同期語(SW)および二つの誤り訂正語のうち第一のもの(CRC1)を含む同期情報(SI)セクションと;メタデータの大半を含むビットストリーム情報(BSI)セクションと;データ圧縮されたオーディオ・コンテンツを含む(そしてメタデータも含むことができる)六つのオーディオ・ブロック(AB0からAB5)と;オーディオ・コンテンツが圧縮されたのちに残される未使用ビットがあればそれを含む余剰(waste)ビット・セグメント(W)(「スキップ・フィールド」としても知られる)と;さらなるメタデータを含んでいてもよい補助(AUX)情報セクションと;二つの誤り訂正語のうちの第二のもの(CRC2)とを含む。
【0033】
図7に示されるように、各E-AC-3フレームはセクション(セグメント)に分割される。セクションは、(図5に示されるように)同期語(SW)を含む同期情報(SI)セクションと;メタデータの大半を含むビットストリーム情報(BSI)セクションと;データ圧縮されたオーディオ・コンテンツを含む(そしてメタデータも含むことができる)一から六個までの間のオーディオ・ブロック(AB0からAB5)と;オーディオ・コンテンツが圧縮されたのちに残される未使用ビットがあればそれを含む余剰(waste)ビット・セグメント(W)(「スキップ・フィールド」としても知られる)(一つの余剰ビット・セグメントしか示されていないが、典型的には各オーディオ・ブロックには異なる余剰ビットまたはスキップ・フィールド・セグメントが後続する)と;さらなるメタデータを含んでいてもよい補助(AUX)情報セクションと;誤り訂正語(CRC)とを含む。
【0034】
AC-3(またはE-AC-3)ビットストリームでは、聴取環境に送達されるプログラムの音を変える際に使うよう特に意図されたいくつかのオーディオ・メタデータ・パラメータがある。そうしたメタデータ・パラメータの一つはDIALNORMパラメータであり、これはBSIセグメントに含まれる。
【0035】
図6に示されるように、AC-3フレームのBSIセグメントは、当該プログラムについてのDIALNORM値を示す五ビットのパラメータ(「DIALNORM」)を含む。当該AC-3フレームのオーディオ符号化モード(「acmod」)が「0」であってデュアル・モノあるいは「1+1」チャネル構成が使われていることを示す場合には、同じAC-3フレームにおいて担持される第二のオーディオ・プログラムについてのDIALNORM値を示す五ビットのパラメータ(「DIALNORM2」)が含まれる。
【0036】
BSIセグメントは、フラグ(「addbsie」)であって、該「addbsie」ビットに続く追加的なビットストリーム情報の存在(または不在)を示すフラグと、パラメータ(「addbsil」)であって、該「addbsil」値に続く追加的なビットストリーム情報があればその長さを示すパラメータと、「addbsil」値に続く64ビットまでの追加的なビットストリーム情報(「addbsi」)とを含む。
【0037】
BSIセグメントは、図6に具体的に示されない他のメタデータ値を含んでいてもよい。
【0038】
あるクラスの実施形態によれば、エンコードされたオーディオ・ビットストリームが、オーディオ・コンテンツの複数のサブストリームを示す。いくつかの場合には、それらのサブストリームはマルチチャネル・プログラムのオーディオ・コンテンツを示し、各サブストリームはそのプログラムのチャネルの一つまたは複数を示す。他の場合には、エンコードされたオーディオ・ビットストリームの複数のサブストリームは、いくつかのオーディオ・プログラム、典型的には「メイン」オーディオ・プログラム(これはマルチチャネル・プログラムであってもよい)および少なくとも一つの他のオーディオ・プログラム(たとえばメイン・オーディオ・プログラムに対するコメンタリーであるプログラム)のオーディオ・コンテンツを示す。
【0039】
少なくとも一つのオーディオ・プログラムを示すエンコードされたオーディオ・ビットストリームは、必然的に、オーディオ・コンテンツの少なくとも一つの「独立な」サブストリームを含む。この独立なサブストリームは、オーディオ・プログラムの少なくとも一つのチャネルを示す(たとえば、この独立なサブストリームは、通常の5.1チャネル・オーディオ・プログラムの五つのフルレンジ・チャネルを示していてもよい)。ここで、このオーディオ・プログラムは「メイン」プログラムと称される。
【0040】
いくつかのクラスの実施形態では、エンコードされたオーディオ・ビットストリームは、二つ以上のオーディオ・プログラム(「メイン」プログラムと少なくとも一つの他のオーディオ・プログラム)を示す。そのような場合は、ビットストリームは二つ以上の独立なサブストリームを含む。メイン・プログラムの少なくとも一つのチャネルを示す第一の独立なサブストリームと、別のオーディオ・プログラム(メイン・プログラムとは異なるプログラム)の少なくとも一つのチャネルを示す少なくとも一つの他の独立なサブストリームである。各独立なサブストリームは、独立にデコードでき、デコーダは、エンコードされたビットストリームの独立なサブストリームの部分集合(全部でなく)のみをデコードするよう動作できる。
【0041】
二つの独立なサブストリームを示すエンコードされたオーディオ・ビットストリームの典型的な例では、独立なサブストリームの一方はマルチチャネル・メイン・プログラムの標準フォーマット・スピーカー・チャネルを示し(たとえば、5.1チャネルのメイン・プログラムの左、右、中央、左サラウンド、右サラウンドのフルレンジのスピーカー・チャネル)、他方の独立なサブストリームはメイン・プログラムに対するモノフォニック・オーディオ・コメンタリーを示す(たとえば、メイン・プログラムが映画のサウンドトラックである場合の映画に対する監督のコメンタリー)。複数の独立なサブストリームを示すエンコードされたオーディオ・ビットストリームのもう一つの例では、独立なサブストリームの一方は、マルチチャネル・メイン・プログラム(たとえば5.1チャネルのメイン・プログラム)の標準フォーマット・スピーカー・チャネルであって第一の言語でのダイアログを含むものを示し(たとえば、メイン・プログラムのスピーカー・チャネルの一つが該ダイアログを示していてもよい)、他のそれぞれの独立なサブストリームは、該ダイアログのモノフォニックな翻訳(他の言語への)を示す。
【0042】
任意的に、メイン・プログラムを(および任意的には少なくとも一つの他のオーディオ・プログラムも)示すエンコードされたビットストリームは、オーディオ・コンテンツの少なくとも一つの「従属」サブストリームを含む。各従属サブストリームは、ビットストリームの一つの独立サブストリームに関連付けられており、プログラム(たとえばメイン・プログラム)の少なくとも一つの追加的チャネルを示す。その内容は、関連付けられた独立サブストリームによって示される。(すなわち、従属サブストリームは、関連付けられた独立サブストリームによって示されるのでないプログラムの少なくとも一つのチャネルを示し、関連付けられた独立サブストリームは該プログラムの少なくとも一つのチャネルを示す。)
独立サブストリーム(メイン・プログラムの少なくとも一つのチャネルを示す)を含むエンコードされたビットストリームの例において、ビットストリームは、メイン・プログラムの一つまたは複数の追加的なスピーカー・チャネルを示す従属サブストリーム(前記独立ビットストリームに関連付けられている)をも含む。そのような追加的なスピーカー・チャネルは、前記独立サブストリームによって示されるメイン・プログラム・チャネル(単数または複数)に対して追加的である。たとえば、独立サブストリームが、7.1チャネル・メイン・プログラムの標準的なフォーマットの左、右、中央、左サラウンド、右サラウンドのフルレンジ・スピーカー・チャネルを示す場合、従属サブストリームは、メイン・プログラムの二つの他のフルレンジ・スピーカー・チャネルを示してもよい。
【0043】
E-AC-3標準によれば、E-AC-3ビットストリームは少なくとも一つの独立サブストリーム(たとえば単一のAC-3ビットストリーム)を示す必要があり、八個までの独立サブストリームを示してもよい。E-AC-3ビットストリームの各独立サブストリームは八個までの従属サブストリームに関連付けられてもよい。
【0044】
E-AC-3ビットストリームは、ビットストリームのサブストリーム構造を示すメタデータを含む。たとえば、E-AC-3ビットストリームのビットストリーム情報(BSI: Bitstream Information)セクション内の「chanmap」フィールドは、ビットストリームの従属サブストリームによって示されるプログラム・チャネルについてのチャネル・マップを決定する。しかしながら、サブストリーム構造を示すメタデータは通常、E-AC-3デコーダによる(エンコードされたE-AC-3ビットストリームのデコードの際の)アクセスおよび使用のためのみに便利なフォーマットでE-AC-3ビットストリームに含められ、デコード後の(たとえば後処理器による)あるいはデコード前の(たとえば上記メタデータを認識するよう構成された処理器による)アクセスおよび使用のために便利ではない。また、デコーダが、上記の通常通りに含められたメタデータを使って通常のE-AC-3エンコードされたビットストリームのサブストリームを誤って同定してしまうかもしれないリスクがある。本発明までは、エンコードされたビットストリーム(たとえばエンコードされたE-AC-3ビットストリーム)中に、いかにして、ビットストリームのデコードの際のサブストリーム同定における誤りの便利で効率的な検出および訂正を許容するようなフォーマットで、サブストリーム構造メタデータを含めるかは、知られていなかった。
【0045】
E-AC-3ビットストリームは、オーディオ・プログラムのオーディオ・コンテンツに関するメタデータをも含んでいてもよい。たとえば、オーディオ・プログラムを示すE-AC-3ビットストリームは、プログラムのコンテンツをエンコードするためにスペクトル拡張処理(およびチャネル結合エンコード)が用いられた最小および最大周波数を示すメタデータを含む。しかしながら、そのようなメタデータは一般に、E-AC-3デコーダによる(エンコードされたE-AC-3ビットストリームのデコードの際の)アクセスおよび使用のためのみに便利なフォーマットでE-AC-3ビットストリームに含められ、デコード後の(たとえば後処理器による)あるいはデコード前の(たとえば上記メタデータを認識するよう構成された処理器による)アクセスおよび使用のために便利ではない。また、そのようなメタデータは、ビットストリームのデコードの際のそのようなメタデータの同定の便利で効率的な誤り検出および誤り訂正を許容するようなフォーマットでE-AC-3ビットストリームに含められるのではない。
【0046】
本発明の典型的な実施形態によれば、PIMおよび/またはSSMが(および任意的には他のメタデータ、たとえばラウドネス処理状態メタデータまたは「LPSM」も)、他のセグメント(オーディオ・データ・セグメント)にオーディオ・データも含むオーディオ・ビットストリームのメタデータ・セグメントの一つまたは複数のリザーブされたフィールド(またはスロット)に埋め込まれる。典型的には、ビットストリームの各フレームの少なくとも一つのセグメントは、PIMまたはSSMを含み、フレームの少なくとも一つの他のセグメントは対応するオーディオ・データ(すなわち、そのサブストリーム構造がSSMによって示されるおよび/またはPIMによって示される少なくとも一つの特性または属性をもつオーディオ・データ)を含む。
【0047】
あるクラスの諸実施形態では、各メタデータ・セグメントは、一つまたは複数のメタデータ・ペイロードを含んでいてもよいデータ構造(本稿では時にコンテナと称される)である。各ペイロードは、該ペイロード内に存在するメタデータの型の曖昧さのない指示を与えるよう特定のペイロード識別子(およびペイロード構成データ)を含むヘッダを含む。コンテナ内のペイロードの順序は未定義であり、よってペイロードは任意の順序で格納されることができ、パーサがコンテナ全体をパースして有意なペイロードを抽出し、有意でないまたはサポートされていないペイロードを無視することができる必要がある。図8(後述)は、そのようなコンテナの構造およびコンテナ内のペイロードを示している。
【0048】
オーディオ・データ処理チェーンにおいてメタデータ(たとえばSSMおよび/またはPIMおよび/またはLPSM)を通信することが、二つ以上のオーディオ処理ユニットが処理チェーン(またはコンテンツ・ライフサイクル)を通じて互いに縦続的に機能する必要があるときに特に有用である。メタデータをオーディオ・ビットストリームに含めなければ、たとえばチェーンにおいて二つ以上のオーディオ・コーデックが利用され、メディア消費装置(またはビットストリームのオーディオ・コンテンツのレンダリング点)に至るビットストリーム経路の間に二回以上シングルエンドのボリューム平準化が適用されるときに、品質、レベルおよび空間的劣化といった深刻なメディア処理問題が起こりうる。
【0049】
本発明のいくつかの実施形態に基づいてオーディオ・ビットストリームに埋め込まれたラウドネス処理状態メタデータ(LPSM)は、たとえばラウドネス規制エンティティが特定のプログラムのラウドネスがすでに指定された範囲内であるかどうかおよび対応するオーディオ・データ自身が修正されていないことを検証する(verify)(それにより該当する規制に準拠していることを保証する)ことができるようにするために、認証され(authenticated)有効確認され(validated)てもよい。これを検証するために、ラウドネスを再び計算する代わりに、ラウドネス処理状態メタデータを含むデータ・ブロックに含まれるラウドネス値が読み出されてもよい。LPSMに応答して、規制当局は、(LPSMによって示されるところにより)対応するオーディオ・コンテンツがラウドネスの法制および/または規制上の要求(たとえば「CALM法」としても知られる商業広告ラウドネス緩和法(Commercial Advertisement Loudness Mitigation Act)のもとで公布されている規制)に準拠していることを、オーディオ・コンテンツのラウドネスを計算する必要なしに、判別しうる。
【0050】
図1は、システムの要素の一つまたは複数が本発明のある実施形態に基づいて構成されうる例示的なオーディオ処理チェーン(オーディオ・データ処理システム)のブロック図である。システムは、図のように一緒に結合された以下の要素を含む:前処理ユニット、エンコーダ、信号解析およびメタデータ補正ユニット、トランスコーダ、デコーダおよび前処理ユニット。図示したシステムの変形では、要素の一つまたは複数が省略されたり、あるいは追加的なオーディオ・データ処理ユニットが含まれたりする。
【0051】
いくつかの実装では、図1の前処理ユニットは、入力としてオーディオ・コンテンツを含むPCM(時間領域)サンプルを受け容れ、処理されたPCMサンプルを出力するよう構成されている。エンコーダは、入力として該PCMサンプルを受け容れ、前記オーディオ・コンテンツを示す、エンコードされた(たとえば圧縮された)オーディオ・ビットストリームを出力するよう構成されていてもよい。前記オーディオ・コンテンツを示す前記ビットストリームのデータは、本稿では時に、「オーディオ・データ」と称される。エンコーダが本発明の典型的な実施形態に従って構成されている場合、エンコーダからのオーディオ・ビットストリーム出力は、オーディオ・データのほかにPIMおよび/またはSSMを(および任意的にはラウドネス処理状態メタデータおよび/または他のメタデータも)含む。
【0052】
図1の信号解析およびメタデータ補正ユニットは、入力として一つまたは複数のエンコードされたオーディオ・ビットストリームを受け容れ、(たとえばエンコードされたオーディオ・ビットストリーム中のプログラム境界メタデータを使って)信号解析を実行することによって、各エンコードされたオーディオ・ビットストリーム内のメタデータ(たとえば処理状態メタデータ)が正しいかどうかを判定(たとえば有効確認)してもよい。信号解析およびメタデータ補正ユニットが、含まれているメタデータが無効であることを見出す場合、該ユニットは典型的には正しくない値(単数または複数)を信号解析から得られる正しい値(単数または複数)で置き換える。このように、信号解析およびメタデータ補正ユニットから出力される各エンコードされたオーディオ・ビットストリームは、エンコードされたオーディオ・データのほかに訂正された(または訂正されていない)処理状態メタデータを含んでいてもよい。
【0053】
図1のトランスコーダは、入力としてエンコードされたオーディオ・ビットストリームを受け容れて、応答して(たとえば入力ストリームをデコードして、デコードされたストリームを異なるエンコード・フォーマットで再エンコードすることによって)修正された(たとえば異なる仕方でエンコードされた)オーディオ・ビットストリームを出力してもよい。トランスコーダが本発明の典型的な実施形態に基づいて構成されている場合、トランスコーダから出力されるオーディオ・ビットストリームは、エンコードされたオーディオ・データのほかSSMおよび/またはPIMを(典型的には他のメタデータも)含む。該メタデータは入力ビットストリームに含められていたものであってもよい。
【0054】
図1のデコーダは、入力としてエンコードされた(たとえば圧縮された)ビットストリームを受け容れ、(応答して)デコードされたPCMオーディオ・サンプルのストリームを出力してもよい。デコーダが本発明の典型的な実施形態に基づいて構成される場合、典型的な動作におけるデコーダの出力は、以下のうちの任意のものであるまたはそれを含む:
オーディオ・サンプルのストリームおよび入力されたエンコードされたビットストリームから抽出されたSIMおよび/またはPIM(および典型的には他のメタデータも)の少なくとも一つの対応するストリーム;または
オーディオ・サンプルのストリームおよび入力されたエンコードされたビットストリームから抽出されたSSMおよび/またはPIM(および典型的には他のメタデータ、たとえばLPSMも)から決定された制御ビットの対応するストリーム;または
メタデータやメタデータから決定された制御ビットの対応するストリームなしの、オーディオ・サンプルのストリーム。この最後の場合、デコーダは、抽出されたメタデータやそれから決定される制御ビットを出力しなくても、入力されたエンコードされたビットストリームからメタデータを抽出し、抽出されたメタデータに対する少なくとも一つの動作(たとえば有効確認)を実行してもよい。
【0055】
図1の後処理ユニットを本発明の典型的な実施形態に基づいて構成することによって、後処理ユニットは、デコードされたPCMオーディオ・サンプルのストリームを受け容れ、サンプルと一緒に受領されたSSMおよび/またはPIM(および典型的には他のメタデータ、たとえばLPSMも)またはサンプルと一緒に受領されたメタデータからデコーダによって決定される制御ビットを使って、それに対して後処理(たとえばオーディオ・コンテンツのボリューム平準化)を実行するよう構成される。後処理ユニットは典型的には、該後処理されたオーディオ・コンテンツを、一つまたは複数のスピーカーによる再生のためにレンダリングするようにも構成される。
【0056】
本発明の典型的な実施形態は、向上されたオーディオ処理チェーンであって、オーディオ処理ユニット(たとえばエンコーダ、デコーダ、トランスコーダおよび前処理および後処理ユニット)が、オーディオ・データに適用されるそのそれぞれの処理を、それぞれオーディオ処理ユニットによって受領されるメタデータによって示されるメディア・データの同時的状態に従って適応させるものを提供する。
【0057】
図1のシステムのいずれかのオーディオ処理ユニット(たとえば図1のエンコーダまたはトランスコーダ)に入力されるオーディオ・データは、オーディオ・データ(たとえばエンコードされたオーディオ・データ)のほかにSSMおよび/またはPIMを(および任意的には他のメタデータも)含んでいてもよい。本発明のある実施形態によれば、このメタデータは、図1のシステムの他の要素(または図1に示されない他の源)によって入力オーディオに含められたものであってもよい。入力オーディオを(メタデータとともに)受領する本処理ユニットは、少なくとも一つの動作を該メタデータに対して(たとえば有効確認)または該メタデータに応答して(たとえば入力オーディオの適応処理)実行し、典型的にはまた、その出力オーディオ内に該メタデータ、該メタデータの処理されたバージョンまたは該メタデータから決定される制御ビットを含めるよう構成されていてもよい。
【0058】
本発明のオーディオ処理ユニット(またはオーディオ・プロセッサ)の典型的な実施形態は、オーディオ・データに対応するメタデータによって示されるオーディオ・データの状態に基づいてオーディオ・データの適応処理を実行するよう構成される。いくつかの実施形態では、適応処理は、(メタデータがラウドネス処理またはそれと同様の処理がすでにオーディオ・データに対して実行されているのでないことを示す場合は)ラウドネス処理である(またはラウドネス処理を含む)。だが、(メタデータがそのようなラウドネス処理またはそれと同様の処理がすでにオーディオ・データに対して実行されていることを示す場合は)ラウドネス処理ではない(またはラウドネス処理を含まない)。いくつかの実施形態では、適応処理は、メタデータによって示されるオーディオ・データの状態に基づいてオーディオ処理ユニットがオーディオ・データの他の適応処理を実行することを保証するための、(たとえばメタデータ有効確認サブユニットにおいて実行される)メタデータ有効確認であるまたはそれを含む。いくつかの実施形態では、該有効確認は、オーディオ・データに関連付けられた(たとえばオーディオ・データと一緒にビットストリームに含まれている)メタデータの信頼性を決定する。たとえば、メタデータが信頼できると有効確認される場合、ある型の前に実行されたオーディオ処理からの結果が再使用されてもよく、同じ型のオーディオ処理の新たな実行は回避されてもよい。他方、メタデータが細工されている(または他の仕方で信頼できない)ことが見出される場合、(その信頼できないメタデータによって示される)前に実行されたとされる型のメディア処理がオーディオ処理ユニットによって反復されてもよく、および/またはオーディオ処理ユニットによって前記メタデータおよび/またはオーディオ・データに対して他の処理が実行されてもよい。オーディオ処理ユニットは、該ユニットが(たとえば抽出された暗号学的な値および参照の暗号学的な値の一致に基づいて)メタデータが有効であると判定する場合、向上したメディア処理チェーンにおける下流の他のオーディオ処理ユニットに対して、(たとえばメディア・ビットストリーム中に存在する)メタデータが有効であることを信号伝達するよう構成されていてもよい。
【0059】
図2は、本発明のオーディオ処理ユニットの実施形態であるエンコーダ(100)のブロック図である。エンコーダ100のコンポーネントまたは要素の任意のものは、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの組み合わせにおいて、一つまたは複数のプロセスおよび/または一つまたは複数の回路(たとえばASIC、FPGAまたは他の集積回路)として実装されうる。エンコーダ100は、図のように接続された、フレーム・バッファ110、パーサ111、デコーダ101、オーディオ状態有効確認器102、ラウドネス処理段103、オーディオ・ストリーム選択段104、エンコーダ105、詰め込み器(stuffer)/フォーマッタ段107、メタデータ生成段106、ダイアログ・ラウドネス測定サブシステム108およびフレーム・バッファ109を有する。典型的には、エンコーダ100は他の処理要素(図示せず)も含む。
【0060】
エンコーダ100(これはトランスコーダである)は、入力オーディオ・ビットストリーム(これはたとえばAC-3ビットストリーム、E-AC-3ビットストリームまたはドルビーEビットストリームのうちの一つであってもよい)をエンコードされた出力オーディオ・ビットストリーム(これはたとえばAC-3ビットストリーム、E-AC-3ビットストリームまたはドルビーEビットストリームのうちの別の一つであってもよい)に変換するよう構成されている。これは、入力ビットストリームに含まれるラウドネス処理状態メタデータを使って適応的および自動化されたラウドネス処理を実行することによることを含む。たとえば、エンコーダ100は、入力ドルビーEビットストリーム(製作および放送施設において典型的に使われるが、放送されたオーディオ・プログラムを受信する消費者装置においてはそうではないフォーマット)を、AC-3またはE-AC-3の形のエンコードされた出力オーディオ・ビットストリーム(消費者装置への放送に好適)に変換するよう構成されていてもよい。
【0061】
図2のシステムはまた、エンコードされたオーディオの送達サブシステム150(これはエンコーダ100から出力されるエンコードされたビットストリームを記憶するおよび/または送達する)と、デコーダ152とを含む。エンコーダ100から出力されるエンコードされたオーディオ・ビットストリームは、サブシステム150によって(たとえばDVDまたはブルーレイ・ディスクの形で)記憶されても、あるいはサブシステム150(これは伝送リンクまたはネットワークを実装していてもよい)によって伝送されてもよく、あるいはサブシステム150によって記憶および伝送の両方をされてもよい。デコーダ152は、サブシステム150を介して受領する(エンコーダ100によって生成された)エンコードされたオーディオ・ビットストリームをデコードするよう構成されている。これは、ビットストリームの各フレームからメタデータ(PIMおよび/またはSSMおよび任意的にはラウドネス処理状態メタデータおよび/または他のメタデータも)を抽出し、(任意的にはビットストリームからプログラム境界メタデータも抽出し、)デコードされたオーディオ・データを生成することによることを含む。典型的には、デコーダ152は、PIMおよび/またはSSMおよび/またはLPSM(および任意的にはプログラム境界メタデータも)を使ってデコードされたオーディオ・データに対して適応処理を実行し、および/またはデコードされたオーディオ・データおよびメタデータを、該メタデータを使ってデコードされたオーディオ・データに対して適応処理を実行するよう構成されている後処理器に転送するよう構成される。典型的には、デコーダ152は、サブシステム150から受領されたエンコードされたオーディオ・ビットストリームを(たとえば非一時的な仕方で)記憶するバッファを含む。
【0062】
エンコーダ100およびデコーダ152のさまざまな実装が、本発明の方法の種々の実施形態を実行するよう構成される。
【0063】
フレーム・バッファ110は、エンコードされた入力オーディオ・ビットストリームを受領するよう結合されたバッファ・メモリである。動作では、バッファ110は、エンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを(たとえば非一時的な仕方で)記憶し、エンコードされたオーディオ・ビットストリームのフレームのシーケンスがバッファ110からパーサ111に呈される。
【0064】
パーサ111は、PIMおよび/またはSSMおよびラウドネス処理メタデータ(LPSM)を、任意的にはプログラム境界メタデータ(および/または他のメタデータ)も、そのようなメタデータが含まれているエンコードされた入力オーディオの各フレームから抽出し、少なくともLPSMを(任意的にはプログラム境界メタデータおよび/または他のメタデータをも)オーディオ状態有効確認器102、ラウドネス処理段103、段106およびサブシステム108に呈し、エンコードされた入力オーディオからオーディオ・データを抽出し、該オーディオ・データをデコーダ101に呈するよう結合され、構成されている。エンコーダ100のデコーダ101は、オーディオ・データをデコードしてデコードされたオーディオ・データを生成し、該デコードされたオーディオ・データをラウドネス処理段103、オーディオ・ストリーム選択段104、サブシステム108および典型的には状態有効確認器102にも呈するよう構成されている。
【0065】
状態有効確認器102は、それに対して呈されるLPSM(および任意的には他のメタデータ)を認証し、有効確認するよう構成される。いくつかの実施形態では、LPSMは、(たとえば本発明のある実施形態に従って)入力ビットストリームに含まれていたデータ・ブロックである(または該データ・ブロックに含まれる)。該ブロックは、LPSM(および任意的には他のメタデータも)および/または基礎になるオーディオ・データ(デコーダ101から有効確認器102に提供される)を処理するための暗号学的ハッシュ(ハッシュ・ベースのメッセージ認証コードまたは「HMAC」)を含んでいてもよい。該データ・ブロックは、これらの実施形態において、デジタル署名されてもよい。それにより、下流のオーディオ処理ユニットは比較的容易に、該処理状態メタデータを認証および有効確認しうる。
【0066】
たとえば、HMACは、ダイジェストを生成するために使われ、本発明のビットストリームに含まれる保護値(単数または複数)は該ダイジェストを含んでいてもよい。該ダイジェストは、AC-3フレームについては、以下のように生成されてもよい:
1.AC-3データおよびLPSMがエンコードされたのち、フレーム・データ・バイト(連結されたフレーム・データ#1およびフレーム・データ#2)およびLPSMデータ・バイトが、ハッシュ関数HMACのための入力として使われる。補助データ・フィールド内に存在していてもよい他のデータは、このダイジェストを計算するためには考慮に入れられない。そのような他のデータは、AC-3データにもLSPSMデータにも属さないバイトであってもよい。LPSMに含まれる保護ビットは、HMACダイジェストを計算するためには考慮されなくてもよい。
2.ダイジェストが計算されたのち、該ダイジェストは保護ビットのためにリザーブされているフィールドにおいてビットストリームに書き込まれる。
3.完全なAC-3フレームの生成の最後の段階は、CRC検査の計算である。これは、フレームのいちばん最後に書かれ、LPSMビットを含む、このフレームに属するすべてのデータが考慮に入れられる。
【0067】
一つまたは複数のHMACでない暗号学的方法の任意のものを含むがそれに限定されない他の暗号学的方法が、メタデータおよび/または基礎になるオーディオ・データの安全な伝送および受領を保証するための(たとえば有効確認器102における)LPSMおよび/または他のメタデータの有効確認のために使われてもよい。たとえば、(そのような暗号学的方法を使う)有効確認は、本発明のオーディオ・ビットストリームの実施形態を受領する各オーディオ処理ユニットにおいて実行され、ビットストリームに含まれるメタデータおよび対応するオーディオ・データが(該メタデータによって示されるような)特定の処理を受けている(および/または特定のラウドネス処理から帰結する)ものであり、そのような特定の処理の実行後に修正されていないかどうかを判定することができる。
【0068】
状態有効確認器102は、有効確認動作の結果を示すために、オーディオ・ストリーム選択段104、メタデータ生成器106およびダイアログ・ラウドネス測定サブシステム108に制御データを呈する。該制御データに応答して、段104は次のいずれかを選択する(そしてエンコーダ105まで伝える)ことができる:
(たとえば、LPSMがデコーダ101から出力されたオーディオ・データが特定の型のラウドネス処理を受けていないことを示し、有効確認器102からの制御ビットがLPSMが有効であることを示すとき)ラウドネス処理段103の適応的に処理された出力;または
(たとえば、LPSMがデコーダ101から出力されたオーディオ・データが段103によって実行されるはずの特定の型のラウドネス処理をすでに受けていることを示し、有効確認器102からの制御ビットがLPSMが有効であることを示すとき)デコーダ101から出力された前記オーディオ・データ。
【0069】
エンコーダ100の段103は、デコーダ101から出力されたデコードされたオーディオ・データに対して、デコーダ101によって抽出されたLPSMによって示される一つまたは複数のオーディオ・データ特性に基づいて、適応的なラウドネス処理を実行するよう構成されている。段103は、適応的な変換領域のリアルタイムのラウドネスおよびダイナミックレンジ制御プロセッサであってもよい。段103はユーザー入力(たとえばユーザー目標ラウドネス/ダイナミックレンジ値またはdialnorm値)または他のメタデータ入力(たとえば、一つまたは複数の型のサードパーティー・データ、追跡情報、識別子、所有権があるか標準かの情報、ユーザー注釈データ、ユーザー選好データなど)および/または(たとえばフィンガープリンティング・プロセスからの)他の入力を受領して、そのような入力を、デコーダ101から出力されるデコードされたオーディオ・データを処理するために使ってもよい。段103は、(パーサ111によって抽出されるプログラム境界メタデータによって示される)単一のオーディオ・プログラムを示す(デコーダ101から出力される)デコードされたオーディオ・データに対して適応的なラウドネス処理を実行してもよく、パーサ111によって抽出されたプログラム境界メタデータによって示される異なるオーディオ・プログラムを示す(デコーダ101から出力される)デコードされたオーディオ・データを受領するのに応答して、ラウドネス処理をリセットしてもよい。
【0070】
ダイアログ・ラウドネス測定サブシステム108は、有効確認器102からの制御ビットがLPSMが無効であることを示す場合には、たとえばデコーダ101によって抽出されたLPSM(および/または他のメタデータ)を使って、ダイアログ(または他の発話)を示す(デコーダ101からの)デコードされたオーディオの諸セグメントのラウドネスを決定するよう動作してもよい。有効確認器102からの制御ビットがLPSMが有効であることを示す場合には、LPSMが(デコーダ101からの)デコードされたオーディオのダイアログ(または他の発話)セグメントの以前に決定されたラウドネスを示しているときは、ダイアログ・ラウドネス測定サブシステム108の動作は無効にされてもよい。サブシステム108は、(パーサ111によって抽出されるプログラム境界メタデータによって示される)単一オーディオ・プログラムを示すデコードされたオーディオ・データに対してラウドネス測定を実行してもよく、そのようなプログラム境界メタデータによって示される異なるオーディオ・プログラムを示すデコードされたオーディオ・データを受領するのに応答して、前記測定をリセットしてもよい。
【0071】
オーディオ・コンテンツにおけるダイアログのレベルを便利かつ簡単に測定するための有用なツール(たとえばドルビーLM100ラウドネス・メーター)が存在している。本発明のAPU(たとえばエンコーダ100の段108)のいくつかの実施形態は、オーディオ・ビットストリーム(たとえば、エンコーダ100のデコーダ101から段108に呈されるデコードされたAC-3ビットストリーム)のオーディオ・コンテンツの平均ダイアログ・ラウドネスを測定するためにそのようなツールを含むよう(またはそのようなツールの機能を実行するよう)実装される。
【0072】
段108がオーディオ・データの真の平均ダイアログ・ラウドネスを測定するよう実装される場合、測定は、オーディオ・コンテンツの、主として発話を含んでいる諸セグメントを単離する段階を含んでいてもよい。主として発話であるオーディオ・セグメントは、次いで、ラウドネス測定アルゴリズムに従って処理される。AC-3ビットストリームからデコードされるオーディオ・データについては、このアルゴリズムは、(国際規格ITU-R BS.1770に従う)標準的なK重み付けされたラウドネス指標(K-weighted loudness measure)であってもよい。あるいはまた、他のラウドネス指標(たとえばラウドネスの音響心理学的モデルに基づくもの)が使われてもよい。
【0073】
発話セグメントの単離は、オーディオ・データの平均ダイアログ・ラウドネスを測定するためには本質的ではないが、指標の精度を改善し、典型的には聴取者の観点からの、より満足のいく結果を与える。すべてのオーディオ・コンテンツがダイアログ(発話)を含むのではないので、オーディオ・コンテンツ全体のラウドネス指標は、発話が存在していたとした場合の、当該オーディオのダイアログ・レベルの十分な近似を提供しうる。
【0074】
メタデータ生成器106は、エンコーダ100から出力されるエンコードされたビットストリームに段107によって含められるメタデータを生成する(および/または段107まで渡す)。メタデータ生成器106は、段107まで、エンコーダ101および/またはパーサ111によって抽出されたLPSM(および任意的にはLIMおよび/またはPIMおよび/またはプログラム境界メタデータおよび/または他のメタデータも)を渡してもよいし(たとえば、有効確認器102からの制御ビットがLPSMおよび/または他のメタデータが有効であることを示す場合)、あるいは新たなLIMおよび/またはPIMおよび/またはLPSMおよび/またはプログラム境界メタデータおよび/または他のメタデータを生成して、該新たなメタデータを段107に呈してもよい(たとえば、有効確認器102からの制御ビットが、デコーダ101によって抽出されたメタデータが無効であることを示す場合)。あるいは、段107に対して、デコーダ101および/またはパーサ111によって抽出されたメタデータと新たに生成されたメタデータとの組み合わせを呈してもよい。メタデータ生成器106は、サブシステム108によって生成されたラウドネス・データと、サブシステム108によって実行されたラウドネス処理の型を示す少なくとも一つの値とを、エンコーダ100から出力されるエンコードされたビットストリームに含めるために、段107に対して呈するLPSM中に含めてもよい。
【0075】
メタデータ生成器106は、エンコードされたビットストリームに含めるべきLPSM(および任意的には他のメタデータも)および/またはエンコードされたビットストリームに含めるべき基礎になるオーディオ・データの解読、認証または有効確認の少なくとも一つについて有用な保護ビット(これはハッシュ・ベースのメッセージ認証コードまたは「HMAC」からなっていてもよく、あるいはそれを含んでいてもよい)を生成してもよい。メタデータ生成器106はそのような保護ビットを、エンコードされたビットストリーム中に含めるために段107に提供してもよい。
【0076】
典型的な動作では、ダイアログ・ラウドネス測定サブシステム108は、デコーダ101から出力されたオーディオ・データを処理して、それに応答して、ラウドネス値(たとえば、ゲーティングされたおよびゲーティングされないダイアログ・ラウドネス値)およびダイナミックレンジ値を生成する。これらの値に応答して、メタデータ生成器106は、エンコーダ100から出力されるエンコードされたビットストリームに(詰め込み器/フォーマッタ107によって)含めるためにラウドネス処理状態メタデータ(LPSM)を生成してもよい。
【0077】
追加的、任意的または代替的に、エンコーダ100の106および/または108のサブシステムは、オーディオ・データの追加的な解析を実行して、段107から出力されるエンコードされたビットストリームに含めるための、オーディオ・データの少なくとも一つの特性を示すメタデータを生成してもよい。
【0078】
エンコーダ105は、選択段104から出力されたオーディオ・データを(たとえばそれに対して圧縮を実行することによって)エンコードし、段107から出力されるエンコードされたビットストリームに含めるために、エンコードされたオーディオを段107に呈する。
【0079】
段107は、エンコーダ105からのエンコードされたオーディオと生成器106からのメタデータ(PIMおよび/またはSSMを含む)とを多重化して、段107から出力される、エンコードされたビットストリームを生成する。好ましくは、エンコードされたビットストリームは、本発明のある好ましい実施形態によって指定されるフォーマットをもつようにされる。
【0080】
フレーム・バッファ109は、段107から出力されるエンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを(たとえば非一時的な仕方で)記憶するバッファ・メモリである。次いで、エンコードされたオーディオ・ビットストリームのそれらのフレームのシーケンスが、バッファ109から、エンコーダ100からの出力として、送達システム150に呈される。
【0081】
メタデータ生成器106によって生成され、段107によって、エンコードされたビットストリームに含められたLPSMは、典型的には、対応するオーディオ・データのラウドネス処理状態(たとえば、該オーディオ・データに対してどんな型(単数または複数)のラウドネス処理が実行されたか)および対応するオーディオ・データのラウドネス(たとえば、測定されたダイアログ・ラウドネス、ゲーティングされたおよび/またはゲーティングされないラウドネスおよび/またはダイナミックレンジ)を示す。
【0082】
本稿において、オーディオ・データに対して実行されるラウドネスおよび/またはレベル測定の「ゲーティング」とは特定のレベルまたはラウドネスの閾値を参照し、閾値を超える計算された値(単数または複数)が最終的な測定に含められる(たとえば、最終的な測定された値において-60dBFSより低い短期的なラウドネス値を無視する)。絶対的な値に対するゲーティングは固定したレベルまたはラウドネスを参照し、相対値に対するゲーティングは現在の「ゲーティングされていない」測定値に依存する値を参照する。
【0083】
エンコーダ100のいくつかの実装では、メモリ109にバッファリングされている(そして送達システム150に出力される)エンコードされたビットストリームは、AC-3ビットストリームまたはE-AC-3ビットストリームであり、オーディオ・データ・セグメント(たとえば、図4に示したフレームのAB0~AB5セグメント)およびメタデータ・セグメントを含む。ここで、オーディオ・データ・セグメントはオーディオ・データを示し、メタデータ・セグメントのうち少なくともいくつかのセグメントのそれぞれは、PIMおよび/またはSSM(および任意的には他のメタデータも)を含む。段107は(メタデータを含む)メタデータ・セグメントを次のフォーマットでビットストリーム中に挿入する。PIMおよび/またはSSMを含むメタデータ・セグメントのそれぞれは、ビットストリームの余剰ビット・セグメント(たとえば、図4または図7に示される余剰ビット・セグメント「W」)またはビットストリームのフレームのビットストリーム情報(「BSI」)セグメントの「addbsi」フィールドまたはビットストリームのフレームの末尾にある補助データ・フィールド(たとえば図4または図7に示されるAUXセグメント)に含められる。ビットストリームのフレームは、それぞれがメタデータを含む一つまたは二つのメタデータ・セグメントを含んでいてもよく、フレームが二つのメタデータ・セグメントを含む場合には、一方はフレームのaddbsiフィールドに、他方はフレームのAUXフィールドに存在していてもよい。
【0084】
いくつかの実施形態では、段107によって挿入される各メタデータ・セグメント(本稿では時に「コンテナ」と称される)は、メタデータ・セグメント・ヘッダ(任意的には他の必須のまたは「コア」要素も)および該メタデータ・セグメント・ヘッダに続く一つまたは複数のメタデータ・ペイロードを含むフォーマットをもつ。SIMはもし存在すれば、メタデータ・ペイロードの一つ(ペイロード・ヘッダによって識別され、典型的には第一の型のフォーマットをもつ)に含められる。PIMはもし存在すれば、メタデータ・ペイロードの別の一つ(ペイロード・ヘッダによって識別され、典型的には第二の型のフォーマットをもつ)に含められる。同様に、それぞれの他の型のメタデータは(もし存在すれば)、メタデータ・ペイロードの別のもの(ペイロード・ヘッダによって識別され、典型的にはメタデータの型に固有なフォーマットをもつ)に含められる。この例示的なフォーマットは、デコード中以外の時点において(たとえばデコード後に後処理器による、あるいはそのメタデータを認識するよう構成されたプロセッサによる、エンコードされたビットストリームに対して完全なデコードを実行しないでの)SSM、PIMおよび他のメタデータへの便利なアクセスを許容し、ビットストリームのデコードの間の(たとえばサブストリーム識別の)便利で効率的な誤り検出および訂正を許容する。たとえば、本例示的フォーマットのSSMへのアクセスなしでは、デコーダは、プログラムに関連付けられたサブストリームの正しい数を、誤って識別することがありうる。あるメタデータ・セグメント中の一つのメタデータ・ペイロードがSSMを含んでいてもよく、該メタデータ・セグメント中の別のメタデータ・ペイロードがPIMを含んでいてもよく、任意的にはまた、該メタデータ・セグメント中の少なくとも一つの他のメタデータ・ペイロードが他のメタデータ(たとえばラウドネス処理状態メタデータまたは「LPSM」)を含んでいてもよい。
【0085】
いくつかの実施形態では、エンコードされたビットストリーム(たとえば、少なくとも一つのオーディオ・プログラムを示すE-AC-3ビットストリーム)のフレーム内に(段107によって)含められるサブストリーム構造メタデータ(SSM)ペイロードは次のフォーマットでSSMを含む:
ペイロード・ヘッダ。これは典型的には少なくとも一つの識別情報値(たとえば、SSMフォーマット・バージョンを示す2ビット値および任意的には、長さ、期間(period)、カウントおよびサブストリーム関連付け値)を含む;
ヘッダ後に、
ビットストリームによって示されるプログラムの独立サブストリームの数を示す独立サブストリーム・メタデータ;および
プログラムの各独立サブストリームが少なくとも一つの関連付けられた従属サブストリームをもつかどうか(すなわち、前記各独立サブストリームに少なくとも一つの従属サブストリームが関連付けられているかどうか)およびもしそうであればプログラムの各独立サブストリームに関連付けられた従属サブストリームの数を示す従属サブストリーム・メタデータ。
【0086】
エンコードされたビットストリームの独立サブストリームがオーディオ・プログラムの一組のスピーカー・チャネル(たとえば、5.1スピーカー・チャネル・オーディオ・プログラムのスピーカー・チャネル)を示してもよく、一つまたは複数の従属サブストリーム(従属サブストリーム・メタデータによって示されるように前記独立サブストリームに関連付けられている)のそれぞれがプログラムのオブジェクト・チャネルを示していてもよいことが考えられている。しかしながら、典型的には、エンコードされたビットストリームの独立サブストリームはプログラムの一組のスピーカー・チャネルを示し、(従属サブストリーム・メタデータによって示されるように)該独立サブストリームに関連付けられた各従属サブストリームは、そのプログラムの少なくとも一つの追加的なスピーカー・チャネルを示す。
【0087】
いくつかの実施形態では、エンコードされたビットストリーム(たとえば、少なくとも一つのオーディオ・プログラムを示すE-AC-3ビットストリーム)のフレーム内に(段107によって)含められるプログラム情報メタデータ(PIM)ペイロードは次のフォーマットをもつ:
ペイロード・ヘッダ。これは典型的には少なくとも一つの識別情報値(たとえば、PIMフォーマット・バージョンを示す値および任意的には、長さ、期間(period)、カウントおよびサブストリーム関連付け値)を含む;および
ヘッダ後に、次のフォーマットでのPIM:
オーディオ・プログラムの各無音チャネルおよび各非無音チャネル(すなわち、プログラムのどのチャネルがオーディオ情報を含むかおよび(もしあれば)どのチャネルが無音のみを含むか(典型的には当該フレームの継続時間にわたって))を示すアクティブ・チャネル・メタデータ。エンコードされたビットストリームがAC-3またはE-AC-3ビットストリームである実施形態では、プログラムのどのチャネルがオーディオ情報を含み、どのチャネルが無音を含むかを決定するために、ビットストリームのフレーム中のアクティブ・チャネル・メタデータは、ビットストリームの追加的なメタデータ(たとえば、当該フレームのオーディオ符号化モード(「acmod」)フィールドおよびもし存在すれば当該フレームもしくは関連付けられた従属サブストリーム・フレーム(単数または複数)内のchanmapフィールド)との関連で使用されてもよい。AC-3またはE-AC-3フレームの「acmod」フィールドは、当該フレームのオーディオ・コンテンツによって示されるオーディオ・プログラムのフルレンジ・チャネルの数(たとえば、プログラムが1.0チャネル・モノフォニック・プログラム、2.0チャネル・ステレオ・プログラムまたはL、R、C、Ls、Rsフルレンジ・チャネルを含むプログラムのいずれであるか)を示すか、あるいは当該フレームが二つの独立な1.0チャネル・モノフォニック・プログラムを示すことを示す。E-AC-3ビットストリームの「chanmap」フィールドは、ビットストリームによって示される従属サブストリームについてのチャネル・マップを示す。アクティブ・チャネル・メタデータは、たとえばデコーダの出力において無音を含むチャネルにオーディオを加えるために、デコーダの下流で(後処理器内での)上方混合〔増数混合〕を実装するために有用でありうる;。
【0088】
プログラムが(エンコード前にまたはエンコード中に)下方混合〔減数混合〕されたものであるかどうかおよびもしそうであれば適用された下方混合の型を示す下方混合処理状態メタデータ。下方混合処理状態メタデータは、たとえば適用された下方混合の型に最もよく一致するパラメータを使ってプログラムのオーディオ・コンテンツを上方混合するために、デコーダの下流で(後処理器内での)上方混合を実装するために有用でありうる。エンコードされたビットストリームがAC-3またはE-AC-3ビットストリームである実施形態では、下方混合処理状態メタデータは、プログラムのチャネルに適用された下方混合(もしあれば)の型を決定するために、フレームのオーディオ符号化モード(「acmod」)フィールドとの関連で使用されてもよい;。
【0089】
プログラムがエンコード前にまたはエンコード中に(たとえばより少数のチャネルから)上方混合されたものであるかどうかおよびもしそうであれば適用された上方混合の型を示す上方混合処理状態メタデータ。上方混合処理状態メタデータは、たとえばプログラムに適用された上方混合の型(たとえば、ドルビー・プロ・ロジックまたはドルビー・プロ・ロジックII映画モードまたはドルビー・プロ・ロジックII音楽モードまたはドルビー・プロフェッショナル・アップミキサー)と互換な仕方でプログラムのオーディオ・コンテンツを下方混合するために、デコーダの下流で(後処理器内での)下方混合を実装するために有用でありうる。エンコードされたビットストリームがE-AC-3ビットストリームである実施形態では、上方混合処理状態メタデータは、プログラムのチャネルに適用された上方混合(もしあれば)の型を決定するために、他のメタデータ(たとえば当該フレームの「strmtyp」フィールドの値)との関連で使用されてもよい。(E-AC-3ビットストリームのフレームのBSIセグメント内の)「strmtyp」フィールドの値は、フレームのオーディオ・コンテンツが独立ストリーム(これはプログラムを決定する)または(複数のサブストリームを含むまたは複数のサブストリームに関連付けられているプログラムの)独立サブストリームに属し、よって当該E-AC-3ビットストリームによって示される他のどのサブストリームとも独立にデコードされうるかどうか、あるいは当該フレームのオーディオ・コンテンツが(複数のサブストリームを含むまたは複数のサブストリームに関連付けられているプログラムの)従属サブストリームに属し、よって関連付けられている独立サブストリームとの関連でデコードされる必要があるかどうかを示す;。
【0090】
当該フレームのオーディオ・コンテンツに対して(エンコードされたビットストリームを生成するためにオーディオ・コンテンツをエンコードする前に)前処理が実行されたかどうかおよびもしそうであれば実行された前処理の型を示す前処理状態メタデータ。
【0091】
いくつかの実装では、前処理状態メタデータは、以下のことを示す:
サラウンド減衰が適用されたかどうか(たとえば、オーディオ・プログラムのサラウンド・チャネルがエンコードに先立って3dB減衰されたかどうか)、
90度位相シフトが適用されたかどうか(たとえばエンコードに先立ってオーディオ・プログラムのサラウンド・チャネルLsおよびRsチャネルに)、
エンコードに先立ってオーディオ・プログラムのLFEチャネルに低域通過フィルタが適用されたかどうか、
プログラムのLFEチャネルのレベルが制作中にモニタリングされたかどうかおよびもしそうであればプログラムのフルレンジ・オーディオ・チャネルのレベルに対するLFEチャネルのモニタリングされたレベル、。
【0092】
ダイナミックレンジ圧縮が、プログラムのデコードされたオーディオ・コンテンツの各ブロックに対して(たとえばデコーダにおいて)実行されるべきであるかどうかおよびもしそうであれば実行されるべきダイナミックレンジ圧縮の型(および/またはパラメータ)(たとえば、この型の前処理状態メタデータは、エンコードされたビットストリームに含められるダイナミックレンジ圧縮制御値を生成するために、エンコーダによって、以下の圧縮プロファイル型のうちのどれが想定されたかを示してもよい:フィルム・スタンダード、フィルム・ライト、音楽スタンダード、音楽ライトまたはスピーチ。あるいはまた、この型の前処理状態メタデータは、エンコードされたビットストリームに含められるダイナミックレンジ圧縮制御値によって決定される仕方でプログラムのデコードされたオーディオ・コンテンツの各フレームに対して重度のダイナミックレンジ圧縮(「compr」圧縮)が実行されるべきであることを示してもよい)、。
【0093】
プログラムのコンテンツの特定の周波数範囲をエンコードするためにスペクトル拡張処理および/またはチャネル結合エンコードが用いられたかどうかおよびもしそうであればスペクトル拡張エンコードが実行されたコンテンツの周波数成分の最小および最大周波数およびチャネル結合エンコードが実行されたコンテンツの周波数成分の最小および最大周波数。この型の前処理状態メタデータ情報は、デコーダの下流で(後処理器内での)等化を実行するために有用でありうる。チャネル結合およびスペクトル拡張情報はいずれも、トランスコード動作および適用の際の品質を最適化するためにも有用である。たとえば、エンコーダは、スペクトル拡張およびチャネル結合情報のようなパラメータの状態に基づいてその挙動を最適化しうる(ヘッドフォン仮想化、上方混合などといった前処理段階の適応を含む)。さらに、エンコーダは、はいってくる(かつ認証された)メタデータの状態に基づく最適な値に一致および/またはするようその結合およびスペクトル拡張パラメータを動的に適応してもよい。
【0094】
ダイアログ向上調整範囲データがエンコードされたビットストリームに含まれるかどうかおよびもしそうであればオーディオ・プログラム中の非ダイアログ・コンテンツのレベルに対するダイアログ・コンテンツのレベルを調整するための(たとえばデコーダの下流の後処理器内での)ダイアログ向上処理の実行中に利用可能な調整の範囲。
【0095】
いくつかの実装では、追加的な前処理状態メタデータ(たとえばヘッドフォン関係のパラメータを示すメタデータ)が、エンコーダ100から出力されるエンコードされたビットストリームのPIMペイロードに(段107によって)含められる。
【0096】
いくつかの実施形態では、エンコードされたビットストリーム(たとえば少なくとも一つのオーディオ・プログラムを示すE-AC-3ビットストリーム)のフレームに(段107によって)含められるLPSMペイロードは、以下のフォーマットでLPSMを含む:
ヘッダ(典型的にはLPSMペイロードの始まりを同定する同期語を含み、それに続いて少なくとも一つの識別情報値、たとえば下記の表2に示されるLPSMフォーマット・バージョン、長さ、期間(period)、カウントおよびサブストリーム関連付け値がくる);
ヘッダ後に、
対応するオーディオ・データがダイアログを示すかダイアログを示さないか(たとえば、対応するオーディオ・データのどのチャネルがダイアログを示すか)を示す少なくとも一つのダイアログ指示値(たとえば、表2のパラメータ「ダイアログ・チャネル」);
対応するオーディオ・データがラウドネス規制の示されるセットに準拠しているかどうかを示す少なくとも一つのラウドネス規制準拠値(たとえば、表2のパラメータ「ラウドネス規制型」);
対応するオーディオ・データに対して実行されたラウドネス処理の少なくとも一つの型を示す少なくとも一つのラウドネス処理値(たとえば、表2のパラメータ「ダイアログ・ゲーテッド・ラウドネス補正フラグ」、「ラウドネス補正型」の一つまたは複数);および
対応するオーディオ・データに特徴的な少なくとも一つのラウドネス(たとえばピークまたは平均ラウドネス)を示す少なくとも一つのラウドネス値(たとえば、パラメータ「ITU相対ゲーテッド・ラウドネス」、「ITU発話ゲーテッド・ラウドネス」、「ITU(EBU3341)短時間3sラウドネス」および「真のピーク」の一つまたは複数)。
【0097】
いくつかの実施形態では、PIMおよび/またはSSMを(および任意的には他のメタデータも)含む各メタデータ・セグメントは、メタデータ・セグメント・ヘッダを(および任意的には追加的なコア要素も)含み、該メタデータ・セグメント・ヘッダのあとに(または該メタデータ・セグメント・ヘッダおよび他のコア要素のあとに)、次のフォーマットをもつ少なくとも一つのメタデータ・ペイロード・セグメントを含む:
ペイロード・ヘッダ。典型的には少なくとも一つの識別情報値(たとえば、SSMまたはPIMフォーマット・バージョン、長さ、期間(period)、カウントおよびサブストリーム関連付け値)を含む;
ペイロード・ヘッダ後に、当該SSMまたはPIM(または他の型のメタデータ)。
【0098】
いくつかの実装では、段107によってビットストリームのフレームの余剰ビット/スキップ・フィールド・セグメント(または「addbsi」フィールドまたは補助データ・フィールド)に挿入されるメタデータ・セグメントのそれぞれは、次のフォーマットをもつ:
メタデータ・セグメント・ヘッダ(典型的にはメタデータ・セグメントの開始を同定する同期語と、それに続く識別情報値、たとえば下記の表1に示されるバージョン、長さ、期間(period)、拡張要素カウントおよびサブストリーム関連付け値を含む);および
メタデータ・セグメント・ヘッダ後に、メタデータ・セグメントのメタデータまたは対応するオーディオ・データの少なくとも一方の解読、認証(authentication)または有効確認(validation)のうちの少なくとも一つのために有用な少なくとも一つの保護値(たとえば、表1のHMACダイジェストおよびオーディオ・フィンガープリント値);および
やはりメタデータ・セグメント・ヘッダ後に後続の各メタデータ・ペイロード内のメタデータの型を同定し、それぞれのそのようなペイロードの構成の少なくとも一つの側面(たとえばサイズ)を示すメタデータ・ペイロード識別情報(「ID」)およびペイロード構成値。
【0099】
各メタデータ・ペイロードは、対応するペイロードIDおよびペイロード構成値に続く。
【0100】
いくつかの実施形態では、フレームの余剰ビット・セグメント(または補助データ・フィールドまたは「addbsi」フィールド)中の各メタデータ・セグメントは、三レベルの構造をもつ:
高レベル構造(たとえばメタデータ・セグメント・ヘッダ)。これは、余剰ビット(または補助データまたはaddbsi)フィールドがメタデータを含むかどうかを示すフラグと、どの型(単数または複数)のメタデータが存在しているかを示す少なくとも一つのID値と、典型的にはまた(メタデータが存在する場合)(たとえば各型の)何ビットのメタデータが存在するかを示す値とを含む。存在できるメタデータの一つの型はPIMであり、存在できるメタデータのもう一つの型はSSMであり、存在できるメタデータの他の型はLPSMおよび/またはプログラム境界メタデータおよび/またはメディア・リサーチ(research)・メタデータである;
中間レベル構造。これは、メタデータのそれぞれの同定される型に関連するデータを含む(たとえば、メタデータのそれぞれの同定される型についてのメタデータ・ペイロード・ヘッダ、保護値およびペイロードIDおよびペイロード構成値);および
低レベル構造。これは、それぞれの同定される型のメタデータについてのメタデータ・ペイロード(たとえば、PIMが存在すると同定されている場合のPIM値および/または他の型のメタデータが存在すると同定されている場合の該他の型のメタデータ値(たとえばSSMまたはLPSM)のシーケンス)。
【0101】
そのような三レベル構造におけるデータ値は、ネストされることができる。たとえば、高レベルおよび中間レベル構造によって同定される各ペイロード(たとえば各PIMまたはSSMまたは他のメタデータ・ペイロード)についての保護値(単数または複数)がペイロード後に(よって、該ペイロードのメタデータ・ペイロード・ヘッダ後に)含まれることができ、高レベルおよび中間レベル構造によって同定されるすべてのメタデータ・ペイロードについての保護値(単数または複数)がメタデータ・セグメント中の最終メタデータ・ペイロード後に(よって、該メタデータ・セグメントのすべてのペイロードのメタデータ・ペイロード・ヘッダ後に)含まれることができる。
【0102】
一例では(図8のメタデータ・セグメントまたは「コンテナ」を参照して後述)、メタデータ・セグメント・ヘッダは四つのメタデータ・ペイロードを同定する。図8に示されるように、メタデータ・セグメント・ヘッダはコンテナ同期語(「コンテナ同期」として同定されている)およびバージョンおよびキーID値を含む。該メタデータ・セグメント・ヘッダに続いて四つのメタデータ・ペイロードおよび保護ビットがある。第一のペイロード(たとえばPIMペイロード)についてのペイロードIDおよびペイロード構成(たとえばペイロード・サイズ)値がメタデータ・セグメント・ヘッダに続き、第一のペイロード自身が該IDおよび構成値に続き、第二のペイロード(たとえばSSMペイロード)についてのペイロードIDおよびペイロード構成(たとえばペイロード・サイズ)値が第一のペイロードに続き、第二のペイロード自身がこれらのIDおよび構成値に続き、第三のペイロード(たとえばLPSMペイロード)についてのペイロードIDおよびペイロード構成(たとえばペイロード・サイズ)値が第二のペイロードに続き、第三のペイロード自身がこれらのIDおよび構成値に続き、第四のペイロードについてのペイロードIDおよびペイロード構成(たとえばペイロード・サイズ)値が第三のペイロードに続き、第四のペイロード自身がこれらのIDおよび構成値に続き、前記ペイロードの全部または一部についての(あるいは高レベルおよび中間レベル構造についてペイロードの全部または一部についての)保護値(単数または複数)(図8では「保護データ」として同定されている)が最後のペイロードに続く。
【0103】
いくつかの実施形態では、デコーダ101が、暗号学的ハッシュをもつ本発明のある実施形態に従って生成されたオーディオ・ビットストリームを受領する場合、デコーダは、ビットストリームから決定されたデータ・ブロックからの該暗号学的ハッシュをパースして取り出すよう構成されている。前記ブロックはメタデータを含む。有効確認器102は該暗号学的ハッシュを使って、受領されたビットストリームおよび/または関連付けられたメタデータを有効確認してもよい。たとえば、有効確認器102が、参照暗号学的ハッシュと前記データ・ブロックから取り出された前記暗号学的ハッシュとの間の一致に基づいて前記メタデータが有効であると見出す場合、有効確認器102は、対応するオーディオ・データに対するプロセッサ103の動作を無効にしてもよく、選択段104にオーディオ・データを(変更なしに)素通りさせてもよい。追加的、任意的または代替的に、暗号学的ハッシュに基づく方法の代わりに他の型の暗号技法が使用されてもよい。
【0104】
図2のエンコーダ100は、(デコーダ101によって抽出されたLPSMに、任意的にはプログラム境界メタデータにも応答して)後/前処理ユニットが、ある型のラウドネス処理を、(要素105、106および107において)エンコードされるべきオーディオ・データに対して実行したことを判別してもよく、よって前に実行されたラウドネス処理において使われたおよび/または前に実行されたラウドネス処理から導出された特定のパラメータを含むラウドネス処理状態メタデータを(生成器106において)生成してもよい。いくつかの実装では、エンコーダ100は、エンコーダがオーディオ・コンテンツに対して実行された処理の型を認識する限り、オーディオ・コンテンツに対する処理履歴を示すメタデータを生成して(そしてそれから出力されるエンコードされたビットストリームに含めて)もよい。
【0105】
図3は、本発明のオーディオ処理ユニットのある実施形態であるデコーダ(200)およびそれに結合された後処理器(300)のブロック図である。後処理器(300)は、本発明のオーディオ処理ユニットの実施形態でもある。デコーダ200および後処理器300のコンポーネントまたは要素の任意のものは、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの組み合わせにおいて、一つまたは複数のプロセスおよび/または一つまたは複数の回路(たとえばASIC、FPGAまたは他の集積回路)として実装されうる。デコーダ200は、図のように接続された、フレーム・バッファ201、パーサ205、オーディオ・デコーダ202、オーディオ状態有効確認段(有効確認器)203および制御ビット生成段204を有する。典型的には、デコーダ200は他の処理要素(図示せず)も含む。
【0106】
フレーム・バッファ201(バッファ・メモリ)は、デコーダ200によって受領されるエンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを(たとえば非一時的な仕方で)記憶する。エンコードされたオーディオ・ビットストリームのフレームのシーケンスがバッファ201からパーサ205に呈される。
【0107】
パーサ205は、PIMおよび/またはSSMを(および任意的には他のメタデータ、たとえばLPSMも)、前記エンコードされた入力オーディオの各フレームから抽出し、メタデータの少なくとも一部(たとえばLPSMおよびプログラム境界メタデータ(もし抽出されるならば)および/またはPIMおよび/またはSSM)をオーディオ状態有効確認器203および段204に呈し、抽出されたメタデータを出力として(たとえば後処理器300に)呈し、エンコードされた入力オーディオからオーディオ・データを抽出し、抽出されたオーディオ・データをデコーダ202に呈するよう結合され、構成されている。
【0108】
デコーダ200に入力されるエンコードされたオーディオ・ビットストリームは、AC-3ビットストリーム、E-AC-3ビットストリームまたはドルビーEビットストリームのうちの一つであってもよい。
【0109】
図3のシステムは後処理器300をも含む。後処理器300は、フレーム・バッファ301と、バッファ301に結合された少なくとも一つの処理要素を含む他の処理要素(図示せず)とを有する。フレーム・バッファ301は、デコーダ200から後処理器300によって受領されるデコードされたオーディオ・ビットストリームの少なくとも一つのフレームを(たとえば非一時的な仕方で)記憶する。後処理器300の処理要素は、バッファ301から出力されるデコードされたオーディオ・ビットストリームのフレームのシーケンスを受領し、デコーダ200から出力されるメタデータおよび/またはデコーダ200の段204から出力される制御ビットを使って適応的に処理するよう結合され、構成されている。典型的には、後処理器300は、デコーダ200からのメタデータを使って、デコードされたオーディオ・データに対して適応的なラウドネス処理を実行するよう構成されている(たとえば、LPSM値および任意的にはプログラム境界メタデータを使った、エンコードされたオーディオ・データに対する適応的なラウドネス処理。ここで、適応的な処理は、単一のオーディオ・プログラムを示すオーディオ・データについてのLPSMによって示される、ラウドネス処理状態および/または一つまたは複数のオーディオ特性に基づいていてもよい)。
【0110】
デコーダ200および後処理器300のさまざまな実装は、本発明の方法の種々の実施形態を実行するよう構成されている。
【0111】
デコーダ200のオーディオ・デコーダ202は、パーサ205によって抽出されたオーディオ・データをデコードして、デコードされたオーディオ・データを生成し、該デコードされたオーディオ・データを出力として(たとえば後処理器300に)呈するよう構成されている。
【0112】
状態有効確認器203は、それに対して呈されるメタデータを認証し、有効確認するよう構成されている。いくつかの実施形態では、メタデータは、(たとえば本発明のある実施形態に従って)入力ビットストリームに含められたデータ・ブロックである(または該データ・ブロックに含まれる)。該ブロックは、該メタデータおよび/または基礎になるオーディオ・データ(パーサ205および/またはデコーダ202から有効確認器203に提供される)を処理するための暗号学的ハッシュ(ハッシュ・ベースのメッセージ認証コードまたは「HMAC」)を含んでいてもよい。該データ・ブロックは、これらの実施形態において、デジタル署名されてもよい。それにより、下流のオーディオ処理ユニットは比較的容易に、該処理状態メタデータを認証および有効確認しうる。
【0113】
一つまたは複数のHMACでない暗号学的方法の任意のものを含むがそれに限定されない他の暗号学的方法が、メタデータおよび/または基礎になるオーディオ・データの安全な送受信を保証するための(たとえば有効確認器203における)メタデータの有効確認のために使われてもよい。たとえば、(そのような暗号学的方法を使う)有効確認は、本発明のオーディオ・ビットストリームの実施形態を受領する各オーディオ処理ユニットにおいて実行され、ビットストリームに含まれるラウドネス処理状態メタデータおよび対応するオーディオ・データが(該メタデータによって示されるような)特定のラウドネス処理を受けている(および/または特定のラウドネス処理から帰結する)ものであり、そのような特定のラウドネス処理の実行後に修正されていないかどうかを判定することができる。
【0114】
状態有効確認器203は、有効確認動作の結果を示すために、ビット生成器204を制御する制御データを呈するおよび/または該制御データを出力として(たとえば後処理器300に)呈する。該制御データに(任意的には入力ビットストリームから抽出される他のメタデータにも)応答して、段204は次のいずれかを生成し(そして後処理器300に呈し)てもよい:
(たとえば、LPSMがデコーダ202から出力されたオーディオ・データが特定の型のラウドネス処理を受けていることを示し、有効確認器203からの制御ビットがLPSMが有効であることを示すとき)デコーダ202から出力されたデコードされたオーディオ・データが該特定の型のラウドネス処理を受けていることを示す制御ビット;または
(たとえば、LPSMがデコーダ202から出力されたオーディオ・データが特定の型のラウドネス処理を受けていないことを示す、またはLPSMがデコーダ202から出力されたオーディオ・データが特定の型のラウドネス処理を受けていることを示すが、有効確認器203からの制御ビットがLPSMが有効でないことを示すとき)デコーダ202から出力されたデコードされたオーディオ・データが該特定の型のラウドネス処理を受けるべきであることを示す制御ビット。
【0115】
あるいはまた、デコーダ200は、入力ビットストリームからデコーダ202によって抽出されたメタデータおよび入力ビットストリームからパーサ205によって抽出されたメタデータを後処理器300に呈し、後処理器300は該メタデータを使って、デコードされたオーディオ・データに対して適応的な処理を実行し、あるいは該メタデータの有効確認を実行し、次いで有効確認がLPSMが有効であることを示す場合には、該メタデータを使って、デコードされたオーディオ・データに対して適応的な処理を実行する。
【0116】
いくつかの実施形態では、デコーダ200が、暗号学的ハッシュをもつ本発明のある実施形態に従って生成されるオーディオ・ビットストリームを受領する場合、デコーダは、ビットストリームから決定されたデータ・ブロックからの該暗号学的ハッシュをパースして取り出すよう構成されている。前記ブロックは、ラウドネス処理状態メタデータ(LPSM)を含む。有効確認器203は該暗号学的ハッシュを使って、受領されたビットストリームおよび/または関連付けられたメタデータを有効確認してもよい。たとえば、有効確認器203が、参照暗号学的ハッシュと前記データ・ブロックから取り出された前記暗号学的ハッシュとの間の一致に基づいて前記LPSMが有効であると見出す場合、有効確認器203は、下流のオーディオ処理ユニット(たとえば、ボリューム平準化ユニットであるまたはボリューム平準化ユニットを含んでいてもよい後処理器300)に、ビットストリームの該オーディオ・データを(変更なしに)素通りさせるよう信号伝達してもよい。追加的、任意的または代替的に、暗号学的ハッシュに基づく方法の代わりに他の型の暗号技法が使用されてもよい。
【0117】
デコーダ200のいくつかの実装では、受領される(そしてメモリ201にバッファリングされる)エンコードされたビットストリームはAC-3ビットストリームまたはE-AC-3ビットストリームであり、オーディオ・データ・セグメント(たとえば図4に示されるフレームのAB0~AB5セグメント)およびメタデータ・セグメントを含む。ここで、オーディオ・データ・セグメントはオーディオ・データを示し、メタデータ・セグメントの少なくともいくつかの各セグメントはPIMまたはSSM(または他のメタデータ)を含む。デコーダ段202(および/またはパーサ205)は、ビットストリームから該メタデータを抽出するよう構成されている。PIMおよび/またはSSMを(および任意的には他のメタデータも)含むメタデータ・セグメントのそれぞれは、ビットストリームのフレームの余剰ビット・セグメントまたはビットストリームのフレームのビットストリーム情報(「BSI」)セグメントの「addbsi」フィールド中に、あるいはビットストリームのフレームの末尾の補助データ・フィールド(たとえば図4に示されるAUXセグメント)中に含まれる。ビットストリームのフレームは、それぞれメタデータを含む一つまたは二つのメタデータ・セグメントを含んでいてもよく、フレームが二つのメタデータ・セグメントを含む場合、一方がフレームのaddbsiフィールドに存在し、他方がフレームのAUXフィールドに存在していてもよい。
【0118】
いくつかの実施形態では、バッファ201にバッファリングされるビットストリームの各メタデータ・セグメント(本稿では時に「コンテナ」と称される)は、メタデータ・セグメント・ヘッダ(および任意的には他の必須または「コア」要素も)と、該メタデータ・セグメント・ヘッダに続く一つまたは複数のメタデータ・ペイロードとを含むフォーマットをもつ。SIMは、もし存在すれば、メタデータ・ペイロードの一つ(ペイロード・ヘッダによって同定され、典型的には第一の型のフォーマットをもつ)に含まれる。PIMは、もし存在すれば、メタデータ・ペイロードの別の一つ(ペイロード・ヘッダによって同定され、典型的には第二の型のフォーマットをもつ)に含まれる。同様に、他のそれぞれの型のメタデータは(もし存在すれば)メタデータ・ペイロードの別の一つ(ペイロード・ヘッダによって同定され、典型的にはメタデータの型に固有のフォーマットをもつ)に含まれる。この例示的なフォーマットは、デコード中以外の時に、SSM、PIMおよび他のメタデータへの便利なアクセス(たとえばデコードに続く後処理器300によるアクセスまたはエンコードされたビットストリームに対する完全なデコードを実行することなくメタデータを認識するよう構成されているプロセッサによるアクセス)を許容し、ビットストリームのデコード中の(たとえばサブストリーム識別の)便利で効率的な誤り検出および訂正を許容する。たとえば、上記例示的なフォーマットにおけるSSMへのアクセスなしでは、デコーダ200は、プログラムに関連するサブストリームの正しい数を誤って識別することがありうる。メタデータ・セグメント中のあるメタデータ・ペイロードがSSMを含んでいてもよく、該メタデータ・セグメント中の別のメタデータ・ペイロードがPIMを含んでいてもよく、任意的には、該メタデータ・セグメント中の少なくとも一つの他のメタデータ・ペイロードが他のメタデータ(たとえばラウドネス処理状態メタデータ(loudness processing state metadata)または「LPSM」)をも含んでいてもよい。
【0119】
いくつかの実施形態では、バッファ201にバッファリングされたエンコードされたビットストリーム(たとえば、少なくとも一つのオーディオ・プログラムを示すE-AC-3ビットストリーム)のフレーム内に含まれるサブストリーム構造メタデータ(SSM)ペイロードは、次のフォーマットでSSMを含む:
ペイロード・ヘッダ。これは典型的には少なくとも一つの識別情報値(たとえば、SSMフォーマット・バージョンを示す2ビット値および任意的には、長さ、期間(period)、カウントおよびサブストリーム関連付け値)を含む;
ヘッダ後に、
ビットストリームによって示されるプログラムの独立サブストリームの数を示す独立サブストリーム・メタデータ;および
プログラムの各独立サブストリームがそれに関連付けられた少なくとも一つの従属サブストリームをもつかどうかおよびもしそうであればプログラムの各独立サブストリームに関連付けられた従属サブストリームの数を示す従属サブストリーム・メタデータ。
【0120】
いくつかの実施形態では、バッファ201にバッファリングされたエンコードされたビットストリーム(たとえば、少なくとも一つのオーディオ・プログラムを示すE-AC-3ビットストリーム)のフレーム内に含まれるプログラム情報メタデータ(PIM)ペイロードは次のフォーマットをもつ:
ペイロード・ヘッダ。これは典型的には少なくとも一つの識別情報値(たとえば、PIMフォーマット・バージョンを示す値および任意的には、長さ、期間(period)、カウントおよびサブストリーム関連付け値)を含む;および
ヘッダ後に、次のフォーマットでのPIM:
オーディオ・プログラムの各無音チャネルおよび各非無音チャネル(すなわち、プログラムのどのチャネルがオーディオ情報を含むかおよび(もしあれば)どのチャネルが無音のみを含むか(典型的には当該フレームの継続時間にわたって))を示すアクティブ・チャネル・メタデータ。エンコードされたビットストリームがAC-3またはE-AC-3ビットストリームである実施形態では、プログラムのどのチャネルがオーディオ情報を含み、どのチャネルが無音を含むかを決定するために、ビットストリームのフレーム中のアクティブ・チャネル・メタデータは、ビットストリームの追加的なメタデータ(たとえば、当該フレームのオーディオ符号化モード(「acmod」)フィールドおよびもし存在すれば当該フレームもしくは関連付けられた従属サブストリーム・フレーム(単数または複数)内のchanmapフィールド)との関連で使用されてもよい;。
【0121】
プログラムが(エンコード前にまたはエンコード中に)下方混合〔減数混合〕されたものであるかどうかおよびもしそうであれば適用された下方混合の型を示す下方混合処理状態メタデータ。下方混合処理状態メタデータは、たとえば適用された下方混合の型に最もよく一致するパラメータを使ってプログラムのオーディオ・コンテンツを上方混合するために、デコーダの下流で(たとえば、後処理器300内での)上方混合を実装するために有用でありうる。エンコードされたビットストリームがAC-3またはE-AC-3ビットストリームである実施形態では、下方混合処理状態メタデータは、プログラムのチャネルに適用された下方混合(もしあれば)の型を決定するために、フレームのオーディオ符号化モード(「acmod」)フィールドとの関連で使用されてもよい;。
【0122】
プログラムがエンコード前にまたはエンコード中に(たとえばより少数のチャネルから)上方混合されたものであるかどうかおよびもしそうであれば適用された上方混合の型を示す上方混合処理状態メタデータ。上方混合処理状態メタデータは、たとえばプログラムに適用された上方混合の型(たとえば、ドルビー・プロ・ロジックまたはドルビー・プロ・ロジックII映画モードまたはドルビー・プロ・ロジックII音楽モードまたはドルビー・プロフェッショナル・アップミキサー)と互換な仕方でプログラムのオーディオ・コンテンツを下方混合するために、デコーダの下流で(後処理器内での)下方混合を実装するために有用でありうる。エンコードされたビットストリームがE-AC-3ビットストリームである実施形態では、上方混合処理状態メタデータは、プログラムのチャネルに適用された上方混合(もしあれば)の型を決定するために、他のメタデータ(たとえば当該フレームの「strmtyp」フィールドの値)との関連で使用されてもよい。(E-AC-3ビットストリームのフレームのBSIセグメント内の)「strmtyp」フィールドの値は、フレームのオーディオ・コンテンツが独立ストリーム(これはプログラムを決定する)または(複数のサブストリームを含むまたは複数のサブストリームに関連付けられているプログラムの)独立サブストリームに属し、よって当該E-AC-3ビットストリームによって示される他のどのサブストリームとも独立にデコードされうるかどうか、あるいは当該フレームのオーディオ・コンテンツが(複数のサブストリームを含むまたは複数のサブストリームに関連付けられているプログラムの)従属サブストリームに属し、よって関連付けられている独立サブストリームとの関連でデコードされる必要があるかどうかを示す;。
【0123】
当該フレームのオーディオ・コンテンツに対して(エンコードされたビットストリームを生成するためにオーディオ・コンテンツをエンコードする前に)前処理が実行されたかどうかおよびもしそうであれば実行された前処理の型を示す前処理状態メタデータ。
【0124】
いくつかの実装では、前処理状態メタデータは、以下のことを示す:
サラウンド減衰が適用されたかどうか(たとえば、オーディオ・プログラムのサラウンド・チャネルがエンコードに先立って3dB減衰されたかどうか)、
90度位相シフトが適用されたかどうか(たとえばエンコードに先立ってオーディオ・プログラムのサラウンド・チャネルLsおよびRsチャネルに)、
エンコードに先立ってオーディオ・プログラムのLFEチャネルに低域通過フィルタが適用されたかどうか、
プログラムのLFEチャネルのレベルが制作中にモニタリングされたかどうかおよびもしそうであればプログラムのフルレンジ・オーディオ・チャネルのレベルに対するLFEチャネルのモニタリングされたレベル、。
【0125】
ダイナミックレンジ圧縮が、プログラムのデコードされたオーディオ・コンテンツの各ブロックに対して(たとえばデコーダにおいて)実行されるべきであるかどうかおよびもしそうであれば実行されるべきダイナミックレンジ圧縮の型(および/またはパラメータ)(たとえば、この型の前処理状態メタデータは、エンコードされたビットストリームに含められるダイナミックレンジ圧縮制御値を生成するために、エンコーダによって、以下の圧縮プロファイル型のうちのどれが想定されたかを示してもよい:フィルム・スタンダード、フィルム・ライト、音楽スタンダード、音楽ライトまたはスピーチ。あるいはまた、この型の前処理状態メタデータは、エンコードされたビットストリームに含められるダイナミックレンジ圧縮制御値によって決定される仕方でプログラムのデコードされたオーディオ・コンテンツの各フレームに対して重度のダイナミックレンジ圧縮(「compr」圧縮)が実行されるべきであることを示してもよい)、。
【0126】
プログラムのコンテンツの特定の周波数範囲をエンコードするためにスペクトル拡張処理および/またはチャネル結合エンコードが用いられたかどうかおよびもしそうであればスペクトル拡張エンコードが実行されたコンテンツの周波数成分の最小および最大周波数およびチャネル結合エンコードが実行されたコンテンツの周波数成分の最小および最大周波数。この型の前処理状態メタデータ情報は、デコーダの下流で(後処理器内での)等化を実行するために有用でありうる。チャネル結合およびスペクトル拡張情報はいずれも、トランスコード動作および適用の際の品質を最適化するためにも有用である。たとえば、エンコーダは、スペクトル拡張およびチャネル結合情報のようなパラメータの状態に基づいてその挙動を最適化しうる(ヘッドフォン仮想化、上方混合などといった前処理段階の適応を含む)。さらに、エンコーダは、はいってくる(かつ認証された)メタデータの状態に基づく最適な値に一致および/またはするようその結合およびスペクトル拡張パラメータを動的に適応してもよい。
【0127】
ダイアログ向上調整範囲データがエンコードされたビットストリームに含まれるかどうかおよびもしそうであればオーディオ・プログラム中の非ダイアログ・コンテンツのレベルに対するダイアログ・コンテンツのレベルを調整するための(たとえばデコーダの下流の後処理器内での)ダイアログ向上処理の実行中に利用可能な調整の範囲。
【0128】
いくつかの実施形態では、バッファ201においてバッファリングされたエンコードされたビットストリーム(たとえば少なくとも一つのオーディオ・プログラムを示すE-AC-3ビットストリーム)のフレームに含まれるLPSMペイロードは、以下のフォーマットでLPSMを含む:
ヘッダ(典型的にはLPSMペイロードの始まりを同定する同期語を含み、それに続いて少なくとも一つの識別情報値、たとえば下記の表2に示されるLPSMフォーマット・バージョン、長さ、期間(period)、カウントおよびサブストリーム関連付け値がくる);
ヘッダ後に、
対応するオーディオ・データがダイアログを示すかダイアログを示さないか(たとえば、対応するオーディオ・データのどのチャネルがダイアログを示すか)を示す少なくとも一つのダイアログ指示値(たとえば、表2のパラメータ「ダイアログ・チャネル」);
対応するオーディオ・データがラウドネス規制の示されるセットに準拠しているかどうかを示す少なくとも一つのラウドネス規制準拠値(たとえば、表2のパラメータ「ラウドネス規制型」);
対応するオーディオ・データに対して実行されたラウドネス処理の少なくとも一つの型を示す少なくとも一つのラウドネス処理値(たとえば、表2のパラメータ「ダイアログ・ゲーテッド・ラウドネス補正フラグ」、「ラウドネス補正型」の一つまたは複数);および
対応するオーディオ・データに特徴的な少なくとも一つのラウドネス(たとえばピークまたは平均ラウドネス)を示す少なくとも一つのラウドネス値(たとえば、パラメータ「ITU相対ゲーテッド・ラウドネス」、「ITU発話ゲーテッド・ラウドネス」、「ITU(EBU3341)短時間3sラウドネス」および「真のピーク」の一つまたは複数)。
【0129】
いくつかの実装では、パーサ205(および/またはデコーダ段202)は、ビットストリームのフレームの余剰ビット・セグメントまたは「addbsi」フィールドまたは補助データ・フィールドから、次のフォーマットをもつ各メタデータ・セグメントを抽出するよう構成される:
メタデータ・セグメント・ヘッダ(典型的にはメタデータ・セグメントの開始を同定する同期語と、それに続く少なくとも一つの識別情報値、たとえばバージョン、長さ、期間(period)、拡張要素カウントおよびサブストリーム関連付け値を含む);および
メタデータ・セグメント・ヘッダ後に、メタデータ・セグメントのメタデータまたは対応するオーディオ・データの少なくとも一方の解読、認証(authentication)または有効確認(validation)のうちの少なくとも一つのために有用な少なくとも一つの保護値(たとえば、表1のHMACダイジェストおよびオーディオ・フィンガープリント値);および
やはりメタデータ・セグメント・ヘッダ後に後続の各メタデータ・ペイロードの型およびその構成の少なくとも一つの側面(たとえばサイズ)を同定するメタデータ・ペイロード識別情報(「ID」)およびペイロード構成値。
【0130】
各メタデータ・ペイロード(好ましくは上記で指定したフォーマットをもつ)は、対応するメタデータ・ペイロードIDおよびペイロード構成値に続く。
【0131】
より一般には、本発明の好ましい実施形態によって生成されたエンコードされたオーディオ・ビットストリームは、メタデータ要素およびサブ要素をコア(必須)または拡張(任意的)要素またはサブ要素としてラベル付けする機構を提供する構造をもつ。これは、ビットストリーム(そのメタデータを含む)のデータ・レートが数多くのアプリケーションを横断してスケールすることを許容する。好ましいビットストリーム・シンタックスのコア(必須)要素は、オーディオ・コンテンツに関連付けられた拡張(任意的)要素が存在する(帯域内(in-band))および/またはリモート位置にある(帯域外(out of band))ことを信号伝達することもできるべきである。
【0132】
コア要素(単数または複数)は、ビットストリームの全フレームに存在することが要求される。コア要素のいくつかのサブ要素は任意的であり、任意の組み合わせにおいて存在していてもよい。拡張要素は全フレームに存在することは要求されない(ビットレート・オーバーヘッドを制限するため)。このように、拡張要素は、いくつかのフレームに存在していて、他のフレームには存在しなくてもよい。拡張要素のいくつかのサブ要素は任意的であり、任意の組み合わせにおいて存在していてもよいが、拡張要素のいくつかのサブ要素は必須であってもよい(つまり、その拡張要素がビットストリームのフレームに存在するならば必須)。
【0133】
あるクラスの実施形態では、オーディオ・データ・セグメントおよびメタデータ・セグメントのシーケンスを含むエンコードされたオーディオ・ビットストリームが(たとえば、本発明を具現するオーディオ処理ユニットによって)生成される。オーディオ・データ・セグメントはオーディオ・データを示し、メタデータ・セグメントのうち少なくともいくつかのセグメントのそれぞれは、PIMおよび/またはSSMを(および任意的には少なくとも一つの他の型のメタデータも)を含み、オーディオ・データ・セグメントはメタデータ・セグメントと時分割多重される。このクラスの好ましい実施形態では、メタデータ・セグメントのそれぞれは、本稿に記載される好ましいフォーマットをもつ。
【0134】
ある好ましいフォーマットでは、エンコードされたビットストリームはAC-3ビットストリームまたはE-AC-3ビットストリームであり、SSMおよび/またはPIMを含むメタデータ・セグメントのそれぞれは、追加的なビットストリーム情報として、ビットストリームのフレームのビットストリーム情報(「BSI」)セグメントの「addbsi」フィールド(図6に示される)に、またはビットストリームのフレームの補助データ・フィールドに、またはビットストリームのフレームの余剰ビット・セグメントに(たとえばエンコーダ100の好ましい実装の段107によって)含められる。
【0135】
上記の好ましいフォーマットでは、各フレームは、メタデータ・セグメント(本稿ではメタデータ・コンテナまたはコンテナとも称される)をフレームの余剰ビット・セグメント(またはaddbsiフィールド)に含む。メタデータ・セグメントは、下記の表1に示されるフォーマットをもつ諸必須要素(まとめて「コア要素」と称される)をもつ(そして表1に示される任意的な要素を含んでいてもよい)。表1に示される必要とされる要素の少なくともいくつかは、メタデータ・セグメントのメタデータ・セグメント・ヘッダに含まれるが、メタデータ・セグメントにおける他の場所に含められてもよい。
【0136】
【表1】
該好ましいフォーマットでは、SSM、PIMまたはLPSMを含む(エンコードされたビットストリームのフレームの余剰ビット・セグメントまたはaddbsiまたは補助データ・フィールド内の)各メタデータ・セグメントは、メタデータ・セグメント・ヘッダ(および任意的には追加的なコア要素)と、メタデータ・セグメント・ヘッダのあとの(またはメタデータ・セグメント・ヘッダおよび他のコア要素のあとの)一つまたは複数のメタデータ・ペイロードとを含む。各メタデータ・ペイロードは、メタデータ・ペイロード・ヘッダ(ペイロードに含まれるメタデータの特定の型(たとえばSSM、PIMまたはLPSM)を示す)とそれに続いてその特定の型のメタデータとを含む。典型的には、メタデータ・ペイロード・ヘッダは次の値(パラメータ)を含む:
ペイロードID(メタデータの型、たとえばSSM、PIMまたはLPSMを同定する)。これは(たとえば表1において指定される値を含んでいてもよい)メタデータ・セグメント・ヘッダに続く;
ペイロード構成値(典型的にはペイロードの大きさを示す)。これはペイロードIDに続く;
任意的にはまた、追加的なペイロード構成値(たとえば、フレームの先頭から当該ペイロードに関する最初のオーディオ・サンプルまでのオーディオ・サンプル数を示すオフセット値ならびにたとえばペイロードが破棄されうる条件を示す、ペイロード優先度値)。
【0137】
典型的には、ペイロードのメタデータは次のフォーマットの一つをもつ。
【0138】
ペイロードのメタデータがSSM。これは、ビットストリームによって示されるプログラムの独立サブストリームの数を示す独立サブストリーム・メタデータと、プログラムの各独立サブストリームがそれに関連付けられた少なくとも一つの従属サブストリームをもつかどうかおよびもしそうであればプログラムの各独立サブストリームに関連付けられた従属サブストリームの数を示す従属サブストリーム・メタデータとを含む;
ペイロードのメタデータがPIM。これは、
オーディオ・プログラムのどのチャネルがオーディオ情報を含むかおよび(もしあれば)どのチャネルが無音のみを含むか(典型的には当該フレームの継続時間にわたって)を示すアクティブ・チャネル・メタデータと;プログラムが(エンコード前にまたはエンコード中に)下方混合〔減数混合〕されたものであるかどうかおよびもしそうであれば適用された下方混合の型を示す下方混合処理状態メタデータと、プログラムがエンコード前にまたはエンコード中に(たとえばより少数のチャネルから)上方混合されたものであるかどうかおよびもしそうであれば適用された上方混合の型を示す上方混合処理状態メタデータと、当該フレームのオーディオ・コンテンツに対して(エンコードされたビットストリームを生成するためにオーディオ・コンテンツをエンコードする前に)前処理が実行されたかどうかおよびもしそうであれば実行された前処理の型を示す前処理状態メタデータ;
ペイロードのメタデータはLPSMデータで、次の表(表2)に示されるフォーマットをもつ。
【0139】
【表2-1】
【表2-2】
本発明に基づいて生成されるエンコードされたビットストリームのもう一つの好ましいフォーマットでは、ビットストリームはAC-3ビットストリームまたはE-AC-3ビットストリームであり、メタデータ・セグメントのうちPIMおよび/またはSSMを(および任意的には少なくとも一つの他の型のメタデータも)含むそれぞれは:ビットストリームのフレームの余剰ビット・セグメント;またはビットストリームのフレームのビットストリーム情報(「BSI」)セグメントの「addbsi」フィールド(図6に示した);またはビットストリームのフレームの末尾の補助データ・フィールド(たとえば図4に示されるAUXセグメント)のうちの任意のものに(たとえばエンコーダ100の好ましい実装の段107によって)含められる。フレームは、それぞれがPIMおよび/またはSSMを含む一つまたは二つのメタデータ・セグメントを含んでいてもよく、(いくつかの実施形態では)フレームが二つのメタデータ・セグメントを含む場合、一方はフレームのaddbsiフィールドに存在し、他方はフレームのAUXフィールドに存在してもよい。各メタデータ・セグメントは好ましくは、上記の表1を参照して上記で規定したフォーマットをもつ(すなわち、表1に指定されるコア要素を含み、それに続いて、ペイロードID(メタデータ・セグメントの各ペイロード内のメタデータの型を同定する)およびペイロード構成値ならびに各メタデータ・ペイロードがくる)。LPSMを含む各メタデータ・セグメントは好ましくは、上記の表1および表2を参照して上記で規定したフォーマットをもつ(すなわち、表1に指定されるコア要素を含み、それに続いて、ペイロードID(当該メタデータをLPSMとして同定する)およびペイロード構成値がきて、それにペイロード(表2に示されるフォーマットをもつLPSMデータ)が続く)。
【0140】
もう一つの好ましいフォーマットでは、エンコードされたビットストリームはドルビーEビットストリームであり、メタデータ・セグメントのうちPIMおよび/またはSSMを(および任意的には他のメタデータも)含むそれぞれは、ドルビーE保護帯域区間の最初のN個のサンプル位置である。LPSMを含むそのようなメタデータ・セグメントを含むドルビーEビットストリームは、好ましくは、SMPTE 337MプリアンブルのPd語において信号伝達されるLPSMペイロード長を示す値を含む(SMPTE 337M Pa語反復レートは好ましくは、関連するビデオ・フレーム・レートと同じまま)。
【0141】
エンコードされたビットストリームがE-AC-3ビットストリームであるある好ましいフォーマットでは、メタデータ・セグメントのうちPIMおよび/またはSSMを(および任意的にはLPSMおよび/または他のメタデータも)含むそれぞれは、ビットストリームのフレームの、余剰ビット・セグメントに、またはビットストリーム情報(「BSI」)セグメントの「addbsi」フィールドにおいて、追加的なビットストリーム情報として(たとえば、エンコーダ100の好ましい実装の段107によって)含められる。次に、この好ましいフォーマットにおけるLPSMをもつE-AC-3ビットストリームのエンコードのさらなる諸側面について述べる。
【0142】
1.E-AC-3ビットストリームの生成中において、(LPSM値をビットストリーム中に挿入する)E-AC-3エンコーダが「アクティブである」間は、生成されるすべてのフレーム(同期フレーム)について、ビットストリームは、フレームのaddbsiフィールド(または余剰ビット・セグメント)において担持される(LPSMを含む)メタデータ・ブロックを含むべきである。該メタデータ・ブロックを担持するために必要とされるビットは、エンコーダ・ビットレート(フレーム長)を増大させるべきではない。
【0143】
2.(LPSMを含む)すべてのメタデータ・ブロックは、以下の情報を含むべきである:
loudness_correction_type_flag〔ラウドネス補正型フラグ〕:ここで、「1」は対応するオーディオ・データのラウドネスが当該エンコーダの上流で補正されたことを示し、「0」は該ラウドネスが当該エンコーダに組み込まれているラウドネス補正器(たとえば、図2のエンコーダ100のラウドネス処理器103)によって補正されたことを示す;
speech_channel〔発話チャネル〕:どの源チャネル(単数または複数)が(それまでの0.5秒の間に)発話を含むかを示す。発話が検出されない場合、その旨が示される;
speech_loudness〔発話ラウドネス〕:発話を含む各対応するオーディオ・チャネルの(それまでの0.5秒の間の)統合された発話ラウドネスを示す;
ITU_loudness〔ITUラウドネス〕:各対応するオーディオ・チャネルの統合されたITU BS.1770-3ラウドネスを示す;
利得:(可逆性を実証するため)デコーダにおいて反転するためのラウドネス複合利得(単数または複数)。
【0144】
3.(LPSM値をビットストリーム中に挿入する)E-AC-3エンコーダが「アクティブ」であり、「信頼」フラグをもつAC-3フレームを受領している間は、当該エンコーダにおけるラウドネス・コントローラ(たとえば図2のエンコーダ100のラウドネス処理器103)はバイパスされるべきである。「信頼される」源dialnorm〔ダイアログ正規化〕およびDRC値は(たとえばエンコーダ100の生成器106によって)E-AC-3エンコーダ・コンポーネント(たとえばエンコーダ100の段107)に渡されるべきである。LPSMブロック生成は継続し、loudness_correction_type_flagは「1」に設定される。ラウドネス・コントローラ・バイパス・シーケンスは、「信頼」フラグが現われるデコードされたAC-3フレームの先頭に同期される必要がある。ラウドネス・コントローラ・バイパス・シーケンスは次のように実装されるべきである。leveler_amount〔平準化器量〕コントロールが、10オーディオ・ブロック期間(すなわち、53.3msec)にわたって値9から値0にデクリメントされ、leveler_back_end_meter〔平準化器バック・エンド・メーター〕コントロールがバイパス・モードにされる(この動作は、シームレスな遷移を与えるべきである)。平準化器の「信頼される」バイパスという用語は、源ビットストリームのdialnorm値が、エンコーダの出力においても再利用されることを含意する(たとえば、「信頼される」源ビットストリームが-30のdialnorm値をもつ場合、エンコーダの出力は出て行くdialnorm値について-30を利用するべきである)。
(LPSM値をビットストリーム中に挿入する)E-AC-3エンコーダが「アクティブ」であり、「信頼」フラグなしのAC-3フレームを受領している間は、当該エンコーダに組み込まれたラウドネス・コントローラ(たとえば図2のエンコーダ100のラウドネス処理器103)はアクティブであるべきである。LPSMブロック生成は継続し、loudness_correction_type_flagは「0」に設定される。ラウドネス・コントローラ・アクティブ化シーケンスは、「信頼」フラグが消失するデコードされたAC-3フレームの先頭に同期されるべきである。ラウドネス・コントローラ・アクティブ化シーケンスは次のように実装されるべきである。leveler_amount〔平準化器量〕コントロールが、1オーディオ・ブロック期間(すなわち、5.3msec)にわたって値0から値9にインクリメントされ、leveler_back_end_meter〔平準化器バック・エンド・メーター〕コントロールが「アクティブ」モードにされる(この動作は、シームレスな遷移を与え、back_end_meter統合リセットを含むべきである)。
【0145】
5.エンコード中、グラフィカル・ユーザー・インターフェース(GUI)はユーザーに対して以下のパラメータを示すべきである:「入力オーディオ・プログラム[信頼される/信頼されない]」-このパラメータの状態は入力信号内の「信頼」フラグの存在に基づく;および「リアルタイム・ラウドネス補正:[有効化/無効化]」-このパラメータの状態は、エンコーダに組み込まれているこのラウドネス・コントローラがアクティブであるかどうかに基づく。
【0146】
(上記の好ましいフォーマットでは)ビットストリームの各フレームの余剰ビットもしくはスキップ・フィールド・セグメントまたはビットストリーム情報(「BSI」)セグメントの「addbsi」フィールドに含まれるLPSMを有するAC-3またはE-AC-3ビットストリームをデコードするとき、デコーダは、(余剰ビット・セグメントまたはaddbsiフィールド中の)LPSMブロック・データをパースして、抽出されたLPSM値のすべてをグラフィカル・ユーザー・インターフェース(GUI)に渡すべきである。抽出されたLPSM値の組は、フレーム毎にリフレッシュされる。
【0147】
本発明に基づいて生成されるエンコードされたビットストリームのもう一つの好ましいフォーマットでは、エンコードされたビットストリームはAC-3ビットストリームまたはE-AC-3ビットストリームであり、メタデータ・セグメントのうちPIMおよび/またはSSMを(および任意的にはLPSMおよび/または他のメタデータも)含むそれぞれは、(たとえばエンコーダ100の好ましい実装の段107によって)余剰ビット・セグメントに、またはAuxセグメントに、またはビットストリームのフレームのビットストリーム情報(「BSI」)セグメントの「addbsi」フィールド(図6に示した)における追加的なビットストリーム情報として、含められる。(表1および表2を参照して上述したフォーマットに対する変形である)このフォーマットでは、addbsi(またはAuxまたは余剰ビット)フィールドのうちLPSMを含むそれぞれは、以下のLPSM値を含む。
【0148】
表1に規定されるコア要素。それに続いてペイロードID(当該メタデータをLPSMとして同定する)およびペイロード構成値、それに続いてペイロード(LPSMデータ)。LPSMデータは次のフォーマット(上記の表2に示した必須要素と同様)をもつ。
【0149】
LPSMペイロードのバージョン:LPSMペイロードのバージョンを示す2ビット・フィールド。
【0150】
dialchan:対応するオーディオ・データの左、右および/または中央チャネルが話されたダイアログを含んでいるかどうかを示す3ビット・フィールド。dialchanフィールドのビット割り当ては次のとおりであってもよい:左チャネルにおけるダイアログの存在を示すビット0はdialchanフィールドの最上位ビットに格納され、中央チャネルにおけるダイアログの存在を示すビット2はdialchanフィールドの最下位ビットに格納される。対応するチャネルがプログラムの先行する0.5秒の間に話されるダイアログを含んでいる場合には、dialchanフィールドの各ビットが「1」に設定される。
【0151】
loudregtyp:プログラム・ラウドネスがどのラウドネス規制規格に準拠しているかを示す4ビット・フィールド。「loudregtyp」フィールドを「000」に設定することは、LPSMがラウドネス規制準拠を示さないことを示す。たとえば、このフィールドのある値(たとえば0000)は、ラウドネス規制規格への準拠が示されないことを示してもよく、このフィールドの別の値(たとえば0001)は当該プログラムのオーディオ・データがATSC A/85規格に準拠していることを示してもよく、このフィールドの別の値(たとえば0010)は当該プログラムのオーディオ・データがEBU R128規格に準拠していることを示してもよい。この例において、このフィールドが「0000」以外の何らかの値に設定される場合、loudcorrdialgatおよびloudcorrtypフィールドがペイロードのあとに続くべきである。
【0152】
loudcorrdialgat:ダイアログでゲーティングされたラウドネス補正が適用されたかどうかを示す1ビット・フィールド。プログラムのラウドネスがダイアログ・ゲーティングを使って補正されている場合には、loudcorrdialgatフィールドの値は「1」に設定される。そうでない場合には「0」に設定される。
【0153】
loudcorrtyp:プログラムに適用されたラウドネス補正の型を示す1ビット・フィールド。プログラムのラウドネスが無限先読み(ファイル・ベース)のラウドネス補正プロセスで補正されている場合には、loudcorrtypフィールドの値は「0」に設定される。プログラムのラウドネスがリアルタイム・ラウドネス測定およびダイナミックレンジ制御の組み合わせを使って補正されている場合には、このフィールドの値は「1」に設定される。
【0154】
loudrelgate:相対的なゲーティングされたラウドネス・データ(ITU)が存在するかどうかを示す1ビット・フィールド。loudrelgateフィールドが「1」に設定される場合、ペイロードにおいて、7ビットのituloudrelgatフィールドが後続するべきである。
【0155】
loudrelgat:相対的なゲーティングされたプログラム・ラウドネス(ITU)を示す7ビット・フィールド。このフィールドは、dialnormおよびダイナミックレンジ圧縮(DRC)に起因するいかなる利得調整も適用されることなく、ITU-R BS.1770-3に従って測定された、オーディオ・プログラムの統合されたラウドネスを示す。0ないし127の値は、0.5LKFSきざみで、-58LKFSから+5.5LKFSとして解釈される。
【0156】
loudspchgate:発話でゲーティングされたラウドネス・データ(ITU)が存在するかどうかを示す1ビット・フィールド。loudspchgateフィールドが「1」に設定される場合、ペイロードにおいて、7ビットのloudspchgatフィールドが後続するべきである。
【0157】
loudspchgat:発話ゲーティングされたプログラム・ラウドネスを示す7ビット・フィールド。このフィールドは、dialnormおよびダイナミックレンジ圧縮に起因するいかなる利得調整も適用されることなく、ITU-R BS.1770-3の公式(2)に従って測定された、対応するオーディオ・プログラム全体の統合されたラウドネスを示す。0ないし127の値は、0.5LKFSきざみで、-58LKFSから+5.5LKFSとして解釈される。
【0158】
loudstrm3se:短時間(3秒)ラウドネス・データが存在するかどうかを示す1ビット・フィールド。このフィールドが「1」に設定される場合、ペイロードにおいて7ビットのloudstrm3sフィールドが後続するべきである。
【0159】
loudstrm3s:dialnormおよびダイナミックレンジ圧縮に起因するいかなる利得調整も適用されることなく、ITU-R BS.1770-1に従って測定された、対応するオーディオ・プログラムの先行する3秒のゲーティングされていないラウドネスを示す7ビット・フィールド。0ないし256の値は、0.5LKFSきざみで、-116LKFSから+5.5LKFSとして解釈される。
【0160】
truepke:真のピーク・ラウドネス・データが存在するかどうかを示す、1ビット・フィールド。truepkeフィールドが「1」に設定されていたら、ペイロードにおいて8ビットのtruepkフィールドが後続するべきである。
【0161】
truepk:dialnormおよびダイナミックレンジ圧縮に起因するいかなる利得調整も適用されることなく、ITU-R BS.1770-3の付属書2に従って測定された、プログラムの真のピーク・サンプル値を示す8ビット・フィールド。0ないし256の値は、0.5LKFSきざみで、-116LKFSから+11.5LKFSとして解釈される。
【0162】
いくつかの実施形態では、AC-3ビットストリームまたはE-AC-3ビットストリームのフレームの余剰ビット・セグメントまたは補助データ(または「addbsi」)フィールドにおけるメタデータ・セグメントのコア要素は、メタデータ・セグメント・ヘッダ(典型的には識別情報値、たとえばバージョンを含む)と、該メタデータ・セグメント・ヘッダ後に:メタデータ・セグメントのメタデータについてフィンガープリント・データが(または他の保護値が)含まれるかどうかを示す値と、(当該メタデータ・セグメントのメタデータに対応するオーディオ・データに関係する)外部データが存在するかどうかを示す値と、コア要素によって同定される各型のメタデータ(たとえばPIMおよび/またはSSMおよび/またはLPSMおよび/またはある型のメタデータ)についてのペイロードIDおよびペイロード構成値と、メタデータ・セグメント・ヘッダ(またはメタデータ・セグメントの他のコア要素)によって同定されるメタデータの少なくとも一つの型についての保護値とを含む。メタデータ・セグメントのメタデータ・ペイロード(単数または複数)は、メタデータ・セグメント・ヘッダに続き、(場合によっては)メタデータ・セグメントのコア要素内にネストされる。
【0163】
本発明の実施形態は、ハードウェア、ファームウェアまたはソフトウェアまたは両者の組み合わせにおいて(たとえばプログラム可能な論理アレイとして)実装されてもよい。特に断わりのない限り、本発明の一部として含まれるアルゴリズムまたはプロセスは、いかなる特定のコンピュータまたは他の装置にも本来的に関係していない。特に、さまざまな汎用機械が、本願の教示に従って書かれたプログラムとともに使用されてもよく、あるいは必要とされる方法ステップを実行するためにより特化した装置(たとえば集積回路)を構築することがより便利であることがある。このように、本発明は、一つまたは複数のプログラム可能なコンピュータ・システム(たとえば、図1の諸要素または図2のエンコーダ100(またはその要素)または図3のデコーダ200(またはその要素)または図3の後処理器(またはその要素)のうちの任意のものの実装)上で実行される一つまたは複数のコンピュータ・プログラムにおいて実装されてもよい。各コンピュータ・システムは、少なくとも一つのプロセッサ、少なくとも一つのデータ記憶システム(揮発性および不揮発性メモリおよび/または記憶要素を含む)、少なくとも一つの入力装置またはポートおよび少なくとも一つの出力装置またはポートを有する。本稿に記載される機能を実行し、出力情報を生成するようプログラム・コードが入力データに適用される。出力情報は、既知の仕方で一つまたは複数の出力装置に適用される。
【0164】
そのような各プログラムは、コンピュータ・システムと通信するためにいかなる所望されるコンピュータ言語(機械、アセンブリーまたは高水準手続き型、論理的またはオブジェクト指向のプログラミング言語を含む)において実装されてもよい。いずれの場合にも、言語はコンパイルされる言語でもインタープリットされる言語でもよい。
【0165】
たとえば、コンピュータ・ソフトウェア命令のシーケンスによって実装されるとき、本発明の実施形態のさまざまな機能および段階は、好適なデジタル信号処理ハードウェアにおいて実行されるマルチスレッド式のソフトウェア命令シーケンスによって実装されてもよく、その場合、実施形態のさまざまな装置、段階および機能は、ソフトウェア命令の諸部分に対応してもよい。
【0166】
そのような各コンピュータ・プログラムは好ましくは、汎用または専用のプログラム可能なコンピュータによって読み取り可能な記憶媒体またはデバイス(たとえば半導体メモリまたはメディアまたは磁気式もしくは光学式メディア)に記憶されるまたはダウンロードされ、記憶媒体またはデバイスがコンピュータ・システムによって読まれたときに、本稿に記載される手順を実行するようコンピュータを構成するまたは動作させる。本発明のシステムは、コンピュータ・プログラムをもって構成された(すなわちコンピュータ・プログラムを記憶している)コンピュータ可読記憶媒体として実装されてもよく、そのように構成された記憶媒体はコンピュータ・システムに、本稿に記載される機能を実行するよう特定のあらかじめ定義された仕方で動作させる。
【0167】
本発明のいくつかの実施形態を記述してきたが、本発明の精神および範囲から外れることなくさまざまな修正がなしうることは理解されるであろう。上記の教示に照らして、本発明の数多くの修正および変形が可能である。付属の請求項の範囲内で、本発明が、本稿で具体的に記載される以外の仕方で実施されてもよいことは理解される。
【0168】
いくつかの態様を記載しておく。
〔態様1〕
バッファ・メモリと該バッファ・メモリに結合された少なくとも一つの処理サブシステムとを含むオーディオ処理ユニットであって、
前記バッファ・メモリは、エンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを記憶し、前記フレームは、前記フレームの少なくとも一つのスキップ・フィールドの少なくとも一つのメタデータ・セグメントにおいてプログラム情報メタデータまたはサブストリーム構造メタデータを、前記フレームの少なくとも一つの他のセグメントにおいてオーディオ・データを含み、
前記処理サブシステムは、前記ビットストリームの生成、前記ビットストリームのデコードまたは前記ビットストリームのメタデータを使った前記ビットストリームのオーディオ・データの適応的な処理または前記ビットストリームのメタデータを使った前記ビットストリームのオーディオ・データもしくはメタデータの少なくとも一方の認証もしくは検証の少なくとも一方、のうちの少なくとも一つを実行するよう結合され、構成されており、
前記メタデータ・セグメントは少なくとも一つのメタデータ・ペイロードを含み、前記メタデータ・ペイロードは:
ヘッダと;
前記ヘッダ後に、前記プログラム情報メタデータの少なくとも一部または前記サブストリーム構造メタデータの少なくとも一部を含む、
オーディオ処理ユニット。
〔態様2〕
前記エンコードされたオーディオ・ビットストリームが少なくとも一つのオーディオ・プログラムを示し、前記メタデータ・セグメントはプログラム情報メタデータ・ペイロードを含み、前記プログラム情報メタデータ・ペイロードは:
プログラム情報メタデータ・ヘッダと;
前記プログラム情報メタデータ・ヘッダ後に、前記プログラムのオーディオ・コンテンツの少なくとも一つの属性または特性を示すプログラム情報メタデータとを含み、
前記プログラム情報メタデータは、前記プログラムの各非無音チャネルおよび各無音チャネルを示すアクティブ・チャネル・メタデータを含む、
態様1記載のオーディオ処理ユニット。
〔態様3〕
前記プログラム情報メタデータは:
前記プログラムが下方混合されたものであるかどうかおよびもしそうであれば前記プログラムに適用された下方混合の型を示す下方混合処理状態メタデータ;
前記プログラムが上方混合されたものであるかどうかおよびもしそうであれば前記プログラムに適用された上方混合の型を示す上方混合処理状態メタデータ;
前記フレームのオーディオ・コンテンツに対して前処理が実行されたかどうかおよびもしそうであれば前記オーディオ・コンテンツに対して実行された前処理の型を示す前処理状態メタデータ;または
前記プログラムにスペクトル拡張処理またはチャネル結合が適用されたかどうかおよびもしそうであれば前記スペクトル拡張またはチャネル結合が適用された周波数範囲を示すスペクトル拡張処理またはチャネル結合メタデータ、
のうちの少なくとも一つをも含む、態様2記載のオーディオ処理ユニット。
〔態様4〕
前記エンコードされたオーディオ・ビットストリームは、オーディオ・コンテンツの少なくとも一つの独立サブストリームをもつ少なくとも一つのオーディオ・プログラムを示し、前記メタデータ・セグメントはサブストリーム構造メタデータ・ペイロードを含み、前記サブストリーム構造メタデータ・ペイロードは:
サブストリーム構造メタデータ・ペイロード・ヘッダと;
前記サブストリーム構造メタデータ・ペイロード・ヘッダの後に、前記プログラムの独立サブストリームの数を示す独立サブストリーム・メタデータおよび前記プログラムの各独立サブストリームが少なくとも一つの関連付けられた従属サブストリームをもつかどうかを示す従属サブストリーム・メタデータとを含む、
態様1記載のオーディオ処理ユニット。
〔態様5〕
前記メタデータ・セグメントが:
メタデータ・セグメント・ヘッダと;
前記メタデータ・セグメント・ヘッダの後に、前記プログラム情報メタデータまたは前記サブストリーム構造メタデータまたは前記プログラム情報メタデータもしくは前記サブストリーム構造メタデータに対応するオーディオ・データのうちの少なくとも一つの解読、認証または有効確認のうちの少なくとも一つのために有用な少なくとも一つのために有用な保護値と;
前記メタデータ・セグメント・ヘッダ後に、メタデータ・ペイロード識別情報およびペイロード構成値とを含み、前記メタデータ・ペイロードは前記メタデータ・ペイロード識別情報およびペイロード構成値に後続する、
態様1記載のオーディオ処理ユニット。
〔態様6〕
前記メタデータ・セグメントが、前記メタデータ・セグメントの始まりを同定する同期語と、該同期語に続いて少なくとも一つの識別情報値とを含み、前記メタデータ・ペイロードのヘッダが少なくとも一つの識別情報値を含む、態様5記載のオーディオ処理ユニット。
〔態様7〕
前記エンコードされたオーディオ・ビットストリームがAC-3ビットストリームまたはE-AC-3ビットストリームである、態様1記載のオーディオ処理ユニット。
〔態様8〕
前記バッファ・メモリが前記フレームを非一時的な仕方で記憶する、態様1記載のオーディオ処理ユニット。
〔態様9〕
前記オーディオ処理ユニットがエンコーダである、態様1記載のオーディオ処理ユニット。
〔態様10〕
前記処理サブシステムが:
入力オーディオ・ビットストリームを受領して、該入力オーディオ・ビットストリームから入力メタデータおよび入力オーディオ・データを抽出するよう構成されているデコード・サブシステムと;
前記入力メタデータを使って前記入力オーディオ・データに対して適応処理を実行し、それにより処理されたオーディオ・データを生成するよう結合され、構成されている適応処理サブシステムと;
前記エンコードされたオーディオ・ビットストリーム中に前記プログラム情報メタデータまたは前記サブストリーム構造メタデータを含めることによることを含め、前記処理されたオーディオ・データに応答して前記エンコードされたオーディオ・ビットストリームを生成し、前記エンコードされたオーディオ・ビットストリームを前記バッファ・メモリに呈するよう結合され、構成されているエンコード・サブシステムとを含む、
態様9記載のオーディオ処理ユニット。
〔態様11〕
前記オーディオ処理ユニットがデコーダである、態様1記載のオーディオ処理ユニット。
〔態様12〕
前記処理サブシステムが、前記バッファ・メモリに結合され、前記エンコードされたオーディオ・ビットストリームから前記プログラム情報メタデータまたは前記サブストリーム構造メタデータを抽出するよう構成されているデコード・サブシステムである、態様11記載のオーディオ処理ユニット。
〔態様13〕
前記バッファ・メモリに結合され、前記エンコードされたオーディオ・ビットストリームから前記プログラム情報メタデータまたは前記サブストリーム構造メタデータを抽出し、前記エンコードされたオーディオ・ビットストリームから前記オーディオ・データを抽出するよう構成されているサブシステムと;
前記サブシステムに結合され、前記エンコードされたオーディオ・ビットストリームから抽出された前記プログラム情報メタデータまたは前記サブストリーム構造メタデータの少なくとも一つを使って前記オーディオ・データに対して適応処理を実行するよう構成されている後処理器とを含む、
態様1記載のオーディオ処理ユニット。
〔態様14〕
前記オーディオ処理ユニットがデジタル信号プロセッサである、態様1記載のオーディオ処理ユニット。
〔態様15〕
当該オーディオ処理ユニットが、前記エンコードされたオーディオ・ビットストリームから前記プログラム情報メタデータまたは前記サブストリーム構造メタデータおよび前記オーディオ・データを抽出し、前記エンコードされたオーディオ・ビットストリームから抽出された前記プログラム情報メタデータまたは前記サブストリーム構造メタデータの少なくとも一つを使って前記オーディオ・データに対して適応処理を実行するよう構成されている前処理器である、態様1記載のオーディオ処理ユニット。
〔態様16〕
エンコードされたビットストリームをデコードする方法であって:
エンコードされたオーディオ・ビットストリームを受領する段階と;
前記エンコードされたオーディオ・ビットストリームからメタデータおよびオーディオ・データを抽出する段階であって、前記メタデータはプログラム情報メタデータおよびサブストリーム構造メタデータであるまたはプログラム情報メタデータおよびサブストリーム構造メタデータを含む、段階とを含み、
前記エンコードされたオーディオ・ビットストリームはフレームのシーケンスを含み、少なくとも一つのオーディオ・プログラムを示し、前記プログラム情報メタデータおよび前記サブストリーム構造メタデータは前記プログラムを示し、各フレームは、少なくとも一つのオーディオ・データ・セグメントを含み、前記オーディオ・データ・セグメントのそれぞれは前記オーディオ・データの少なくとも一部を含み、前記フレームの少なくとも部分集合の各フレームはメタデータ・セグメントを含み、前記メタデータ・セグメントのそれぞれは前記プログラム情報メタデータの少なくとも一部および前記サブストリーム構造メタデータの少なくとも一部を含む、
方法。
〔態様17〕
前記メタデータ・セグメントはプログラム情報メタデータ・ペイロードを含み、前記プログラム情報メタデータ・ペイロードは:
プログラム情報メタデータ・ヘッダと;
前記プログラム情報メタデータ・ヘッダ後に、前記プログラムのオーディオ・コンテンツの少なくとも一つの属性または特性を示すプログラム情報メタデータとを含み、
前記プログラム情報メタデータは、前記プログラムの各非無音チャネルおよび各無音チャネルを示すアクティブ・チャネル・メタデータを含む、
態様16記載の方法。
〔態様18〕
前記プログラム情報メタデータは:
前記プログラムが下方混合されたものであるかどうかおよびもしそうであれば前記プログラムに適用された下方混合の型を示す下方混合処理状態メタデータ;
前記プログラムが上方混合されたものであるかどうかおよびもしそうであれば前記プログラムに適用された上方混合の型を示す上方混合処理状態メタデータ;または
前記フレームのオーディオ・コンテンツに対して前処理が実行されたかどうかおよびもしそうであれば前記オーディオ・コンテンツに対して実行された前処理の型を示す前処理状態メタデータ
のうちの少なくとも一つをも含む、態様17記載の方法。
〔態様19〕
前記エンコードされたオーディオ・ビットストリームは、オーディオ・コンテンツの少なくとも一つの独立サブストリームをもつ少なくとも一つのオーディオ・プログラムを示し、前記メタデータ・セグメントはサブストリーム構造メタデータ・ペイロードを含み、前記サブストリーム構造メタデータ・ペイロードは:
サブストリーム構造メタデータ・ペイロード・ヘッダと;
前記サブストリーム構造メタデータ・ペイロード・ヘッダの後に、前記プログラムの独立サブストリームの数を示す独立サブストリーム・メタデータおよび前記プログラムの各独立サブストリームが少なくとも一つの関連付けられた従属サブストリームをもつかどうかを示す従属サブストリーム・メタデータとを含む、
態様16記載の方法。
〔態様20〕
前記メタデータ・セグメントが:
メタデータ・セグメント・ヘッダと;
前記メタデータ・セグメント・ヘッダの後に、前記プログラム情報メタデータまたは前記サブストリーム構造メタデータまたは前記プログラム情報メタデータおよび前記サブストリーム構造メタデータに対応するオーディオ・データのうちの少なくとも一つの解読、認証または有効確認のうちの少なくとも一つのために有用な少なくとも一つの保護値と;
前記メタデータ・セグメント・ヘッダ後に、前記プログラム情報メタデータの前記少なくとも一部および前記サブストリーム構造メタデータの前記少なくとも一部を含むメタデータ・ペイロードとを含む、
態様16記載の方法。
〔態様21〕
前記エンコードされたオーディオ・ビットストリームがAC-3ビットストリームまたはE-AC-3ビットストリームである、態様16記載の方法。
〔態様22〕
前記エンコードされたオーディオ・ビットストリームから抽出された前記プログラム情報メタデータまたは前記サブストリーム構造メタデータの少なくとも一方を使って前記オーディオ・データに対して適応処理を実行する段階をも含む、
態様16記載の方法。
図1
図2
図3
図4
図5
図6
図7
図8