6371340 プログラム・ラウドネスおよび境界メタデータをもつオーディオ・エンコーダおよびデコーダ

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6371340

(24)【登録日】2018年7月20日

(45)【発行日】2018年8月8日

(54)【発明の名称】プログラム・ラウドネスおよび境界メタデータをもつオーディオ・エンコーダおよびデコーダ

(51)【国際特許分類】

   G10L 19/00 20130101AFI20180730BHJP

【ＦＩ】

   G10L19/00 330B

   G10L19/00 400Z

【請求項の数】16

【全頁数】53

(21)【出願番号】特願2016-133170(P2016-133170)

(22)【出願日】2016年7月5日

(62)【分割の表示】特願2015-537032(P2015-537032)の分割

【原出願日】2014年1月15日

(65)【公開番号】特開2016-191941(P2016-191941A)

(43)【公開日】2016年11月10日

【審査請求日】2016年12月1日

(31)【優先権主張番号】61/754,882

(32)【優先日】2013年1月21日

(33)【優先権主張国】US

(31)【優先権主張番号】61/824,010

(32)【優先日】2013年5月16日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】507236292

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】グラント，マイケル

(72)【発明者】

【氏名】ノークロス，スコット グレゴリー

(72)【発明者】

【氏名】リードミラー，ジェフリー

(72)【発明者】

【氏名】ワード，マイケル

【審査官】 菊池 智紀

(56)【参考文献】

【文献】 特表２００８−５３６１９３（ＪＰ，Ａ）

【文献】 特開２０１０−１５２２８１（ＪＰ，Ａ）

【文献】 国際公開第２００４／０７７４０６（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ１０Ｌ １９／００−２１／０６

(57)【特許請求の範囲】

【請求項1】

オーディオ処理ユニットであって：
エンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを記憶するよう構成されたバッファ・メモリであって、前記エンコードされたオーディオ・ビットストリームはオーディオ・データおよびメタデータ・コンテナを含み、前記メタデータ・コンテナはヘッダおよび該ヘッダ後の一つまたは複数のメタデータ・ペイロードを含み、前記一つまたは複数のメタデータ・ペイロードは前記オーディオ・データのラウドネス処理状態を示すメタデータを含み、前記オーディオ・データのラウドネス処理状態を示す前記メタデータは、前記オーディオ・データに対して実行されたラウドネス処理の少なくとも一つの型を示すメタデータであるまたはそのようなメタデータを示す、バッファ・メモリと；
前記バッファ・メモリに結合された、前記エンコードされたオーディオ・ビットストリームをパースするよう構成された、パーサと；
前記パーサに結合された、前記オーディオ・データのラウドネス処理状態を示す前記メタデータの少なくとも一部を使って適応的なラウドネス処理を実行するよう構成されている、サブシステムとを有し、前記適応的なラウドネス処理は、前記オーディオ・データのラウドネス処理状態を示す前記メタデータの前記少なくとも一部が前記オーディオ・データに対してラウドネス処理がすでに実行されているのではないことを示す場合は前記ラウドネス処理を実行し、前記オーディオ・データのラウドネス処理状態を示す前記メタデータの前記少なくとも一部が前記オーディオ・データに対して前記ラウドネス処理がすでに実行されていることを示す場合は前記ラウドネス処理を実行しないことを含む、
オーディオ処理ユニット。

【請求項2】

前記オーディオ・データのラウドネス処理状態を示す前記メタデータは、前記オーディオ・データの少なくとも一つのラウドネスまたはダイナミックレンジ特性を示すメタデータを含む、請求項１記載のオーディオ処理ユニット。

【請求項3】

前記ラウドネス処理を実行することがさらにダイナミックレンジ制御を実行することを含む、請求項１記載のオーディオ処理ユニット。

【請求項4】

前記オーディオ・データをデコードし、それにより、デコードされたオーディオ・データを生成するよう結合され、構成されているオーディオ・デコーダをも含む、
請求項１記載のオーディオ処理ユニット。

【請求項5】

前記パーサに結合された前記サブシステムが前記オーディオ・デコーダにも結合されており、前記サブシステムは、前記オーディオ・データのラウドネス処理状態を示す前記メタデータの少なくとも一部を使って、前記デコードされたオーディオ・データの少なくとも一部に対して前記適応的なラウドネス処理を実行するよう構成されている、請求項４記載のオーディオ処理ユニット。

【請求項6】

前記ラウドネス処理を実行することがさらにダイナミックレンジ制御を実行することを含む、請求項５記載のオーディオ処理ユニット。

【請求項7】

前記一つまたは複数のメタデータ・ペイロードが、前記オーディオ・データに関連するオーディオ・プログラムの測定されたラウドネスを示すデータを含むプログラム・ラウドネス・ペイロードを含み、前記パーサに結合された前記サブシステムが前記オーディオ・デコーダにも結合されており、前記サブシステムは、前記プログラム・ラウドネス・ペイロードに基づいて、前記オーディオ・データの少なくとも一部に対するラウドネス処理を適応させるよう構成されている、請求項４記載のオーディオ処理ユニット。

【請求項8】

前記一つまたは複数のメタデータ・ペイロードが、前記オーディオ・データに関連するオーディオ・プログラムの測定されたラウドネスを示すデータを含むプログラム・ラウドネス・ペイロードを含む、請求項１記載のオーディオ処理ユニット。

【請求項9】

前記プログラム・ラウドネス・ペイロードが、前記プログラム・ラウドネス・ペイロードに含まれるラウドネス・データを生成するために使われたラウドネス測定方法を示すフィールドを含む、請求項８記載のオーディオ処理ユニット。

【請求項10】

オーディオ処理方法であって：
一つまたは複数のフレームにセグメント分割されている、エンコードされたオーディオ・ビットストリームを受領する段階と；
前記エンコードされたオーディオ・ビットストリームからオーディオ・データおよびメタデータのコンテナを抽出する段階であって、前記メタデータのコンテナは、ヘッダおよび該ヘッダ後の一つまたは複数のメタデータ・ペイロードを含み、前記一つまたは複数のメタデータ・ペイロードは前記オーディオ・データのラウドネス処理状態を示すメタデータを含み、前記オーディオ・データのラウドネス処理状態を示す前記メタデータは、前記オーディオ・データに対して実行されたラウドネス処理の少なくとも一つの型を示すメタデータであるまたはそのようなメタデータを含む、段階と；
前記オーディオ・データのラウドネス処理状態を示す前記メタデータの少なくとも一部を使って適応的なラウドネス処理を実行する段階とを含み、前記適応的なラウドネス処理は、前記オーディオ・データのラウドネス処理状態を示す前記メタデータの前記少なくとも一部が前記オーディオ・データに対してラウドネス処理がすでに実行されているのではないことを示す場合は前記ラウドネス処理を実行し、前記オーディオ・データのラウドネス処理状態を示す前記メタデータの前記少なくとも一部が前記オーディオ・データに対して前記ラウドネス処理がすでに実行されていることを示す場合は前記ラウドネス処理を実行しないことを含む、
方法。

【請求項11】

前記オーディオ・データのラウドネス処理状態を示す前記メタデータは、前記オーディオ・データの少なくとも一つのラウドネスまたはダイナミックレンジ特性を示すメタデータを含む、請求項１０記載の方法。

【請求項12】

前記オーディオ・データがエンコードされたオーディオ・データであり、
前記エンコードされたオーディオ・データをデコードし、デコードされたオーディオ・データを生成する段階をも含む、
請求項１０記載の方法。

【請求項13】

適応的なラウドネス処理を実行する前記段階が、前記オーディオ・データのラウドネス処理状態を示す前記メタデータの少なくとも一部を使って、前記デコードされたオーディオ・データの少なくとも一部に対して前記適応的なラウドネス処理を実行することを含む、請求項１２記載の方法。

【請求項14】

前記ラウドネス処理を実行することがさらにダイナミックレンジ制御を実行することを含む、請求項１３記載の方法。

【請求項15】

前記一つまたは複数のメタデータ・ペイロードが、前記オーディオ・データに関連するオーディオ・プログラムの測定されたラウドネスを示すデータを含むプログラム・ラウドネス・ペイロードを含み、適応的なラウドネス処理を実行する前記段階が、前記プログラム・ラウドネス・ペイロードに基づいて、前記エンコードされたオーディオ・ビットストリームから抽出された前記オーディオ・データの少なくとも一部に対するラウドネス処理を適応させることを含む、請求項１０記載の方法。

【請求項16】

前記ラウドネス処理を実行することがさらにダイナミックレンジ制御を実行することを含む、請求項１０記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願への相互参照
本願は2013年1月21日に出願された米国仮特許出願第61/754,882号および2013年5月16日に出願された米国仮特許出願第61/824,010号の優先権を主張するものである。各出願はここに引用によってその全体において組み込まれる。

【0002】

技術分野
本発明は、オーディオ信号処理に、より詳細にはオーディオ・コンテンツのラウドネス処理状態および当該ビットストリームによって示されるオーディオ・プログラム境界の位置を示すメタデータをもつ、オーディオ・データ・ビットストリームのエンコードおよびデコードに関する。本発明のいくつかの実施形態は、AC-3、向上AC-3またはE-AC-3またはドルビーEとして知られるフォーマットの一つになっているオーディオ・データを生成またはデコードする。

【背景技術】

【0003】

ドルビー、ドルビー・デジタル、ドルビー・デジタル・プラスおよびドルビーEはドルビー・ラボラトリーズ・ライセンシング・コーポレイションの商標である。ドルビー・ラボラトリーズはそれぞれドルビー・デジタルおよびドルビー・デジタル・プラスとして知られるAC-3およびE-AC-3の独自の実装を提供している。

【0004】

オーディオ・データ処理ユニットは典型的には、盲目的な仕方で動作し、データが受領される前に行なわれるオーディオ・データの処理履歴には注意を払わない。これは、単一エンティティが多様な目標メディア・レンダリング装置のためのすべてのオーディオ・データ処理およびエンコードを行ない、目標メディア・レンダリング装置がエンコードされたオーディオ・データのすべてのデコードおよびレンダリングを行なう処理フレームワークでは機能するかもしれない。しかしながら、この盲目的な処理は、複数のオーディオ処理ユニットが多様ネットワークを横断して分散しているまたは縦続的に（チェーンに）配置されていて、それぞれの型のオーディオ処理を最適に実行することが期待される状況では、うまく機能しない（または全く機能しない）。たとえば、一部のオーディオ・データは高性能メディア・システムのためにエンコードされていることがあり、メディア処理チェーンに沿ってモバイル装置に好適な軽減された形に変換される必要があることがある。よって、オーディオ処理ユニットは、すでに実行されている型の処理を該オーディオ・データに対して不必要に実行することがある。たとえば、ボリューム平準化（leveling）ユニットは、入力オーディオ・クリップに対して、以前に該入力オーディオ・クリップに対して同じまたは同様のボリューム平準化が実行されているか否かに関わりなく、処理を実行する。結果として、ボリューム平準化ユニットは、必要でないときにも平準化を実行することがある。この不必要な処理は、オーディオ・データ中のコンテンツをレンダリングする際に、特定の特徴の劣化および／または除去を引き起こすこともある。

【0005】

オーディオ・データの典型的なストリームは、オーディオ・コンテンツ（たとえば一つまたは複数のチャネルのオーディオ・コンテンツ）および該オーディオ・コンテンツの少なくとも一つの特性を示すメタデータの両方を含む。たとえば、AC-3ビットストリームでは、聴取環境に送達されるプログラムの音を変える際に使うよう特に意図されているいくつかのオーディオ・メタデータ・パラメータがある。メタデータ・パラメータの一つはDIALNORMパラメータである。これはオーディオ・プログラムに現われるダイアログの平均レベルを示すことが意図されており、オーディオ再生信号レベルを決定するために使われる。

【0006】

種々のオーディオ・プログラム・セグメント（それぞれ異なるDIALNORMパラメータをもつ）のシーケンスを有するビットストリームの再生中、AC-3デコーダは各セグメントのDIALNORMパラメータを使って、該セグメントのシーケンスのダイアログの知覚されるラウドネスが一貫したレベルにあるよう再生レベルまたはラウドネスを修正するような型のラウドネス処理を実行する。エンコードされたオーディオ・アイテムのシーケンスにおける各エンコードされたオーディオ・セグメント（アイテム）は、（一般に）異なるDIALNORMパラメータをもち、デコーダは、各アイテムについてのダイアログの再生レベルまたはラウドネスが同じであるまたは非常に似通っているよう各アイテムのレベルをスケーリングする。ただし、これは再生中に、異なるアイテムに異なる量の利得を適用することを要求することがある。

【0007】

DIALNORMは典型的にはユーザーによって設定され、自動的に生成されるのではない。ただし、ユーザーによって値が設定されていない場合には、デフォルトのDIALNORM値がある。たとえば、コンテンツ・クリエーターは、AC-3エンコーダの外部の装置を用いてラウドネス測定を行ない、次いで（オーディオ・プログラムの話されるダイアログのラウドネスを示す）結果を、DIALNORM値を設定するようエンコーダに転送してもよい。このように、DIALNORMパラメータを正しく設定するには、コンテンツ・クリエーターに頼っている。

【0008】

AC-3ビットストリーム中のDIALNORMパラメータがなぜ正しくないことがあるかについてはいくつかの異なる理由がある。第一に、各AC-3エンコーダは、DIALNORM値がコンテンツ・クリエーターによって設定されない場合にビットストリームの生成中に使われるデフォルトのDIALNORM値をもつ。このデフォルト値は、オーディオの実際のダイアログ・ラウドネス・レベルとは実質的に異なることがある。第二に、たとえコンテンツ・クリエーターがラウドネスを測定してDIALNORM値をしかるべく設定したとしても、推奨されるAC-3ラウドネス測定方法に準拠しないラウドネス測定アルゴリズムまたはメーターが使われ、その結果正しくないDIALNORM値を与えた可能性がある。第三に、AC-3ビットストリームが、コンテンツ・クリエーターによって測定され正しく設定されたDIALNORM値をもって生成されたとしても、ビットストリームの伝送および／または記憶の間に正しくない値に変更された可能性がある。たとえば、テレビジョン放送アプリケーションでは、AC-3ビットストリームがデコードされ、修正され、次いで正しくないDIALNORMメタデータ情報を使ってエンコードされることはめずらしくない。このように、AC-3ビットストリームに含まれるDIALNORM値は正しくないまたは不正確であることがあり、よって聴取経験の品質に対してマイナスの影響をもつことがある。

【0009】

さらに、DIALNORMパラメータは、対応するオーディオ・データのラウドネス処理状態（たとえば、どんな型（単数または複数）のラウドネス処理がそのオーディオ・データに対して実行されたか）を示さない。本発明まで、オーディオ・ビットストリームは、オーディオ・ビットストリームのオーディオ・コンテンツのラウドネス処理状態（たとえば、それに適用されたラウドネス処理の型（単数または複数））またはビットストリームのオーディオ・コンテンツのラウドネス処理状態およびラウドネスを本開示に記述される型のフォーマットで示すメタデータを含まなかった。そのようなフォーマットにおけるラウドネス処理メタデータは、オーディオ・ビットストリームの適応ラウドネス処理および／またはオーディオ・コンテンツのラウドネス処理状態およびラウドネスの有効性の検証を、特に効率的な仕方で容易にするために有用である。

【0010】

本発明はAC-3ビットストリーム、E-AC-3ビットストリームまたはドルビーEビットストリームと一緒の使用に限定されるものではないが、便宜上、ラウドネス処理状態メタデータを含むそのようなビットストリームを生成、デコードまたは他の仕方で処理する実施形態において記述される。

【0011】

AC-3エンコードされたビットストリームはメタデータおよび一ないし六個のチャネルのオーディオ・コンテンツを含む。オーディオ・コンテンツは、知覚的オーディオ符号化を使って圧縮されたオーディオ・データである。メタデータは、聴取環境に送達されるプログラムの音を変える際に使うために意図されているいくつかのオーディオ・メタデータ・パラメータを含む。

【0012】

AC-3（ドルビー・デジタルとしても知られる）符号化の詳細はよく知られており、非特許文献１、特許文献１、２、３、４、５を含む多くの刊行物で記述されている。そのすべてはここに参照によってその全体において組み込まれる。

【0013】

ドルビー・デジタル・プラス（E-AC-3）の詳細は、非特許文献２に記載されている。

【0014】

ドルビーE符号化の詳細は、非特許文献３および非特許文献４に記載されている。

【0015】

AC-3エンコードされたオーディオ・ビットストリームの各フレームは、デジタル・オーディオの1536サンプルについてのオーディオ・コンテンツおよびメタデータを含む。48kHzのサンプリング・レートについては、これは32ミリ秒のデジタル・オーディオまたはオーディオの31.25フレーム毎秒のレートを表わす。

【0016】

E-AC-3エンコードされたオーディオ・ビットストリームの各フレームは、フレームに含まれるオーディオ・データが一、二、三または六ブロックのいずれであるかに依存して、それぞれデジタル・オーディオの256、512、768または1536サンプルについてのオーディオ・コンテンツおよびメタデータを含む。48kHzのサンプリング・レートについては、これはそれぞれ5.333、10.667、16または32ミリ秒のデジタル・オーディオまたはそれぞれオーディオの189.9、93.75、62.5または31.25フレーム毎秒のレートを表わす。

【0017】

図４に示されるように、各AC-3フレームはセクション（セグメント）に分割される。セクションは、（図５に示されるように）同期語（SW）および二つの誤り訂正語のうち第一のもの（CRC1）を含む同期情報（SI）セクションと；メタデータの大半を含むビットストリーム情報（BSI）セクションと；データ圧縮されたオーディオ・コンテンツを含む（そしてメタデータも含むことができる）六つのオーディオ・ブロック（AB0からAB5）と；オーディオ・コンテンツが圧縮されたのちに残される未使用ビットがあればそれを含む余剰（waste）ビット・セグメント（W）と；さらなるメタデータを含んでいてもよい補助（AUX）情報セクションと；二つの誤り訂正語のうちの第二のもの（CRC2）とを含む。余剰ビット・セグメント（W）は、「スキップ・フィールド」と称されることもある。

【0018】

図７に示されるように、各E-AC-3フレームはセクション（セグメント）に分割される。セクションは、（図５に示されるように）同期語（SW）を含む同期情報（SI）セクションと；メタデータの大半を含むビットストリーム情報（BSI）セクションと；データ圧縮されたオーディオ・コンテンツを含む（そしてメタデータも含むことができる）一から六個までの間のオーディオ・ブロック（AB0からAB5）と；オーディオ・コンテンツが圧縮されたのちに残される未使用ビットがあればそれを含む余剰（waste）ビット・セグメント（W）（一つの余剰ビット・セグメントしか示されていないが、典型的には各オーディオ・ブロックに続いて異なる余剰ビット・セグメントがある）と；さらなるメタデータを含んでいてもよい補助（AUX）情報セクションと；誤り訂正語（CRC）とを含む。余剰ビット・セグメント（W）は、「スキップ・フィールド」と称されることもある。

【0019】

AC-3（またはE-AC-3）ビットストリームでは、聴取環境に送達されるプログラムの音を変える際に使うよう特に意図されたいくつかのオーディオ・メタデータ・パラメータがある。そうしたメタデータ・パラメータの一つはDIALNORMパラメータであり、これはBSIセグメントに含まれる。

【0020】

図６に示されるように、AC-3フレームのBSIセグメントは、当該プログラムについてのDIALNORM値を示す五ビットのパラメータ（「DIALNORM」）を含む。当該AC-3フレームのオーディオ符号化モード（「acmod」）が「0」であってデュアル・モノあるいは「1＋1」チャネル構成が使われていることを示す場合には、同じAC-3フレームにおいて担持される第二のオーディオ・プログラムについてのDIALNORM値を示す五ビットのパラメータ（「DIALNORM2」）が含まれる。

【0021】

BSIセグメントは、フラグ（「addbsie」）であって、該「addbsie」ビットに続く追加的なビットストリーム情報の存在（または不在）を示すフラグと、パラメータ（「addbsil」）であって、該「addbsil」値に続く追加的なビットストリーム情報があればその長さを示すパラメータと、「addbsil」値に続く64ビットまでの追加的なビットストリーム情報（「addbsi」）とを含む。

【0022】

BSIセグメントは、図６に具体的に示されない他のメタデータ値を含む。

【先行技術文献】

【特許文献】

【0023】

【特許文献1】米国特許第5,583,962号

【特許文献2】米国特許第5,632,005号

【特許文献3】米国特許第5,633,981号

【特許文献4】米国特許第5,727,119号

【特許文献5】米国特許第6,021,386号

【非特許文献】

【0024】

【非特許文献1】ATSC Standard A52/A: Digital Audio Compression Standard (AC-3), Revision A, Advanced Television Systems Committee, 20 Aug. 2001

【非特許文献2】Introduction to Dolby Digital Plus, an Enhancement to the Dolby Digital Coding System, AES Convention Paper 6196, 117th AES Convention, October 28, 2004

【非特許文献3】"Efficient Bit Allocation, Quantization, and Coding in an Audio Distribution System", AES Preprint 5068, 107th AES Conference, August 1999

【非特許文献4】"Professional Audio Coder Optimized for Use with Video", AES Preprint 5033, 107th AES Conference August 1999

【発明の概要】

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

【0025】

あるクラスの諸実施形態において、本発明は、バッファ・メモリ、オーディオ・デコーダおよびパーサを含むオーディオ処理ユニットである。バッファ・メモリはエンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを記憶する。エンコードされたオーディオ・ビットストリームはオーディオ・データおよびメタデータ・コンテナを含む。メタデータ・コンテナはヘッダと、一つまたは複数のメタデータ・ペイロードと、保護データとを含む。ヘッダは、コンテナの先頭を同定する同期語を含む。前記一つまたは複数のメタデータ・ペイロードは、オーディオ・データに関連付けられたオーディオ・プログラムを記述する。保護データは、前記一つまたは複数のメタデータ・ペイロードのあとに位置する。保護データは、メタデータ・コンテナおよび該メタデータ・コンテナ内の前記一つまたは複数のペイロードの完全性を検証するために使われることもできる。前記オーディオ・デコーダは、前記バッファ・メモリに結合されており、前記オーディオ・データをデコードすることができる。前記パーサは、前記オーディオ・デコーダに結合されるかこれと統合されるかしており、前記メタデータ・コンテナをパースすることができる。

【0026】

典型的な実施形態では、本方法は、一つまたは複数のフレームにセグメント分割されている、エンコードされたオーディオ・ビットストリームを受領することを含む。前記オーディオ・データは、メタデータのコンテナとともに、前記エンコードされたオーディオ・ビットストリームから抽出される。前記メタデータのコンテナは、ヘッダと、それに続く一つまたは複数のメタデータ・ペイロードと、それに続く保護データとを含む。最後に、前記コンテナおよび前記一つまたは複数のメタデータ・ペイロードの完全性が、前記保護データの使用を通じて検証される。前記一つまたは複数のメタデータ・ペイロードは、前記オーディオ・データに関連付けられたオーディオ・プログラムの測定されたラウドネスを示すデータを含むプログラム・ラウドネス・ペイロードを含んでいてもよい。

【0027】

ラウドネス処理状態メタデータ（LPSM: loudness processing state metadata）と称される、本発明の典型的な実施形態に従ってオーディオ・ビットストリームに埋め込まれたプログラム・ラウドネス・メタデータのペイロードは、たとえばラウドネス規制エンティティが特定のプログラムのラウドネスがすでに指定された範囲内であるかどうかおよび対応するオーディオ・データ自身が修正されていないことを検証する（verify）（それにより該当する規制に準拠していることを保証する）ことができるようにするために、認証され（authenticated）有効確認され（validated）てもよい。これを検証するために、ラウドネスを再び計算する代わりに、ラウドネス処理状態メタデータを含むデータ・ブロックに含まれるラウドネス値が読み出されてもよい。LPSMに応答して、規制当局は、（LPSMによって示されるところにより）対応するオーディオ・コンテンツがラウドネスの法制および／または規制上の要求（たとえば「CALM法」としても知られる商業広告ラウドネス緩和法（Commercial Advertisement Loudness Mitigation Act））に準拠していることを、オーディオ・コンテンツのラウドネスを計算する必要なしに、判別しうる。

【0028】

いくつかのラウドネス法制および／または規制要求（たとえばCALM法のもとで発布される規則）への準拠のために要求されるラウドネス測定は、統合された（integrated）プログラム・ラウドネスに基づく。統合されたプログラム・ラウドネスは、ダイアログ・レベルまたはフル・ミックス・レベルいずれかのラウドネス測定が、オーディオ・プログラム全体に対してなされることを要求する。このように、典型的な法律上の要求への準拠を検証するためにプログラム・ラウドネス測定を（たとえば放送チェーンにおけるさまざまな段階において）なすためには、どのオーディオ・データ（およびメタデータ）がオーディオ・プログラム全体を決定するかの知識をもって測定がなされることが本質的であり、これは典型的には、（たとえば諸オーディオ・プログラムのシーケンスを示すビットストリームの処理中に）当該プログラムの始まりと終わりの位置の知識を必要とする。

【0029】

本発明の典型的な実施形態によれば、エンコードされたオーディオ・ビットストリームは少なくとも一つのオーディオ・プログラム（たとえばオーディオ・プログラムのシーケンス）を示し、該ビットストリームに含まれるプログラム境界メタデータおよびLPSMが、プログラムの終わりにおけるプログラム・ラウドネス測定のリセットを可能にし、よって統合されたプログラム・ラウドネスを測定する自動化された方法を提供する。本発明の典型的な実施形態は、エンコードされたオーディオ・ビットストリームにプログラム境界メタデータを効率的な仕方で含み、これはビットストリームによって示される連続するオーディオ・プログラムの間の少なくとも一つの境界の正確かつ堅牢な決定を許容する。典型的な実施形態は、異なるプログラムを示すビットストリームが、継ぎ合わされた（spliced）ビットストリームの一方または両方を打ち切る（よって継ぎ合わせ前のビットストリームの少なくとも一つに含まれていたプログラム境界メタデータを破棄する）仕方で（本発明のビットストリームを生成するよう）一緒に継ぎ合わされる場合でさえ、正確なプログラム境界決定を許容するという意味で、プログラム境界の正確かつ堅牢な決定を許容する。

【0030】

典型的な実施形態では、本発明のビットストリームのフレームにおけるプログラム境界メタデータは、フレーム・カウントを示すプログラム境界フラグである。典型的には、このフラグは現在フレーム（当該フラグを含んでいるフレーム）とプログラム境界（現在のオーディオ・プログラムの始まりまたは終わり）との間のフレーム数を示す。いくつかの好ましい実施形態では、プログラム境界フラグは、単独のプログラムを示す各ビットストリーム・セグメントの始まりおよび終わりにおいて対称的で効率的な仕方で（すなわち、当該セグメントの始まりのあと何らかの所定数のフレーム内に生起するフレームにおいておよび当該セグメントの終わりの前の何らかの所定数のフレーム内に生起するフレームにおいて）挿入される。それにより、二つのそのようなビットストリームが連結される（それにより二つのプログラムのシーケンスを示すようになる）とき、プログラム境界メタデータは、二つのプログラムの間の境界の両方の側に（たとえば対称的に）存在することができる。

【0031】

（一つのオーディオ・プログラムまたはオーディオ・プログラムのシーケンスを示しうる）エンコードされたオーディオ・ビットストリームにプログラム境界メタデータを含めることから帰結するデータ・レート増を制限するために、典型的な実施形態では、プログラム境界フラグは、ビットストリームのフレームの部分集合にのみ挿入される。典型的には、境界フラグ挿入レートは、（フラグが挿入される）ビットストリームの各フレームの、該各フレームに最も近いプログラム境界からの増大する離間の非増加関数である。ここで、「境界フラグ挿入レート」とは、プログラム境界フラグを含む（プログラムを示す）フレームの数の、プログラム境界フラグを含まない（該プログラムを示す）フレームの数に対する、平均的な比を表わす。ここで、平均は、エンコードされたオーディオ・ビットストリームのある数（たとえば比較的少数）の連続するフレームにわたる移動平均である。あるクラスの諸実施形態では、境界フラグ挿入レートは、最も近いプログラム境界からの（各フラグ挿入位置の）増大する距離の対数的に減少する関数であり、フラグの一つを含む各フラグ含有フレームについて、該フラグ含有フレーム中のフラグのサイズは、該フラグ含有フレームよりも前記最も近いプログラム境界により近くに位置するフレームにおける各フラグのサイズ以上である（すなわち、各フラグ含有フレーム内のプログラム境界フラグのサイズは、当該フラグ含有フレームの、前記最も近いプログラム境界からの増大する離間の非減少関数である）。

【0032】

本発明のもう一つの側面は、本発明の方法のいずれかの実施形態を実行するよう構成されたオーディオ処理ユニット（APU: audio processing unit）である。もう一つのクラスの諸実施形態では、本発明は、本発明の方法のいずれかの実施形態によって生成されたエンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを（たとえば非一時的な仕方で）記憶しているバッファ・メモリ（バッファ）を含むAPUである。APUの例は、エンコーダ（たとえばトランスコーダ）、デコーダ、コーデック、前処理システム（前処理器）、後処理システム（後処理器）、オーディオ・ビットストリーム処理システムおよびそのような要素の組み合わせを含むがこれに限られない。

【0033】

もう一つのクラスの諸実施形態では、本発明は、オーディオ・データ・セグメントおよびメタデータ・セグメントを含むエンコードされたオーディオ・ビットストリームを生成するよう構成されたオーディオ処理ユニット（APU）である。オーディオ・データ・セグメントはオーディオ・データを示し、前記メタデータ・セグメントのうち少なくともいくつかの各セグメントはラウドネス処理状態メタデータ（LPSM）を、任意的にはプログラム境界メタデータをも、含む。典型的には、ビットストリームのフレーム中の少なくとも一つのそのようなメタデータ・セグメントが、そのフレームのオーディオ・データ（すなわち、そのフレームの少なくとも一つのオーディオ・データ・セグメント中のオーディオ・データ）に対して第一の型のラウドネス処理が実行されているかどうかを示すLPSMの少なくとも一つのセグメントと、そのフレームのオーディオ・データの少なくとも一部のラウドネス（たとえば、そのフレームのオーディオ・データの、ダイアログを示す少なくとも一部のデータのダイアログ・ラウドネス）を示すLPSMの少なくとも一つの他のセグメントとを含む。このクラスのある実施形態では、APUは、エンコードされたオーディオを生成するよう入力オーディオをエンコードするよう構成されているエンコーダであり、オーディオ・データ・セグメントはエンコードされたオーディオを含む。このクラスの典型的な実施形態では、メタデータ・セグメントのそれぞれは、本稿に記載される好ましいフォーマットをもつ。

【0034】

いくつかの実施形態では、LPSM（たとえばLPSMおよびプログラム境界メタデータ）を含むエンコードされたビットストリーム（いくつかの実施形態ではAC-3ビットストリームまたはE-AC-3ビットストリーム）のメタデータ・セグメントのそれぞれは、そのビットストリームのフレームのスキップ・フィールド・セグメントの余剰ビット（たとえば、図４または図７に示される型の余剰ビット・セグメントW）に含まれる。他の実施形態では、LPSM（たとえばLPSMおよびプログラム境界メタデータ）を含むエンコードされたビットストリーム（いくつかの実施形態ではAC-3ビットストリームまたはE-AC-3ビットストリーム）のメタデータ・セグメントのそれぞれは、そのビットストリームのフレームのビットストリーム情報（「BSI」）セグメントの「addbsi」フィールド中の追加的なビットストリーム情報として、あるいはそのビットストリームのフレームの末尾の補助データ・フィールド（たとえば、図４または図７に示される型のAUXセグメント）中に、含まれる。LPSMを含む各メタデータ・セグメントは、下記の表１および表２を参照して本稿に記載されるフォーマットを有していてもよい（すなわち、表１に記載されるコア要素またはその変形と、それに続くペイロードID（当該メタデータをLPSMとして同定する）およびペイロード・サイズの値と、それに続くペイロード（表２に示されるようなフォーマットまたは本稿に記載される表２に対する変形で示されるようなフォーマットをもつLPSMデータ）とを含む）。いくつかの実施形態では、フレームは一つまたは複数のメタデータ・セグメントを含んでいてもよく、フレームが二つのメタデータ・セグメントを含む場合、一方がそのフレームのaddbsiフィールドに存在していて他方がそのフレームのAUXフィールドに存在していてもよい。

【0035】

あるクラスの諸実施形態では、本発明は、AC-3またはE-AC-3エンコードされたオーディオ・ストリームを生成するようオーディオ・データをエンコードする段階を含む方法である。該段階は、（ビットストリームの少なくとも一つのフレームの）メタデータ・セグメント中にLPSMおよびプログラム境界メタデータを、任意的にはそのフレームが属するオーディオ・プログラムについての他のメタデータをも、含めることによることを含む。いくつかの実施形態では、それぞれのそのようなメタデータ・セグメントは、フレームのaddbsiフィールドあるいはフレームの補助データ・フィールド中に含まれる。他の実施形態では、それぞれのそのようなメタデータは、フレームの余剰ビット・セグメント中に含まれる。いくつかの実施形態では、LPSMおよびプログラム境界メタデータを含む各メタデータ・セグメントは、コア・ヘッダ（および任意的には追加的なコア要素も）と、該コア・ヘッダ後に（または該コア・ヘッダおよび他のコア要素後に）下記のフォーマットをもつLPSMペイロード（またはコンテナ）セグメントとを含む。

【0036】

ヘッダ。典型的には少なくとも一つの識別情報値を含む（たとえば、本稿の表２に記載されるような、LPSMフォーマット・バージョン、長さ、期間（period）、カウントおよびサブストリーム関連付け値）、
ヘッダ後に、LPSMおよびプログラム境界メタデータ。プログラム境界メタデータは、プログラム境界フレーム・カウントと、そのフレームがプログラム境界フレーム・カウントのみを含むか、プログラム境界フレーム・カウントおよびオフセット値の両方を含むかを示す符号値（たとえば「offset_exist」〔オフセット存在〕値）と、（場合によっては）オフセット値とを含んでいてもよい。

【0037】

LPSMは下記を含んでいてもよい：
対応するオーディオ・データがダイアログを示すかダイアログを示さないか（たとえば、対応するオーディオ・データのどのチャネルがダイアログを示すか）を示す少なくとも一つのダイアログ指示値。ダイアログ指示値（単数または複数）は、対応するオーディオ・データのチャネルの任意の組み合わせまたは全部にダイアログが存在しているかどうかを示してもよい；
対応するオーディオ・データがラウドネス規制の示されるセットに準拠しているかどうかを示す少なくとも一つのラウドネス規制準拠値；
対応するオーディオ・データに対して実行されたラウドネス処理の少なくとも一つの型を示す少なくとも一つのラウドネス処理値；および
対応するオーディオ・データに特徴的な少なくとも一つのラウドネス（たとえばピークまたは平均ラウドネス）を示す少なくとも一つのラウドネス値。

【0038】

他の実施形態では、エンコードされるビットストリームは、AC-3ビットストリームまたはE-AC-3ビットストリームではないビットストリームであり、LPSMを（および任意的にはプログラム境界メタデータをも）含むメタデータ・セグメントのそれぞれは、追加的なデータの記憶のためにリザーブされているビットストリームのセグメント（またはフィールドまたはスロット）に含まれる。LPSMを含む各メタデータ・セグメントは、下記の表１および表２を参照して本稿に記載されるものと同様または同一のフォーマットを有していてもよい（すなわち、表１に記載されるのと同様または同一のコア要素を、続いて（当該メタデータをLPSMとして同定する）ペイロードIDおよびペイロード・サイズの値、続いてペイロード（本稿に記載される表２または表２の変形に示されるフォーマットと同様または同一のフォーマットをもつLPSMデータ）を含む）。

【0039】

いくつかの実施形態では、エンコードされたビットストリームは、フレームのシーケンスを含み、各フレームは、「addbsi」フィールド（時にセグメントまたはスロットと称される）および補助データ・フィールドもしくはスロットを含むビットストリーム情報（「BSI」）セグメントを含む（たとえば、エンコードされたビットストリームはAC-3ビットストリームまたはE-AC-3ビットストリームである）。当該ビットストリームは、オーディオ・データ・セグメント（たとえば図４に示されるフレームのAB0〜AB5セグメント）およびメタデータ・セグメントを含む。ここで、オーディオ・データ・セグメントはオーディオ・データを示し、メタデータ・セグメントの少なくともいくつかの各セグメントはラウドネス処理状態メタデータ（LPSM）および任意的にはプログラム境界メタデータを含む。LPSMは、以下のフォーマットでビットストリームに存在している。LPSMを含むメタデータ・セグメントのそれぞれは、ビットストリームのフレームのBSIセグメントの「addbsi」フィールド中に、あるいはビットストリームのフレームの補助データ・フィールド中に、あるいはビットストリームのフレームの余剰ビット・セグメント中に含まれる。LPSMを含む各メタデータ・セグメントは、以下のフォーマットをもつLPSMペイロード（またはコンテナ）セグメントを含む。

【0040】

ヘッダ。典型的には少なくとも一つの識別情報値、たとえば、下記の表２に示されるような、LPSMフォーマット・バージョン、長さ、期間（period）、カウントおよびサブストリーム関連付け値を含む；
ヘッダ後に、LPSMおよび任意的にはプログラム境界メタデータも。プログラム境界メタデータは、プログラム境界フレーム・カウントと、そのフレームがプログラム境界フレーム・カウントのみを含むか、プログラム境界フレーム・カウントおよびオフセット値の両方を含むかを示す符号値（たとえば「offset_exist」〔オフセット存在〕値）と、（場合によっては）オフセット値とを含んでいてもよい。

【0041】

LPSMは下記を含んでいてもよい：
対応するオーディオ・データがダイアログを示すかダイアログを示さないか（たとえば、対応するオーディオ・データのどのチャネルがダイアログを示すか）を示す少なくとも一つのダイアログ指示値（たとえば表２のパラメータ「ダイアログ・チャネル」）。ダイアログ指示値（単数または複数）は、対応するオーディオ・データのチャネルの任意の組み合わせまたは全部にダイアログが存在しているかどうかを示してもよい；
対応するオーディオ・データがラウドネス規制の示されるセットに準拠しているかどうかを示す少なくとも一つのラウドネス規制準拠値（たとえば表２のパラメータ「ラウドネス規制型」）；
対応するオーディオ・データに対して実行されたラウドネス処理の少なくとも一つの型を示す少なくとも一つのラウドネス処理値（たとえば、表２のパラメータ「ダイアログ・ゲーテッド・ラウドネス補正フラグ」「ラウドネス補正型」の一つまたは複数）；および
対応するオーディオ・データに特徴的な少なくとも一つのラウドネス（たとえばピークまたは平均ラウドネス）を示す少なくとも一つのラウドネス値（たとえば、表２のパラメータ「ITU相対ゲーテッド・ラウドネス」「ITU発話ゲーテッド・ラウドネス」「ITU（EBU3341）短時間3sラウドネス」および「真のピーク」の一つまたは複数）。

【0042】

対応するオーディオ・データを示す少なくとも一つのラウドネス値を考慮する、使用するまたは生成する本発明の任意の実施形態において、ラウドネス値（単数または複数）は、オーディオ・データのラウドネスおよび／またはダイナミックレンジを処理するために利用される少なくとも一つのラウドネス測定特性を示してもよい。

【0043】

いくつかの実装では、当該ビットストリームのフレームの「addbsi」フィールドまたは補助データ・フィールドまたは余剰ビット・セグメントにおける各メタデータ・セグメントは次のフォーマットをもつ。

【0044】

コア・ヘッダ（典型的にはメタデータ・セグメントの開始を同定する同期語と、それに続く識別情報値、たとえば下記の表１に示されるコア要素バージョン、長さおよび期間（period）、拡張要素カウントおよびサブストリーム関連付け値；および
コア・ヘッダ後に、ラウドネス処理状態メタデータまたは対応するオーディオ・データの少なくとも一方の解読、認証（authentication）または有効確認（validation）のうちの少なくとも一つのために有用な少なくとも一つの保護値（たとえば、HMACダイジェストおよびオーディオ・フィンガープリント値。ここで、該HMACダイジェストは、表１に示されるように、フレーム全体のオーディオ・データ、コア要素およびすべての展開された（expanded）要素に対して（SHA-2アルゴリズムを使って）計算された256ビットHMACダイジェストであってもよい）；および
やはりコア・ヘッダ後に、当該メタデータ・セグメントがLPSMを含む場合、LPSMペイロード識別情報（「ID」）およびLPSMペイロード・サイズの値であって、後続のメタデータをLPSMペイロードとして同定し、該LPSMペイロードのサイズを示すもの。（好ましくは上記のフォーマットをもつ）LPSMペイロード・セグメントは、LPSMペイロードIDおよびLPSMペイロード・サイズの値に続く。

【0045】

前段に記載される型のいくつかの実施形態では、フレームの補助データ・フィールド（または「addbsi」フィールドまたは余剰ビット・セグメント）中の各メタデータ・セグメントは、三レベルの構造をもつ：
高レベル構造。これは、補助データ（またはaddbsi）フィールドがメタデータを含むかどうかを示すフラグと、どの型（単数または複数）のメタデータが存在しているかを示す少なくとも一つのID値と、典型的にはまた（メタデータが存在する場合）（たとえば各型の）何ビットのメタデータが存在するかを示す値とを含む。存在できるメタデータの一つの型はLPSMであり、存在できるメタデータのもう一つの型はプログラム境界メタデータであり、存在できるメタデータのもう一つの型はメディア・リサーチ（research）・メタデータである；
中間レベル構造。これは、メタデータのそれぞれの同定される型についてのコア要素を含む（たとえば、メタデータのそれぞれの同定される型についてのたとえば上述した型のコア・ヘッダ、保護値およびペイロードIDおよびペイロード・サイズの値）；および
低レベル構造。これは、あるコア要素についての各ペイロード（たとえば、前記コア要素によってLPSMペイロードが存在すると同定されている場合のLPSMペイロードおよび／または前記コア要素によってメタデータ・ペイロードが存在すると同定されている場合の別の型のメタデータ・ペイロード）を含む。

【0046】

そのような三レベル構造におけるデータ値は、ネストされることができる。たとえば、コア要素によって同定されるLPSMペイロードおよび／または別のメタデータ・ペイロードについての保護値（単数または複数）が、コア要素によって同定される各ペイロード後に（よって、コア要素のコア・ヘッダ後に）含まれることができる。一例では、コア・ヘッダは、LPSMペイロードおよび別のメタデータ・ペイロードを同定することができ、第一のペイロード（たとえばLPSMペイロード）についてのペイロードIDおよびペイロード・サイズの値がコア・ヘッダに続くことができ、第一のペイロード自身が該IDおよびサイズの値に続くことができ、第二のペイロードについてのペイロードIDおよびペイロード・サイズ値が第一のペイロードに続くことができ、第二のペイロード自身がこれらのIDおよびサイズの値に続くことができ、ペイロードの一方または両方についての（またはコア要素値ならびにペイロードの一方または両方についての）保護値（単数または複数）が最後のペイロードに続くことができる。

【0047】

いくつかの実施形態では、フレームの補助フィールド（または「addbsi」フィールドまたは余剰ビット・セグメント）中のメタデータ・セグメントのコア要素はコア・ヘッダ（典型的には識別情報値、たとえばコア要素バージョンを含む）と、該コア・ヘッダ後に：メタデータ・セグメントのメタデータについてフィンガープリント・データが含まれるかどうかを示す値と、（当該メタデータ・セグメントのメタデータに対応するオーディオ・データに関係する）外部データが存在するかどうかを示す値と、コア要素によって同定される各型のメタデータ（たとえばLPSMおよび／またはLPSM以外の型のメタデータ）についてのペイロードIDおよびペイロード・サイズの値と、コア要素によって同定されるメタデータの少なくとも一つの型についての保護値とを含む。メタデータ・セグメントのメタデータ・ペイロード（単数または複数）は、コア・ヘッダに続き、（場合によっては）コア要素の値内にネストされる。

【0048】

もう一つの好ましいフォーマットでは、エンコードされたビットストリームはドルビーEビットストリームであり、LPSM（および任意的にはプログラム境界メタデータも）を含むメタデータ・セグメントのそれぞれは、ドルビーE保護帯域区間の最初のN個のサンプル位置に含まれる。

【0049】

もう一つのクラスの諸実施形態では、本発明は、オーディオ・データ・セグメントおよびメタデータ・セグメントを含むエンコードされたオーディオ・ビットストリームを受領するよう結合され、構成されたAPU（たとえばデコーダ）である。ここで、オーディオ・データ・セグメントはオーディオ・データを示し、メタデータ・セグメントの少なくともいくつかの各メタデータ・セグメントは、ラウドネス処理状態メタデータ（LPSM）を、任意的にはプログラム境界メタデータをも含む。当該APUはまた、前記オーディオ・データに応答して、前記ビットストリームからLPSMを抽出してデコードされたオーディオ・データを生成し、前記LPSMを使って前記オーディオ・データに対して少なくとも一つの適応ラウドネス処理動作を実行するよう結合され、構成されている。このクラスのいくつかの実施形態はまた、当該APUに結合された後処理器をも含む。該後処理器は、前記LPSMを使って前記オーディオ・データに対して少なくとも一つの適応ラウドネス処理動作を実行するよう結合され、構成されている。

【0050】

もう一つのクラスの諸実施形態では、本発明は、バッファ・メモリ（バッファ）および該バッファに結合された処理サブシステムを含むオーディオ処理ユニット（APU）である。当該APUは、オーディオ・データ・セグメントおよびメタデータ・セグメントを含むエンコードされたオーディオ・ビットストリームを受領するよう結合されている。オーディオ・データ・セグメントはオーディオ・データを示し、メタデータ・セグメントの少なくともいくつかの各メタデータ・セグメントは、ラウドネス処理状態メタデータ（LPSM）を、任意的にはプログラム境界メタデータをも含む。前記バッファは、（たとえば非一時的な仕方で）エンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを記憶し、前記処理サブシステムは、該ビットストリームから前記LPSMを抽出し、前記LPSMを使って前記オーディオ・データに対して少なくとも一つの適応ラウドネス処理動作を実行するよう構成されている。このクラスの典型的な実施形態では、前記APUはエンコーダ、デコーダおよび後処理器のうちの一つである。

【0051】

本発明の方法のいくつかの実装では、生成されるオーディオ・ビットストリームはAC-3エンコードされたビットストリーム、E-AC-3ビットストリームまたはドルビーEビットストリームのうちの一つであり、ラウドネス処理状態メタデータおよび他のメタデータ（たとえば、DIALNORMメタデータ・パラメータ、ダイナミックレンジ制御メタデータ・パラメータおよび他のメタデータ・パラメータ）を含む。本方法の他のいくつかの実装では、生成されるオーディオ・ビットストリームは別の型のエンコードされたビットストリームである。

【0052】

本発明の諸側面は、本発明の方法の任意の実施形態を実行するよう構成された（たとえばプログラムされた）システムまたは装置ならびに本発明の方法またはそのステップの任意の実施形態を実装するためのコードを（たとえば非一時的な仕方で）記憶するコンピュータ可読媒体（たとえばディスク）を含む。たとえば、本発明のシステムは、プログラム可能な汎用プロセッサ、デジタル信号プロセッサまたはマイクロプロセッサであって、データに対して本発明の方法またはそのステップの実施形態を含む多様な動作のうちの任意のものを実行するようソフトウェアまたはファームウェアによってプログラムされたおよび／または他の仕方で構成されたものであるまたはそれを含むことができる。そのような汎用プロセッサは、入力装置と、メモリと、呈されるデータに応答して本発明の方法（またはそのステップ）の実施形態を実行するようプログラムされた（および／または他の仕方で構成された）処理回路とを含むコンピュータ・システムであるまたはそれを含むものであってもよい。

【図面の簡単な説明】

【0053】

【図1】本発明の方法のある実施形態を実行するよう構成されていてもよいシステムのある実施形態のブロック図である。

【図2】本発明のオーディオ処理ユニットの実施形態であるエンコーダのブロック図である。

【図3】本発明のオーディオ処理ユニットの実施形態であるデコーダならびにそれに結合された、本発明のオーディオ処理ユニットのもう一つの実施形態である後処理器のブロック図である。

【図4】AC-3フレームを、それが分割された諸セグメントを含めて描く図である。

【図5】AC-3フレームの同期情報（SI）セグメントを、それが分割された諸セグメントを含めて描く図である。

【図6】AC-3フレームのビットストリーム情報（BSI）セグメントを、それが分割された諸セグメントを含めて描く図である。

【図7】E-AC-3フレームを、それが分割された諸セグメントを含めて描く図である。

【図8】本発明のある実施形態に基づくフォーマットをもつプログラム境界メタデータを含むエンコードされたオーディオ・ビットストリームの諸フレームの図である。

【図9】図９のエンコードされたオーディオ・ビットストリームの他の諸フレームの図である。これらのフレームのいくつかは、本発明のある実施形態に基づくフォーマットをもつプログラム境界メタデータを含む。

【図10】二つのエンコードされたオーディオ・ビットストリーム、すなわちプログラム境界（「境界」とラベル付けされている）がビットストリームの二つのフレームの間の遷移と整列されているビットストリーム（IEB）と、プログラム境界（「真の境界」とラベル付けされている）がビットストリームの二つのフレームの間の遷移から512サンプルだけオフセットされている別のビットストリーム（TB）とを描く図である。

【図11】四つのエンコードされたオーディオ・ビットストリームを示す図のセットである。図１１のいちばん上のビットストリーム（「シナリオ１」とラベル付けされている）は、プログラム境界メタデータを含む第一のオーディオ・プログラム（P1）と、それに続く、やはりプログラム境界メタデータを含む第二のオーディオ・プログラム（P2）とを示しており；第二のビットストリーム（「シナリオ２」とラベル付けされている）は、プログラム境界メタデータを含む第一のオーディオ・プログラム（P1）と、それに続く、プログラム境界メタデータを含まない第二のオーディオ・プログラム（P2）とを示しており；第三のビットストリーム（「シナリオ３」とラベル付けされている）は、プログラム境界メタデータを含む打ち切りされた第一のオーディオ・プログラム（P1）であって、プログラム境界メタデータを含む第二のオーディオ・プログラム（P2）全体と継ぎ合わされているものを示しており；第四のビットストリーム（「シナリオ４」とラベル付けされている）は、プログラム境界メタデータを含む打ち切りされた第一のオーディオ・プログラム（P1）と、プログラム境界メタデータを含む打ち切りされた第二のオーディオ・プログラム（P2）であって、第一のオーディオ・プログラムの一部と継ぎ合わされているものとを示している。

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

【0054】

〈記法および命名法〉
請求項を含む本開示を通じて、信号またはデータ「に対して」動作を実行する（たとえば信号またはデータをフィルタリングする、スケーリングする、変換するまたは利得を適用する）という表現は、信号またはデータに対して直接的に、または信号またはデータの処理されたバージョンに対して（たとえば、予備的なフィルタリングまたは前処理を該動作の実行に先立って受けている前記信号のバージョンに対して）該動作を実行することを表わすために広義で使用される。

【0055】

請求項を含む本開示を通じて、「システム」という表現は、装置、システムまたはサブシステムを表わす広義で使用される。たとえば、デコーダを実装するサブシステムは、デコーダ・システムと称されてもよく、そのようなサブシステムを含むシステム（たとえば、複数の入力に応答してX個の出力信号を生成するシステムであって、前記サブシステムが入力のうちのM個を生成し、他のX−M個の入力は外部源から受領されるもの）もデコーダ・システムと称されることがある。

【0056】

請求項を含む本開示を通じて、「プロセッサ」という表現は、データ（たとえばオーディオまたはビデオまたは他の画像データ）に対して動作を実行するよう（たとえばソフトウェアまたはファームウェアを用いて）プログラム可能または他の仕方で構成可能であるシステムまたは装置を表わす広義で使用される。プロセッサの例は、フィールド・プログラム可能なゲート・アレイ（または他の構成可能な集積回路またはチップセット）、オーディオまたは他のサウンド・データに対してパイプライン化された処理を実行するようプログラムされたおよび／または他の仕方で構成されたデジタル信号プロセッサ、プログラム可能な汎用プロセッサもしくはコンピュータおよびプログラム可能なマイクロプロセッサ・チップまたはチップセットを含む。

【0057】

請求項を含む本開示を通じて、「オーディオ・プロセッサ」および「オーディオ処理ユニット」という用語は交換可能に、オーディオ・データを処理するよう構成されたシステムを表わす広義で使用される。オーディオ処理ユニットの例は、エンコーダ（たとえばトランスコーダ）、デコーダ、コーデック、前処理システム、後処理システムおよびビットストリーム処理システム（時にビットストリーム処理ツールと称される）を含むがこれに限られない。

【0058】

請求項を含む本開示を通じて、「処理状態メタデータ」（たとえば「ラウドネス処理状態メタデータ」という表現におけるような）という表現は、対応するオーディオ・データ（処理状態メタデータをも含むオーディオ・データ・ストリームのオーディオ・コンテンツ）とは別個の異なるデータを指す。処理状態メタデータは、オーディオ・データに関連付けられ、対応するオーディオ・データのラウドネス処理状態（たとえばどの型（単数または複数）の処理がそのオーディオ・データに対してすでに実行されているか）を示し、典型的にはそのオーディオ・データの少なくとも一つの特徴または特性をも示す。処理状態メタデータのオーディオ・データとの関連付けは、時間同期的である。このように、現在の（最も最近受領または更新された）処理状態メタデータは、対応するオーディオ・データが同時的に、示される型（単数または複数）のオーディオ・データ処理の結果を含むことを示す。場合によっては、処理状態メタデータは、処理履歴および／または示される型の処理において使われるおよび／または示される型の処理から導出されるパラメータの一部または全部を含んでいてもよい。さらに、処理状態メタデータは、オーディオ・データから計算されたまたは抽出された、対応するオーディオ・データの少なくとも一つの特徴または特性を含んでいてもよい。処理状態メタデータはまた、対応するオーディオ・データのいかなる処理にも関係せず対応するオーディオ・データのいかなる処理から導出されたのでもない他のメタデータを含んでいてもよい。たとえば、サードパーティー・データ、追跡情報、識別子、所有権があるか標準かの情報、ユーザー注釈データ、ユーザー選好データなどが、特定のオーディオ処理ユニットによって加えられて他のオーディオ処理ユニットに渡されてもよい。

【0059】

請求項を含む本開示を通じて、「ラウドネス処理状態メタデータ」（または「LPSM」）という表現は、対応するオーディオ・データのラウドネス処理状態（たとえばどの型（単数または複数）のラウドネス処理がそのオーディオ・データに対してすでに実行されているか）を、典型的にはまた対応するオーディオ・データの少なくとも一つの特徴または特性（たとえばラウドネス）をも示す処理状態メタデータを表わす。ラウドネス処理状態メタデータは、（単独で考えると）ラウドネス処理状態メタデータではないデータ（たとえば他のメタデータ）を含んでいてもよい。

【0060】

請求項を含む本開示を通じて、「チャネル」（または「オーディオ・チャネル」）という表現は、モノフォニック・オーディオ信号を表わす。

【0061】

請求項を含む本開示を通じて、「オーディオ・プログラム」という表現は、一つまたは複数のオーディオ・チャネルおよび任意的には関連するメタデータ（たとえば、所望される空間的オーディオ呈示を記述するメタデータおよび／またはLPSMおよび／またはプログラム境界メタデータ）の集合を表わす。

【0062】

請求項を含む本開示を通じて、「プログラム境界メタデータ」という表現は、少なくとも一つのオーディオ・プログラム（たとえば二つ以上のオーディオ・プログラム）を示すエンコードされたオーディオ・ビットストリームのメタデータを表わし、プログラム境界メタデータは、少なくとも一つの前記オーディオ・プログラムの少なくとも一つの境界（始まりおよび／または終わり）のビットストリーム中の位置を示す。たとえば、（オーディオ・プログラムを示すエンコードされたオーディオ・ビットストリームの）プログラム境界メタデータは、プログラムの先頭の位置（たとえば、ビットストリームのN番目のフレームの始まりまたはビットストリームのN番目のフレームのM番目のサンプル位置）を示すメタデータと、プログラムの末尾の位置（たとえば、ビットストリームのJ番目のフレームの始まりまたはビットストリームのJ番目のフレームのK番目のサンプル位置）を示す追加的なメタデータとを含んでいてもよい。

【0063】

請求項を含む本開示を通じて、「結合する」または「結合される」という用語は、直接的または間接的な接続を意味するために使われる。よって、第一の装置が第二の装置に結合するとき、その接続は、直接接続を通じてであってもよいし、他の装置および接続を介した間接的な接続を通じてであってもよい。

【0064】

〈発明の実施形態の詳細な説明〉
本発明の典型的な実施形態によれば、ラウドネス処理状態メタデータ（「LPSM」）と称されるプログラム・ラウドネス・メタデータのペイロードおよび任意的にはまた、プログラム境界メタデータが、オーディオ・ビットストリームのメタデータ・セグメントの一つまたは複数のリザーブされたフィールド（またはスロット）に埋め込まれる。該オーディオ・ビットストリームは、他のセグメント（オーディオ・データ・セグメント）においてオーディオ・データをも含む。典型的には、ビットストリームの各フレームの少なくとも一つのセグメントがLPSMを含み、フレームの少なくとも一つの他のセグメントが、対応するオーディオ・データ（すなわち、前記LPSMによってラウドネス処理状態およびラウドネスが示されているオーディオ・データ）を含む。いくつかの実施形態では、LPSMのデータ・ボリュームは、オーディオ・データを担持するために割り当てられるビットレートに影響することなく担持されるのに十分小さくてもよい。

【0065】

オーディオ・データ処理チェーンにおいてラウドネス処理状態メタデータを通信することは、二つ以上のオーディオ処理ユニットが処理チェーン（またはコンテンツ・ライフサイクル）を通じて互いに縦続的に機能する必要があるときに特に有用である。ラウドネス処理状態メタデータをオーディオ・ビットストリームに含めなければ、たとえばチェーンにおいて二つ以上のオーディオ・コーデックが利用され、メディア消費装置（またはビットストリームのオーディオ・コンテンツのレンダリング点）に至るビットストリームの行程の間に二回以上シングルエンドのボリューム平準化が適用されるときに、品質、レベルおよび空間的劣化といった深刻なメディア処理問題が起こりうる。

【0066】

図１は、例示的なオーディオ処理チェーン（オーディオ・データ処理システム）のブロック図である。ここで、システムの要素の一つまたは複数が本発明の実施形態に基づいて構成されていてもよい。システムは、図のように一緒に結合された以下の要素を含む：前処理ユニット、エンコーダ、信号解析およびメタデータ補正ユニット、トランスコーダ、デコーダおよび前処理ユニット。図示したシステムの変形では、要素の一つまたは複数が省略されたり、あるいは追加的なオーディオ・データ処理ユニットが含まれたりする。

【0067】

いくつかの実装では、図１の前処理ユニットは、入力としてオーディオ・コンテンツを含むPCM（時間領域）サンプルを受け容れ、処理されたPCMサンプルを出力するよう構成されている。エンコーダは、入力として該PCMサンプルを受け容れ、前記オーディオ・コンテンツを示す、エンコードされた（たとえば圧縮された）オーディオ・ビットストリームを出力するよう構成されている。前記オーディオ・コンテンツを示す前記ビットストリームのデータは、本稿では時に、「オーディオ・データ」と称される。エンコーダが本発明の典型的な実施形態に従って構成されている場合、エンコーダからのオーディオ・ビットストリーム出力は、オーディオ・データのほかにラウドネス処理状態メタデータを（典型的には、任意的にプログラム境界メタデータを含む、他のメタデータも）含む。

【0068】

図１の信号解析およびメタデータ補正ユニットは、入力として一つまたは複数のエンコードされたオーディオ・ビットストリームを受け容れ、（たとえばエンコードされたオーディオ・ビットストリーム中のプログラム境界メタデータを使って）信号解析を実行することによって、各エンコードされたオーディオ・ビットストリーム内の処理状態メタデータが正しいかどうかを判定（たとえば有効確認）してもよい。信号解析およびメタデータ補正ユニットが、含まれているメタデータが無効であることを見出す場合、該ユニットは典型的には正しくない値（単数または複数）を信号解析から得られる正しい値（単数または複数）で置き換える。このように、信号解析およびメタデータ補正ユニットから出力される各エンコードされたオーディオ・ビットストリームは、エンコードされたオーディオ・データのほかに訂正された（または訂正されていない）処理状態メタデータを含んでいてもよい。

【0069】

図１のトランスコーダは、入力としてエンコードされたオーディオ・ビットストリームを受け容れて、応答して（たとえば入力ストリームをデコードして、デコードされたストリームを異なるエンコード・フォーマットで再エンコードすることによって）修正された（たとえば異なる仕方でエンコードされた）オーディオ・ビットストリームを出力してもよい。トランスコーダが本発明の典型的な実施形態に基づいて構成されている場合、トランスコーダから出力されるオーディオ・ビットストリームは、エンコードされたオーディオ・データのほかラウドネス処理状態メタデータを（典型的には他のメタデータも）含む。該メタデータはビットストリームに含められていてもよい。

【0070】

図１のデコーダは、入力としてエンコードされた（たとえば圧縮された）ビットストリームを受け容れ、（応答して）デコードされたPCMオーディオ・サンプルのストリームを出力する。デコーダが本発明の典型的な実施形態に基づいて構成される場合、典型的な動作におけるデコーダの出力は、以下のうちの任意のものであるまたはそれを含む：
オーディオ・サンプルのストリームおよび入力されたエンコードされたビットストリームから抽出されたラウドネス処理状態メタデータ（および典型的には他のメタデータも）の対応するストリーム；または
オーディオ・サンプルのストリームおよび入力されたエンコードされたビットストリームから抽出されたラウドネス処理状態メタデータ（および典型的には他のメタデータも）から決定された制御ビットの対応するストリーム；または
処理状態メタデータから決定された処理状態メタデータや制御ビットの対応するストリームなしの、オーディオ・サンプルのストリーム。この最後の場合、デコーダは、抽出されたメタデータやそれから決定される制御ビットを出力しなくても、入力されたエンコードされたビットストリームからラウドネス処理状態メタデータ（および／または他のメタデータ）を抽出し、抽出されたメタデータに対する少なくとも一つの動作（たとえば有効確認）を実行してもよい。

【0071】

図１の後処理ユニットを本発明の典型的な実施形態に基づいて構成することによって、後処理ユニットは、デコードされたPCMオーディオ・サンプルのストリームを受け容れ、サンプルと一緒に受領されたラウドネス処理状態メタデータ（および典型的には他のメタデータも）または（デコーダによってラウドネス処理状態メタデータおよび典型的にはまた他のメタデータから決定される）制御ビットを使って、それに対して後処理（たとえばオーディオ・コンテンツのボリューム平準化）を実行するよう構成される。後処理ユニットは典型的には、該後処理されたオーディオ・コンテンツを、一つまたは複数のスピーカーによる再生のためにレンダリングするようにも構成される。

【0072】

本発明の典型的な実施形態は、向上されたオーディオ処理チェーンであって、オーディオ処理ユニット（たとえばエンコーダ、デコーダ、トランスコーダおよび前処理および後処理ユニット）がそのそれぞれの処理を、それぞれオーディオ処理ユニットによって受領されるラウドネス処理状態メタデータによって示されるメディア・データの同時的状態に従って適応させるものを提供する。

【0073】

図１のシステムのいずれかのオーディオ処理ユニット（たとえば図１のエンコーダまたはトランスコーダ）に入力されるオーディオ・データは、オーディオ・データ（たとえばエンコードされたオーディオ・データ）のほかにラウドネス処理状態メタデータを（任意的には他のメタデータも）含んでいてもよい。本発明のある実施形態によれば、このメタデータは、図１のシステムの他の要素（または図１に示されない他の源）によって入力オーディオに含められたものであってもよい。入力オーディオを（メタデータとともに）受領する本処理ユニットは、該メタデータに対してまたは該メタデータに応答して（たとえば入力オーディオの適応処理）少なくとも一つの動作（たとえば有効確認）を実行し、典型的にはまた、その出力オーディオ内に該メタデータ、該メタデータの処理されたバージョンまたは該メタデータから決定される制御ビットを含めるよう構成されていてもよい。

【0074】

本発明のオーディオ処理ユニット（またはオーディオ・プロセッサ）の典型的な実施形態は、オーディオ・データに対応するラウドネス処理状態メタデータによって示されるオーディオ・データの状態に基づいてオーディオ・データの適応処理を実行するよう構成される。いくつかの実施形態では、適応処理は、（メタデータがラウドネス処理またはそれと同様の処理がすでにオーディオ・データに対して実行されているのでないことを示す場合は）ラウドネス処理である（またはラウドネス処理を含む）。だが、（メタデータがそのようなラウドネス処理またはそれと同様の処理がすでにオーディオ・データに対して実行されていることを示す場合は）ラウドネス処理ではない（またはラウドネス処理を含まない）。いくつかの実施形態では、適応処理は、ラウドネス処理状態メタデータによって示されるオーディオ・データの状態に基づいてオーディオ処理ユニットがオーディオ・データの他の適応処理を実行することを保証するための、（たとえばメタデータ検証サブユニットにおいて実行される）メタデータ有効確認であるまたはそれを含む。いくつかの実施形態では、該有効確認は、オーディオ・データに関連付けられた（たとえばオーディオ・データと一緒にビットストリームに含まれている）ラウドネス処理状態メタデータの信頼性を決定する。たとえば、メタデータが信頼できると有効確認される場合、ある型の前に実行されたオーディオ処理からの結果が再使用されてもよく、同じ型のオーディオ処理の新たな実行は回避されてもよい。他方、メタデータが細工されている（または他の仕方で信頼できない）ことが見出される場合、（その信頼できないメタデータによって示される）前に実行されたとされる型のメディア処理がオーディオ処理ユニットによって反復されてもよく、および／またはオーディオ処理ユニットによって前記メタデータおよび／またはオーディオ・データに対して他の処理が実行されてもよい。オーディオ処理ユニットは、該ユニットが（たとえば抽出された暗号学的な値および参照の暗号学的な値の一致に基づいて）処理状態メタデータが有効であると判定する場合、向上したメディア処理チェーンにおける下流の他のオーディオ処理ユニットに対して、（たとえばメディア・ビットストリーム中に存在する）ラウドネス処理状態メタデータが有効であることを信号伝達するよう構成されていてもよい。

【0075】

図２は、本発明のオーディオ処理ユニットの実施形態であるエンコーダ（１００）のブロック図である。エンコーダ１００のコンポーネントまたは要素の任意のものは、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの組み合わせにおいて、一つまたは複数のプロセスおよび／または一つまたは複数の回路（たとえばASIC、FPGAまたは他の集積回路）として実装されうる。エンコーダ１００は、図のように接続された、フレーム・バッファ１１０、パーサ１１１、デコーダ１０１、オーディオ状態有効確認器１０２、ラウドネス処理段１０３、オーディオ・ストリーム選択段１０４、エンコーダ１０５、詰め込み器（stuffer）／フォーマッタ段１０７、メタデータ生成段１０６、ダイアログ・ラウドネス測定サブシステム１０８およびフレーム・バッファ１０９を有する。典型的には、エンコーダ１００は他の処理要素（図示せず）も含む。

【0076】

エンコーダ１００（これはトランスコーダである）は、入力オーディオ・ビットストリーム（これはたとえばAC-3ビットストリーム、E-AC-3ビットストリームまたはドルビーEビットストリームのうちの一つであってもよい）をエンコードされた出力オーディオ・ビットストリーム（これはたとえばAC-3ビットストリーム、E-AC-3ビットストリームまたはドルビーEビットストリームのうちの別の一つであってもよい）に変換するよう構成されている。これは、入力ビットストリームに含まれるラウドネス処理状態メタデータを使って適応的および自動化されたラウドネス処理を実行することによることを含む。たとえば、エンコーダ１００は、入力ドルビーEビットストリーム（製作および放送施設において典型的に使われるが、放送されたオーディオ・プログラムを受信する消費者装置においては典型的には使われないフォーマット）を、AC-3またはE-AC-3の形のエンコードされた出力オーディオ・ビットストリーム（消費者装置への放送に好適）に変換するよう構成されていてもよい。

【0077】

図２のシステムはまた、エンコードされたオーディオの送達サブシステム１５０（これはエンコーダ１００から出力されるエンコードされたビットストリームを記憶するおよび／または送達する）と、デコーダ１５２とを含む。エンコーダ１００から出力されるエンコードされたオーディオ・ビットストリームは、サブシステム１５０によって（たとえばDVDまたはブルーレイ・ディスクの形で）記憶されても、あるいはサブシステム１５０（これは伝送リンクまたはネットワークを実装していてもよい）によって伝送されてもよく、あるいはサブシステム１５０によって記憶および伝送の両方をされてもよい。デコーダ１５２は、サブシステム１５０を介して受領する（エンコーダ１００によって生成された）エンコードされたオーディオ・ビットストリームをデコードするよう構成されている。これは、ビットストリームの各フレームからラウドネス処理状態メタデータ（LPSM）を抽出し、（任意的にはビットストリームからプログラム境界メタデータも抽出し、）デコードされたオーディオ・データを生成することによることを含む。典型的には、デコーダ１５２は、LPSM（および任意的にはプログラム境界メタデータも）を使ってデコードされたオーディオ・データに対して適応ラウドネス処理を実行し、および／またはデコードされたオーディオ・データおよびLPSMを、LPSM（および任意的にはプログラム境界メタデータも）を使ってデコードされたオーディオ・データに対して適応ラウドネス処理を実行するよう構成されている後処理器に転送するよう構成される。典型的には、デコーダ１５２は、サブシステム１５０から受領されたエンコードされたオーディオ・ビットストリームを（たとえば非一時的な仕方で）記憶するバッファを含む。

【0078】

エンコーダ１００およびデコーダ１５２のさまざまな実装が、本発明の方法の種々の実施形態を実行するよう構成される。

【0079】

フレーム・バッファ１１０は、エンコードされた入力オーディオ・ビットストリームを受領するよう結合されたバッファ・メモリである。動作では、バッファ１１０は、エンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを（たとえば非一時的な仕方で）記憶し、エンコードされたオーディオ・ビットストリームのフレームのシーケンスがバッファ１１０からパーサ１１１に呈される。

【0080】

パーサ１１１は、ラウドネス処理メタデータ（LPSM）を、任意的にはプログラム境界メタデータ（および／または他のメタデータをも、）そのようなメタデータが含まれているエンコードされた入力オーディオの各フレームから抽出し、少なくともLPSMを（任意的にはプログラム境界メタデータおよび／または他のメタデータをも）オーディオ状態有効確認器１０２、ラウドネス処理段１０３、段１０６およびサブシステム１０８に呈し、エンコードされた入力オーディオからオーディオ・データを抽出し、該オーディオ・データをデコーダ１０１に呈するよう結合され、構成されている。エンコーダ１００のデコーダ１０１は、オーディオ・データをデコードしてデコードされたオーディオ・データを生成し、該デコードされたオーディオ・データをラウドネス処理段１０３、オーディオ・ストリーム選択段１０４、サブシステム１０８および典型的には状態有効確認器１０２にも呈するよう構成されている。

【0081】

状態有効確認器１０２は、それに対して呈されるLPSM（および任意的には他のメタデータ）を認証し、有効確認するよう構成される。いくつかの実施形態では、LPSMは、（たとえば本発明のある実施形態に従って）入力ビットストリームに含まれていたデータ・ブロックである（または該データ・ブロックに含まれる）。該ブロックは、LPSM（および任意的には他のメタデータも）および／または基礎になるオーディオ・データ（デコーダ１０１から有効確認器１０２に提供される）を処理するための暗号学的ハッシュ（ハッシュ・ベースのメッセージ認証コードまたは「HMAC」）を含んでいてもよい。該データ・ブロックは、これらの実施形態において、デジタル署名されてもよい。それにより、下流のオーディオ処理ユニットは比較的容易に、該処理状態メタデータを認証および有効確認しうる。

【0082】

たとえば、HMACは、ダイジェストを生成するために使われ、本発明のビットストリームに含まれる保護値（単数または複数）は該ダイジェストを含んでいてもよい。該ダイジェストは、AC-3フレームについては、以下のように生成されてもよい：
１．AC-3データおよびLPSMがエンコードされたのち、フレーム・データ・バイト（連結されたフレーム・データ#1およびフレーム・データ#2）およびLPSMデータ・バイトが、ハッシュ関数HMACのための入力として使われる。補助データ・フィールド内に存在していてもよい他のデータは、このダイジェストを計算するためには考慮に入れられない。そのような他のデータは、AC-3データにもLSPSMデータにも属さないバイトであってもよい。LPSMに含まれる保護ビットは、HMACダイジェストを計算するためには考慮されなくてもよい。
２．ダイジェストが計算されたのち、該ダイジェストは保護ビットのためにリザーブされているフィールドにおいてビットストリームに書き込まれる。
３．完全なAC-3フレームの生成の最後の段階は、CRC検査の計算である。これは、フレームのいちばん最後に書かれ、LPSMビットを含む、このフレームに属するすべてのデータが考慮に入れられる。

【0083】

一つまたは複数のHMACでない暗号学的方法の任意のものを含むがそれに限定されない他の暗号学的方法が、LPSMおよび／または基礎になるオーディオ・データの安全な伝送および受領を保証するための（たとえば有効確認器１０２における）LPSMの有効確認のために使われてもよい。たとえば、（そのような暗号学的方法を使う）有効確認は、本発明のオーディオ・ビットストリームの実施形態を受領する各オーディオ処理ユニットにおいて実行され、ビットストリームに含まれるラウドネス処理状態メタデータおよび対応するオーディオ・データが（該メタデータによって示されるような）特定のラウドネス処理を受けている（および／または特定のラウドネス処理から帰結する）ものであり、そのような特定のラウドネス処理の実行後に修正されていないかどうかを判定することができる。

【0084】

状態有効確認器１０２は、有効確認動作の結果を示すために、オーディオ・ストリーム選択段１０４、メタデータ生成器１０６およびダイアログ・ラウドネス測定サブシステム１０８に制御データを呈する。該制御データに応答して、段１０４は次のいずれかを選択する（そしてエンコーダ１０５に伝える）ことができる：
（たとえば、LPSMがデコーダ１０１から出力されたオーディオ・データが特定の型のラウドネス処理を受けていないことを示し、有効確認器１０２からの制御ビットがLPSMが有効であることを示すとき）ラウドネス処理段１０３の適応的に処理された出力；または
（たとえば、LPSMがデコーダ１０１から出力されたオーディオ・データが段１０３によって実行されるはずの特定の型のラウドネス処理をすでに受けていることを示し、有効確認器１０２からの制御ビットがLPSMが有効であることを示すとき）デコーダ１０１から出力された前記オーディオ・データ。

【0085】

エンコーダ１００の段１０３は、デコーダ１０１から出力されたデコードされたオーディオ・データに対して、デコーダ１０１によって抽出されたLPSMによって示される一つまたは複数のオーディオ・データ特性に基づいて、適応的なラウドネス処理を実行するよう構成されている。段１０３は、適応的な変換領域のリアルタイムのラウドネスおよびダイナミックレンジ制御プロセッサであってもよい。段１０３はユーザー入力（たとえばユーザー目標ラウドネス／ダイナミックレンジ値またはdialnorm値）または他のメタデータ入力（たとえば、一つまたは複数の型のサードパーティー・データ、追跡情報、識別子、所有権があるか標準かの情報、ユーザー注釈データ、ユーザー選好データなど）および／または（たとえばフィンガープリンティング・プロセスからの）他の情報を受領して、そのような入力を、デコーダ１０１から出力されるデコードされたオーディオ・データを処理するために使ってもよい。段１０３は、（パーサ１１１によって抽出されるプログラム境界メタデータによって示される）単一のオーディオ・プログラムを示す（デコーダ１０１から出力される）デコードされたオーディオ・データに対して適応的なラウドネス処理を実行してもよく、パーサ１１１によって抽出されたプログラム境界メタデータによって示される異なるオーディオ・プログラムを示す（デコーダ１０１から出力される）デコードされたオーディオ・データを受領するのに応答して、ラウドネス処理をリセットしてもよい。

【0086】

ダイアログ・ラウドネス測定サブシステム１０８は、有効確認器１０２からの制御ビットがLPSMが無効であることを示す場合には、たとえばデコーダ１０１によって抽出されたLPSM（および／または他のメタデータ）を使って、ダイアログ（または他の発話）を示す（デコーダ１０１からの）デコードされたオーディオの諸セグメントのラウドネスを決定するよう動作してもよい。有効確認器１０２からの制御ビットがLPSMが有効であることを示す場合には、LPSMが（デコーダ１０１からの）デコードされたオーディオのダイアログ（または他の発話）セグメントの以前に決定されたラウドネスを示しているときは、ダイアログ・ラウドネス測定サブシステム１０８の動作は無効にされてもよい。サブシステム１０８は、（パーサ１１１によって抽出されるプログラム境界メタデータによって示される）単一オーディオ・プログラムを示すデコードされたオーディオ・データに対してラウドネス測定を実行してもよく、そのようなプログラム境界メタデータによって示される異なるオーディオ・プログラムを示すデコードされたオーディオ・データを受領するのに応答して、前記測定をリセットしてもよい。

【0087】

オーディオ・コンテンツにおけるダイアログのレベルを便利かつ簡単に測定するための有用なツール（たとえばドルビーLM100）が存在している。本発明のAPU（たとえばエンコーダ１００の段１０８）のいくつかの実施形態は、オーディオ・ビットストリーム（たとえば、エンコーダ１００のデコーダ１０１から段１０８に呈されるデコードされたAC-3ビットストリーム）のオーディオ・コンテンツの平均ダイアログ・ラウドネスを測定するためにそのようなツールを含むよう（またはそのようなツールの機能を実行するよう）実装される。

【0088】

段１０８がオーディオ・データの真の平均ダイアログ・ラウドネスを測定するよう実装される場合、測定は、オーディオ・コンテンツの、主として発話を含んでいる諸セグメントを単離する段階を含んでいてもよい。主として発話であるオーディオ・セグメントは、次いで、ラウドネス測定アルゴリズムに従って処理される。AC-3ビットストリームからデコードされるオーディオ・データについては、このアルゴリズムは、（国際規格ITU-R BS.1770に従う）標準的なK重み付けされたラウドネス指標（K-weighted loudness measure）であってもよい。あるいはまた、他のラウドネス指標（たとえばラウドネスの音響心理学的モデルに基づくもの）が使われてもよい。

【0089】

発話セグメントの単離は、オーディオ・データの平均ダイアログ・ラウドネスを測定するためには本質的ではないが、指標の精度を改善し、典型的には聴取者の観点からの、より満足のいく結果を与える。すべてのオーディオ・コンテンツがダイアログ（発話）を含むのではないので、オーディオ・コンテンツ全体のラウドネス指標は、発話が存在していたとした場合の、当該オーディオのダイアログ・レベルの十分な近似を提供しうる。

【0090】

メタデータ生成器１０６は、エンコーダ１００から出力されるエンコードされたビットストリームに段１０７によって含められるメタデータを生成する（および／または段１０７に渡す）。メタデータ生成器１０６は、段１０７に、エンコーダ１０１および／またはパーサ１１１によって抽出されたLPSM（および任意的にはプログラム境界メタデータおよび／または他のメタデータも）を渡してもよいし（たとえば、有効確認器１０２からの制御ビットがLPSMおよび／または他のメタデータが有効であることを示す場合）、あるいは新たなLPSM（および任意的にはプログラム境界メタデータおよび／または他のメタデータも）を生成して、該新たなメタデータを段１０７に呈してもよい（たとえば、有効確認器１０２からの制御ビットが、デコーダ１０１によって抽出されたLPSMおよび／または他のメタデータが無効であることを示す場合）。あるいは、段１０７に対して、デコーダ１０１および／またはパーサ１１１によって抽出されたメタデータと新たに生成されたメタデータとの組み合わせを呈してもよい。メタデータ生成器１０６は、サブシステム１０８によって生成されたラウドネス・データと、サブシステム１０８によって実行されたラウドネス処理の型を示す少なくとも一つの値とを、エンコーダ１００から出力されるエンコードされたビットストリームに含めるために、段１０７に対して呈するLPSM中に含めてもよい。

【0091】

メタデータ生成器１０６は、エンコードされたビットストリームに含めるべきLPSM（および任意的には他のメタデータも）および／またはエンコードされたビットストリームに含めるべき基礎になるオーディオ・データの解読、認証または有効確認の少なくとも一つについて有用な保護ビット（これはハッシュ・ベースのメッセージ認証コードまたは「HMAC」からなっていてもよく、あるいはそれを含んでいてもよい）を生成してもよい。

【0092】

典型的な動作では、ダイアログ・ラウドネス測定サブシステム１０８は、デコーダ１０１から出力されたオーディオ・データを処理して、それに応答して、ラウドネス値（たとえば、ゲーティングされたおよびゲーティングされないダイアログ・ラウドネス値）およびダイナミックレンジ値を生成する。これらの値に応答して、メタデータ生成器１０６は、エンコーダ１００から出力されるエンコードされたビットストリームに（詰め込み器／フォーマッタ１０７によって）含めるためにラウドネス処理状態メタデータ（LPSM）を生成してもよい。

【0093】

追加的、任意的または代替的に、エンコーダ１００の１０６および／または１０８のサブシステムは、オーディオ・データの追加的な解析を実行して、段１０７から出力されるエンコードされたビットストリームに含めるための、オーディオ・データの少なくとも一つの特性を示すメタデータを生成してもよい。

【0094】

エンコーダ１０５は、選択段１０４から出力されたオーディオ・データを（たとえばそれに対して圧縮を実行することによって）エンコードし、段１０７から出力されるエンコードされたビットストリームに含めるために、エンコードされたオーディオを段１０７に呈する。

【0095】

段１０７は、エンコーダ１０５からのエンコードされたオーディオと生成器１０６からのメタデータ（LPSMを含む）とを多重化して、段１０７から出力される、エンコードされたビットストリームを生成する。好ましくは、エンコードされたビットストリームは、本発明のある好ましい実施形態によって指定されるフォーマットをもつようにされる。

【0096】

フレーム・バッファ１０９は、段１０７から出力されるエンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを（たとえば非一時的な仕方で）記憶するバッファ・メモリである。次いで、エンコードされたオーディオ・ビットストリームのそれらのフレームのシーケンスが、バッファ１０９から、エンコーダ１００からの出力として、送達システム１５０に呈される。

【0097】

メタデータ生成器１０６によって生成され、段１０７によって、エンコードされたビットストリームに含められたLPSMは、対応するオーディオ・データのラウドネス処理状態（たとえば、該オーディオ・データに対してどんな型（単数または複数）のラウドネス処理が実行されたか）および対応するオーディオ・データのラウドネス（たとえば、測定されたダイアログ・ラウドネス、ゲーティングされたおよび／またはゲーティングされないラウドネスおよび／またはダイナミックレンジ）を示す。

【0098】

本稿において、ラウドネスおよび／またはオーディオ・データに対して実行されるレベル測定の「ゲーティング」とは、閾値を超える計算された値（単数または複数）が最終的な測定に含められる（たとえば、最終的な測定された値において−60dBFSより低い短期的なラウドネス値を無視する）ような特定のレベルまたはラウドネスの閾値を参照する。絶対的な値に対するゲーティングは固定したレベルまたはラウドネスを参照し、相対値に対するゲーティングは現在の「ゲーティングされていない」測定値に依存する値を参照する。

【0099】

エンコーダ１００のいくつかの実装では、メモリ１０９にバッファリングされている（そして送達システム１５０に出力される）エンコードされたビットストリームは、AC-3ビットストリームまたはE-AC-3ビットストリームであり、オーディオ・データ・セグメント（たとえば、図４に示したフレームのAB0〜AB5セグメント）およびメタデータ・セグメントを含む。ここで、オーディオ・データ・セグメントはオーディオ・データを示し、メタデータ・セグメントのうち少なくともいくつかのセグメントのそれぞれは、ラウドネス処理状態メタデータ（LPSM）を含む。段１０７はLPSMを（および任意的にはプログラム境界メタデータも）次のフォーマットでビットストリーム中に挿入する。LPSMを（および任意的にはプログラム境界メタデータも）含むメタデータ・セグメントのそれぞれは、ビットストリームの余剰ビット・セグメント（たとえば、図４または図７に示される余剰ビット・セグメント「W」）またはビットストリームのフレームのビットストリーム情報（「BSI」）セグメントの「addbsi」フィールドまたはビットストリームのフレームの末尾にある補助データ・フィールド（たとえば図４または図７に示されるAUXセグメント）に含められる。ビットストリームのフレームは、それぞれがLPSMを含む一つまたは二つのメタデータ・セグメントを含んでいてもよく、フレームが二つのメタデータ・セグメントを含む場合には、一方はフレームのaddbsiフィールドに、他方はフレームのAUXフィールドに存在していてもよい。いくつかの実施形態では、LPSMを含む各メタデータ・セグメントは、次のフォーマットをもつLPSMペイロード（またはコンテナ）・セグメントを含む：
ヘッダ（典型的にはLPSMペイロードの始まりを同定する同期語を含み、それに続いて少なくとも一つの識別情報値、たとえば下記の表２に示されるLPSMフォーマット・バージョン、長さ、期間（period）、カウントおよびサブストリーム関連付け値がくる）、
ヘッダ後に、
対応するオーディオ・データがダイアログを示すかダイアログを示さないか（たとえば、対応するオーディオ・データのどのチャネルがダイアログを示すか）を示す少なくとも一つのダイアログ指示値（たとえば、表２のパラメータ「ダイアログ・チャネル」）；
対応するオーディオ・データがラウドネス規制の示されるセットに準拠しているかどうかを示す少なくとも一つのラウドネス規制準拠値（たとえば、表２のパラメータ「ラウドネス規制型」）；
対応するオーディオ・データに対して実行されたラウドネス処理の少なくとも一つの型を示す少なくとも一つのラウドネス処理値（たとえば、表２のパラメータ「ダイアログ・ゲーテッド・ラウドネス補正フラグ」、「ラウドネス補正型」の一つまたは複数）；および
対応するオーディオ・データに特徴的な少なくとも一つのラウドネス（たとえばピークまたは平均ラウドネス）を示す少なくとも一つのラウドネス値（たとえば、パラメータ「ITU相対ゲーテッド・ラウドネス」、「ITU発話ゲーテッド・ラウドネス」、「ITU（EBU3341）短時間3sラウドネス」および「真のピーク」の一つまたは複数）。

【0100】

いくつかの実施形態では、LPSMおよびプログラム境界メタデータを含む各メタデータ・セグメントは、コア・ヘッダを（任意的には追加的なコア要素も）含み、該コア・ヘッダのあとに（または該コア・ヘッダおよび他のコア要素のあとに）、次のフォーマットをもつLPSMペイロード（またはコンテナ）セグメントを含む：
ヘッダ。典型的には少なくとも一つの識別情報値（たとえば、本稿に記載される表２に示されるような、LPSMフォーマット・バージョン、長さ、期間（period）、カウントおよびサブストリーム関連付け値）を含む；
ヘッダ後に、LPSMおよびプログラム境界メタデータ。プログラム境界メタデータは、プログラム境界フレーム・カウントと、そのフレームがプログラム境界フレーム・カウントのみを含むか、プログラム境界フレーム・カウントおよびオフセット値の両方を含むかを示す符号値（たとえば「offset_exist」〔オフセット存在〕値）と、（場合によっては）オフセット値とを含んでいてもよい。

【0101】

いくつかの実装では、段１０７によって余剰ビット・セグメントまたはビットストリームのフレームの「addbsi」フィールドまたは補助データ・フィールドに挿入されるメタデータ・セグメントのそれぞれは、次のフォーマットをもつ：
コア・ヘッダ（典型的にはメタデータ・セグメントの開始を同定する同期語と、それに続く識別情報値、たとえば下記の表１に示されるコア要素バージョン、長さおよび期間（period）、拡張要素カウントおよびサブストリーム関連付け値を含む）；および
コア・ヘッダ後に、ラウドネス処理状態メタデータまたは対応するオーディオ・データの少なくとも一方の解読、認証（authentication）または有効確認（validation）のうちの少なくとも一つのために有用な少なくとも一つの保護値（たとえば、表１のHMACダイジェストおよびオーディオ・フィンガープリント値）；および
やはりコア・ヘッダ後に、当該メタデータ・セグメントがLPSMを含む場合、LPSMペイロード識別情報（「ID」）およびLPSMペイロード・サイズの値であって、後続のメタデータをLPSMペイロードとして同定し、該LPSMペイロードのサイズを示すもの。

【0102】

（好ましくは上記で指定したフォーマットをもつ）LPSMペイロード（またはコンテナ）・セグメントは、LPSMペイロードIDおよびLPSMペイロード・サイズの値に続く。

【0103】

いくつかの実施形態では、フレームの補助データ・フィールド（または「addbsi」フィールド）中の各メタデータ・セグメントは、三レベルの構造をもつ：
高レベル構造。これは、補助データ（またはaddbsi）フィールドがメタデータを含むかどうかを示すフラグと、どの型（単数または複数）のメタデータが存在しているかを示す少なくとも一つのID値と、典型的にはまた（メタデータが存在する場合）（たとえば各型の）何ビットのメタデータが存在するかを示す値とを含む。存在できるメタデータの一つの型はLPSMであり、存在できるメタデータのもう一つの型はプログラム境界メタデータであり、存在できるメタデータのもう一つの型はメディア・リサーチ（research）・メタデータ（たとえば、ニールセン・メディア・リサーチ（Nielsen Media Research）・メタデータ）である；
中間レベル構造。これは、メタデータのそれぞれの同定される型についてのコア要素を含む（たとえば、メタデータのそれぞれの同定される型についての上述したようなコア・ヘッダ、保護値およびLPSMペイロードIDおよびLPSMペイロード・サイズの値）；および
低レベル構造。これは、あるコア要素についての各ペイロード（たとえば、前記コア要素によってLPSMペイロードが存在すると同定されている場合のLPSMペイロードおよび／または前記コア要素によってメタデータ・ペイロードが存在すると同定されている場合の別の型のメタデータ・ペイロード）を含む。

【0104】

そのような三レベル構造におけるデータ値は、ネストされることができる。たとえば、コア要素によって同定されるLPSMペイロードおよび／または別のメタデータ・ペイロードについての保護値（単数または複数）が、コア要素によって同定される各ペイロード後に（よって、コア要素のコア・ヘッダ後に）含まれることができる。一例では、コア・ヘッダは、LPSMペイロードおよび別のメタデータ・ペイロードを同定することができ、第一のペイロード（たとえばLPSMペイロード）についてのペイロードIDおよびペイロード・サイズの値がコア・ヘッダに続くことができ、第一のペイロード自身が該IDおよびサイズの値に続くことができ、第二のペイロードについてのペイロードIDおよびペイロード・サイズ値が第一のペイロードに続くことができ、第二のペイロード自身がこれらのIDおよびサイズの値に続くことができ、両方のペイロードについての（またはコア要素値ならびに両方のペイロードについての）保護ビット（単数または複数）が最後のペイロードに続くことができる。

【0105】

いくつかの実施形態では、デコーダ１０１が、暗号学的ハッシュをもつ本発明のある実施形態に従って生成されたオーディオ・ビットストリームを受領する場合、デコーダは、ビットストリームから決定されたデータ・ブロックからの該暗号学的ハッシュをパースして取り出すよう構成されている。前記ブロックは、ラウドネス処理状態メタデータ（LPSM）および任意的にはプログラム境界メタデータをも含む。有効確認器１０２は該暗号学的ハッシュを使って、受領されたビットストリームおよび／または関連付けられたメタデータを有効確認してもよい。たとえば、有効確認器１０２が、参照暗号学的ハッシュと前記データ・ブロックから取り出された前記暗号学的ハッシュとの間の一致に基づいて前記LPSMが有効であると見出す場合、有効確認器１０２は、対応するオーディオ・データに対するプロセッサ１０３の動作を無効にしてもよく、選択段１０４にオーディオ・データを（変更なしに）素通りさせてもよい。追加的、任意的または代替的に、暗号学的ハッシュに基づく方法の代わりに他の型の暗号技法が使用されてもよい。

【0106】

図２のエンコーダ１００は、（デコーダ１０１によって抽出されたLPSMに、任意的にはプログラム境界メタデータにも応答して）後／前処理ユニットが、ある型のラウドネス処理を、（要素１０５、１０６および１０７において）エンコードされるべきオーディオ・データに対して実行したことを判別してもよく、よって前に実行されたラウドネス処理において使われたおよび／または前に実行されたラウドネス処理から導出された特定のパラメータを含むラウドネス処理状態メタデータを（生成器１０６において）生成してもよい。いくつかの実装では、エンコーダ１００は、エンコーダがオーディオ・コンテンツに対して実行された処理の型を認識する限り、オーディオ・コンテンツに対する処理履歴を示す処理状態メタデータを生成して（そしてそれから出力されるエンコードされたビットストリームに含めて）もよい。

【0107】

図３は、本発明のオーディオ処理ユニットのある実施形態であるデコーダ（２００）およびそれに結合された後処理器（３００）のブロック図である。後処理器（３００）は、本発明のオーディオ処理ユニットの実施形態でもある。デコーダ２００および後処理器３００のコンポーネントまたは要素の任意のものは、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの組み合わせにおいて、一つまたは複数のプロセスおよび／または一つまたは複数の回路（たとえばASIC、FPGAまたは他の集積回路）として実装されうる。デコーダ２００は、図のように接続された、フレーム・バッファ２０１、パーサ２０５、オーディオ・デコーダ２０２、オーディオ状態有効確認段（有効確認器）２０３および制御ビット生成段２０４を有する。典型的には、デコーダ２００は他の処理要素（図示せず）も含む。

【0108】

フレーム・バッファ２０１（バッファ・メモリ）は、デコーダ２００によって受領されるエンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを（たとえば非一時的な仕方で）記憶する。エンコードされたオーディオ・ビットストリームのフレームのシーケンスがバッファ２０１からパーサ２０５に呈される。

【0109】

パーサ２０５は、ラウドネス処理メタデータ（LPSM）を、任意的にはプログラム境界メタデータおよび他のメタデータをも、前記エンコードされた入力オーディオの各フレームから抽出し、少なくともLPSMを（プログラム境界メタデータが抽出される場合にはプログラム境界メタデータをも）オーディオ状態有効確認器２０３および段２０４に呈し、LPSMを（任意的にはプログラム境界メタデータをも）出力として（たとえば後処理器３００に）呈し、エンコードされた入力オーディオからオーディオ・データを抽出し、抽出されたオーディオ・データをデコーダ２０２に呈するよう結合され、構成されている。

【0110】

デコーダ２００に入力されるエンコードされたオーディオ・ビットストリームは、AC-3ビットストリーム、E-AC-3ビットストリームまたはドルビーEビットストリームのうちの一つであってもよい。

【0111】

図３のシステムは後処理器３００をも含む。後処理器３００は、フレーム・バッファ３０１と、バッファ３０１に結合された少なくとも一つの処理要素を含む他の処理要素（図示せず）とを有する。フレーム・バッファ３０１は、デコーダ２００から後処理器３００によって受領されるデコードされたオーディオ・ビットストリームの少なくとも一つのフレームを（たとえば非一時的な仕方で）記憶する。後処理器３００の処理要素は、バッファ３０１から出力されるデコードされたオーディオ・ビットストリームのフレームのシーケンスを受領し、デコーダ２０２から出力される（LPSMを含む）メタデータおよび／またはデコーダ２００の段２０４から出力される制御ビットを使って適応的に処理するよう結合され、構成されている。典型的には、後処理器３００は、LPSM値および任意的にはプログラム境界メタデータも使って（たとえば、単一のオーディオ・プログラムを示すオーディオ・データについてのLPSMによって示される、ラウドネス処理状態および／または一つまたは複数のオーディオ・データ特性に基づいて）デコードされたオーディオ・データに対して適応的なラウドネス処理を実行するよう構成されている。

【0112】

デコーダ２００および後処理器３００のさまざまな実装は、本発明の方法の種々の実施形態を実行するよう構成されている。

【0113】

デコーダ２００のオーディオ・デコーダ２０２は、パーサ２０５によって抽出されたオーディオ・データをデコードして、デコードされたオーディオ・データを生成し、該デコードされたオーディオ・データを出力として（たとえば後処理器３００に）呈するよう構成されている。

【0114】

状態有効確認器２０３は、それに対して呈されるLPSMを（任意的には他のメタデータも）認証し、有効確認するよう構成されている。いくつかの実施形態では、LPSMは、（たとえば本発明のある実施形態に従って）入力ビットストリームに含められたデータ・ブロックである（または該データ・ブロックに含まれる）。該ブロックは、LPSM（および任意的には他のメタデータも）および／または基礎になるオーディオ・データ（パーサ２０５および／またはデコーダ２０２から有効確認器２０３に提供される）を処理するための暗号学的ハッシュ（ハッシュ・ベースのメッセージ認証コードまたは「HMAC」）を含んでいてもよい。該データ・ブロックは、これらの実施形態において、デジタル署名されてもよい。それにより、下流のオーディオ処理ユニットは比較的容易に、該処理状態メタデータを認証および有効確認しうる。

【0115】

一つまたは複数のHMACでない暗号学的方法の任意のものを含むがそれに限定されない他の暗号学的方法が、LPSMおよび／または基礎になるオーディオ・データの安全な送受信を保証するための（たとえば有効確認器２０３における）LPSMの有効確認のために使われてもよい。たとえば、（そのような暗号学的方法を使う）有効確認は、本発明のオーディオ・ビットストリームの実施形態を受領する各オーディオ処理ユニットにおいて実行され、ビットストリームに含まれるラウドネス処理状態メタデータおよび対応するオーディオ・データが（該メタデータによって示されるような）特定のラウドネス処理を受けている（および／または特定のラウドネス処理から帰結する）ものであり、そのような特定のラウドネス処理の実行後に修正されていないかどうかを判定することができる。

【0116】

状態有効確認器２０３は、有効確認動作の結果を示すために、ビット生成器２０４を制御する制御データを呈するおよび／または該制御データを出力として（たとえば後処理器３００に）呈する。該制御データに（任意的には入力ビットストリームから抽出される他のメタデータにも）応答して、段２０４は次のいずれかを生成し（そして後処理器３００に呈し）てもよい：
（たとえば、LPSMがデコーダ２０２から出力されたオーディオ・データが特定の型のラウドネス処理を受けていることを示し、有効確認器２０３からの制御ビットがLPSMが有効であることを示すとき）デコーダ２０２から出力されたデコードされたオーディオ・データが該特定の型のラウドネス処理を受けていることを示す制御ビット；または
（たとえば、LPSMがデコーダ２０２から出力されたオーディオ・データが特定の型のラウドネス処理を受けていないことを示す、またはLPSMがデコーダ２０２から出力されたオーディオ・データが特定の型のラウドネス処理を受けていることを示すが、有効確認器２０３からの制御ビットがLPSMが有効でないことを示すとき）デコーダ２０３から出力されたデコードされたオーディオ・データが該特定の型のラウドネス処理を受けるべきであることを示す制御ビット。

【0117】

あるいはまた、デコーダ２００は、入力ビットストリームからデコーダ２０２によって抽出されたメタデータおよび入力ビットストリームからパーサ２０５によって抽出されたLPSM（および任意的にはプログラム境界メタデータも）を後処理器３００に呈し、後処理器３００はLPSM（および任意的にはプログラム境界メタデータも）を使って、デコードされたオーディオ・データに対してラウドネス処理を実行し、LPSMの有効確認を実行し、次いで有効確認がLPSMが有効であることを示す場合には、LPSM（および任意的にはプログラム境界メタデータも）を使って、デコードされたオーディオ・データに対してラウドネス処理を実行する。

【0118】

いくつかの実施形態では、デコーダ２００が、暗号学的ハッシュをもつ本発明のある実施形態に従って生成されるオーディオ・ビットストリームを受領する場合、デコーダは、ビットストリームから決定されたデータ・ブロックからの該暗号学的ハッシュをパースして取り出すよう構成されている。前記ブロックは、ラウドネス処理状態メタデータ（LPSM）を含む。有効確認器２０３は該暗号学的ハッシュを使って、受領されたビットストリームおよび／または関連付けられたメタデータを有効確認してもよい。たとえば、有効確認器２０３が、参照暗号学的ハッシュと前記データ・ブロックから取り出された前記暗号学的ハッシュとの間の一致に基づいて前記LPSMが有効であると見出す場合、有効確認器２０３は、下流のオーディオ処理ユニット（たとえば、ボリューム平準化ユニットであるまたはボリューム平準化ユニットを含んでいてもよい後処理器３００）に、ビットストリームの該オーディオ・データを（変更なしに）素通りさせるよう信号伝達してもよい。追加的、任意的または代替的に、暗号学的ハッシュに基づく方法の代わりに他の型の暗号技法が使用されてもよい。

【0119】

デコーダ２００のいくつかの実装では、受領される（そしてメモリ２０１にバッファリングされる）エンコードされたビットストリームはAC-3ビットストリームまたはE-AC-3ビットストリームであり、オーディオ・データ・セグメント（たとえば図４に示されるフレームのAB0〜AB5セグメント）およびメタデータ・セグメントを含む。ここで、オーディオ・データ・セグメントはオーディオ・データを示し、メタデータ・セグメントの少なくともいくつかの各セグメントはラウドネス処理状態メタデータ（LPSM）および任意的にはプログラム境界メタデータをも含む。デコーダ段２０２（および／またはパーサ２０５）は、ビットストリームから、以下のフォーマットをもつLPSMを（任意的にはプログラム境界メタデータも）抽出するよう構成されている。LPSMを（任意的にはプログラム境界メタデータも）含むメタデータ・セグメントのそれぞれは、ビットストリームのフレームの余剰ビット・セグメントまたはビットストリームのフレームのビットストリーム情報（「BSI」）セグメントの「addbsi」フィールド中に、あるいはビットストリームのフレームの末尾の補助データ・フィールド（たとえば図４に示されるAUXセグメント）中に含まれる。ビットストリームのフレームは、それぞれLPSMを含む一つまたは二つのメタデータ・セグメントを含んでいてもよく、フレームが二つのメタデータ・セグメントを含む場合、一方がフレームのaddbsiフィールドに存在し、他方がフレームのAUXフィールドに存在していてもよい。いくつかの実施形態では、LPSMを含む各メタデータ・セグメントは、以下のフォーマットをもつLPSMペイロード（またはコンテナ）セグメントを含む。

【0120】

ヘッダ（典型的にはLPSMペイロードの始まりを同定する同期語を含み、それに続いて識別情報値、たとえば、下記の表２に示される、LPSMフォーマット・バージョン、長さ、期間（period）、カウントおよびサブストリーム関連付け値を含む）；
ヘッダ後に、
対応するオーディオ・データがダイアログを示すかダイアログを示さないか（たとえば、対応するオーディオ・データのどのチャネルがダイアログを示すか）を示す少なくとも一つのダイアログ指示値（たとえば表２のパラメータ「ダイアログ・チャネル」）；
対応するオーディオ・データがラウドネス規制の示されるセットに準拠しているかどうかを示す少なくとも一つのラウドネス規制準拠値（たとえば表２のパラメータ「ラウドネス規制型」）；
対応するオーディオ・データに対して実行されたラウドネス処理の少なくとも一つの型を示す少なくとも一つのラウドネス処理値（たとえば、表２のパラメータ「ダイアログ・ゲーテッド・ラウドネス補正フラグ」「ラウドネス補正型」の一つまたは複数）；および
対応するオーディオ・データに特徴的な少なくとも一つのラウドネス（たとえばピークまたは平均ラウドネス）を示す少なくとも一つのラウドネス値（たとえば、表２のパラメータ「ITU相対ゲーテッド・ラウドネス」「ITU発話ゲーテッド・ラウドネス」「ITU（EBU3341）短時間3sラウドネス」および「真のピーク」の一つまたは複数）。

【0121】

いくつかの実施形態では、LPSMおよびプログラム境界メタデータを含む各メタデータ・セグメントは、コア・ヘッダ（任意的には追加的なコア要素も）を含み、該コア・ヘッダのあとに（または該コア・ヘッダおよび他のコア要素のあとに）、次のフォーマットをもつLPSMペイロード（またはコンテナ）セグメントを含む：
ヘッダ。典型的には少なくとも一つの識別情報値（たとえば、下記の表２に示されるような、LPSMフォーマット・バージョン、長さ、期間（period）、カウントおよびサブストリーム関連付け値）を含む；
ヘッダ後に、LPSMおよびプログラム境界メタデータ。プログラム境界メタデータは、プログラム境界フレーム・カウントと、そのフレームがプログラム境界フレーム・カウントのみを含むか、プログラム境界フレーム・カウントおよびオフセット値の両方を含むかを示す符号値（たとえば「offset_exist」〔オフセット存在〕値）と、（場合によっては）オフセット値とを含んでいてもよい。

【0122】

いくつかの実装では、パーサ２０５（および／またはデコーダ段２０２）は、ビットストリームのフレームの余剰ビット・セグメントまたは「addbsi」フィールドまたは補助データ・フィールドから、次のフォーマットをもつ各メタデータ・セグメントを抽出するよう構成される：
コア・ヘッダ（典型的にはメタデータ・セグメントの開始を同定する同期語と、それに続く少なくとも一つの識別情報値、たとえば下記の表１に示されるコア要素バージョン、長さおよび期間（period）、拡張要素カウントおよびサブストリーム関連付け値を含む）；および
コア・ヘッダ後に、ラウドネス処理状態メタデータまたは対応するオーディオ・データの少なくとも一方の解読、認証（authentication）または有効確認（validation）のうちの少なくとも一つのために有用な少なくとも一つの保護値（たとえば、表１のHMACダイジェストおよびオーディオ・フィンガープリント値）；および
やはりコア・ヘッダ後に、当該メタデータ・セグメントがLPSMを含む場合、LPSMペイロード識別情報（「ID」）およびLPSMペイロード・サイズの値であって、後続のメタデータをLPSMペイロードとして同定し、該LPSMペイロードのサイズを示すもの。

【0123】

（好ましくは上記で指定したフォーマットをもつ）LPSMペイロード（またはコンテナ）・セグメントは、LPSMペイロードIDおよびLPSMペイロード・サイズの値に続く。

【0124】

より一般には、本発明の好ましい実施形態によって生成されるエンコードされたオーディオ・ビットストリームは、メタデータ要素およびサブ要素に、コア（必須）または拡張（任意的な要素）としてラベル付けする機構を提供する構造をもつ。これは、（メタデータも含めた）ビットストリームのデータ・レートを、多数の用途を横断してスケーリングすることを許容する。好ましいビットストリーム・シンタックスのコア（必須）要素は、オーディオ・コンテンツに関連付けられた拡張（任意的）要素が（帯域内に（in-band））および／またはリモート位置に（帯域外に（out of band））存在することを信号伝達することもできるべきである。

【0125】

コア要素（単数または複数）は、ビットストリームの全フレームに存在することが要求される。コア要素のいくつかのサブ要素は任意的であり、任意の組み合わせにおいて存在していてもよい。拡張要素は全フレームに存在することは要求されない（ビットレート・オーバーヘッドを限定的にするため）。このように、拡張要素は、いくつかのフレームに存在していて、他のフレームには存在しなくてもよい。拡張要素のいくつかのサブ要素は任意的であり、任意の組み合わせにおいて存在していてもよいが、拡張要素のいくつかのサブ要素は必須であってもよい（つまり、その拡張要素がビットストリームのフレームに存在するならば必須）。

【0126】

あるクラスの実施形態では、オーディオ・データ・セグメントおよびメタデータ・セグメントのシーケンスを含むエンコードされたオーディオ・ビットストリームが（たとえば、本発明を具現するオーディオ処理ユニットによって）生成される。オーディオ・データ・セグメントはオーディオ・データを示し、メタデータ・セグメントのうち少なくともいくつかのセグメントのそれぞれは、ラウドネス処理状態メタデータ（LPSM）および任意的にはプログラム境界メタデータをも含み、オーディオ・データ・セグメントはメタデータ・セグメントと時分割多重される。このクラスの好ましい実施形態では、メタデータ・セグメントのそれぞれは、本稿に記載される好ましいフォーマットをもつ。

【0127】

ある好ましいフォーマットでは、エンコードされたビットストリームはAC-3ビットストリームまたはE-AC-3ビットストリームであり、LPSMを含むメタデータ・セグメントのそれぞれは、追加的なビットストリーム情報として、ビットストリームのフレームのビットストリーム情報（「BSI」）セグメントの「addbsi」フィールド（図６に示される）に、またはビットストリームのフレームの補助データ・フィールドに、またはビットストリームのフレームの余剰ビット・セグメントに（たとえばエンコーダ１００の好ましい実装の段１０７によって）含められる。

【0128】

上記の好ましいフォーマットでは、各フレームは、下記の表１に示されるフォーマットをもつコア要素を、フレームのaddbsiフィールド（または余剰ビット・セグメント）に含む。

【0129】

【表1】

該好ましいフォーマットでは、addbsi（または補助データ）フィールドまたは余剰ビット・セグメントのうち、LPSMを含むそれぞれは、コア・ヘッダ（および任意的には追加的なコア要素）と、コア・ヘッダのあとの（またはコア・ヘッダおよび他のコア要素のあとの）次のLPSM値（パラメータ）とを含む：
ペイロードID（該メタデータをLPSMとして同定する）。これは（たとえば表１において指定されるような）コア要素値に続く；
ペイロード・サイズ（LPSMペイロードの大きさを示す）。これはペイロードIDに続く；
LPSMデータ（ペイロードIDおよびペイロード・サイズ値に続く）。これは次の表（表２）に示されるフォーマットをもつ。

【0130】

【表2】

本発明に基づいて生成されるエンコードされたビットストリームのもう一つの好ましいフォーマットでは、ビットストリームはAC-3ビットストリームまたはE-AC-3ビットストリームであり、メタデータ・セグメントのうちLPSM（および任意的にはプログラム境界メタデータも）を含むそれぞれは：ビットストリームのフレームの余剰ビット・セグメント；またはビットストリームのフレームのビットストリーム情報（「BSI」）セグメントの「addbsi」フィールド（図６に示した）；またはビットストリームのフレームの末尾の補助データ・フィールド（たとえば図４に示されるAUXフィールド）のうちの任意のものに（たとえばエンコーダ１００の好ましい実装の段１０７によって）含められる。フレームは、それぞれがLPSMを含む一つまたは二つのメタデータ・セグメントを含んでいてもよく、フレームが二つのメタデータ・セグメントを含む場合、一方はフレームのaddbsiフィールドに存在し、他方はフレームのAUXフィールドに存在してもよい。LPSMを含む各メタデータ・セグメントは、上記の表１および表２を参照して上記で規定したフォーマットをもつ（すなわち、表１に指定されるコア要素を含み、それに続いて、上記で規定したペイロードID（当該メタデータをLPSMとして同定する）およびペイロード・サイズ値がきて、それにペイロード（表２に示されるフォーマットをもつLPSMデータ）が続く）。

【0131】

もう一つの好ましいフォーマットでは、エンコードされたビットストリームはドルビーEビットストリームであり、メタデータ・セグメントのうちLPSM（および任意的にはプログラム境界メタデータも）を含むそれぞれは、ドルビーE保護帯域区間の最初のN個のサンプル位置である。LPSMを含むそのようなメタデータ・セグメントを含むドルビーEビットストリームは、好ましくは、SMPTE 337MプリアンブルのPd語において信号伝達されるLPSMペイロード長を示す値を含む（SMPTE 337M Pa語反復レートは好ましくは、関連するビデオ・フレーム・レートと同じまま）。

【0132】

エンコードされたビットストリームがE-AC-3ビットストリームであるある好ましいフォーマットでは、メタデータ・セグメントのうちLPSM（および任意的にはプログラム境界メタデータも）を含むそれぞれは、ビットストリームのフレームの、余剰ビット・セグメントに、またはビットストリーム情報（「BSI」）セグメントの「addbsi」フィールドにおいて、追加的なビットストリーム情報として（たとえば、エンコーダ１００の好ましい実装の段１０７によって）含められる。次に、この好ましいフォーマットにおけるLPSMをもつE-AC-3ビットストリームのエンコードのさらなる諸側面について述べる。

【0133】

１．E-AC-3ビットストリームの生成中において、（LPSM値をビットストリーム中に挿入する）E-AC-3エンコーダが「アクティブである」間は、生成されるすべてのフレーム（同期フレーム）について、ビットストリームは、フレームのaddbsiフィールド（または余剰ビット・セグメント）において担持される（LPSMを含む）メタデータ・ブロックを含むべきである。該メタデータ・ブロックを担持するために必要とされるビットは、エンコーダ・ビットレート（フレーム長）を増大させるべきではない。

【0134】

２．（LPSMを含む）すべてのメタデータ・ブロックは、以下の情報を含むべきである：
loudness_correction_type_flag〔ラウドネス補正型フラグ〕：ここで、「1」は対応するオーディオ・データのラウドネスが当該エンコーダの上流で補正されたことを示し、「0」は該ラウドネスが当該エンコーダに組み込まれているラウドネス補正器（たとえば、図２のエンコーダ１００のラウドネス処理器１０３）によって補正されたことを示す；
speech_channel〔発話チャネル〕：どの源チャネル（単数または複数）が（それまでの0.5秒の間に）発話を含むかを示す。発話が検出されない場合、その旨が示される；
speech_loudness〔発話ラウドネス〕：発話を含む各対応するオーディオ・チャネルの（それまでの0.5秒の間の）統合された発話ラウドネスを示す；
ITU_loudness〔ITUラウドネス〕：各対応するオーディオ・チャネルの統合されたITU BS.1770-3ラウドネスを示す；
利得：（可逆性を実証するため）デコーダにおいて反転するためのラウドネス複合利得（単数または複数）。

【0135】

３．（LPSM値をビットストリーム中に挿入する）E-AC-3エンコーダが「アクティブ」であり、「信頼」フラグをもつAC-3フレームを受領している間は、当該エンコーダにおけるラウドネス・コントローラ（たとえば図２のエンコーダ１００のラウドネス処理器１０３）はバイパスされるべきである。「信頼される」源dialnorm〔ダイアログ正規化〕およびDRC値は（たとえばエンコーダ１００の生成器１０６によって）E-AC-3エンコーダ・コンポーネント（たとえばエンコーダ１００の段１０７）に渡されるべきである。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フレームを受領している間は、当該エンコーダに組み込まれたラウドネス・コントローラ（たとえば図２のエンコーダ１００のラウドネス処理器１０３）はアクティブであるべきである。LPSMブロック生成は継続し、loudness_correction_type_flagは「0」に設定される。ラウドネス・コントローラ・アクティブ化シーケンスは、「信頼」フラグが消失するデコードされたAC-3フレームの先頭に同期されるべきである。ラウドネス・コントローラ・アクティブ化シーケンスは次のように実装されるべきである。leveler_amount〔平準化器量〕コントロールが、1オーディオ・ブロック期間（すなわち、5.3msec）にわたって値0から値9にインクリメントされ、leveler_back_end_meter〔平準化器バック・エンド・メーター〕コントロールが「アクティブ」モードにされる（この動作は、シームレスな遷移を与え、back_end_meter統合リセットを含むべきである）。

【0136】

５．エンコード中、グラフィカル・ユーザー・インターフェース（GUI）はユーザーに対して以下のパラメータを示すべきである：「入力オーディオ・プログラム［信頼される／信頼されない］」−このパラメータの状態は入力信号内の「信頼」フラグの存在に基づく；および「リアルタイム・ラウドネス補正：［有効化／無効化］」−このパラメータの状態は、エンコーダに組み込まれているこのラウドネス・コントローラがアクティブであるかどうかに基づく。

【0137】

（上記の好ましいフォーマットでは）ビットストリームの各フレームの余剰ビット・セグメントまたはビットストリーム情報（「BSI」）セグメントの「addbsi」フィールドに含まれるLPSMを有するAC-3またはE-AC-3ビットストリームをデコードするとき、デコーダは、（余剰ビット・セグメントまたはaddbsiフィールド中の）LPSMブロック・データをパースして、抽出されたLPSM値のすべてをグラフィカル・ユーザー・インターフェース（GUI）に渡すべきである。抽出されたLPSM値の組は、フレーム毎にリフレッシュされる。

【0138】

本発明に基づいて生成されるエンコードされたビットストリームのもう一つの好ましいフォーマットでは、エンコードされたビットストリームはAC-3ビットストリームまたはE-AC-3ビットストリームであり、メタデータ・セグメントのうちLPSMを含むそれぞれは、（たとえばエンコーダ１００の好ましい実装の段１０７によって）余剰ビット・セグメントに、またはAuxセグメントに、またはビットストリームのフレームのビットストリーム情報（「BSI」）セグメントの「addbsi」フィールド（図６に示した）における追加的なビットストリーム情報として、含められる。（表１および表２を参照して上述したフォーマットに対する変形である）このフォーマットでは、addbsi（またはAuxまたは余剰ビット）フィールドのうちLPSMを含むそれぞれは、以下のLPSM値を含む。

【0139】

表１に規定されるコア要素。それに続いてペイロードID（当該メタデータをLPSMとして同定する）およびペイロード・サイズ値、それに続いてペイロード（LPSMデータ）。LPSMデータは次のフォーマット（上記の表２に示した必須要素と同様）をもつ。

【0140】

LPSMペイロードのバージョン：LPSMペイロードのバージョンを示す2ビット・フィールド。

【0141】

dialchan：対応するオーディオ・データの左、右および／または中央チャネルが話されたダイアログを含んでいるかどうかを示す3ビット・フィールド。dialchanフィールドのビット割り当ては次のとおりであってもよい：左チャネルにおけるダイアログの存在を示すビット0はdialchanフィールドの最上位ビットに格納され、中央チャネルにおけるダイアログの存在を示すビット2はdialchanフィールドの最下位ビットに格納される。対応するチャネルがプログラムの先行する0.5秒の間に話されるダイアログを含んでいる場合には、dialchanフィールドの各ビットが「1」に設定される。

【0142】

loudregtyp：プログラム・ラウドネスがどの規制規格に準拠しているかを示す4ビット・フィールド。「loudregtyp」フィールドを「000」に設定することは、LPSMがラウドネス規制準拠を示さないことを示す。たとえば、このフィールドのある値（たとえば0000）は、ラウドネス規制規格への準拠が示されないことを示してもよく、このフィールドの別の値（たとえば0001）は当該プログラムのオーディオ・データがATSC A/85規格に準拠していることを示してもよく、この値の別の値（たとえば0010）は当該プログラムのオーディオ・データがEBU R128規格に準拠していることを示してもよい。この例において、このフィールドが「0000」以外の何らかの値に設定される場合、loudcorrdialgatおよびloudcorrtypフィールドがペイロードのあとに続くべきである。

【0143】

loudcorrdialgat：ダイアログでゲーティングされたラウドネス補正が適用されたかどうかを示す1ビット・フィールド。プログラムのラウドネスがダイアログ・ゲーティングを使って補正されている場合には、loudcorrdialgatフィールドの値は「1」に設定される。そうでない場合にはその値は「0」に設定される。

【0144】

loudcorrtyp：プログラムに適用されたラウドネス補正の型を示す1ビット・フィールド。プログラムのラウドネスが無限先読み（ファイル・ベース）のラウドネス補正プロセスで補正されている場合には、loudcorrtypフィールドは「0」に設定される。プログラムのラウドネスがリアルタイム・ラウドネス測定およびダイナミックレンジ制御の組み合わせを使って補正されている場合には、このフィールドの値は「1」に設定される。

【0145】

loudrelgate：相対的なゲーティングされたラウドネス・データ（ITU）が存在するかどうかを示す1ビット・フィールド。loudrelgateフィールドが「1」に設定される場合、ペイロードにおいて、7ビットのituloudrelgatフィールドが後続するべきである。

【0146】

loudrelgat：相対的なゲーティングされたプログラム・ラウドネス（ITU）を示す7ビット・フィールド。このフィールドは、dialnormおよびダイナミックレンジ圧縮に起因するいかなる利得調整も適用されることなく、ITU-R BS.1770-3に従って測定された、オーディオ・プログラムの統合されたラウドネスを示す。0ないし127の値は、0.5LKFSきざみで、−58LKFSから＋5.5LKFSとして解釈される。

【0147】

loudspchgate：発話でゲーティングされたラウドネス・データ（ITU）が存在するかどうかを示す1ビット・フィールド。loudspchgateフィールドが「1」に設定される場合、ペイロードにおいて、7ビットのloudspchgatフィールドが後続するべきである。

【0148】

loudspchgat：発話ゲーティングされたプログラム・ラウドネスを示す7ビット・フィールド。このフィールドは、dialnormおよびダイナミックレンジ圧縮に起因するいかなる利得調整も適用されることなく、ITU-R BS.1770-3の公式(2)に従って測定された、対応するオーディオ・プログラム全体の統合されたラウドネスを示す。0ないし127の値は、0.5LKFSきざみで、−58LKFSから＋5.5LKFSとして解釈される。

【0149】

loudstrm3se：短時間（3秒）ラウドネス・データが存在するかどうかを示す1ビット・フィールド。このフィールドが「1」に設定される場合、ペイロードにおいて7ビットのloudstrm3sフィールドが後続するべきである。

【0150】

loudstrm3s：dialnormおよびダイナミックレンジ圧縮に起因するいかなる利得調整も適用されることなく、ITU-R BS.1770-3に従って測定された、対応するオーディオ・プログラムの先行する3秒のゲーティングされていないラウドネスを示す7ビット・フィールド。0ないし256の値は、0.5LKFSきざみで、−116LKFSから＋5.5LKFSとして解釈される。

【0151】

truepke：真のピーク・ラウドネス・データが存在するかどうかを示す、1ビット・フィールド。truepkeフィールドが「1」に設定されていたら、ペイロードにおいて8ビットのtruepkフィールドが後続するべきである。

【0152】

truepk：dialnormおよびダイナミックレンジ圧縮に起因するいかなる利得調整も適用されることなく、ITU-R BS.1770-3の付属書2に従って測定された、プログラムの真のピーク・サンプル値を示す8ビット・フィールド。0ないし256の値は、0.5LKFSきざみで、−116LKFSから＋5.5LKFSとして解釈される。

【0153】

いくつかの実施形態では、AC-3ビットストリームまたはE-AC-3ビットストリームのフレームの余剰ビット・セグメントまたは補助データ（または「addbsi」）フィールドにおけるメタデータ・セグメントのコア要素は、コア・ヘッダ（典型的には識別情報値、たとえばコア要素バージョン）と、該コア・ヘッダ後に：メタデータ・セグメントのメタデータについてフィンガープリント・データが（または他の保護値が）含まれるかどうかを示す値と、（当該メタデータ・セグメントのメタデータに対応するオーディオ・データに関係する）外部データが存在するかどうかを示す値と、コア要素によって同定される各型のメタデータ（たとえばLPSMおよび／またはLPSM以外の型のメタデータ）についてのペイロードIDおよびペイロード・サイズの値と、コア要素によって同定されるメタデータの少なくとも一つの型についての保護値とを含む。メタデータ・セグメントのメタデータ・ペイロード（単数または複数）は、コア・ヘッダに続き、（場合によっては）コア要素の値内にネストされる。

【0154】

本発明の典型的な実施形態は、ビットストリームによって示される連続するオーディオ・プログラムの間の少なくとも一つの境界の正確かつ堅牢な判定を許容する効率的な仕方で、エンコードされたオーディオ・ビットストリーム内にプログラム境界メタデータを含める。典型的な実施形態は、異なるプログラムを示すビットストリームが、継ぎ合わされるビットストリームの一方または両方を打ち切る（よって継ぎ合わせ前のビットストリームの少なくとも一方に含まれていたプログラム境界メタデータを破棄する）仕方で一緒に（本発明のビットストリームを生成するよう）継ぎ合わされている場合でも、正確なプログラム境界決定を許容するという意味で、プログラム境界の正確かつ堅牢な決定を許容する。

【0155】

典型的な実施形態では、本発明のビットストリームのフレームにおけるプログラム境界メタデータは、フレーム・カウントを示すプログラム境界フラグである。典型的には、このフラグは、現在フレーム（当該フラグを含んでいるフレーム）とプログラム境界（現在のオーディオ・プログラムの先頭または末尾）との間のフレーム数を示す。いくつかの好ましい実施形態では、プログラム境界フラグは対称的で効率的な仕方で、単一のプログラムを示す各ビットストリーム・セグメントの始まりおよび終わりに（すなわち、当該セグメントの始まりのあと何らかの所定数のフレーム内に生起するフレームにおいておよび当該セグメントの終わりの前の何らかの所定数のフレーム内に生起するフレームにおいて）挿入される。それにより、二つのそのようなビットストリームが連結される（それにより二つのプログラムのシーケンスを示すようになる）とき、プログラム境界メタデータは、二つのプログラムの間の境界の両方の側に（たとえば対称的に）存在することができる。

【0156】

プログラム境界フラグを、プログラムを示すビットストリームの全フレームに挿入することによって最大の堅牢性が達成できるが、これは典型的には、付随するデータ・レートの増大のため、実際的ではない。典型的な実施形態では、プログラム境界フラグは、エンコードされたオーディオ・ビットストリーム（これは一つのオーディオ・プログラムまたはオーディオ・プログラムのシーケンスを示しうる）のフレームの部分集合にのみ挿入され、境界フラグ挿入レートは、ビットストリームの（フラグが挿入される）各フレームの、該各フレームに最も近いプログラム境界からの離間の増大に対する非増加関数である。ここで、「境界フラグ挿入レート」とは、プログラム境界フラグを含む（プログラムを示す）フレームの数の、プログラム境界フラグを含まない（該プログラムを示す）フレームの数に対する、平均的な比を表わす。ここで、平均は、エンコードされたオーディオ・ビットストリームのある数（たとえば比較的少数）の連続するフレームにわたる移動平均である。

【0157】

（プログラム境界により近いビットストリーム中の位置において）境界フラグ挿入レートを増大させると、ビットストリームの送達のために必要とされるデータ・レートが増す。これを補償するために、挿入される各フラグのサイズ（ビット数）が、境界フラグ挿入レートが増すにつれて減少させられることが好ましい（それにより、Nは整数であるとして、ビットストリームのN番目のフレームにおけるプログラム境界フラグのサイズは、該N番目のフレームと最も近いプログラム境界との間の距離（フレーム数）の非増加関数である）。あるクラスの諸実施形態では、境界フラグ挿入レートは、最も近いプログラム境界からの（各フラグ挿入位置の）増大する距離の対数的に減少する関数であり、フラグの一つを含む各フラグ含有フレームについて、該フラグ含有フレーム中のフラグのサイズは、該フラグ含有フレームよりも前記最も近いプログラム境界により近くに位置するフレームにおける各フラグのサイズ以上である。典型的には、各フラグのサイズは、フラグの挿入位置から最も近いプログラム境界までのフレーム数の増加関数によって決定される。

【0158】

たとえば、図８および図９の実施形態を考える。ここで、フレーム番号（いちばん上の行）によって同定される各列がエンコードされたオーディオ・ビットストリームのフレームを示す。ビットストリームは、図９の左側のフレーム番号「17」によって同定される列のすぐ左に現われる第一のプログラム境界（当該プログラムの始まりを示す）および図８の右側のフレーム番号「1」によって同定される列のすぐ右に現われる第二のプログラム境界（当該プログラムの終わりを示す）をもつオーディオ・プログラムを示す。図８に示される諸フレームに含まれるプログラム境界フラグは、現在フレームと第二のプログラム境界との間のフレーム数をカウントダウンする。図９に示される諸フレームに含まれるプログラム境界フラグは、現在フレームと第一のプログラム境界との間のフレーム数をカウントアップする。

【0159】

図８および図９の実施形態では、プログラム境界フラグは、ビットストリームによって示されるオーディオ・プログラムの開始後、エンコードされたビットストリームの最初のX個のフレームの2^N番目のフレームのそれぞれにおいて、および、ビットストリームによって示されるプログラムの終わりに最も近い（ビットストリームの最後のX個のフレームの）2^N番目のフレームのそれぞれにおいてのみ示されている。ここで、プログラムはY個のフレームを含み、XはY/2以下の整数であり、Nは1からlog₂Xまでの範囲の正の整数である。このように、（図８および図９に示されるように）プログラム境界フラグがビットストリームの第二のフレーム（N＝1）（プログラムの先頭に最も近いフラグ含有フレーム）、第四のフレーム（N＝2）、第八のフレーム（N＝3）などに挿入され、また、ビットストリームの終わりから八番目のフレーム、ビットストリームの終わりから四番目のフレームおよびビットストリームの終わりから二番目のフレーム（プログラムの末尾に最も近いフラグ含有フレーム）に挿入される。この例では、プログラムの先頭（または末尾）から2^N番目のフレームにおけるプログラム境界フラグは、図８および図９に示されるように、log₂(2^N+2)二進ビットを有する。こうして、プログラムの先頭（または末尾）から二番目のフレーム（N＝1）におけるプログラム境界フラグはlog₂(2^N+2)＝log₂(2³)＝3二進ビットを有し、プログラムの先頭（または末尾）から四番目のフレーム（N＝2）におけるフラグはlog₂(2^N+2)＝log₂(2⁴)＝4二進ビットを有する、などとなる。

【0160】

図８および図９の例では、各プログラム境界フラグのフォーマットは次のとおり。各プログラム境界フラグは、先頭の「1」のビット、該先頭の「1」のビット後の「0」のビットのシーケンス（「0」のビットなしまたは一つまたは複数の連続する「0」のビット）および2ビットの後端符号（trailing code）からなる。ビットストリームの最後のX個のフレーム（プログラム末尾に最も近い諸フレーム）におけるフラグについては、後端符号は、図８に示されるように、「11」である。ビットストリームの最初のX個のフレーム（プログラム先頭に最も近い諸フレーム）におけるフラグについては、後端符号は、図９に示されるように、「10」である。このように、各フラグを読む（デコードする）ために、先頭の「1」のビットと後端符号との間の0の数が数えられる。後端符号が「11」であると識別される場合には、フラグは現在フレーム（そのフラグを含んでいるフレーム）とプログラムの終わりとの間に(2^Z+1−1)個のフレームがあることを示す。ここで、Zは、このフラグの先頭の「1」のビットと後端符号との間の0の数である。このデコーダは、それぞれのそのようなフラグの最初と最後のビットを無視し、フラグの他の（中間の）諸ビットのシーケンスの逆を決定し（たとえば、中間ビットのシーケンスが「0001」であり、「1」のビットがシーケンスの最後のビットであれば、中間ビットの反転されたシーケンスは「1000」となり、「1」のビットが反転されたシーケンスの最初のビットになる）、中間ビットの反転されたシーケンスの二進値を、プログラムの終わりに対する現在フレーム（そのフラグが含まれているフレーム）のインデックスとして同定するよう効率的に実装されることができる。たとえば、中間ビットの反転されたシーケンスが「1000」であれば、この反転されたシーケンスは二進値2⁴＝16をもち、このフレームは、プログラムの終わりの前の16番目のフレームとして識別される（図８の、フレーム「0」を記述する列において示されるように）。

【0161】

後端符号が「10」であると識別される場合には、フラグはプログラムの始まりと現在フレーム（そのフラグを含んでいるフレーム）との間に(2^Z+1−1)個のフレームがあることを示す。ここで、Zは、このフラグの先頭の「1」のビットと後端符号との間の0の数である。このデコーダは、それぞれのそのようなフラグの最初と最後のビットを無視し、フラグの中間ビットのシーケンスの逆を決定し（たとえば、中間ビットのシーケンスが「0001」であり、「1」のビットがシーケンスの最後のビットであれば、中間ビットの反転されたシーケンスは「1000」となり、「1」のビットが反転されたシーケンスの最初のビットになる）、中間ビットの反転されたシーケンスの二進値を、プログラムの始まりに対する現在フレーム（そのフラグが含まれているフレーム）のインデックスとして同定するよう効率的に実装されることができる。たとえば、中間ビットの反転されたシーケンスが「1000」であれば、この反転されたシーケンスは二進値2⁴＝16をもち、このフレームは、プログラムの始まりの後の16番目のフレームとして識別される（図９の、フレーム「32」を記述する列において示されるように）。

【0162】

図８および図９の例では、プログラム境界フラグは、ビットストリームによって示されるオーディオ・プログラムの開始後のエンコードされたビットストリームの最初のX個のフレームの2^N番目のフレームのそれぞれに、および、ビットストリームによって示されるオーディオ・プログラムの終了に最も近い（ビットストリームの最後のX個のフレームの）2^N番目のフレームのそれぞれに、存在するだけであり、プログラムはY個のフレームを有し、XはY/2以下の整数であり、Nは1からlog₂Xまでの範囲の正の整数である。プログラム境界フラグを含めることは、フラグなしでビットストリームを送信するのに必要されるビットレートに、1.875ビット／フレームの平均ビットレートを追加するだけである。

【0163】

ビットストリームがAC-3エンコードされたオーディオ・ビットストリームである図８および図９の実施形態の典型的な実装では、各フレームはデジタル・オーディオの1536サンプルについてのオーディオ・コンテンツおよびメタデータを含む。48kHzのサンプリング・レートについては、これは32ミリ秒のデジタル・オーディオまたはオーディオの31.25フレーム毎秒のレートを表わす。このように、そのような実施形態では、ある数のフレーム（「X」個のフレーム）だけプログラム境界から離間されるフレームにおけるプログラム境界フラグは、境界が、フラグ含有フレームの終了後32Xミリ秒（またはフラグ含有フレームの開始前32Xミリ秒）に現われることを示す。

【0164】

ビットストリームがE-AC-3エンコードされたオーディオ・ビットストリームである図８および図９の実施形態の典型的な実装では、ビットストリームの各フレームは、フレームが一ブロック、二ブロック、三ブロックまたは六ブロックのオーディオ・データのどれを含んでいるかに依存して、それぞれデジタル・オーディオの256、512、768または1536サンプルについてのオーディオ・コンテンツおよびメタデータを含む。48kHzのサンプリング・レートについては、これはそれぞれ5.333、10.667、16または32ミリ秒のデジタル・オーディオまたはそれぞれオーディオの189.9、93.75、62.5または31.25フレーム毎秒のレートを表わす。このように、そのような実施形態では、（各フレームが32ミリ秒のデジタル・オーディオを示すとすると）ある数のフレーム（「X」個のフレーム）だけプログラム境界から離間されるフレームにおけるプログラム境界フラグは、境界が、フラグ含有フレームの終了後32Xミリ秒（またはフラグ含有フレームの開始前32Xミリ秒）に現われることを示す。

【0165】

プログラム境界がオーディオ・ビットストリームのフレーム内に（すなわち、フレームの始まりまたは終わりに整列せずに）生起できるいくつかの実施形態では、ビットストリームのフレームに含まれるプログラム境界メタデータはプログラム境界フレーム・カウント（すなわち、フレーム・カウント含有フレームの先頭または末尾とプログラム境界との間の完全なフレームの数を示すメタデータ）と、オフセット値とを含む。オフセット値は、プログラム境界含有フレームの先頭または末尾と、プログラム境界含有フレーム内のプログラム境界の実際の位置との間のオフセット（典型的にはサンプル数）を示す。

【0166】

エンコードされたオーディオ・ビットストリームは、ビデオ・プログラムの対応するシーケンスのプログラム（サウンドトラック）のシーケンスを示していてもよく、そのようなオーディオ・プログラムの境界は、オーディオ・フレームのエッジではなくビデオ・フレームのエッジにおいて生起する傾向がある。また、いくつかのオーディオ・コーデック（たとえばE-AC-3の諸コーデック）は、ビデオ・フレームと整列していないオーディオ・フレーム・サイズを使う。また、場合によっては、最初にエンコードされたオーディオ・ビットストリームがトランスコードを受けて、トランスコードされたビットストリームを生成し、最初にエンコードされたビットストリームはトランスコードされたビットストリームとは異なるフレーム・サイズをもつ。このため、プログラム境界（最初にエンコードされたビットストリームによって決定される）は、トランスコードされたビットストリームのフレーム境界に現われることは保証されない。たとえば、最初にエンコードされたビットストリーム（たとえば図１０のビットストリーム「IEB」）が1536サンプル毎フレームのフレーム・サイズをもち、トランスコードされたビットストリーム（たとえば図１０のビットストリーム「TB」）が1024サンプル毎フレームのフレーム・サイズをもつ場合、トランスコード・プロセスにより、異なるコーデックの異なるフレーム・サイズのため、実際のプログラム境界は、トランスコードされたビットストリームのフレーム境界にではなく、そのフレームのどこかに（たとえば図１０に示されるように、トランスコードされたビットストリームのフレームに512サンプルはいったところに）現われることになりうる。エンコードされたオーディオ・ビットストリームのフレームに含まれるプログラム境界メタデータがプログラム境界フレーム・カウントのほかにオフセット値を含む本発明の実施形態は、この段落に記された三つの場合（および他の場合）において有用である。

【0167】

図８および図９を参照して上述した実施形態は、エンコードされたビットストリームのフレームのいずれにもオフセット値（たとえばオフセット・フィールド）を含まない。この実施形態に対する諸変形では、オフセット値は、プログラム境界フラグを含むエンコードされたオーディオ・ビットストリームの各フレームに（たとえば、図８における0、8、12および14の番号を付されたフレームおよび図９における18、20、24および32の番号を付されたフレームに対応するフレームに）含まれる。

【0168】

あるクラスの諸実施形態では、（本発明のプログラム境界メタデータを含むエンコードされたビットストリームの各フレームにおける）データ構造が、当該フレームがプログラム境界フレーム・カウントのみを含んでいるか、プログラム境界フレーム・カウントおよびオフセット値の両方を含んでいるかを示す符号値を含む。たとえば、符号値は、単一ビット・フィールド（本稿では「offset_exist〔オフセット存在〕」フィールドと称される）の値であってもよい。offset_exist＝0の値は、そのフレームにオフセット値が含まれないことを示してもよく、offset_exist＝1の値は、そのフレームにプログラム境界フレーム・カウントおよびオフセット値が含まれることを示してもよい。

【0169】

いくつかの実施形態では、AC-3またはE-AC-3エンコードされたオーディオ・ビットストリームの少なくとも一つのフレームは、ビットストリームによって決定されるオーディオ・プログラムについてのLPSMおよびプログラム境界メタデータ（および任意的には他のメタデータも）を含むメタデータ・セグメントを含む。そのような各メタデータ・セグメント（これはビットストリームのaddbsiフィールドまたは補助データ・フィールドまたは余剰ビット・セグメントに含まれていてもよい）は、コア・ヘッダ（および任意的には追加的なコア要素も）と、コア・ヘッダのあとの（またはコア・ヘッダおよび他のコア要素のあとの）以下のフォーマットをもつLPSMペイロード（またはコンテナ）セグメントとを含む。

【0170】

ヘッダ（典型的には少なくとも一つの識別情報値、たとえばLPSMフォーマット・バージョン、長さ、期間（period）、カウントおよびサブストリーム関連付け値を含む）、
ヘッダ後に、プログラム境界メタデータ（これは、プログラム境界フレーム・カウントと、そのフレームがプログラム境界フレーム・カウントのみを含むか、プログラム境界フレーム・カウントおよびオフセット値の両方を含むかを示す符号値（たとえば「offset_exist」〔オフセット存在〕値）と、場合によっては、オフセット値とを含んでいてもよい）およびLPSM。該LPSMは下記を含んでいてもよい：
対応するオーディオ・データがダイアログを示すかダイアログを示さないか（たとえば、対応するオーディオ・データのどのチャネルがダイアログを示すか）を示す少なくとも一つのダイアログ指示値。ダイアログ指示値（単数または複数）は、対応するオーディオ・データのチャネルの任意の組み合わせまたは全部にダイアログが存在しているかどうかを示してもよい；
対応するオーディオ・データがラウドネス規制の示されるセットに準拠しているかどうかを示す少なくとも一つのラウドネス規制準拠値；
対応するオーディオ・データに対して実行されたラウドネス処理の少なくとも一つの型を示す少なくとも一つのラウドネス処理値；および
対応するオーディオ・データに特徴的な少なくとも一つのラウドネス（たとえばピークまたは平均ラウドネス）を示す少なくとも一つのラウドネス値。

【0171】

いくつかの実施形態では、LPSMペイロード・セグメントは、そのフレームがプログラム境界フレーム・カウントのみを含むか、プログラム境界フレーム・カウントおよびオフセット値の両方を含むかを示す符号値（たとえば「offset_exist」〔オフセット存在〕値）を含む。たとえば、一つのそのような実施形態では、そのような符号値（たとえばoffset_exist＝1）が、そのフレームがプログラム境界フレーム・カウントおよびオフセット値を含むことを示すとき、LPSMペイロード・セグメントは、11ビット符号なし整数（すなわち、0から2048までの値をもつ）であり、合図されるフレーム境界（プログラム境界を含むフレームの境界）と実際のプログラム境界との間の追加的なオーディオ・サンプルの数を示すオフセット値を含んでいてもよい。プログラム境界フレーム・カウントが、プログラム境界含有フレームまでの（現在のフレーム・レートにおける）フレームの数を示す場合には、（LPSMペイロード・セグメントを含むフレームの始まりまたは終わりに対する）プログラム境界の（サンプル数単位での）精密な位置が：
S＝（frame_counter*frame size）＋offset
として計算される。ここで、Sは（LPSMペイロード・セグメントを含んでいるフレームの始まりまたは終わりから）プログラム境界までのサンプル数であり、
「frame_counter」は、プログラム境界フレーム・カウントによって示されるフレーム・カウントであり、「frame size」はフレーム当たりのサンプル数であり、「offset」は前記オフセット値によって示されるサンプル数である。

【0172】

プログラム境界フラグの挿入レートが実際のプログラム境界の近くで増大するいくつかの実施形態は、フレームが、プログラム境界を含むフレームからある数（「Y」）のフレーム以下である場合には、そのフレームにはオフセット値は決して含まれないという規則を実装する。典型的には、Y＝32である。この規則を（Y＝32として）実装するE-AC-3エンコーダについては、エンコーダは、オーディオ・プログラムの最後の1秒には決してオフセット値を挿入しない。この場合、受領装置が、タイマーを維持し、それにより（プログラム境界含有フレームからYフレームより多く離れている当該エンコードされたビットストリームのフレームにおける、オフセット値を含むプログラム境界メタデータに応答して）自分自身のオフセット計算を実行することを受け持つ。

【0173】

オーディオ・プログラムが対応するビデオ・プログラムのビデオ・フレームに「フレーム整列されている」ことがわかっているプログラム（たとえば、ドルビーEエンコードされたオーディオをもつ典型的な寄与フィード）については、オーディオ・プログラムを示すエンコードされたビットストリーム中のオフセット値を含めることは余計である。そこで、オフセット値は典型的にはそのようなエンコードされたビットストリームには含められない。

【0174】

図１１を参照するに、次に、エンコードされたオーディオ・ビットストリームが本発明のオーディオ・ビットストリームの実施形態を生成するよう一緒に継ぎ合わされる場合を考える。

【0175】

図１１のいちばん上のビットストリーム（「シナリオ１」とラベル付けされている）は、プログラム境界メタデータ（プログラム境界フラグF）を含む第一のオーディオ・プログラム（P1）全体と、それに続く、やはりプログラム境界メタデータ（プログラム境界フラグF）を含む第二のオーディオ・プログラム（P2）全体とを示している。第一のプログラムの終わりの部分におけるプログラム境界フラグ（そのいくつかが図１１に示されている）は、図８を参照して述べたものと同一または同様であり、二つのプログラムの間の境界（すなわち、第二のプログラムの始まりにおける境界）の位置を決定する。第二のプログラムの始まりの部分におけるプログラム境界フラグ（そのいくつかが図１１に示されている）は、図９を参照して述べたものと同一または同様であり、やはり境界の位置を決定する。典型的な実施形態では、エンコーダまたはデコーダが、プログラム境界までカウントダウンするタイマー（第一のプログラム内のフラグによって較正される）を実装し、同じタイマー（第二のプログラム内のフラグによって較正される）が同じプログラム境界からカウントアップする。図１１のシナリオ１における境界タイマー・グラフによって示されるように、そのようなタイマーのカウントダウン（第一のプログラム内のフラグによって較正される）は境界において0に達し、タイマーのカウントアップ（第二のプログラム内のフラグによって較正される）は境界の同じ位置を参照する。

【0176】

図１１の上から二番目のビットストリーム（「シナリオ２」とラベル付けされている）は、プログラム境界メタデータ（プログラム境界フラグF）を含む第一のオーディオ・プログラム（P1）全体と、それに続く、プログラム境界メタデータを含まない第二のオーディオ・プログラム（P2）全体とを示している。第一のプログラムの終わりの部分におけるプログラム境界フラグ（そのいくつかが図１１に示されている）は、図８を参照して述べたものと同一または同様であり、シナリオ１と同様に、二つのプログラムの間の境界（すなわち、第二のプログラムの始まりにおける境界）の位置を決定する。典型的な実施形態では、エンコーダまたはデコーダが、プログラム境界までカウントダウンするタイマー（第一のプログラム内のフラグによって較正される）を実装し、同じタイマーが（さらに較正されることなく）該プログラム境界からカウントアップすることを続ける（図１１のシナリオ２における境界タイマー・グラフによって示されるように）。

【0177】

図１１の上から三番目のビットストリーム（「シナリオ３」とラベル付けされている）は、プログラム境界メタデータ（プログラム境界フラグF）を含む打ち切りされた第一のオーディオ・プログラム（P1）であって、やはりプログラム境界メタデータ（プログラム境界フラグF）を含む第二のオーディオ・プログラム（P2）全体と継ぎ合わされているものを示している。継ぎ合わせは、第一のプログラムの最後の「N」個のフレームを除去している。第二のプログラムの始まりの部分におけるプログラム境界フラグ（そのいくつかが図１１に示されている）は、図９を参照して述べたものと同一または同様であり、打ち切りされた第一のプログラムと完全な第二のプログラムとの間の境界（継ぎ〔スプライス〕）の位置を決定する。典型的な実施形態では、エンコーダまたはデコーダが、打ち切りされていない第一のプログラムの終わりまでカウントダウンするタイマー（第一のプログラム内のフラグによって較正される）を実装し、同じタイマー（第二のプログラム内のフラグによって較正される）が第二のプログラムの先頭からカウントアップする。第二のプログラムの先頭が、シナリオ３におけるプログラム境界である。図１１のシナリオ３における境界タイマー・グラフによって示されるように、そのようなタイマーのカウントダウン（第一のプログラム内のプログラム境界メタデータによって較正される）は、（第一のプログラム内のプログラム境界メタデータに応答して）0に達する前に（第二のプログラム内のプログラム境界メタデータに応答して）リセットされる。このように、（継ぎ合わせによる）第一のプログラムの打ち切りはタイマーが、第一のプログラム内のプログラム境界メタデータだけに応答して（すなわち、それによる較正のもとで）、打ち切りされた第一のプログラムと第二のプログラムの先頭との間のプログラム境界を同定することを妨げるが、第二のプログラムにおけるプログラム・メタデータがタイマーをリセットし、それによりリセットされたタイマーが、打ち切りされた第一のプログラムと第二のプログラムの先頭との間のプログラム境界の位置を（リセットされたタイマーの「0」カウントに対応する位置として）正しく示す。

【0178】

第四のビットストリーム（「シナリオ４」とラベル付けされている）は、プログラム境界メタデータ（プログラム境界フラグF）を含む打ち切りされた第一のオーディオ・プログラム（P1）と、プログラム境界メタデータ（プログラム境界フラグF）を含む打ち切りされた第二のオーディオ・プログラム（P2）であって、第一のオーディオ・プログラムの一部（打ち切りされていない部分）と継ぎ合わされているものとを示している。（打ち切り前の）第二のプログラム全体の始まりの部分におけるプログラム境界フラグ（そのいくつかが図１１に示されている）は、図９を参照して述べたものと同一または同様であり、（打ち切り前の）第一のプログラム全体の終わりの部分におけるプログラム境界フラグ（そのいくつかが図１１に示されている）は、図８を参照して述べたものと同一または同様である。継ぎ合わせにより、第一のプログラムの最後の「N」個のフレームが（よって継ぎの前に含まれていたプログラム境界フラグの一部が）ならびに第二のプログラムの最初の「M」個のフレームが（よって継ぎの前に含まれていたプログラム境界フラグの一部が）除去されている。典型的な実施形態では、エンコーダまたはデコーダが、打ち切りされていない第一のプログラムの終わりに向けてカウントダウンするタイマー（打ち切りされた第一のプログラム内のフラグによって較正される）を実装し、同じタイマー（打ち切りされた第二のプログラム内のフラグによって較正される）が打ち切りされていない第二のプログラムの先頭からカウントアップする。図１１のシナリオ４における境界タイマー・グラフによって示されるように、そのようなタイマーのカウントダウン（第一のプログラム内のプログラム境界メタデータによって較正される）は、（第一のプログラム内のプログラム境界メタデータに応答して）0に達する前に（第二のプログラム内のプログラム境界メタデータに応答して）リセットされる。（継ぎ合わせによる）第一のプログラムの打ち切りは、タイマーが、第一のプログラム内のプログラム境界メタデータだけに応答して（すなわち、それによる較正のもとで）、打ち切りされた第一のプログラムと打ち切りされた第二のプログラムの先頭との間のプログラム境界を同定することを妨げる。しかしながら、リセットされたタイマーは、打ち切りされた第一のプログラムの終わりと打ち切りされた第二のプログラムの始まりとの間のプログラム境界の位置を正しく示さない。このように、継ぎ合わされるビットストリーム両方の打ち切りは、両者の間の境界の正確な決定を妨げることがある。

【0179】

本発明の実施形態は、ハードウェア、ファームウェアまたはソフトウェアまたは両者の組み合わせにおいて（たとえばプログラム可能な論理アレイとして）実装されてもよい。特に断わりのない限り、本発明の一部として含まれるアルゴリズムまたはプロセスは、いかなる特定のコンピュータまたは他の装置にも本来的に関係していない。特に、さまざまな汎用機械が、本願の教示に従って書かれたプログラムとともに使用されてもよく、あるいは必要とされる方法ステップを実行するためにより特化した装置（たとえば集積回路）を構築することがより便利であることがある。このように、本発明は、一つまたは複数のプログラム可能なコンピュータ・システム（たとえば、図１の諸要素または図２のエンコーダ１００（またはその要素）または図３のデコーダ２００（またはその要素）または図３の後処理器（またはその要素）のうちの任意のものの実装）上で実行される一つまたは複数のコンピュータ・プログラムにおいて実装されてもよい。各コンピュータ・システムは、少なくとも一つのプロセッサ、少なくとも一つのデータ記憶システム（揮発性および不揮発性メモリおよび／または記憶要素を含む）、少なくとも一つの入力装置またはポートおよび少なくとも一つの出力装置またはポートを有する。本稿に記載される機能を実行し、出力情報を生成するようプログラム・コードが入力データに適用される。出力情報は、既知の仕方で一つまたは複数の出力装置に適用される。

【0180】

そのような各プログラムは、コンピュータ・システムと通信するためにいかなる所望されるコンピュータ言語（機械、アセンブリーまたは高水準手続き型、論理的またはオブジェクト指向のプログラミング言語を含む）において実装されてもよい。いずれの場合にも、言語はコンパイルされる言語でもインタープリットされる言語でもよい。

【0181】

たとえば、コンピュータ・ソフトウェア命令のシーケンスによって実装されるとき、本発明の実施形態のさまざまな機能および段階は、好適なデジタル信号処理ハードウェアにおいて実行されるマルチスレッド式のソフトウェア命令シーケンスによって実装されてもよく、その場合、実施形態のさまざまな装置、段階および機能は、ソフトウェア命令の諸部分に対応してもよい。

【0182】

そのような各コンピュータ・プログラムは好ましくは、汎用または専用のプログラム可能なコンピュータによって読み取り可能な記憶媒体またはデバイス（たとえば半導体メモリまたはメディアまたは磁気式もしくは光学式メディア）に記憶されるまたはダウンロードされ、記憶媒体またはデバイスがコンピュータ・システムによって読まれたときに、本稿に記載される手順を実行するようコンピュータを構成するまたは動作させる。本発明のシステムは、コンピュータ・プログラムをもって構成された（すなわちコンピュータ・プログラムを記憶している）コンピュータ可読記憶媒体として実装されてもよく、そのように構成された記憶媒体はコンピュータ・システムに、本稿に記載される機能を実行するよう特定のあらかじめ定義された仕方で動作させる。

【0183】

本発明のいくつかの実施形態を記述してきたが、本発明の精神および範囲から外れることなくさまざまな修正がなしうることは理解されるであろう。上記の教示に照らして、本発明の数多くの修正および変形が可能である。付属の請求項の範囲内で、本発明が、本稿で具体的に記載される以外の仕方で実施されてもよいことは理解される。

【0184】

いくつかの態様を記載しておく。
〔態様１〕
オーディオ処理ユニットであって：
エンコードされたオーディオ・ビットストリームの少なくとも一つのフレームを記憶するバッファ・メモリであって、前記エンコードされたオーディオ・ビットストリームはオーディオ・データおよびメタデータ・コンテナを含み、前記メタデータ・コンテナはヘッダ、一つまたは複数のメタデータ・ペイロードおよび保護データを含む、バッファ・メモリと；
前記バッファ・メモリに結合された、前記オーディオ・データをデコードするオーディオ・デコーダと；
前記オーディオ・デコーダに結合されるか前記オーディオ・デコーダと統合されている、前記エンコードされたオーディオ・ビットストリームをパースする、パーサとを有しており、
前記ヘッダは、前記メタデータ・コンテナの先頭を同定する同期語を含み、前記一つまたは複数のメタデータ・ペイロードは、前記オーディオ・データに関連付けられたオーディオ・プログラムを記述し、前記保護データは、前記一つまたは複数のメタデータ・ペイロードのあとに位置し、前記保護データは、前記メタデータ・コンテナおよび該メタデータ・コンテナ内の前記一つまたは複数のペイロードの完全性を検証するために使用できる、
オーディオ処理ユニット。
〔態様２〕
前記メタデータ・コンテナが、スキップ・フィールド、補助データ・フィールド、addbsiフィールドおよびそれらの組み合わせからなる群から選択されるAC-3またはE-AC-3のリザーブされたデータ・スペースに格納される、態様１記載のオーディオ処理ユニット。
〔態様３〕
前記一つまたは複数のメタデータ・ペイロードが、連続するオーディオ・プログラムの間の少なくとも一つの境界を示すメタデータを含む、態様１または２記載のオーディオ処理ユニット。
〔態様４〕
前記一つまたは複数のメタデータ・ペイロードが、オーディオ・プログラムの測定されたラウドネスを示すデータを含むプログラム・ラウドネス・ペイロードを含む、態様１または２記載のオーディオ処理ユニット。
〔態様５〕
前記プログラム・ラウドネス・ペイロードが、オーディオ・チャネルが話されたダイアログを含むかどうかを示すフィールドを含む、態様４記載のオーディオ処理ユニット。
〔態様６〕
前記プログラム・ラウドネス・ペイロードが、前記プログラム・ラウドネス・ペイロードに含まれるラウドネス・データを生成するために使われたラウドネス測定方法を示すフィールドを含む、態様４記載のオーディオ処理ユニット。
〔態様７〕
前記プログラム・ラウドネス・ペイロードが、オーディオ・プログラムのラウドネスがダイアログ・ゲーティングを使って補正されているかどうかを示すフィールドを含む、態様４記載のオーディオ処理ユニット。
〔態様８〕
前記プログラム・ラウドネス・ペイロードが、オーディオ・プログラムのラウドネスが、無限先読みまたはファイル・ベースのラウドネス補正プロセスを使って補正されているかどうかを示すフィールドを含む、態様４記載のオーディオ処理ユニット。
〔態様９〕
前記プログラム・ラウドネス・ペイロードが、ダイナミックレンジ圧縮に帰着できるいかなる利得調整もなしにオーディオ・プログラムの統合されたラウドネスを示すフィールドを含む、態様４記載のオーディオ処理ユニット。
〔態様１０〕
前記プログラム・ラウドネス・ペイロードが、ダイアログ正規化（dialog normalization）に帰着できるいかなる利得調整もなしにオーディオ・プログラムの統合されたラウドネスを示すフィールドを含む、態様４記載のオーディオ処理ユニット。
〔態様１１〕
前記プログラム・ラウドネス・ペイロードを使って適応的なラウドネス処理を実行するよう構成されている、態様４記載のオーディオ処理ユニット。
〔態様１２〕
前記エンコードされたオーディオ・ビットストリームがAC-3ビットストリームまたはE-AC-3ビットストリームである、態様１ないし１１のうちいずれか一項記載のオーディオ処理ユニット。
〔態様１３〕
前記エンコードされたオーディオ・ビットストリームから前記プログラム・ラウドネス・ペイロードを抽出し、前記プログラム・ラウドネス・ペイロードを認証または有効確認するよう構成されている、態様４ないし１１のうちいずれか一項記載のオーディオ処理ユニット。
〔態様１４〕
前記一つまたは複数のメタデータ・ペイロードがそれぞれ、一意的なペイロード識別子を含み、前記一意的なペイロード識別子が各メタデータ・ペイロードの先頭に位置される、態様１ないし１３のうちいずれか一項記載のオーディオ処理ユニット。
〔態様１５〕
前記同期語が値0x5838をもつ16ビット同期語である、態様１ないし１３のうちいずれか一項記載のオーディオ処理ユニット。
〔態様１６〕
エンコードされたオーディオ・ビットストリームをデコードする方法であって：
一つまたは複数のフレームにセグメント分割されている、エンコードされたオーディオ・ビットストリームを受領する段階と；
前記エンコードされたオーディオ・ビットストリームからオーディオ・データおよびメタデータのコンテナを抽出する段階であって、前記メタデータのコンテナは、ヘッダと、それに続く一つまたは複数のメタデータ・ペイロードと、それに続く保護データとを含む、段階と；
前記コンテナおよび前記一つまたは複数のメタデータ・ペイロードの完全性を、前記保護データの使用を通じて検証する段階とを含み、
前記一つまたは複数のメタデータ・ペイロードは、前記オーディオ・データに関連するオーディオ・プログラムの測定されたラウドネスを示すデータを含むプログラム・ラウドネス・ペイロードを含む、
方法。
〔態様１７〕
前記エンコードされたオーディオ・ビットストリームがAC-3ビットストリームまたはE-AC-3ビットストリームである、態様１６記載の方法。
〔態様１８〕
前記エンコードされたオーディオ・ビットストリームから抽出されたオーディオ・データに対して、前記プログラム・ラウドネス・ペイロードを使って適応的なラウドネス処理を実行する段階をさらに含む、態様１６記載の方法。
〔態様１９〕
前記コンテナが、スキップ・フィールド、補助データ・フィールド、addbsiフィールドおよびそれらの組み合わせからなる群から選択されるAC-3またはE-AC-3のリザーブされたデータ・スペースに位置しておりそこから抽出される、態様１６記載の方法。
〔態様２０〕
前記プログラム・ラウドネス・ペイロードが、オーディオ・チャネルが話されたダイアログを含むかどうかを示すフィールドを含む、態様１６記載の方法。
〔態様２１〕
前記プログラム・ラウドネス・ペイロードが、前記プログラム・ラウドネス・ペイロードに含まれるラウドネス・データを生成するために使われたラウドネス測定方法を示すフィールドを含む、態様１６記載の方法。
〔態様２２〕
前記プログラム・ラウドネス・ペイロードが、オーディオ・プログラムのラウドネスがダイアログ・ゲーティングを使って補正されているかどうかを示すフィールドを含む、態様１６記載の方法。
〔態様２３〕
前記プログラム・ラウドネス・ペイロードが、オーディオ・プログラムのラウドネスが、無限先読みまたはファイル・ベースのラウドネス補正プロセスを使って補正されているかどうかを示すフィールドを含む、態様１６記載の方法。
〔態様２４〕
前記プログラム・ラウドネス・ペイロードが、ダイナミックレンジ圧縮に起因するいかなる利得調整もなしにオーディオ・プログラムの統合されたラウドネスを示すフィールドを含む、態様１６記載の方法。
〔態様２５〕
前記プログラム・ラウドネス・ペイロードが、ダイアログ正規化（dialog normalization）に帰着できるいかなる利得調整もなしにオーディオ・プログラムの統合されたラウドネスを示すフィールドを含む、態様１６記載の方法。
〔態様２６〕
前記メタデータのコンテナが、連続するオーディオ・プログラムの間の少なくとも一つの境界を示すメタデータを含む、態様１６記載の方法。
〔態様２７〕
前記メタデータのコンテナが、フレームの一つまたは複数のスキップ・フィールドまたは余剰ビット・セグメントに格納されている、態様１６記載の方法。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】