JP2014512020A - オーディオコンテントを表すビットストリームのフレームにおけるフレーム要素位置決め - Google Patents

Abstract

高すぎるビットストリームおよび復号化オーバヘッドと、フレーム要素位置決めとのより良い妥協が、ビットストリームのフレームのシーケンスの各々が、Ｎ個のフレーム要素のシーケンスを含み、かつビットストリームが要素数Ｎを表示するフィールドおよびタイプ表示構文部を含むコンフィギュレーションブロックを含み、タイプ表示構文部が、Ｎ個の要素位置のシーケンスの各要素位置について、複数の要素タイプのうちから要素タイプを表示し、フレームのＮ個のフレーム要素のシーケンスにおいて、各フレーム要素が、ビットストリームにおいてそれぞれのフレームのＮ個のフレーム要素のシーケンス内でそれぞれのフレーム要素が位置するそれぞれの要素位置について、タイプ表示部が表示する要素タイプである構成にすることで達成される。このように、各フレームが、同じ順序でビットストリーム内に位置する、タイプ表示構文部により表示されるフレーム要素タイプのＮ個のフレーム要素の同じシーケンスを含む点で、フレームは等しく構成される。この順序は、Ｎ個の要素位置のシーケンスの各要素位置について、複数の要素タイプのうちから要素タイプを表示するタイプ表示構文部を使用することによりフレームのシーケンスについて共通に調節可能である。

Description

本発明は、所謂ＵＳＡＣコーデック（Ｕｎｉｆｉｅｄ Ｓｐｅｅｃｈ ａｎｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ、音声音響統合符号化）等のオーディオ符号化に関連し、特に、それぞれのビットストリームのフレーム内でのフレーム要素の位置決めに関連する。

近年、いくつかのオーディオコーデックが利用可能となっており、各オーディオコーデックは、専用アプリケーションにフィットするよう詳細に設計されている。多くの場合、オーディオコーデックは、１を超える数のオーディオチャネルまたはオーディオ信号を並列に符号化することができる。オーディオコンテントのオーディオチャネルまたはオーディオオブジェクトを異なってグループ化してこれらのグループを異なるオーディオ符号化原則の対象にすることで、オーディオコンテントを異なって符号化するのにさえ適したオーディオコーデックが存在する。またさらに、オーディオコーデックには、オーディオコーデックの将来の拡張／展開に対応するようビットストリームへの拡張の挿入を図るものもある。

このようなオーディオコーデックの一例がＩＳＯ／ＩＥＣ ＣＤ２３００３−３に規定されるようなＵＳＡＣコーデックである。この「情報技術―ＭＰＥＧオーディオ技術―パート３、音声音響統合符号化」と言う名称の標準は、音声音響統合符号化に関する提案について求められるものの基準モデルの機能ブロックを詳細に記述する。

図５ａおよび図５ｂは、エンコーダおよびデコーダのブロック図である。以下では、個別のブロックの一般的機能性について簡単に説明する。その上で、結果として得られる構文部分のすべてを結合してビットストリームにすることの問題点について、図６を参照して説明する。

図５ａおよび図５ｂは、エンコーダおよびデコーダのブロックを示す。ＵＳＡＣエンコーダおよびデコーダのブロック図は、ＭＰＥＧ−Ｄ ＵＳＡＣ符号化の構造を反映する。概略の構造は、次のように記述することができる。まず第１に、ステレオまたは多チャネル処理を扱うＭＰＥＧサラウンド（ＭＰＥＧＳ）機能部および入力信号におけるより高いオーディオ周波数のパラメータ表現を扱うエンハンストＳＢＲ（ｅＳＢＲ）部からなる一般的な前／後処理がある。そして、修正アドバンスドオーディオ符号化（ＡＣＣ）ツール経路からなる一方の分岐と、ＬＰＣ残差の周波数領域表現または時間領域表現のいずれかを特徴とする線形予測符号化（ＬＰまたはＬＰＣ領域）系の経路とからなる他方の分岐の２つの分岐がある。ＡＡＣおよびＬＰＣの両方のために伝送されるスペクトルのすべてが、量子化および算術符号化に続くＭＤＣＴ領域において表現される。時間領域表現はＡＣＥＬＰ励起符号化スキームを使用する。

ＭＰＥＧ−Ｄ ＵＳＡＣの基本構造を図５ａおよび図５ｂに示す。この図面におけるデータの流れは、左右および上下である。デコーダの機能は、ビットストリームペイロードにおける量子化オーディオスペクトルまたは時間領域表現の記述を見つけて、量子化された値や他の再構成情報を復号化することである。

送信されたスペクトル情報の場合、デコーダは、量子化スペクトルを再構成し、ビットストリームペイロードにおいて活性であるいずれかのツールで、再構成されたスペクトルを処理して、入力ビットストリームペイロードにより記述される実際の信号スペクトルに到達して、最終的に周波数領域のスペクトルを時間領域に変換する。最初の再構成およびスペクトル再構成のスケーリングに続いて、より効率的符号化を図るために、スペクトルのうち１以上を変更する随意のツールが存在する。

送信された時間領域信号表現の場合、デコーダは、量子化された時間信号を再構成し、この再構成された時間信号をビットストリームペイロードにおいて活性であるいずれかのツールで処理して、入力ビットストリームペイロードにより記述される実際の時間領域信号に到達する。

信号データに対して作用する随意のツールごとに、「パススルー」する選択肢が保持され、かつ処理が省略されるすべての場合において、その入力としてのスペクトルまたは時間サンプルは、修正なしで、ツールを介して直接スルーされる。

ビットストリームが、その信号表現を時間領域から周波数領域の表現へ、または、ＬＰ領域から非ＬＰ領域へまたはその逆に変更する場合、デコーダは、適当な遷移オーバラップ加算ウィンドウ化により１つの領域から他の領域への遷移を容易にする。

ｅＳＢＲおよびＭＰＥＧＳ処理を、遷移取扱い後の両方の符号化経路に同じ態様で適用する。

ビットストリームペイロードデマルチプレクサツールへの入力は、ＭＰＥＧ−Ｄ ＵＳＡＣビットストリームペイロードである。デマルチプレクサは、ビットストリームペイロードをツールごとに部分に分けて、そのツールに関連するビットストリームペイロード情報をツールの各々に付与する。

ビットストリームペイロードデマルチプレクサツールからの出力は以下のとおりである。
・現在のフレームにおけるコア符号化のタイプによって、
‐量子化されかつ雑音なしで符号化されるスペクトルであって、
‐スケールファクタ情報
‐算術的に符号化されたスペクトルラインにより表現され
・または、以下のいずれかにより表現される励起信号を伴う線形予測（ＬＰ）パラメータのいずれかである。すなわち、それらは
‐量子化されかつ算術的に符号化されるスペクトルライン（変換符号化励起、ＴＣＸ）もしくは
‐ＡＣＥＬＰ符号化時間領域励起
・スペクトルノイズフィリング情報（随意）
・Ｍ／Ｓ決定情報（随意）
・時間雑音整形（ＴＮＳ）情報（随意）
・フィルタバンク制御情報
・時間アンワープ（ＴＷ）制御情報（随意）
・エンハンストスペクトル帯域幅複製（ｅＳＢＲ）制御情報（随意）
・ＭＰＥＧサラウンド（ＭＰＥＧＳ）制御情報

スケールファクタノイズレス復号化ツールは、ビットストリームペイロードデマルチプレクサから情報を得て、この情報を構文解析し、かつハフマン（Ｈｕｆｆｍａｎ）およびＤＰＣＭ符号化スケールファクタを復号化する。

スケールファクタノイズレス復号化ツールへの入力は以下のとおりである。
・ノイズレスで符号化されたスペクトルのためのスケールファクタ情報

スケールファクタノイズレス復号化ツールの出力は、以下のとおりである。
・スケールファクタの復号化整数表現。

スペクトルノイズレス復号化ツールは、ビットストリームペイロードデマルチプレクサから情報を得て、この情報を構文解析し、算術的に符号化されたデータを復号化し、かつ量子化スペクトルを再構成する。このノイズレス復号化ツールへの入力は、以下のとおりである。
・ノイズレスに復号化されたスペクトル

このノイズレス復号化ツールの出力は、以下のとおりである。
・スペクトルの量子化された値
逆量子化部ツールは、スペクトルのための量子化された値を得、かつ整数値を非スケーリングの再構成スペクトルへ変換する。この量子化部は、コンパンディング量子化部であり、そのコンパンディングファクタは、選択されるコア符号化モードに依存する。

逆量子化部ツールへの入力は、以下のとおりである。
・スペクトルのための量子化された値

逆量子化部ツールの出力は、以下のとおりである。
・非スケーリングの逆量子化されたスペクトル

ノイズフィリングツールを使用して復号化されたスペクトルにおけるスペクトルギャップを充填するが、これは、たとえば、エンコーダ内のビット要求に対する強い制限等により、スペクトル値がゼロに量子化される場合に発生する。

ノイズフィリングツールに対する入力は、以下のとおりである。
・非スケーリング、逆量子化スペクトル
・ノイズフィリングパラメータ
・スケールファクタの復号化された整数表現

ノイズフィリングツールへの出力は以下のとおりである。
・前回ゼロに量子化されたスペクトルラインの非スケーリング、逆量子化スペクトル値
・スケールファクタの修正された整数表現

再スケーリングツールで、スケールファクタの整数表現を実際の値に変換しかつ非スケーリング、逆量子化スペクトルに関連のスケールファクタを乗算する

スケールファクタツールへの入力は以下のとおりである。
・スケールファクタの復号化された整数表現
・非スケーリングの、逆量子化されたスペクトル

スケールファクタツールからの出力は以下のとおりである。
・スケーリングされ、逆量子化されたスペクトル

Ｍ／Ｓツールに関する概要については、非特許文献１（ＩＳＯ／ＩＥＣ１４４９６−３：２００９、４.１.１.２）を参照。

時間雑音整形（ＴＮＳ）ツールに関する概要については、非特許文献１を参照。

フィルタバンク／ブロック切替ツールを、エンコーダで行われた周波数マッピングの逆に適用する。逆修正離散コサイン変換（ＩＭＤＣＴ）は、フィルタバンクツールに使用する。ＩＭＤＣＴは、１２０、１２８、２４０、２５６、４８０、５１２、９６０、または１０２４スペクトル係数をサポートするよう構成することができる。

フィルタバンクツールに対する入力は以下のとおりである。
・（逆量子化された）スペクトル
・フィルタバンク制御情報
フィルタバンクツールからの出力（単数または複数）は、以下のとおりである。
・時間領域再構成オーディオ信号（単数または複数）

時間ワープしたフィルタバンク／ブロック切替ツールは、時間ワープモードが可能化された際に、通常のフィルタバンク／ブロック切替ツールを置換する。フィルタバンクは、通常のフィルタバンクについては、同じ（ＩＭＤＣＴ）であり、付加的には、ウィンドウ化された時間領域サンプルを、時間可変再サンプリングにより、ワープした時間領域から線形時間領域へマッピングする。

時間ワープしたフィルタバンクツールへの入力は、以下のとおりである。
・逆量子化したスペクトル
・フィルタバンク制御情報
・時間ワープ制御情報

フィルタバンクツールからの出力（単数または複数）は以下のとおりである。
・線形時間領域再構成オーディオ信号（単数または複数）

エンハンストＳＢＲ（ｅＳＢＲ）ツールは、オーディオ信号の高帯域を再生成する。これは、符号化の際にトランケートされた高調波のシーケンスの複製による。これは、生成された高帯域のスペクトルエンベロープを調節しかつ逆フィルタリングを適用し、雑音および正弦波成分を付加して、元の信号のスペクトル特性を再現するようになっている。

ｅＳＢＲツールへの入力は、以下のとおりである。
・量子化されたエンベロープデータ
・Ｍｉｓｃ．制御データ
・周波数領域コアデコーダまたはＡＣＥＬＰ／ＴＣＸコアデコーダからの時間領域信号

ｅＳＢＲツールの出力は以下のいずれかである。
・時間領域信号、または
・ＭＰＥＧサラウンドツール等における信号のＱＭＦ領域表現が使用される。

ＭＰＥＧサラウンド（ＭＰＥＧＳ）ツールは、適切な空間パラメータにより制御される入力信号（単数または複数）に複雑なアップミックス過程を適用することにより１以上の入力信号から複数の入力信号を生成する。ＵＳＡＣコンテクストでは、ＭＰＥＧＳが、送信されたダウンミックスされた信号と並んでパラメータサイド情報を送信することにより多チャネル信号を符号化するために使用される。

ＭＰＥＧＳツールへの入力は以下のとおりである。
・ダウンミックスされた時間領域信号、または
・ｅＳＢＲツールからのダウンミックスされた信号のＱＭＦ領域表現

ＭＰＥＧＳツールの出力は以下のとおりである。
・多チャネル時間領域信号

信号分類部ツールは、元の入力信号を解析しかつそれから異なる符号化モードの選択をトリガする制御情報を生成する。入力信号の解析は、実装に依存しかつ所与の入力信号フレームについて最適なコア符号化モードを選択しようとする。信号分類部の出力は、ＭＰＥＧサラウンド、エンハンストＳＢＲ、時間ワープしたフィルタバンク等の他のツールの挙動に影響を与えるためにも（随意に）使用できる。

信号分類部ツールへの入力は、以下のとおりである。
・元の、修正されていない入力信号
・追加の実装依存パラメータ

信号分類部ツールの出力は、以下のとおりである。
・コアコーディック（非ＬＰフィルタ化周波数領域符号化、ＬＰフィルタ化周波数領域またはＬＰフィルタ化時間領域符号化）の選択を制御する制御信号

ＡＣＥＬＰツールは、長期予測部（適応コードワード）とパルス様シーケンス（イノベーションコードワード）とを組み合わせることにより時間領域励起信号を効率的に表現する方法を提供する。再構成された励起は、ＬＰ合成フィルタを介して送られ、時間領域信号を構成する。

ＡＣＥＬＰツールへの入力は、以下のとおりである。
・適合およびイノベーションコードブックインデクス
・適合およびイノベーションコード利得値
・他の制御データ
・逆量子化されかつ補間されたＬＰＣフィルタ係数

ＡＣＥＬＰツールの出力は以下のとおりである。
・時間領域再構成オーディオ信号

ＭＤＣＴ系ＴＣＸ復号化ツールは、ＭＤＣＴ領域からの重み付ＬＰ残差表現を時間領域信号に戻しかつ重み付ＬＰ合成フィルタリングを含む時間領域信号を出力する。ＩＭＤＣＴは、２５６、５１２または１０２４のスペクトル係数をサポートするよう構成することができる。

ＴＣＸツールへの入力は、以下のとおりである。
・（逆量子化された）ＭＤＣＴスペクトル
・逆量子化されかつ補間されたＬＰＣフィルタ係数

ＴＣＸツールの出力は以下のとおりである。
・時間領域再構成オーディオ信号

ＩＳＯ／ＩＥＣ ＣＤ２３００３−３に開示される技術（ここに引用により援用）により、チャネル要素の定義が可能になる。たとえば、単一のチャネルのためのペイロードを含むのみの単一のチャネル要素、２つのチャネルのためのペイロードを含むチャネル対要素またはＬＦＥチャネルのためのペイロードを含むＬＦＥ（低周波数エンハンスメント）チャネル要素である。

当然のことながら、ＵＳＡＣコーデックが、１つのビットストリームを経由して、１または２のオーディオチャネルまたはオーディオオブジェクトのより複雑なオーディオコーデックに関する情報を符号化し転送することができる唯一のコーデックというわけではない。したがって、ＵＳＡＣコーデックは、具体例として挙げられているに過ぎない。

図６は、エンコーダおよびデコーダそれぞれのより一般的な例を示し、いずれもエンコーダがオーディオコンテント１０をビットストリーム１２に符号化し、デコーダがビットストリーム１２からオーディオコンテントまたは少なくともその一部を復号化する一般的な背景において示す。復号化、すなわち再構成の結果を１４で示す。図６に示すとおり、オーディオコンテント１０は、いくつかのオーディオ信号１６から構成され得る。たとえば、オーディオコンテント１０は、いくつかのオーディオチャネル１６からなる空間オーディオシーンであると言える。代替的には、オーディオコンテント１０は、オーディオ信号１６の集まりを表し、オーディオ信号１６が個別にまたはグループで、特定のラウドスピーカーコンフィギュレーションについて、空間オーディオシーン等の形式でオーディオコンテント１０の再構成１４を得るように、デコーダのユーザの判断によってオーディオシーンに結合させ得る個別のオーディオオブジェクトを表す。エンコーダは、連続する期間からなる単位で、オーディオコンテント１０を符号化する。このような期間については、図６に１８で例示する。エンコーダはオーディオコンテント１０の連続する期間１８を、同じ態様で符号化する。すなわち、エンコーダは、ビットストリーム１２に、期間１８当たり１フレーム２０を挿入する。そうすることで、エンコーダは、それぞれ期間１８内のオーディオコンテントをフレーム要素に分解する。その数および意味／タイプは、それぞれ期間１８およびフレーム２０ごとに同じである。上記のＵＳＡＣコーデックに関しては、エンコーダが、たとえば、各期間１８ごとのオーディオ信号１６の同じ対を、フレーム２０の要素２２のチャネル対要素に符号化する一方で、他のオーディオ信号１６については、単一チャネル符号化等の他の符号化原則を用いて単一チャネル要素２２等を得るようにする。１以上のフレーム要素２２により規定されるダウンミクスオーディオ信号からオーディオ信号のアップミクスを得るためのパラメータサイド情報を集めてフレーム２０内に他のフレーム要素を形成する。この場合、このサイド情報を伝達するフレーム要素は他のフレーム要素の一種の拡張データに関連するかまたはこれを構成する。当然ながら、このような拡張は、多チャネルまたは多オブジェクトサイド情報に限定されない。

１つの可能性は、各フレーム要素２２内で、それぞれのフレーム要素がどのタイプであるかを示すことである。このような過程は、ビットストリーム構文の将来の拡張への対処を図るため有利である。ある種のフレーム要素タイプを扱えないデコーダは、これらのフレーム要素内にあるそれぞれの長さ情報を使用することでビットストリーム内のそれぞれのフレーム要素を単純にスキップすることが考えられる。その上、異なるタイプの標準に準拠したデコーダという可能性を提供する。いくつかは、第１のタイプのセットを理解し、いくつかは、他のタイプのセットを理解しこれを扱うことができる。代替的な要素タイプは、それぞれのデコーダが単純に無視すると考えられる。さらに、エンコーダは、このような追加のフレーム要素を処理できるデコーダに、たとえばデコーダ内のバファリングの必要性を最小限にする順序で、フレーム２０内のフレーム要素をフィードし得るように、判断に基づきフレーム要素をソートすることもできる。しかしながら、ビットストリームが、フレーム要素ごとにフレーム要素タイプ情報を伝達する必要があり、この必要性が、今度はビットストリーム１２の圧縮率および復号化の複雑性に悪影響を及ぼすが、これは、それぞれのフレーム要素タイプ情報を調べるための構文解析オーバヘッドが各フレーム要素内に生じるためである。

当然ながら、従来の方法等によりフレーム要素２２の順序をこれ以外に固定することも考えられるが、そのような過程によって、フレーム要素間で異なる順序を要するかまたは提案する等、将来の拡張フレーム要素の特定の特徴によって、エンコーダがフレーム要素を再構成する自由が阻害される。

ＩＳＯ／ＩＥＣ１４４９６−３：２００９、４.１.１２

したがって、ビットストリーム、エンコーダおよびデコーダそれぞれについての他の概念が必要である。

したがって、本発明の目的は、上記の問題を解決し、かつ、フレーム要素位置決めのより効率的な方法の取得を図るビットストリーム、エンコーダおよびデコーダを提供することである。

この目的は、係属中の独立項の主題により達成される。

本発明は、高すぎるビットストリームおよび復号化オーバヘッドと、フレーム要素位置決めの柔軟性とのより良い妥協が、ビットストリームのフレームのシーケンスの各々が、Ｎ個のフレーム要素のシーケンスを含み、かつビットストリームが要素数Ｎを表示するフィールドおよびタイプ表示構文部を含むコンフィギュレーションブロックを含み、タイプ表示構文部が、Ｎ個の要素位置のシーケンスの各要素位置について、複数の要素タイプのうちから要素タイプを表示し、フレームのＮ個のフレーム要素のシーケンスにおいて、各フレーム要素が、ビットストリームにおいてそれぞれのフレームのＮ個のフレーム要素のシーケンス内でそれぞれのフレーム要素が位置するそれぞれの要素位置について、タイプ表示部が表示する要素タイプである構成により得られるとする知見に基づく。このように、各フレームが、同じ順序でビットストリーム内に位置するタイプ表示構文部により表示されるフレーム要素タイプのＮ個のフレーム要素の同じシーケンスを含む点で、フレームは等しく構成される。この順序は、Ｎ個の要素位置のシーケンスの各要素位置について、複数の要素タイプのうちから要素タイプを表示するタイプ表示構文部を使用することによりフレームのシーケンスについて共通に調節可能である。

これにより、フレーム要素タイプは、エンコーダの判断等いずれの順序にも配列が可能であり、それにより、たとえば使用されるフレーム要素タイプについて最も適切な順序を選ぶようにできる。

複数のフレーム要素タイプは、たとえば、特定の拡張要素タイプをサポートしないデコーダが、長さ情報をスキップインターバル長さとして使用して拡張要素タイプのこれらのフレーム要素をスキップできるように、それぞれのフレーム要素の長さについて長さ情報を含む拡張要素タイプのフレーム要素を有する拡張要素タイプを含み得る。他方、拡張要素タイプのこれらのフレーム要素を扱うことができるデコーダは、応じて、そのコンテントまたはペイロード部を処理し、かつエンコーダがフレームのフレーム要素のシーケンス内で拡張要素タイプのこれらのフレーム要素を自由に位置決めできるので、デコーダでのバファリングオーバヘッドは、フレーム要素タイプの順序を適切に選択し、かつ、タイプ表示構文部内にこれを信号伝達することにより最小化され得る。

本発明の実施例の効果的な実現が従属項の主題である。

さらに、本件の好ましい実施例について以下に図面を参照して説明する。

実施例によるエンコーダならびにその入力および出力の模式ブロック図である。 実施例によるデコーダならびにその入力および出力の模式ブロック図である。 実施例によるビットストリームの模式図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 実施例によるビットストリームの具体的構文を示す疑似コードの表を示す図である。 ＵＳＡＣエンコーダおよびデコーダのブロック図である。 ＵＳＡＣエンコーダおよびデコーダのブロック図である。 エンコーダおよびデコーダの典型的な対を示す図である。

図１は、実施例によるエンコーダ２４を示す。エンコーダ２４は、オーディオコンテント１０をビットストリーム１２に符号化するためのものである。

本件明細書の導入部に記載のとおり、オーディオコンテント１０は、いくつかのオーディオ信号１６の集まりであることが可能である。オーディオ信号１６はたとえば空間オーディオシーンの個々のオーディオチャネルを表す。代替的には、オーディオ信号１６は、復号化側で自由にミキシングするための、ともにオーディオシーンを規定するオーディオオブジェクトのセットからなるオーディオオブジェクトを構成する。オーディオ信号１６は、２６で示す共通の時間軸ｔで規定される。すなわち、オーディオ信号１６は、同じ時間間隔に関連し、かつ、従って相互に時間整列し得る。

エンコーダ２４は、各フレーム２０がオーディオコンテント１０の期間１８のそれぞれ１つを表すように、オーディオコンテント１０の連続する期間１８をフレーム２０のシーケンスに符号化するよう構成される。エンコーダ２４は、ある意味においては、各フレーム２０がフレーム要素の要素数Ｎのシーケンスを含むように各期間を同じ態様で符号化するよう構成される。各フレーム２０内では、各フレーム要素２２が複数の要素タイプのそれぞれの１つであり、かつある要素位置にあるフレーム要素２２が同じまたは等しい要素タイプであるということが成り立つ。すなわち、フレーム２０における第１のフレーム要素２２は同じ要素タイプであり、フレーム要素の第１のシーケンス（またはサブストリーム）を構成し、全フレーム２０の第２のフレーム要素２２は、相互に等しい要素タイプからなり、フレーム要素の第２のシーケンスを構成する等である。

実施例によれば、たとえばエンコーダ２４は、複数の要素タイプが以下を含むように構成される。

ａ）たとえば単一チャネル要素タイプのフレーム要素が、１つの単一オーディオ信号を表すために、エンコーダ２４により生成され得る。よって、フレーム２０内のある要素位置、たとえば０＞ｉ＞Ｎ＋１のｉ番目の要素フレームで、したがって、フレーム要素のｉ番目のサブストリームを構成する等のフレーム要素２２のシーケンスは、ともにこのような単一オーディオ信号の連続する期間１８を表すと考えられる。こうして表されるオーディオ信号は、オーディオコンテント１０のオーディオ信号１６のいずれか１つに直接対相当し得る。しかしながら、代替的には、以下に詳説するとおり、このように表されるオーディオ信号は、ダウンミクス信号からの１チャネルであることが可能であり、これは、フレーム２０内の他の要素位置にある他のフレーム要素タイプのフレーム要素のペイロードデータと共に、オーディオコンテント１０のいくつかのオーディオ信号１６を生成し、それは、上記のダウンミクス信号のチャネル数より多い。以下に詳説する実施例の場合には、このような単一チャネル要素タイプのフレーム要素は、ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔと記される。ＭＰＥＧサラウンドおよびＳＡＯＣの場合、たとえば、ＭＰＥＧサラウンドの場合にはモノ、ステレオまたは多チャネルの可能性さえある単一ダウンミクス信号が存在するに過ぎない。後者の場合には、たとえば、５．１ダウンミクスは、２つのチャネル対要素および１つの単一チャネル要素から構成される。この場合、単一チャネル要素および２つのチャネル対要素は、ダウンミクス信号の一部分に過ぎない。ステレオダウンミクスの場合には、チャネル対要素が使用される。

ｂ）チャネル対要素タイプのフレーム要素は、オーディオ信号のステレオ対を表すように、エンコーダ２４により生成され得る。つまり、このタイプのフレーム要素２２は、フレーム２０内の共通の要素位置に置かれるが、ともにこのようなステレオオーディオ対の連続する期間１８を表すフレーム要素のそれぞれのサブストリームを構成すると考えられる。こうして表されるオーディオ信号のステレオ対は、そのままオーディオコンテント１０のオーディオ信号１６のいずれかの対か、または他の要素位置に位置する他の要素タイプのフレーム要素のペイロードデータと共にオーディオコンテント１０の２を超える数のオーディオ信号１６を生成するダウンミクス信号を表すことが可能である。以下に詳説する実施例においては、このようなチャネル対要素タイプのフレーム要素は、ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔとして記される。

ｃ）サブウーファ（ｓｕｂｗｏｏｆｅｒ）チャネル等のより低い帯域幅を必要とするオーディオコンテント１０のオーディオ信号１６に関する情報を伝達するために、エンコーダ２４は、特定のタイプのフレーム要素を、単一のオーディオ信号の連続する期間１８等を表す共通の要素位置に位置するこのようなタイプのフレーム要素でサポートし得る。このオーディオ信号は、そのままオーディオコンテント１０のオーディオ信号１６のいずれかかまたは単一チャネル要素タイプおよびチャネル対要素タイプに関してすでに述べたダウンミクス信号の一部であることが可能である。以下に詳説する実施例では、このような特定のフレーム要素タイプのフレーム要素は、ＵｓａｃＬｆｅＥｌｅｍｅｎｔと記される。

ｄ）タイプａ、ｂおよび／またはｃのいずれかのフレーム要素が表すオーディオ信号のいずれかをデコーダがアップミクスしてより多い数のオーディオ信号を得ることができるように、ビットストリームと共にサイド情報を伝達するよう、拡張要素タイプのフレーム要素をエンコーダ２４により生成することができる。このような拡張要素タイプのフレーム要素は、フレーム２０内のある共通の要素位置に置かれ、よってより多い数のオーディオ信号のそれぞれの期間が得られるように、他のフレーム要素のいずれかにより表される１以上のオーディオ信号のそれぞれの期間のアップミクスを可能にする連続する期間１８に関連するサイド情報を伝達する。後者は、オーディオコンテント１０の元のオーディオ信号１６に対応し得る。このようなサイド情報の例は、たとえばＭＰＳまたはＳＡＯＣサイド情報等のパラメトリックサイド情報である。

以下に詳説する実施例によれば、入手可能な要素タイプは、上記の４つの要素タイプからなるに過ぎないが、他の要素タイプも入手可能かもしれない。他方で、要素タイプａ〜ｃのうち１つまたは２つのみが入手可能かもしれない。

上記の説明から明らかなとおり、ビットストリーム１２から拡張要素タイプのフレーム要素２２を省くことまたは復号化においてこれらのフレーム要素を無視することで、オーディオコンテント１０の再構成が完全にできなくなるというわけではない。少なくとも、他の要素タイプの残りのフレーム要素が、オーディオ信号を生成するために十分な情報を伝達する。これらのオーディオ信号は、オーディオコンテント１０の元のオーディオ信号またはその適切なサブセットに必ずしも対応しているわけではないが、オーディオコンテント１０の一種の「アマルガム」（混合物）を表わす。すなわち、拡張要素タイプのフレーム要素は、フレーム２０内の異なる要素位置の１以上のフレーム要素に関するサイド情報を表す情報（ペイロードデータ）を伝達し得る。

しかしながら、以下の実施例では、拡張要素タイプのフレーム要素は、この種のサイド情報伝達に限定されない。むしろ、拡張要素タイプのフレーム要素は、以下では、ＵｓａｃＥｘｔＥｌｅｍｅｎｔと表記され、長さ情報と共にペイロードデータを伝達するものと規定され、後者の長さ情報が、ビットストリーム１２を受信するデコーダを可能化し、それによりデコーダがこれらのフレーム要素内のそれぞれのペイロードデータを処理できない場合等は、拡張要素タイプのこれらのフレーム要素をスキップするようになっている。これについては以下に詳説する。

しかし、図１のエンコーダの説明に進む前に、上記の要素タイプについては代替例としていくつかの可能性が存在する。これは、上記の拡張要素タイプについては特に当てはまる。特に、そのペイロードデータが、たとえば、それぞれのペイロードデータを処理できないデコーダによってスキップ可能なように拡張要素タイプが構成されている場合、これらの拡張要素タイプのフレーム要素のペイロードデータは、いずれかのペイロードデータタイプの可能性がある。このペイロードデータは、他のフレーム要素タイプの他のフレーム要素のペイロードデータに関するサイド情報を構成するかまたは、たとえば他のオーディオ信号を表す自己完結のペイロードデータを構成できる。さらに、他のフレーム要素タイプのフレーム要素のペイロードデータのサイド情報を表す拡張要素タイプのフレーム要素のペイロードデータの場合でさえ、これら拡張要素タイプフレーム要素のペイロードデータは上記の種類、すなわち多チャネルまたは多オブジェクトサイド情報には限定されない。多チャネルサイド情報ペイロードは、たとえば他の要素タイプのフレーム要素のいずれかが表すダウンミクス信号に、インタチャネルコヒーレンス値（ＩＣＣ）、インタチャネルレベル差（ＩＣＬＤ）および／またはインタチャネル時間差（ＩＣＴＤ）等、バイナリキュー符号化（ＢＣＣ）パラメータ等の空間キュー、ならびに随意にはそのパラメータがＭＰＥＧサラウンド標準等からの先行技術において知られるチャネル予測係数等を伴う。上記の空間キューパラメータは、たとえば、時間／周波数分解能における拡張要素タイプのフレーム要素のペイロードデータ内、すなわち時間／周波数グリッドの時間／周波数タイルごとに１つのパラメータで送信され得る。多オブジェクトサイド情報の場合には、拡張要素タイプフレーム要素のペイロードデータは、インタオブジェクトクロス相関（ＩＯＣ）パラメータ、オブジェクトレベル差（ＯＬＤ）、および他の要素タイプのフレーム要素のいずれかにより表されるダウンミクス信号のチャネルへ元のオーディオ信号がどのようにダウンミクスされたかを明らかにするダウンミクスパラメータ等、同様の情報を含み得る。後者のパラメータは、たとえば、ＳＡＯＣ標準から当該技術分野では既知である。しかしながら、拡張要素タイプフレーム要素のペイロードデータが表すことができる異なるサイド情報の例は、たとえばフレーム２０内の異なる要素位置にある他のフレーム要素タイプのフレーム要素のいずれかが表すオーディオ信号の高周波数部のエンベロープをパラメトリック的に符号化し、かつ、高周波数部の基礎として後者のオーディオ信号から得られる低周波数部の使用により空間帯域の複製を可能にするためのＳＢＲデータであり、そして、たとえばＳＢＲデータのエンベロープによりこうして得られる高周波数部のエンベロープを形成する。より一般的には、拡張要素タイプのフレーム要素のペイロードデータが、時間領域または周波数領域いずれかのフレーム２０内部の異なる要素位置にある他の要素タイプのいずれかのフレーム要素により表されるオーディオ信号を修正するためのサイド情報を伝達できる。周波数領域とは、たとえばＱＭＦ領域または他のフィルタバンク領域または変換領域が可能である。

図１のエンコーダ２４の機能性をさらに説明するが、エンコーダ２４は、要素数Ｎを表示するフィールドと、Ｎ個の要素位置のシーケンスの各要素位置について、それぞれの要素タイプを表示するタイプ表示構文部とを含むコンフィギュレーションブロック２８をビットストリーム１２に符号化するよう構成される。応じて、エンコーダ２４は、ビットストリーム１２のＮ個のフレーム要素２２のシーケンス内にあるそれぞれの要素位置にあるＮ個のフレーム要素２２のシーケンスの各フレーム要素２２が、それぞれの要素位置についてタイプ表示部により表示される要素タイプになるように、各フレーム２０について、Ｎ個のフレーム要素２２のシーケンスをビットストリーム１２に符号化するよう構成される。言い換えれば、エンコーダ２４がＮ個のサブストリームを構成し、その各々が、それぞれの要素タイプのフレーム要素２２のシーケンスである。つまり、これらのＮ個のサブストリームのすべてについて、フレーム要素２２が等しい要素タイプであり、一方、異なるサブストリームのフレーム要素が、異なる要素タイプになり得る。エンコーダ２４は、１つの共通の期間１８に関連するこれらのサブストリームのＮ個のフレーム要素すべてを連結することによりこれらのフレーム要素のすべてを多重化してビットストリーム１２にし、１つのフレーム２０を構成するよう構成される。これにより、ビットストリーム１２では、これらのフレーム要素２２がフレーム２０内に配列される。各フレーム２０内では、Ｎ個のサブストリームを表すもの、すなわち同じ期間１８に関するＮ個のフレーム要素が、要素位置のシーケンスおよびコンフィギュレーションブロック２８におけるタイプ表示構文部それぞれにより規定される静的順序で配列される。

タイプ表示構文部を使用することにより、エンコーダ２４は、順序を自由に選択することができ、これを利用してＮ個のサブストリームのフレーム要素２２は、フレーム２０内に配列される。これにより、エンコーダ２４は、たとえば復号化側のバファリングオーバヘッドをできる限り低く保つことができる。たとえば、他のサブストリーム（ベースサブストリーム）のフレーム要素についてのサイド情報を伝達する拡張要素タイプのフレーム要素のサブストリームは、非拡張要素タイプであり、フレーム２０においてこれらのベースサブストリームフレーム要素が位置する要素位置の直後のフレーム２０内の要素位置に配置され得る。これにより、復号化側が、サイド情報を付与するためベースサブストリームを復号化した結果または中間結果をバッファする必要があるバッファ時間を低く保ち、かつ、バッファオーバヘッドを減じることができる。フレーム要素２２（ベースサブストリーム）の他のサブストリームにより表すオーディオ信号の周波数領域等の中間結果に、拡張要素タイプであるサブストリームのフレーム要素のペイロードデータのサイド情報が付与される場合には、すぐにベースサブストリームに追随するように拡張要素タイプフレーム要素２２のサブストリームを位置決めすれば、バッファオーバヘッドが最小化するのみならず、デコーダが、表現されるオーディオ信号の再構成のさらなる処理を遮断する必要がある持続時間も最小化される。これは、たとえば、拡張要素タイプフレーム要素のペイロードデータがベースサブストリームの表現に相対的にオーディオ信号の再構成を修正することになるからである。しかしながら、拡張サブストリームが帰する、オーディオ信号を表すそのべースサブストリームに先立って、従属する拡張サブストリームの位置決めすることが好ましいかもしれない。たとえば、エンコーダ２４は、チャネル要素タイプサブストリームに対して上流のビットストリーム内に拡張ペイロードのサブストリームを自由に位置決めする。たとえば、サブストリームｉの拡張ペイロードは、動的範囲制御（ＤＲＣ）データを伝達することが可能であり、かつ、たとえば要素位置ｉ＋１のチャネルサブストリーム内の周波数領域（ＦＤ）符号化を介する等対応のオーディオ信号の符号化に先立ってまたはより早いの要素位置ｉにおいて送信される。その後、デコーダは、非拡張タイプサブストリームｉ＋１により表すオーディオ信号を復号化かつ再構成する際に直接的にＤＲＣを使用することができる。

ここまで説明したエンコーダ２４は、本件の可能な実施例を表す。しかしながら、図１には、単に説明として理解すべきエンコーダの可能な内部構造も示す。図１に示すとおり、エンコーダ２４は、ディストリビュータ（ｄｉｓｔｒｉｂｕｔｏｒ）３０およびシーケンシャライザ（ｓｅｑｕｅｎｔｉａｌｉｚｅｒ）３２を含み、その間に様々な符号化モジュール３４ａ〜３４ｅが以下に詳説する態様で接続される。特に、ディストリビュータ３０は、オーディオコンテント１０のオーディオ信号１６を受信し、かつ、これを個々の符号化モジュール３４ａ〜３４ｅへ分配するよう構成される。ディストリビュータ３０がオーディオ信号１６の連続期間１８を符号化モジュール３４ａ〜３４ｅへ分配する態様は静的である。特に、分配は、各オーディオ信号１６を符号化モジュール３４ａ〜３４ｃの１つに排他的に転送するようにしてもよい。ＬＦＥエンコーダ３４ａへフィードされるオーディオ信号は、ＬＦＥエンコーダ３４ａにより、たとえば、タイプｃ（上記参照）のフレーム要素２２のサブストリームに符号化される。単一チャネルエンコーダ３４ｂの入力にフィードされたオーディオ信号は、たとえば、タイプａ（上記参照）のフレーム要素２２のサブストリームへ後者により符号化される。同様に、チャネル対エンコーダ３４ｃの入力にフィードされたオーディオ信号の対は、後者により、たとえば、タイプｄ（上記参照）のフレーム要素２２のサブストリームへ符号化される。上記の符号化モジュール３４ａ〜３４ｃは、ディストリビュータ３０とシーケンシャライザ３２との間で、その入力と出力に接続される。

しかしながら、図１に示すように、符号化モジュール３４ｂおよび３４ｃの入力は、ディストリビュータ３０の出力インタフェースに接続されているだけではない。むしろ、これらは、符号化モジュール３４ｄおよび３４ｅのいずれかの出力信号によりフィードされ得る。後者の符号化モジュール３４ｄおよび３４eは、いくつかのインバウンドオーディオ信号をより少ない数のダウンミクスチャネルのダウンミクス信号におよびタイプｄ（上記参照）のフレーム要素２２のサブストリームに符号化するよう構成される符号化モジュールの例である。上記の説明から明らかなとおり、符号化モジュール３４ｄは、ＳＡＯＣエンコーダであり、かつ符号化モジュール３４eは、ＭＰＳエンコーダであり得る。ダウンミクス信号は、符号化モジュール３４ｂおよび３４ｃのいずれかへ転送される。符号化モジュール３４ａ〜３４ｅにより生成されたサブストリームは、これらを上記のとおりビットストリーム１２に順序決めするシーケンシャライザ３２へ転送される。これにより、符号化モジュール３４ｄおよび３４ｅは、ディストリビュータ３０の出力インタフェースに接続されるいくつかのオーディオ信号のためのそれらの入力を有し、一方で、それらのサブストリーム出力がシーケンシャライザ３２の入力インタフェースに接続され、かつそれらのダウンミクス出力が符号化モジュール３４ｂおよび／または３４ｃの入力にそれぞれ接続される。

なお、上記の説明では、多オブジェクトエンコーダ３４ｄおよび多チャネルエンコーダ３４ｅの存在は、例示的目的のためのみに選択されており、これらの符号化モジュール３４ｄおよび３４ｅのいずれかを省くか他の符号化モジュール等により置換してもよい。

エンコーダ２４およびその考えられる内部構造について説明した後、対応のデコーダについて図２を参照して説明する。図２のデコーダは、一般に参照番号３６で示し、ビットストリーム１２を受信するための入力と、オーディオコンテント１０の再構成したもの３８またはそのアマルガムを出力するための出力とを有する。よって、デコーダ３６は、図１に示すコンフィギュレーションブロック２８およびフレーム２０のシーケンスを含むビットストリーム１２を復号化し、かつ、それぞれのフレーム要素２２がビットストリーム１２におけるそれぞれのフレーム２０のＮ個のフレーム要素２２のシーケンス内に位置するそれぞれの要素位置についてタイプ表示部により示す要素タイプに従ってフレーム要素２２を復号化することにより各フレーム２０を復号化するよう構成される。すなわち、デコーダ３６は、フレーム要素自体の内部の何らかの情報よりもむしろ現在のフレーム２０内のその要素位置に依拠する可能な要素タイプの１つに各フレーム要素２２を割り当てるよう構成される。これにより、デコーダ３６は、Ｎ個のサブストリームを取得し、第１のサブストリームは、フレーム２０の第１のフレーム要素から構成され、第２のサブストリームは、フレーム２０内の第２のフレーム要素２２から構成され、第３のサブストリームは、フレーム２０内の第３のフレーム要素２２から構成される等である。

拡張要素タイプフレーム要素についてより詳細にデコーダ３６の機能性について説明する前に、図２のデコーダ３６の可能な内部構造について、図１のエンコーダ２４の内部構造と対応するように詳説する。エンコーダ２４について説明したとおり、内部構造については例示的に示すものとしてのみ理解されたい。

特に、図２に示すとおり、デコーダ３６は、内部にディストリビュータ４０およびアレンジャ（ａｒｒａｎｇｅｒ）４２を備え、その間に復号化モジュール４４ａ〜４４ｅが接続される。各復号化モジュール４４ａ〜４４ｃは、ある種のフレーム要素タイプのフレーム要素２２のサブストリームを復号化する役割を果たす。したがって、ディストリビュータ４０は、復号化モジュール４４ａ〜４４ｅに対してビットストリーム１２のＮ個のサブストリームを分配するよう構成される。たとえば、復号化モジュール４４ａは、その出力に狭帯域（たとえば）オーディオ信号を取得するようタイプｃ（上記を参考）のフレーム要素２２のサブストリームを復号化するＬＦＥデコーダである。同様に、単一チャネルのデコーダ４４ｂは、要素タイプａ（上記を参照）のフレーム要素２２のインバウンドサブストリームを復号化して、その出力に単一オーディオ信号を取得し、かつチャネル対デコーダ４４ｃは、タイプｂ（上記を参照）のフレーム要素２２のインバウンドサブストリームを復号化して、その出力にオーディオ信号の対を取得する。復号化モジュール４４ａ〜４４ｃは、それらの入力と出力とが、ディストリビュータ４０の出力インタフェースとアレンジャ４２の入力インタフェースとの間に接続される。

デコーダ３６は、復号化モジュール４４ａ〜４４ｃを有するのみでよい。他の復号化モジュール４４ｅおよび４４ｄは、拡張要素タイプのフレーム要素を引き受けるので、オーディオコーデックとの適合性に関する限り随意となる。これらの拡張モジュール４４ｅおよび４４ｄの両方またはいずれかが欠ける場合には、ディストリビュータ４０は、以下に詳説するとおりビットストリーム１２におけるそれぞれの拡張フレーム要素サブストリームをスキップするよう構成され、かつオーディオコンテント１０の再構成されたもの３８は、オーディオ信号１６を有する元のバージョンのアマルガムに過ぎない。

しかしながら、もし存在すれば、すなわち、デコーダ３６が、ＳＡＯＣおよび／またはＭＰＳ拡張フレーム要素をサポートする場合、多チャネルデコーダ４４ｅは、エンコーダ３４ｅが生成するサブストリームを復号化するよう構成され、一方で多オブジェクトデコーダ４４ｄは、多オブジェクトエンコーダ３４ｄにより生成されるサブストリームの復号化を引き受ける。よって、復号化モジュール４４ｅおよび／または４４ｄが存在する場合には、スィッチ４６が、復号化モジュール４４ｃおよび４４ｂのうちのいずれかの出力を復号化モジュール４４ｅおよび／または４４ｄのダウンミクス信号入力と接続してもよい。多チャネルデコーダ４４ｅは、ディストリビュータ４０からのインバウンドサブストリーム内のサイド情報を使用してインバウンドダウンミクス信号をアップミクスして、その出力に増加した数のオーディオ信号を取得するよう構成され得る。多オブジェクトデコーダ４４ｄは、多オブジェクトデコーダ４４ｄが個別のオーディオ信号をオーディオオブジェクトとして扱うのに対して、多チャネルデコーダ４４ｅがその出力でオーディオ信号をオーディオチャネルとして扱うという違いをつけて作用してもよい。
こうして再構成されたオーディオ信号は、アレンジャ４２に転送され、アレンジャ４２がこれらを配列して、再構成したもの３８を構成する。アレンジャ４２は、さらにユーザ入力４８により制御されてもよく、このユーザ入力は、利用可能なラウドスピーカコンフィギュレーションまたは再構成３８の可能な最大数のチャネルを示す。ユーザ入力４８に依存して、アレンジャ４２は、拡張フレーム要素がビットストリーム１２内に存在していても、たとえば拡張モジュール４４ｄおよび４４ｅのいずれかのような復号化モジュール４４ａ〜４４ｅのいずれかを不能化し得る。

デコーダ、エンコーダおよびビットストリームそれぞれの可能な詳細についてさらに説明する前に、エンコーダによる拡張要素タイプでないサブストリームのフレーム要素の間に拡張要素タイプのサブストリームのフレーム要素を分散させる能力により、デコーダ３６のバッファオーバヘッドは、サブストリーム間の順序および各フレーム２０内のサブストリームのフレーム要素間の順序をそれぞれ適切に選ぶエンコーダ２４により減じられ得ることを承知されたい。たとえば、チャネル対デコーダ４４ｃに入るサブストリームは、フレーム２０内の第１の要素位置に配置され、一方、デコーダ４４ｅの多チャネルサブストリームが、各フレームの最後に配置される。この場合、デコーダ３６は、各フレーム２０の第１のフレーム要素の到来と、最後のフレーム要素との間の時間にまたがる期間、多チャネルデコーダ４４ｅのダウンミックス信号を表す中間オーディオ信号をバッファする必要があると考えられる。それで初めて多チャネルデコーダ４４ｅがその処理を開始することができる。この延期は、たとえばフレーム２０の第２の要素位置で多チャネルデコーダ４４ｅ専用のサブストリームを配列するエンコーダ２４により回避され得る。一方、ディストリビュータ４０は、サブストリームのいずれかについてそのメンバーシップに関して各フレーム要素を調べる必要はない。むしろ、ディストリビュータ４０は、コンフィギュレーションブロックおよびそこに含まれるタイプ表示構文部から単純に現在のフレーム２０の現在のフレーム要素２２のＮ個のサブストリームのいずれかに対するメンバーシップを推定することができる。

ここで、上記のとおり、コンフィギュレーションブロック２８およびフレーム２０のシーケンスを含むビットストリーム１２を示す図３を参照する。図３を見ると、右へ向かうビットストリーム部分は、左へ向かう他のビットストリーム部の位置に追随する。図３の場合、たとえば、コンフィギュレーションブロック２８は、図３に示すフレーム２０に先行するが、図３では、図示目的のみで、３つのフレーム２０のみが完全に図示される。

さらに、コンフィギュレーションブロック２８を、周期的または間欠的にフレーム２０の間でビットストリーム１２内へ挿入して、ストリーミング伝送アプリケーションにおいてランダムなアクセスポイントを設けることがきることを承知されたい。一般的には、コンフィギュレーションブロック２８は、ビットストリーム１２の単純に接続された部分でもよい。

コンフィギュレーションブロック２８は、上記のとおり、要素の数Ｎすなわち、各フレーム２０内のフレーム要素数Ｎおよびビットストリーム１２に多重化されるサブストリームの数を示すフィールド５０を含む。ビットストリーム１２の具体的な構文の実施例を記述する以下の実施例において、フィールド５０は、ｎｕｍＥｌｅｍｅｎｔｓと記され、コンフィギュレーションブロック２８は、図４ａ〜ｚおよびｚａ〜ｚｃの以下の特定の構文例においてはＵｓａｃＣｏｎｆｉｇと呼ばれる。さらに、コンフィギュレーションブロック２８は、タイプ表示構文部５２を含む。上記のとおり、この部分５２は、要素位置ごとに、複数の要素タイプの中から１つの要素タイプを示す。図３に示し、かつ、以下の特定の構文例に関しても同様に、タイプ表示構文部５２は、Ｎ個の構文要素５４のシーケンスを含むことが可能で、その各々の構文要素５４は、それぞれの要素位置の要素タイプを示し、その位置において、それぞれの構文要素５４は、タイプ表示構文部５２の内部に位置する。言い換えれば、部分５２内のｉ番目の構文要素５４は、それぞれ、ｉ番目のサブストリームの要素タイプと各フレーム２０のｉ番目のフレーム要素とを示し得る。次に具体的な構文例では、構文要素は、ＵｓａｃＥｌｅｍｅｎｔＴｙｐｅと記される。タイプ表示構文部５２は、ビットストリーム１２内に、ビットストリーム１２の単純に接続されるかまたは連続する部分として含まれ得るが、図３では、その要素５４がＮ個の要素位置の各々について個別に存在するコンフィギュレーションブロック２８の他の構文要素部と互いにかみ合って例示的に示される。以下に概略を述べる実施例では、このかみ合った構文部分は、サブストリームに特定的なコンフィギュレーションデータ５５に関連し、その意味を以下により詳細に説明する。

上記のとおり、各フレーム２０は、Ｎ個のフレーム要素２２のシーケンスから構成される。これらのフレーム要素２２の要素タイプは、フレーム要素２２自体の内部ではそれぞれのタイプ表示部により信号伝達されない。むしろ、フレーム要素２２の要素タイプは、各フレーム２０内の要素位置により規定される。フレーム２０において最初に生じるフレーム要素２２は、図３では、フレーム要素２２ａと表示され、第１の要素位置を有し、かつ、コンフィギュレーションブロック２８内の構文部５２により第１の要素位置について表示される要素タイプとなる。同じことが後続のフレーム要素２２に関して当てはまる。たとえば、ビットストリーム１２内で第１のフレーム要素２２ａの直後に生じるフレーム要素２２ｂ、すなわち要素位置２を有する要素は、構文部５２により示される要素タイプになる。

特定の実施例によれば、構文要素５４は、それらの要素が帰するフレーム要素２２と同じ順序でビットストリーム１２内で配列される。第１の構文要素５４、すなわちビットストリーム１２内で第１に発生し、かつ、図３において最も左側に位置する要素は、各フレーム２０の第１に生じるフレーム要素２２ａの要素タイプを示し、第２の構文要素５４は、第２のフレーム要素２２ｂの要素タイプを示す等ある。当然ながら、ビットストリーム１２内の構文要素５４および構文部５２のシーケンシャルな順序または配列を、フレーム２０内のフレーム要素２２のシーケンシャルな順序に関して切り替えることもできる。他の入れ替えも可能だが、あまり好ましくないと考えられる。

デコーダ３６については、これは、タイプ表示構文部５２からＮ個の構文要素５４からなるこのシーケンスを読み出すように構成され得ることを意味する。より厳密には、デコーダ３６は、ビットストリーム１２から読み出されるべき構文要素５４の数Ｎについてわかるようにフィールド５０を読み出す。上記のとおり、デコーダ３６は、ｉ番目の構文要素５４がｉ番目のフレーム要素２２と関連するように、構文要素とそれにより表示される要素タイプとをフレーム２０内のフレーム要素２２と関連付けるよう構成されてもよい。

上記の説明に加えて、コンフィギュレーションブロック２８は、Ｎ個のコンフィギュレーション要素５６のシーケンス５５を含むことが可能で、各コンフィギュレーション要素５６が、それぞれのコンフィギュレーション要素５６がＮ個のコンフィギュレーション要素５６のシーケンス５５内に位置するそれぞれの要素位置に、要素タイプについてのコンフィギュレーション情報を含む。特に、コンフィギュレーション要素５６のシーケンスがビットストリーム１２に書き込まれる（かつデコーダ３６によりビットストリーム１２から読み出される）順序は、フレーム要素２２および／または構文要素５４それぞれについて使用されるものと同じ順序でもよい。つまり、ビットストリーム１２において第１に生じるコンフィギュレーション要素５６は、第１のフレーム要素２２ａについてのコンフィギュレーション情報、第２のコンフィギュレーション要素５６、フレーム要素２２ｂについてのコンフィギュレーション情報等を含む等である。上記のとおり、タイプ表示構文部５２および要素位置に特定的なコンフィギュレーションデータ５５が、図３の実施例では、要素位置ｉに関連するコンフィギュレーション要素５６が、ビットストリーム１２において、要素位置ｉおよび要素位置ｉ＋１についてのタイプ表示部５４間に位置すると言う意味で、互いにインターリーブして示される。さらに言い換えれば、コンフィギュレーション要素５６および構文要素５４は、ビットストリームにおいて交互に配列され、そこからからデコーダ３６により交互に読み出されるが、ブロック２８内のビットストリーム１２におけるこのデータの他の位置決めも、上記のとおり可能であると考えられる。

コンフィギュレーションブロック２８において各要素位置１．．．Ｎそれぞれのコンフィギュレーション要素５６を伝達することで、ビットストリームは、異なるサブストリームおよび要素位置に属するが同じ要素タイプのフレーム要素をそれぞれ異なって構成することが可能となる。たとえば、ビットストリーム１２は、２つの単一チャネルサブストリームを含み、それに応じて各フレーム２０内に単一チャネル要素タイプの２つのフレーム要素を含み得る。しかしながら、両方のサブストリームについてコンフィギュレーション情報をビットストリーム１２において異なって調節することもできる。これは、図１のエンコーダ２４が、これらの異なるサブストリームについてコンフィギュレーション情報内に異なって符号化パラメータを設定できることを意味し、デコーダ３６の単一のチャネルデコーダ４４ｂが、これら２つのサブストリームを復号化する際、これらの異なる符号化パラメータを使用することにより制御される。これは、他の復号化モジュールにも当てはまる。より一般的には、デコーダ３６は、コンフィギュレーションブロック２８からＮ個のコンフィギュレーション要素５６のシーケンスを読出すよう構成され、ｉ番目の構文要素５４により表示される要素タイプに従って、かつ、ｉ番目のコンフィギュレーション要素５６により構成されるコンフィギュレーション情報を使用してｉ番目のフレーム要素２２を復号化する。

図示目的で、図３において、第２のサブストリーム、すなわち各フレーム２０内で第２の要素位置に発生するフレーム要素２２ｂからなるサブストリームは、拡張要素タイプのフレーム要素２２ｂからなる拡張要素タイプサブストリームを有する。当然ながら、これは説明目的のものに過ぎない。

さらに、ビットストリームまたはコンフィギュレーションブロック２８が、構文部５２により要素位置について示される要素タイプと無関係に要素位置ごとに１つのコンフィギュレーション要素５６を含むのは、図示目的のみのことである。たとえば、代替的な実施例によれば、コンフィギュレーションブロック２８によりコンフィギュレーション要素が含まれない１以上の要素タイプが存在可能で、後者の場合には、コンフィギュレーションブロック２８内のコンフィギュレーション要素５６の数は、構文部５２およびフレーム２０それぞれにおいて発生するこのような要素タイプのフレーム要素の数に依存するＮより少ない数になり得る。

いずれしても、図３は、拡張要素タイプに関連するコンフィギュレーション要素５６を構築するための他の例を示す。以下に説明する特定の構文の実施例では、これらのコンフィギュレーション要素５６は、ＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇとして示される。完全を期す目的のみで、以下に説明する特定の構文の実施例では、他の要素タイプのコンフィギュレーション要素は、ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔＣｏｎｆｉｇ、ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔＣｏｎｆｉｇおよびＵｓａｃＬｆｅＥｌｅｍｅｎｔＣｏｎｆｉｇと表示されることを承知されたい。

しかしながら、拡張要素タイプについてコンフィギュレーション要素５６の可能な構造を説明する前に、拡張要素タイプのフレーム要素の可能な構造、ここでは第２のフレーム要素２２ｂを示す図３の部分を参照する。ここに示すとおり、拡張要素タイプのフレーム要素は、それぞれのフレーム要素２２ｂの長さに関する長さ情報５８を含み得る。デコーダ３６は、各フレーム２０の拡張要素タイプの各フレーム要素２２ｂからこの長さ情報５８を読み出すよう構成される。デコーダ３６が、拡張要素タイプのこのフレーム要素が属するサブストリームを処理できないか、またはユーザの入力により処理しないよう命令された場合には、デコーダ３６は、スキップインターバル長さ、すなわちスキップすべきビットストリームの部分の長さとして長さ情報５８を使用してこのフレーム要素２２ｂをスキップする。言い換えれば、デコーダ３６は、長さ情報５８を使用して、バイト数を計算するかまたは他の適切な手段を用いてビットストリームインターバル長さを規定し、この長さは、現在のフレーム２０内の次のフレーム要素または次の後続フレーム２０の開始にアクセスまたは訪問してビットストリーム１２の読出しをさらに実行するまでスキップされることになる。

以下により詳細に説明するように、拡張要素タイプのフレーム要素は、オーディオコーデックの将来のもしくは代替的な拡張または開発に対処するよう構成され、応じて拡張要素タイプのフレーム要素は、異なる統計的長さ分布を有し得る。いくつかのアプリケーションに従ってあるサブストリームの拡張要素タイプフレーム要素は、一定の長さか、または非常に狭い統計的長さ分布を有する可能性を利用するために、本出願のいくつかの実施例では、拡張要素タイプのためのコンフィギュレーション要素５６は、図３に示すようなデフォルトペイロード長さ情報６０を含み得る。この場合、それぞれのサブストリームの拡張要素タイプのフレーム要素２２ｂが、ペイロード長さを明示的に送信する代わりに、それぞれのサブストリームについてのそれぞれのコンフィギュレーション要素５６内に含まれるデフォルトペイロード長さ情報６０を参照することができる。特に、図３に示すとおり、その場合には、デフォルトペイロード長さフラグ６４が設定されていなければ、拡張ペイロード長さ値６６が後に続くデフォルト拡張ペイロード長さフラグ６４の形で、長さ情報５８が、条件構文部６２を含み得る。拡張要素タイプのいずれかのフレーム要素２２ｂは、拡張要素タイプのそれぞれのフレーム要素２２ｂの長さ情報６２のデフォルト拡張ペイロード長さフラグ６４が設定されている場合には、対応のコンフィギュレーション要素５６において情報６０が示すデフォルト拡張ペイロード長さを有し、拡張要素タイプのそれぞれのフレーム２２ｂの長さ情報５８のデフォルト拡張ペイロード長さフラグ６４が設定されていない場合には、拡張要素タイプのそれぞれのフレーム要素２２ｂの長さ情報５８の拡張ペイロード長さ値６６に対応する拡張ペイロード長さを有する。つまり、拡張ペイロード長さ値６６の明示的な符号化は、それぞれ対応のサブストリームおよび要素位置のコンフィギュレーション要素５６内のデフォルトペイロード長さ情報６０が示すデフォルト拡張ペイロード長さを単純に参照することができる場合は常に、エンコーダ２４により回避され得る。デコーダ３６は以下のように動作する。デコーダ３６は、コンフィギュレーション要素５６の読み出しの際にデフォルトペイロード長さ情報６０を読み出す。対応のサブストリームのフレーム要素２２ｂを読み出す際には、デコーダ３６は、これらフレーム要素の長さ情報を読み出す上で、デフォルトペイロード長さフラグ６４を読み出し、かつ、これが設定されているかどうかをチェックする。デフォルトペイロード長さフラグ６４が設定されていない場合には、デコーダは、ビットストリームからの条件構文部６２の拡張ペイロード長さ値６６の読み出を続け、それぞれのフレーム要素の拡張ペイロード長さを取得する。しかしながら、デフォルトペイロードフラグ６４が設定されている場合には、デコーダ３６は、それぞれのフレームの拡張ペイロード長さを情報６０から生成されるデフォルト拡張ペイロード長さに等しくなるよう設定する。デコーダ３６をスキップすることは、スキップインターバル長さ、すなわち現在のフレーム２０の次のフレーム要素２２または次のフレーム２０の始まりにアクセスするように、スキップすべきビットストリーム１２の部分の長さとして決定されたばかりの拡張ペイロード長さを使用して現在のフレーム要素のペイロードセクション６８をスキップすることを含み得る。

したがって、上記のとおり、あるサブストリームの拡張要素タイプのフレーム要素のペイロード長さをフレームごとに繰り返し送信する事態は、これらのフレーム要素のペイロード長さの多様性がむしろ低い場合には常にフラグ機構６４を用いて回避し得る。

しかしながら、あるサブストリームの拡張要素タイプのフレーム要素により伝達されるペイロードが、フレーム要素のペイロード長さに関するそのような統計値を有するかどうか、かつ、応じて拡張要素タイプのフレーム要素のこのようなサブストリームのコンフィギュレーション要素において明示的にデフォルトペイロード長さを送信することに意義があるかどうかは、演繹的に明白ではないので、他の実施例によれば、デフォルトペイロード長さ情報６０も後続の特定の構文例においてＵｓａｃＥｘｔＥｌｅｍｅｎｔＤｅｆａｕｌｔＬｅｎｇｔｈＰｒｅｓｅｎｔと呼ばれ、かつ、デフォルトペイロード長さの明示的な送信が生じるかどうかを示すフラグ６０ａを含む条件構文部により実現される。設定されるだけで、条件構文部は、以下の特定の構文例において、ＵｓａｃＥｘｔＥｌｅｍｅｎｔＤｅｆａｕｌｔＬｅｎｇｔｈと呼ぶデフォルトペイロード長さの明示的な送信６０ｂを含む。他の態様では、デフォルトペイロード長さは、デフォルトで０に設定される。デフォルトペイロード長さの明示的な送信が回避されるので、後者の場合、ビットストリームビットの消費が節約される。すなわち、デコーダ３６（および上記および以下に記載するすべての読み出過程を引き受けるディストリビュータ４０）は、デフォルトペイロード長さ情報６０を読み出す上では、ビットストリーム１２からのデフォルトペイロード長さプレゼントフラグ６０ａを読み出し、デフォルトペイロード長さプレゼントフラグ６０ａが設定されているかどうかチェックし、デフォルトペイロード長さプレゼントフラグ６０ａが設定されていれば、デフォルト拡張ペイロード長さをゼロになるように設定し、デフォルトペイロード長さプレゼントフラグ６０ａが設定されていなければ、ビットストリーム１２（すなわちフラグ６０ａに続くフィールド６０ｂ）からデフォルト拡張ペイロード長さ６０ｂを明示的に読み出す。

デフォルトペイロード長さ機構に加えてまたはこれに対して代替的には、長さ情報５８は、拡張ペイロードプレゼントフラグ７０を含むことが可能で、その長さ情報５８の拡張ペイロードプレゼントフラグ７０がセットされていない拡張要素タイプのいずれかのフレーム２２ｂは、単に拡張ペイロードプレゼントフラグのみからなり、それだけである。つまり、ペイロードセクション６８はない。一方、その長さ情報５８のペイロードデータプレゼントフラグ７０が設定されている拡張要素タイプのなんらかのフレーム要素２２ｂの長さ情報５８は、それぞれのフレーム２２ｂの拡張ペイロード長さ、すなわちペイロードセクション６８の長さを示す構文部６２または６６をさらに含む。デフォルトペイロード長さ機構に加えて、すなわちデフォルト拡張ペイロード長さフラグ６４と組み合わせて、拡張ペイロードプレゼントフラグ７０が２つの効果的に符号化可能なペイロード長さ、すなわちゼロとデフォルトペイロード長さすなわち最も可能性の高いペイロード長さを拡張要素タイプの各フレーム要素に付与することを可能にする。

拡張要素タイプの現在のフレーム要素２２ｂの長さ情報５８を構文解析または読み出す上で、デコーダ３６は、ビットストリーム１２から拡張ペイロードプレゼントフラグ７０を読み出して、拡張ペイロードプレゼントフラグ７０が設定されているかどうかをチェックし、拡張ペイロードプレゼントフラグ７０が設定されていない場合には、それぞれのフレーム要素２２ｂの読み出しを止めて、現在のフレーム２０の他の、次のフレーム要素２２の読み出しを続けるかまたは次のフレーム２０の読み出しまたは構文解析を開始する。ペイロードデータプレゼントフラグ７０が設定されている場合には、デコーダ３６は、構文部６２かまたは少なくとも部分６６（この機構が入手可能でないので、フラグ６４が存在しない場合）を読み出し、かつ、スキップし、現在のフラグ要素２２のペイロードをスキップする場合には、スキップインターバル長さとして拡張要素タイプのそれぞれのフレーム要素２２ｂの拡張ペイロード長さを使用することによりペイロードセクション６８を読み出す。

上記のとおり、オーディオコーデックの将来の拡張または現在のデコーダが適していない他の拡張について対処するために、拡張要素タイプのフレーム要素が設けられてもよく、かつこれにより拡張要素タイプのフレーム要素を構成可能にする必要がある。特に、実施例によれば、コンフィギュレーションブロック２８が、それについてタイプ表示部５２が拡張要素タイプを示す要素位置ごとに、拡張要素タイプに関するコンフィギュレーション情報を含むコンフィギュレーション要素５６を含み、コンフィギュレーション情報が、上記の構成要素に付加的にまたは代替的に、複数のペイロードデータタイプから１つのペイロードデータタイプを示す拡張要素タイプフィールド７２を含む。複数のペイロードデータタイプは、実施例によれば、将来の開発等に備えた他のデータタイプ以外に、多チャネルサイド情報タイプおよび多オブジェクト符号化サイド情報タイプを含む。表示されるペイロードデータタイプに依存して、コンフィギュレーション要素５６は、ペイロードデータタイプに特定的なコンフィギュレーションデータをさらに含む。したがって、対応の要素位置およびそれぞれのサブストリームのフレーム要素２２ｂは、そのペイロードセクション６８で、表示されるペイロードデータタイプに対応するペイロードデータを伝達する。ペイロードタイプに特定的なコンフィギュレーションデータ７４の長さのペイロードデータタイプへの適合を図るため、かつさらなるペイロードデータタイプの将来の開発に備えるため、以下に記載する特定の構文の実施例は、現在のサブストリームについて表示されるペイロードデータタイプに気づいていないデコーダ３６が、コンフィギュレーション要素５６およびそのペイロードデータタイプに特定的なコンフィギュレーションデータ７４をスキップして、次の要素位置の要素タイプ構文要素５４（または図示しない代替の実施例においては、次の要素位置のコンフィギュレーション要素）または図４ａに示すようなコンフィギュレーションブロック２８に続く第１のフレームまたはなんらかの他のデータ等始まり等、ビットストリーム１２のすぐ後続の部分にアクセスできるように、ＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇＬｅｎｇｔｈと呼ばれるコンフィギュレーション要素長さ値をさらに含む拡張要素タイプのコンフィギュレーション要素５６を有する。特に、以下の構文に特定的な実施例では、多チャネルサイド情報コンフィギュレーションデータが、ＳｐａｔｉａｌＳｐｅｃｉｆｉｃＣｏｎｆｉｇに含まれる一方で、多オブジェクトサイド情報コンフィギュレーションデータが、ＳａｏｃＳｐｅｃｉｆｉｃＣｏｎｆｉｇに含まれる。

後者の特徴によれば、デコーダ３６は、コンフィギュレーションブロック２８を読み出す上で、タイプ表示部５２が拡張要素タイプを示す各要素位置またはサブストリームについての以下のステップを実行する。

複数の使用可能なペイロードデータタイプのうちからペイロードデータタイプを表示する拡張要素タイプフィールド７２を読み出すステップを含むコンフィギュレーション要素５６を読み出すステップ。

拡張要素タイプフィールド７２が、多チャネルサイド情報タイプを示す場合、ビットストリーム１２からのコンフィギュレーション情報の一部として多チャネルサイド情報コンフィギュレーションデータ７４を読み出し、かつ拡張要素タイプフィールド７２が多オブジェクトサイド情報タイプを示す場合には、ビットストリーム１２からのコンフィギュレーション情報の一部として多オブジェクトサイド情報コンフィギュレーションデータ７４を読み出すステップ。

そして、対応のフレーム要素２２ｂ、すなわち対応の要素位置およびサブストリームのものをそれぞれ復号化する際に、デコーダ３６は、ペイロードデータタイプが多チャネルサイド情報タイプを示す場合には、多チャネルサイド情報コンフィギュレーションデータ７４を使用して多チャネルデコーダ４４ｅを構成する一方でこうして構成された多チャネルデコーダ４４ｅにそれぞれのフレーム要素２２ｂのペイロードデータ６８を多チャネルサイド情報としてフィードし、かつペイロードデータタイプが、多オブジェクトサイド情報タイプを示す場合には、多オブジェクトサイド情報コンフィギュレーションデータ７４を使用して多オブジェクトデコーダ４４ｄを構成することにより対応のフレーム要素２２ｂを復号化し、かつ、こうして構成した多オブジェクトデコーダ４４ｄにそれぞれのフレーム要素２２ｂのペイロードデータ６８をフィードする。

しかしながら、未知のペイロードデータタイプがフィールド７２により表示された場合、デコーダ３６は、現在のコンフィギュレーション要素が含む上記のコンフィギュレーション長さ値を使用してペイロードデータタイプに特定的なコンフィギュレーションデータ７４をスキップする。

たとえば、デコーダ３６は、タイプ表示部５２が拡張要素タイプを表示するいずれかの要素位置について、それぞれの要素位置のコンフィギュレーション要素５６のコンフィギュレーション情報の一部としてビットストリーム１２からコンフィギュレーションデータ長さフィールド７６を読み出して、コンフィギュレーションデータ長さを取得し、かつ、それぞれの要素位置についてコンフィギュレーション要素のコンフィギュレーション情報の拡張要素タイプフィールド７２により示されるペイロードデータタイプが複数のペイロードデータタイプのサブセットであるペイロードデータタイプの予め定められたセットに属するかどうかをチェックする。それぞれの要素位置についてのコンフィギュレーション要素のコンフィギュレーション情報の拡張要素タイプフィールド７２により示されるペイロードデータタイプが予め定められたペイロードデータタイプのセットに属する場合には、デコーダ３６は、データストリーム１２からそれぞれの要素位置についてのコンフィギュレーション要素のコンフィギュレーション情報の一部としてペイロードデータに依存するコンフィギュレーションデータ７４を読出し、ペイロードデータに依存するコンフィギュレーションデータ７４を使用して、フレーム２０におけるそれぞれの要素位置の拡張要素タイプのフレーム要素を復号化する。しかしながら、それぞれの要素位置についてコンフィギュレーション要素のコンフィギュレーション情報の拡張要素タイプフィールド７２により表示されるペイロードデータタイプが、予め定められたペイロードデータタイプのセットに属していない場合には、デコーダはコンフィギュレーションデータ長を使用してペイロードデータに依存するコンフィギュレーションデータ７４をスキップし、かつ内部の長さ情報５８を使用してフレーム２０におけるそれぞれの要素位置で拡張要素タイプのフレーム要素をスキップする。

上記の機構に付加的にまたは代替的に、あるサブストリームのフレーム要素は、完全にフレームごと１つではなく、フラグメントで送信されるよう構成することもできる。たとえば、拡張要素タイプのコンフィギュレーション要素は、フラグメンテーション使用フラグ７８を含むことが可能であり、デコーダは、タイプ表示部が拡張要素タイプを示し、かつ、コンフィギュレーション要素のフラグメンテーション使用フラグ７８が設定されたいずれかの要素位置にあるフレーム要素２２を読み出す上で、ビットストリーム１２からのフラグメント情報８０を読み出して、フラグメント情報を利用して、連続するフレームのこれらのフレーム要素のペイロードデータを結合するよう構成され得る。以下の特定の構文例では、フラグメンテーション使用フラグ７８が設定されるサブストリームの各拡張タイプフレーム要素は、サブストリームのペイロードの開始を表示するスタートフラグとサブストリームのペイロードアイテムの終了を表示する終了フラグとからなる対を含む。これらのフラグは、以下の特定の構文例では、ｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｔａｒｔおよびｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｔｏｐと呼ばれる。

さらに、上記の機構に付加的にまたは代替的に、同じ可変長さコードを、長さ情報８０、拡張要素タイプフィールド７２およびコンフィギュレーションデータ長さフィールド７６を読み出すために使用することが可能で、それにより、たとえば、デコーダを実装するための複雑性が低下し、かつ、将来の拡張要素タイプ、より長い拡張要素タイプ長さ等のめったに発生しないケースにのみ追加のビットが必要になるようにすることにより、ビットを節約することができる。以下に説明する具体的な例では、このＶＬＣコードは、図４ｍから導出可能である。

上記を要約すると、以下のことがデコーダの機能性に当てはまり得る。
（１）コンフィギュレーションブロック２８を読み出すステップ。

（２）フレーム２０のシーケンスの読出し／構文解析ステップ。ステップ１および２は、デコーダ３６およびより厳密にはディストリビュータ４０により実行される。

（３）オーディオコンテントの再構成は、これらのサブストリーム、すなわち要素位置におけるこれらのフレーム要素のシーケンスに限定され、その復号化は、デコーダ３６によりサポートされる。ステップ３は、たとえばデコーダ３６内においてその復号化モジュールで実行される（図２を参照）。

したがって、ステップ１では、デコーダ３６は、サブストリームの数５０およびフレーム２０ごとのフレーム要素２２の数ならびにこれらのサブストリームおよび要素位置の各々の要素タイプをそれぞれ明らかにする要素タイプ構文部５２を読み出す。ステップ２において、ビットストリームを構文解析するために、デコーダ３６は、ビットストリーム１２からのフレーム２０のシーケンスのフレーム要素２２を周期的に読み出す。そうすることで、デコーダ３６は、上記のとおり長さ情報５８を使用して、フレーム要素またはその残余／ペイロード部分をスキップする。第３のステップでは、デコーダ３６は、スキップされなかったフレーム要素を復号化することにより再構成を行う。

ステップ２において、要素位置およびサブストリームのうちどれをスキップするかを決定する際に、デコーダ３６は、コンフィギュレーションブロック２８内でコンフィギュレーション要素５６を調べることが可能である。そうするために、デコーダ３６は、要素タイプ表示部５４およびフレーム要素２２自体に使用したのと同じ順序でビットストリーム１２のコンフィギュレーションブロック２８からコンフィギュレーション要素５６を周期的に読み出すように構成され得る。上記のとおり、コンフィギュレーション要素５６の周期的な読み出しは、構文要素５４の周期的な読み出しをインターリーブされることも可能である。特に、デコーダ３６は、拡張要素タイプサブストリームのコンフィギュレーション要素５６内の拡張要素タイプフィールド７２を調べることができる。拡張要素タイプがサポートされているものでなければ、デコーダ３６は、それぞれのサブストリームおよびフレーム２０内のそれぞれのフレーム要素位置で対応のフレーム要素２２をスキップする。

長さ情報５８の送信に必要なビットレートを緩和するために、デコーダ３６は、拡張要素タイプサブストリームのコンフィギュレーション要素５６、かつ特にステップ１におけるそのデフォルトペイロード長さ情報６０を調べるよう構成される。第２のステップで、デコーダ３６は、スキップすべき拡張フレーム要素２２の長さ情報５８を調べる。特に、まず、デコーダ３６がフラグ６４を調べる。設定されている場合には、デコーダ３６は、残りのスキップすべきペイロード長さとしてデフォルトペイロード長さ情報６０によりそれぞれのサブストリームについて表示されるデフォルト長さを使用して、フレームのフレーム要素の周期的な読み出し／構文解析に続ける。しかしながら、フラグ６４が設定されていなければ、デコーダ３６は、ビットストリーム１２から明示的にペイロード長さ６６を読み出す。上では明示的には説明していないが、現在のフレームの次のフレーム要素または次のフレームにアクセスするためにデコーダ３６が、なんらかの付加的な計算により、スキップすべきビットまたはバイト数を導出し得る。たとえば、デコーダ３６が、フラグ７８に関して説明したように、フラグメンテーション機構が活性かどうかを考慮に入れることが可能である。活性であれば、デコーダ３６は、フラグ７８が設定されているサブストリームのフレーム要素は、いずれにしてもフラグメンテーション情報８０を有し、したがって、フラグメンテーションフラグ７８が設定されていない場合に考えられるようにペイロードデータ６８が後程開始することを考慮に入れることができる。

ステップ３の復号化において、デコーダは通常とおり作用する。すなわち、個別のサブストリームが、図２に示すようにそれぞれの復号化機構または復号化モジュールの対象となり、いくつかのサブストリームは、拡張サブストリームの特定の例に関して上に述べたように他のサブストリームに対してサイド情報を構成し得る。

デコーダ機能性に関する他の可能な詳細に関しては、上記の説明を参照する。完全を期すためにのみ、たとえば、フィールド７２により表示される拡張要素タイプが、サポートされる拡張要素タイプのセットに適合しないため、デコーダ３６はステップ１のコンフィギュレーション要素５６のさらなる構文解析を、スキップすべきそれらの要素位置について、スキップすることもできる点を承知されたい。そして、デコーダ３６は、コンフィギュレーション要素５６の周期的な読み出し／構文解析において、それぞれのコンフィギュレーション要素をスキップするために、すなわち、それぞれの数のビット／バイトをスキップする上で、次の要素位置のタイプ表示部５４等の次のビットストリーム構文要素にアクセスするために、コンフィギュレーション長さ情報７６を使用し得る。

上記の特定の構文の実施例を続ける前に、本発明が、音声音響統合符号化と、ＡＣＣのような周波数領域符号化と、パラメトリック符号化（ＡＣＥＬＰ）および変換符号化（ＴＣＸ）を使用するＬＰ符号化との間で両者を組み合わせたものまたは切り替えるものを用いた切替コア符号化のようなその局面とによる実現に限定されないことを承知されたい。むしろ、上記のサブストリームは、いずれかの符号化スキームを使用するオーディオ信号に相当し得る。また、以下に説明する特定の構文の実施例においては、ＳＢＲが単一チャネルおよびチャネル対要素タイプのサブストリームを使用してオーディオ信号を表すために使用されるコアコーデックの符号化オプションであることを想定する一方、ＳＢＲは、後者の要素タイプのオプションではなく単に拡張要素タイプを使用して使用可能としてもよい。

以下では、ビットストリーム１２の特定の構文例について説明する。なお、特定の構文例とは、図３の実施例の可能な実現例に相当しかつ以下の構文の構文と図３のビットストリームの構造との間の一致が、図３のそれぞれの表記および図３の説明から示されるかまたは導きだされる。以下の特定の例の基本的な特徴について、ここで概略を説明する。この点に関して、図３に関連して上にすでに述べた事柄に加えて追加の詳細については、図３の実施例の可能な延長として承知されたい。これら拡張のすべてが、図３の実施例に個別に構築され得る。最後の予備的な説明として、以下に説明する特定の構文例は、図５ａおよび図５ｂにそれぞれ示すデコーダおよびエンコーダ環境を明示的に参照する点を理解されたい。

含まれるオーディオコンテントについてのサンプリングレート、正確なチャネルコンフィギュレーションのような高レベルの情報が、オーディオビットストリーム内に存在する。このためビットストリームはより自立的になり、この情報を明示的に伝送する手段を有し得ない伝達スキームに埋め込まれる場合、コンフィギュレーションおよびペイロードの伝達は確実により容易になる。

このコンフィギュレーション構造は、組合せフレーム長およびＳＢＲサンプリングレートレート比インデクス（ｃｏｒｅＳｂｒＦｒａｍｅＬｅｎｇｔｈＩｎｄｅｘ）を含む。これにより、両方の値の効率的伝送が保証され、かつフレーム長およびＳＢＲ比の無意味な組み合わせの信号伝達が確実にできないようになる。後者は、デコーダの実装をより簡素化する。

コンフィギュレーションを、専用のコンフィギュレーション拡張機構により拡張することができる。これにより、ＭＰＥＧ−４ ＡｕｄｉｏＳｐｅｃｉｆｉｃＣｏｎｆｉ（）から既知のコンフィギュレーション拡張の嵩高く非効率的な伝送が防止される。

コンフィギュレーションは、伝送されるオーディオチャネル各々と関連するラウドスピーカ位置の自由な信号伝達を可能にする。一般に使用されるチャネルからラウドスピーカへのマッピングを信号伝達することは、ｃｈａｎｎｅｌＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘにより効率的に行うことができる。

各チャネル要素のコンフィギュレーションは、各チャネル要素が独立して構成できるように、別の構造に含まれる。

ＳＢＲコンフィギュレーションデータ（「ＳＢＲヘッダ」）は、ＳｂｒＩｎｆｏ（）とＳｂｒＨｅａｄｅｒ（）とに分けられる。ＳｂｒＨｅａｄｅｒ（）については、デフォルトのバ−ジョンが定義され（ＳｂｒＤｆｌｔＨｅａｄｅｒ（））、これをビットストリームにおいて効率的に参照することができる。これにより、ＳＢＲコンフィギュレーションデータの再送信が必要とされる場所におけるビット要求を減じられる。

より一般的にＳＢＲに適用されるコンフィギュレーションの変更は、ＳｂｒＩｎｆｏ（）構文要素の補助により効率的に信号伝達することができる。

パラメータ帯域幅拡張（ＳＢＲ）およびパラメータステレオ符号化ツール（ＭＰＳ２１２、別名ＭＰＥＧサラウンド２−１−２）のためのコンフィギュレーションは、ＵＳＡＣコンフィギュレーション構造にしっかり統合される。これは、両方の技術が実際に標準において採用されるより良い態様を表す。

この構文は、コーデックに対する既存および将来の拡張の伝送を可能にする拡張機構を特徴とする。

これらの拡張は、いずれかの順序でチャネル要素と共に配置（すなわちインターリーブ）され得る。これは、拡張の適用対象である特定のチャネル要素の前または後で読み出すことが必要な拡張を可能にする。

デフォルトの長さを、構文拡張について規定でき、これにより一定長さの拡張の伝送が非常に効率的になる。この場合、拡張ペイロードの長さを毎回伝送する必要がないからである。

必要に応じ値の範囲を拡大するためエスケープ機構の補助により値を信号伝達する一般的な場合は、希望するエスケープ値のコンステレーションおよびビットフィールド拡張すべてをカバーするのに十分な柔軟性を有する専用の純粋な構文要素（ｅｓｃａｐｅｄＶａｌｕｅ（））にモジュール化されていた。

ビットストリームコンフィギュレーション
ＵｓａｃＣｏｎｆｉｇ（）（図４ａ）
ＵｓａｃＣｏｎｆｉｇ（）は、含まれるオーディオコンテントおよび完全なデコーダセットアップのために必要なものすべてについての情報を含むよう拡張されていた。オーディオについてのトップレベルの情報（サンプリングレート、チャネルコンフィギュレーション、出力フレーム長）は、より高い（アプリケーション）レイヤからのアクセスを容易にするために始まりに集められる。

ＵｓａｃＣｈａｎｎｅｌＣｏｎｆｉｇ（）（図４ｂ）
これらの要素は、含まれるビットストリーム要素およびそれらのラウドスピーカへのマッピングについての情報を付与する。ｃｈａｎｎｅｌＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘにより、実際に関連あると考えられた予め定義されるモノ、ステレオまたは多チャネルコンフィギュレーションの範囲から１つを信号伝達する容易で便利な方法が可能になる。

ｃｈａｎｎｅｌＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘによりカバーされないより複雑なコンフィギュレーションについては、ＵｓａｃＣｈａｎｎｅｌＣｏｎｆｉｇ（）により、家庭やシネマサウンド再生用の既知のスピーカセットアップのすべてにおける現在知られている全スピーカ位置をカバーする３２のスピーカ位置のリストからラウドスピーカ位置への要素の自由な割り当てが図られる。

スピーカ位置のこのリストは、ＭＰＥＧサラウンド標準（ＩＳＯ／ＩＥＣ２３００３−１における表１および図１を参照）における特徴であるリストのスーパーセットである。最近導入された２２．２スピーカセットアップをカバーすることができるように４つの追加のスピーカ位置が追加されている（図３ａ、図３ｂ、図４ａおよび図４ｂを参照）。

ＵｓａｃＤｅｃｏｄｅｒＣｏｎｆｉｇ（）（図４ｃ）
この要素は、デコーダコンフィギュレーションの中心にあり、したがって、デコーダがビットストリームを解釈するために必要なすべての追加情報を含む。

特に、ビットストリームの構造はここでは、要素の数およびビットストリームにおけるそれらの順序を明示的に述べることにより規定される。

全要素にわたるループにより、全タイプ（単一、対、ｌｆｅ、拡張）の全要素のコンフィギュレーションを可能にする。

ＵｓａｃＣｏｎｆｉｇＥｘｔｅｎｓｉｏｎ（）（図４ｌ）
将来の拡張について対処するため、コンフィギュレーションは、ＵＳＡＣのいまだ存在しないコンフィギュレーション拡張のために、コンフィギュレーションを拡張する強力な機構を特徴とする。

ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔＣｏｎｆｉｇ（）（図４ｄ）
この要素コンフィギュレーションは、１つの単一チャネルを復号化するデコーダを構成するために必要な情報すべてを含む。これは、本質的にはコアコーダ関連情報であり、ＳＢＲが使用される場合には、ＳＢＲ関連情報である。

ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔＣｏｎｆｉｇ（）（図４ｅ）
上記と同様、この要素コンフィギュレーションは、１つのチャネル対を復号化するデコーダを構成するために必要な情報すべてを含む。上記のコアｃｏｎｆｉｇおよびＳＢＲコンフィギュレーションに加えて、これは適用されるステレオ符号化の正確な種類（ＭＰＳ２１２、残差の有無等）のようなステレオ専用のコンフィギュレーションを含む。なお、この要素は、ＵＳＡＣにおいて入手可能な全種類のステレオ符号化オプションをカバーする。

ＵｓａｃＬｆｅＥｌｅｍｅｎｔＣｏｎｆｉｇ（）（図４ｆ）
ＬＦＥ要素コンフィギュレーションは、ＬＦＥ要素が静的コンフィギュレーションを有するのでコンフィギュレーションデータを含まない。

ＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇ（）（図４ｋ）
この要素コンフィギュレーションは、コーデックに対するいずれかの種類の既存のまたは将来の拡張を構成するために使用され得る。各拡張要素のタイプは、それ自体の専用ＩＤ値を有する。デコーダには未知のコンフィギュレーション拡張を都合よくスキップすることができるように、長さフィールドが含まれる。デフォルトペイロード長さの随意の規定により、実際のビットストリームに存在する拡張ペイロードの符号化効率をさらに向上する。

ＵＳＡＣと組み合わされることがすでに予見される拡張には、ＭＰＥＧ−４ＡＡＣから知られるようなＭＰＥＧサラウンド、ＳＡＯＣおよびなんらかのＦＩＬ要素を含む。

ＵｓａｃＣｏｒｅＣｏｎｆｉｇ（）（図４ｇ）
この要素は、コアコーダセットアップにインパクトを有するコンフィギュレーションデータを含む。現在、これらは、時間ワープツールおよびノイズフィリングツールのためのスィッチである。

ＳｂｒＣｏｎｆｉｇ（）（図４ｈ）
ｓｂｒ＿ｈｅａｄｅｒ（）を頻繁に再送信することにより生成されるビットオーバヘッドを減らすため、典型的には一定に維持されるｓｂｒ＿ｈｅａｄｅｒ（）の要素のためのデフォルト値を、コンフィギュレーション要素ＳｂｒＤｆｌｔＨｅａｄｅｒ（）において保持する。さらに、静的ＳＢＲコンフィギュレーション要素もＳｂｒＣｏｎｆｉｇ（）において保持する。これらの静的ビットには、高調波トランスポジションまたはインタＴＥＳ等のエンハンストＳＢＲの特定の特徴を可能かまたは不能化するフラグを含む。

ＳｂｒＤｆｌｔＨｅａｄｅｒ（）（図４ｉ）
これは、典型的には一定に維持されるｓｂｒ＿ｈｅａｄｅｒ（）の要素を保持する。振幅分解能、クロスオーババンド、スペクトル予備平坦化等に影響を及ぼす要素は、ここで、実行中にこれらを効率的に変更し得るＳｂｒＩｎｆｏ（）において保持される。

Ｍｐｓ２１２Ｃｏｎｆｉｇ（）（図４ｊ）
上記ＳＢＲコンフィギュレーションと同様に、ＭＰＥＧサラウンド２−１−２ツールのための全セットアップパラメータが、このコンフィギュレーションにおいてアセンブルされる。このコンテクストにおいて関連がないかまたは冗長なＳｐａｔｉａｌＳｐｅｃｉｆｉｃＣｏｎｆｉｇ（）からの要素はすべて除去される。

ビットストリームペイロード
ＵｓａｃＦｒａｍｅ（）（図４ｎ）
これは、ＵＳＡＣビットストリームペイロードの最も外側のラッパでかつＵＳＡＣアクセス単位を表す。それは、ｃｏｎｆｉｇ部で信号伝達される、含まれるチャネル要素および拡張要素すべてにわたるループを含む。これは、含み得るものという意味でビットストリームフォーマットをより柔軟にし、かつ、何らかの将来の拡張に対しても将来的に使用可能である。

ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔ（）（図４ｏ）
この要素は、モノストリームを復号化するための全データを含む。コンテントは、コアコーダに関連する部分とｅＳＢＲに関連する部分に分かれる。後者は、より密接にコアに接続され、デコーダが必要とするデータの順序をよりよく反映する。

ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔ（）（図４ｐ）
この要素は、ステレオ対を符号化するためのすべての可能な方法についてのデータをカバーする。特に、旧式のＭ／Ｓ系符号化からＭＰＥＧサラウンド２−１−２の補助による完全なパラメータステレオ符号化まで、統合されたステレオ符号化のフレーバのすべてをカバーする。ｓｔｅｒｅｏＣｏｎｆｉｇＩｎｄｅｘは、どのフレーバが実際に使用されるかを示す。適切なｅＳＢＲデータおよびＭＰＥＧサラウンド２−１−２データをこの要素において送る。

ＵｓａｃＬｆｅＥｌｅｍｅｎｔ（図４ｑ）
以前のｌｆｅ＿ｃｈａｎｎｅｌ＿ｅｌｅｍｅｎｔ（）は、一貫したネーミングスキームに従うためにのみ再ネーミングされる。

ＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）（図４ｒ）
この拡張要素は、小さいペイロードを有する（またはしばしば全くペイロードがない場合も）拡張についてさえ、最大限の柔軟性が得られしかも同時に最大限効率的になり得るよう慎重に設計された。不可知のデコーダがスキップするよう拡張のペイロード長が信号伝達される。ユーザが定義する拡張については、拡張のタイプの予備範囲により信号伝達することができる。拡張は要素の順序で自由に配置することができる。拡張要素の範囲は、フィルバイトを書き込むための機構を含めてすでに考慮されている。

ＵｓａｃＣｏｒｅＣｏｄｅｒＤａｔａ（）（図４ｓ）
この新しい要素は、コアコーダに影響を与える情報のすべてを要約し、かつまたそれによりｆｄ＿ｃｈａｎｎｅｌ＿ｓｔｒｅａｍ（）’ｓおよびｌｐｄ＿ｃｈａｎｎｅｌ＿ｓｔｒｅａｍ（）’ｓも含む。

ＳｔｅｒｅｏＣｏｒｅＴｏｏｌＩｎｆｏ（）（図４ｔ）
構文の読出し性を緩和するために、ステレオ関連情報のすべてがこの要素に捕捉された。これは、ステレオ符号化モードにおける多数のビットの依存性を扱うものである。

ＵｓａｃＳｂｒＤａｔａ（）（図４ｘ）
ＣＲＣ機能性およびスケーリング可能なオーディオ符号化の古い記述要素は、かつてｓｂｒ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ（）要素だったものから除去された。ＳＢＲｉｎｆｏおよびヘッダデータの頻繁な再送信が原因で生じるオーバヘッドを減らすために、これらの存在は、明示的に信号伝達され得る。

ＳｂｒＩｎｆｏ（）（図４ｙ）
実行中に頻繁に修正されるＳＢＲコンフィギュレーションデータ。これは、振幅分解能、クロスオーババンド、スペクトルの予備平坦化等の以前は完全なｓｂｒ＿ｈｅａｄｅｒ（）の送信を必要とした事項を制御する要素を含む（［Ｎ１１６６０］の６．３「効率」を参照）。

ＳｂｒＨｅａｄｅｒ（）（図４ｚ）
実行中にｓｂｒ＿ｈｅａｄｅｒ（）の値を変更するＳＢＲの能力を維持するために、ここでは、ＳｂｒＤｆｌｔＨｅａｄｅｒ（）において送られるもの以外の値を使用する必要がある場合には、ＵｓａｃＳｂｒＤａｔａ（）内部にＳｂｒＨｅａｄｅｒを保持することができる。最も一般的な場合のために、オーバヘッドをできるだけ低く保つため、ｂｓ＿ｈｅａｄｅｒ＿ｅｘｔｒａ機構は維持された。

ｓｂｒ＿ｄａｔａ（）（図４ｚａ）
ここでも、ＵＳＡＣコンテクストでは適用不可能なため、ＳＢＲスケーリング可能符号化の残余が取り除かれている。チャネルの数によって、ｓｂｒ＿ｄａｔａ（）は、１つのｓｂｒ＿ｓｉｎｇｌｅ＿ｃｈａｎｎｅｌ＿ｅｌｅｍｅｎｔ（）または１つのｓｂｒ＿ｃｈａｎｎｅｌ＿ｐａｉｒ＿ｅｌｅｍｅｎｔ（）を含む。

ｕｓａｃＳａｍｐｌｉｎｇＦｒｅｑｕｅｎｃｙＩｎｄｅｘ
この表は、オーディオコーディックのサンプリング周波数を信号伝達するためにＭＰＥＧ−４において使用される表のスーパーセットである。この表は、現在ＵＳＡＣ動作モードにおいて使用されるサンプリングレートをカバーするためにもさらに拡張されている。いくつかのサンプリング周波数の倍数も加えられている。

ｃｈａｎｎｅｌＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ
この表は、ｃｈａｎｎｅｌＣｏｎｆｉｇｕｒａｔｉｏｎを信号伝達するためにＭＰＥＧ−４において使用される表のスーパーセットである。これをさらに拡張して、一般的に使用されかつ将来に見込まれるラウドスピーカのセットアップの信号伝達が可能にされている。この表内へのインデクスを５ビットで信号伝達して、将来の拡張を図る。

ｕｓａｃＥｌｅｍｅｎｔＴｙｐｅ
４つ要素タイプのみが存在する。４つの基本的ビットストリーム要素：ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔ（）、ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔ（）、ＵｓａｃＬｆｅＥｌｅｍｅｎｔ（）およびＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）の各々について１つである。これらの要素は、必要とされる柔軟性をすべて維持しながら、必要なトップレベルの構造を提供する。

ｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅ
ＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）の内部で、この要素は、過剰な拡張の信号伝達を可能にする。将来も使い続けられるよう、考えられるすべての拡張を可能にするのに十分な広さのビットフィールドが選択されている。現在既知の拡張のうち、いくつかが考慮の対象として提案されている。フィル要素、ＭＰＥＧサラウンドおよびＳＡＯＣである。

ｕｓａｃＣｏｎｆｉｇＥｘｔＴｙｐｅ
ある時点で、コンフィギュレーションを拡張することが必要であれば、新しいコンフィギュレーションごとにタイプを割り当てることが可能なＵｓａｃＣｏｎｆｉｇＥｘｔｅｎｓｉｏｎ（）により対処することができる。現在、信号伝達可能な唯一のタイプは、コンフィギュレーションのためのフィル機構である。

ｃｏｒｅＳｂｒＦｒａｍｅＬｅｎｇｔｈＩｎｄｅｘ
この表は、デコーダの複数のコンフィギュレーション特性を信号伝達する。特に、これらは、出力フレーム長、ＳＢＲ比および結果として得られるコアコーダフレーム長（ｃｃｆｌ）である。同時に、ＳＢＲにおいて使用されるＱＭＦ解析および合成帯域数も示す。

ｓｔｅｒｅｏＣｏｎｆｉｇＩｎｄｅｘ
この表は、ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔ（）の内部構造を決定する。モノまたはステレオコアの使用、ＭＰＳ２１２の使用、ステレオＳＢＲが適用されるかどうかおよび残差符号化がＭＰＳ２１２において適用されるかどうかを示す。

ｅＳＢＲヘッダフィールドの大部分をデフォルトヘッダフラグで参照することができるデフォルトヘッダへ移動させることにより、ｅＳＢＲ制御データ送信のビット要求は、かなり減じられる。実世界のシステムで変化すると考えられていた以前のｓｂｒ＿ｈｅａｄｅｒ（）ビットフィールドは、現在最大８ビットをカバーする４要素のみから構成されるｓｂｒＩｎｆｏ（）要素へアウトソースされている。１８ビット以上から構成されるｓｂｒ＿ｈｅａｄｅｒ（）と比較すると、１０ビットの節約になる。

ビットレート全体に対するこの変化のインパクトを評価することはより困難である。これは、ｓｂｒＩｎｆｏ（）におけるｅＳＢＲ制御データの伝送レートに大きく依存するためである。しかしながら、ビットストリームにおいてｓｂｒクロスオーバが変更される一般的使用の場合についてはすでに、このビットの節約は、完全に伝送されるｓｂｒ＿ｈｅａｄｅｒ（）の代わりにｓｂｒＩｎｆｏ（）を送る場合、一回ごとに２２ビットにもなり得る。

ＵＳＡＣデコーダの出力をＭＰＥＧサラウンド（ＭＰＳ）（ＩＳＯ／ＩＥＣ２３００３−１）またはＳＡＯＣ（ＩＳＯ／ＩＥＣ２３００３−２）によりさらに処理できる。ＵＳＡＣにおけるＳＢＲツールが活性の場合、ＵＳＡＣデコーダは典型的には、ＩＳＯ／ＩＥＣ２３００３−１４．４におけるＨＥ−ＡＡＣについて記述されるのと同じやりかたで、ＱＭＦ領域においてそれらを接続することにより、後続のＭＰＳ／ＳＡＯＣデコーダと効率的に組み合わせることができる。ＱＭＦ領域における接続が不可能な場合は、時間領域において接続する必要がある。

ＭＰＳ／ＳＡＯＣサイド情報がｕｓａｃＥｘｔＥｌｅｍｅｎｔ機構（ｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅがＩＤ＿ＥＸＴ＿ＥＬＥ＿ＭＰＥＧＳまたはＩＤ＿ＥＸＴ＿ＥＬＥ＿ＳＡＯＣである）によりＵＳＡＣビットストリームに埋め込まれる場合、ＵＳＡＣデータとＭＰＳ／ＳＡＯＣデータ間のタイムアラインメントは、ＵＳＡＣデコーダとＭＰＳ／ＳＡＯＣデコーダ間の最も効率的接続を想定する。ＵＳＡＣにおけるＳＢＲツールが活性でかつＭＰＳ／ＳＡＯＣが６４帯域ＱＭＦ領域表現（ＩＳＯ／ＩＥＣ２３００３−１ ６.６.３）を採用する場合には、最も効率的接続はＱＭＦ領域におけるものである。それ以外では、最も効率的接続は時間領域におけるものである。これは、ＩＳＯ／ＩＥＣ２３００３−１ ４．４、４．５および７．２．１において規定されるＨＥ−ＡＡＣおよびＭＰＳの組み合わせについてのタイムアラインメントに対応する。

ＵＳＡＣ復号化の後にＭＰＳ復号化を追加することにより導入される追加の遅延は、ＩＳＯ／ＩＥＣ２３００３−１ ４．５により得られ、かつ、ＨＱ ＭＰＳまたはＬＰ ＭＰＳが使用されるかどうか、およびＱＭＦ領域かまたは時間領域においてＭＰＳがＵＳＡＣに接続されるかに依存する。

ＩＳＯ／ＩＥＣ２３００３−１ ４．４は、ＵＳＡＣとＭＰＥＧシステムとの間のインタフェースを明確にする。システムインターフェースからオーディオデコーダに伝達される各アクセス単位は、システムインターフェースすなわちコンポジタにオーディオデコーダから送られる対応の成分の単位となる。これは、スタートアップおよびシャットダウン条件、すなわちアクセス単位がアクセス単位の有限のシーケンスにおける最初または最後のものである場合を含む。

オーディオ構成単位については、ＩＳＯ／ＩＥＣ１４４９６−１ ７．１．３．５コンポジションタイムスタンプ（ＣＴＳ）が、構成時間が構成単位内のｎ番目のオーディオサンプルに当てはまることを特定する。ＵＳＡＣでは、ｎの値は常に１である。なお、これは、ＵＳＡＣデコーダ自体の出力にも適用される。ＵＳＡＣデコーダがたとえば、ＭＰＳデコーダと組み合わされている場合を、ＭＰＳデコーダの出力で伝達される構成単位について配慮する必要がある。

ＭＰＳ／ＳＡＯＣサイド情報を、ｕｓａｃＥｘｔＥｌｅｍｅｎｔ機構によりＵＳＡＣビットストリームに埋め込む場合（ｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅはＩＤ＿ＥＸＴ＿ＥＬＥ＿ＭＰＥＧＳまたはＩＤ＿ＥＸＴ＿ＥＬＥ＿ＳＡＯＣで）、以下の制限を随意に適用しても良い。

・ＭＰＳ／ＳＡＯＣ ｓａｃＴｉｍｅＡｌｉｇｎパラメータ（ＩＳＯ／ＩＥＣ２３００３−１ ７．２．５を参照）は値０に。

・ＭＰＳ／ＳＡＯＣのサンプリング周波数はＵＳＡＣの出力サンプリング周波数と同じに。

・ＭＰＳ／ＳＡＯＣ ｂｓＦｒａｍｅＬｅｎｇｔｈパラメータ（ＩＳＯ／ＩＥＣ２３００３−１ ５．２を参照）は、予め定められたリストのうちの許容される値の１つを有する。

ＵＳＡＣビットストリームペイロード構文は、図４ｎ〜４ｒに示され、かつ補足的ペイロード要素の構文は、図４ｓ〜ｗに示され、かつエンハンストＳＢＲペイロード構文は図４ｘ〜４ｚｃに示される。

データ要素の簡単な説明
ＵｓａｃＣｏｎｆｉｇ（）
この要素は、含まれるオーディオコンテントおよび完全なデコーダセットアップに必要なすべてについての情報を含む。

ＵｓａｃＣｈａｎｎｅｌＣｏｎｆｉｇ（）
この要素は、含まれるビットストリーム要素およびそれらのラウドスピーカへのマッピングについての情報を付与する。

ＵｓａｃＤｅｃｏｄｅｒＣｏｎｆｉｇ（）
この要素は、デコーダがビットストリームを解釈するために必要な他のすべての情報を含む。特に、ＳＢＲ再サンプリング比がここで信号伝達され、かつビットストリームの構造が、ここでは、ビットストリームにおける要素の数およびそれらの順序を明示的に述べることにより規定される。

ＵｓａｃＣｏｎｆｉｇＥｘｔｅｎｓｉｏｎ（）
ＵＳＡＣの将来のコンフィギュレーション拡張のためコンフィギュレーションを拡張するコンフィギュレーション拡張機構。

ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔＣｏｎｆｉｇ（）
１つの単一チャネルを復号化するようデコーダを構成するために必要なすべての情報を含む。これは、本質的にコアコーダに関連する情報であり、かつ、ＳＢＲが使用される場合には、ＳＢＲ関連情報である。

ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔＣｏｎｆｉｇ（）
上記と同様、この要素コンフィギュレーションは、１つのチャネル対を復号化するようデコーダを構成するために必要なすべての情報を含む。上記のコアｃｏｎｆｉｇおよびｓｂｒコンフィギュレーションに加えて、これは、適用されるステレオ符号化の正確な種類（ＭＰＳ２１２、残差等の有無）等のステレオに特定的なコンフィギュレーションを含む。この要素は、ＵＳＡＣにおいて現在使用可能なステレオ符号化オプションのすべての種類をカバーする。

ＵｓａｃＬｆｅＥｌｅｍｅｎｔＣｏｎｆｉｇ（）
ＬＦＥ要素コンフィギュレーションは、ＬＦＥ要素が静的コンフィギュレーションを有するので、コンフィギュレーションデータを含まない。

ＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇ（）
この要素コンフィギュレーションは、いずれかの種類の既存または将来の拡張をコーデックに対して構成するために使用することができる。各拡張要素タイプは、その独自の専用タイプ値を有する。デコーダに未知のコンフィギュレーション拡張をスキップできるように、長さフィールドが含まれる。

ＵｓａｃＣｏｒｅＣｏｎｆｉｇ（）
コアコーダセットアップに対してインパクトのあるコンフィギュレーションデータを含む。

ＳｂｒＣｏｎｆｉｇ（）
典型的には一定に維持されるｅＳＢＲのコンフィギュレーション要素のためのデフォルト値を含む。さらに、静的ＳＢＲコンフィギュレーション要素をＳｂｒＣｏｎｆｉｇ（）内に保持する。これらの静的ビットは、高調波トランスポジションまたはインタＴＥＳ等のエンハンストＳＢＲの特定の特徴を可能化または不能化するためのフラグを含む。

ＳｂｒＤｆｌｔＨｅａｄｅｒ（）
この要素は、ＳｂｒＨｅａｄｅｒ（）の要素について異なる値を希望しない場合に参照することができるこられの要素のデフォルトバージョンを保持する。

Ｍｐｓ２１２Ｃｏｎｆｉｇ（）
ＭＰＥＧサラウンド２−１−２ツールのためのすべてのセットアップパラメータは、このコンフィギュレーションにおいてアセンブルされる。

ｅｓｃａｐｅｄＶａｌｕｅ（）
この要素は、可変数のビットを使用して整数値を送信する一般的な方法を実現する。追加ビットの連続送信により表現可能な値の範囲を拡大することができる２レベルエスケープ機構を特徴とする。

ｕｓａｃＳａｍｐｌｉｎｇＦｒｅｑｕｅｎｃｙＩｎｄｅｘ
このインデクスは、復号化後のオーディオ信号のサンプリング周波数を決定する。ｕｓａｃＳａｍｐｌｉｎｇＦｒｅｑｕｅｎｃｙＩｎｄｅｘの値および関連のサンプリング周波数を表Ｃに示す。

ｕｓａｃＳａｍｐｌｉｎｇＦｒｅｑｕｅｎｃｙ
ｕｓａｃＳａｍｐｌｉｎｇＦｒｅｑｕｅｎｃｙＩｎｄｅｘ＝０である場合、符号のついていない整数値として符号化されるデコーダの出力サンプリング周波数。

ｃｈａｎｎｅｌＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ
このインデクスは、チャネルコンフィギュレーションを決定する。ｃｈａｎｎｅｌＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ＞０の場合、インデクスは、表Ｙに従って、チャネルの数、チャネル要素および関連のラウドスピーカマッピングを明白に規定する。ラウドスピーカの位置の名称、使用される略称および利用可能なラウドスピーカの一般的な位置を図３ａ、図３ｂ、図４ａおよび図４ｂから推定することができる。

ｂｓＯｕｔｐｕｔＣｈａｎｎｅｌＰｏｓ
このインデクスは、表ＸＸに従う所与のチャネルに関連するラウドスピーカの位置を記述する。図Ｙは、リスナの３Ｄ環境におけるラウドスピーカの位置を示す。ラウドスピーカの位置をより容易に理解するため、表ＸＸは、関心のある読者への情報としてここに挙げるＩＥＣ１００／１７０６／ＣＤＶによるラウドスピーカ位置も含む。

ｕｓａｃＣｏｎｆｉｇＥｘｔｅｎｓｉｏｎＰｒｅｓｅｎｔ
コンフィギュレーションに対する拡張の存在を示す。

ｎｕｍＯｕｔＣｈａｎｎｅｌｓ
ｃｈａｎｎｅｌＣｏｎｆｉｇｒａｔｉｏｎＩｎｄｅｘの値が、予め規定されたチャネルコンフィギュレーションのどれも使用されないことを示す場合には、この要素が、特定のラウドスピーカ位置が関連付けられるオーディオチャネルの数を決定する。

ｎｕｍＥｌｅｍｅｎｔｓ
このフィールドは、ＵｓａｃＤｅｃｏｄｅｒＣｏｎｆｉｇ（）におけるループオーバ要素のタイプにおいてフォローする要素の数を含む。

ｕｓａｃＥｌｅｍｅｎｔＴｙｐｅ［ｅｌｅｍＩｄｘ］
ビットストリームにおける位置ｅｌｅｍＩｄｘの要素のＵＳＡＣチャネル要素タイプを規定する。４つの要素タイプが存在し、この４つの基本ビットストリーム要素、ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔ（）、ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔ（）, ＵｓａｃＬｆｅＥｌｅｍｅｎｔ（）、およびＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）の各々について１つ存在する。これらの要素は、必要なトップレベルの構造を付与する一方で、必要とされる柔軟性のすべてを維持する。ｕｓａｃＥｌｅｍｅｎｔＴｙｐｅの意味を表Ａに定義する。

ｓｔｅｒｅｏＣｏｎｆｉｇＩｎｄｅｘ
この要素は、ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔ（）の内部構造を決定する。表ＺＺによれば、これは、モノまたはステレオコアの使用、ＭＰＳ２１２の使用、ステレオＳＢＲ適用の有無およびＭＰＳ２１２における残差符号化適用の有無を示す。この要素はまたヘルパー要素であるｂｓＳｔｅｒｅｏＳＢＲおよびｂｓＲｅｓｉｄｕａｌＣｏｄｉｎｇの値も規定する。

ｔｗ＿ｍｄｃｔ
このフラグは、このストリーム内で時間ワープしたＭＤＣＴの使用を信号伝達する。

ｎｏｉｓｅＦｉｌｌｉｎｇ
このフラグは、ＦＤコアデコーダにおけるスペクトルホールのノイズフィリングの使用を信号伝達する。

ｈａｒｍｏｎｉｃＳＢＲ
このフラグは、ＳＢＲのための高調波パッチングの使用を信号伝達する。

ｂｓ＿ｉｎｔｅｒＴｅｓ
このフラグは、ＳＢＲにおけるインタＴＥＳツールの使用を信号伝達する。

ｄｆｌｔ＿ｓｔａｒｔ＿ｆｒｅｑ
これは、フラグｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒが、ＳｂｒＨｅａｄｅｒ（）要素のデフォルト値が想定されることを示す場合に付与されるビットストリーム要素ｂｓ＿ｓｔａｔ＿ｆｒｅｑのデフォルト値である。

ｄｆｌｔ＿ｓｔｏｐ＿ｆｒｅｑ
これは、フラグｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒが、ＳｂｒＨｅａｄｅｒ（）要素のデフォルト値が想定されることを示す場合に付与されるビットストリーム要素ｂｓ＿ｓｔоｐ＿ｆｒｅｑのデフォルト値である。

ｄｆｌｔ＿ｈｅａｄｅｒ＿ｅｘｔｒａ1
これは、ＳｂｒＨｅａｄｅｒ（）要素のデフォルト値が想定されることをフラグｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒが示す場合に付与されるビットストリーム要素ｂｓ＿ｈｅａｄｅｒ＿ｅｘｔｒａ１のデフォルト値である。

ｄｆｌｔ＿ｈｅａｄｅｒ＿ｅｘｔｒａ２
これは、ＳｂｒＨｅａｄｅｒ（）要素のデフォルト値が想定されることをフラグｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒが示す場合に付与されるビットストリーム要素ｂｓ＿ｈｅａｄｅｒ＿ｅｘｔｒａ２のデフォルト値である。

ｄｆｌｔ＿ｆｒｅｑ＿ｓｃａｌｅ
これは、ＳｂｒＨｅａｄｅｒ（）要素のデフォルト値が想定されることをフラグｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒが示す場合に付与されるビットストリーム要素ｂｓ＿ｆｒｅｑ＿ｓｃａｌｅのデフォルト値である。

ｄｆｌｔ＿ａｌｔｅｒ＿ｓｃａｌｅ
これは、ＳｂｒＨｅａｄｅｒ（）要素のデフォルト値が想定されることをフラグｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒが示す場合に付与されるビットストリーム要素ｂｓ＿ａｌｔｅｒ＿ｓｃａｌｅのデフォルト値である。

ｄｆｌｔ＿ｎｏｉｓｅ＿ｂａｎｄｓ
これは、ＳｂｒＨｅａｄｅｒ（）要素のデフォルト値が想定されることをフラグｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒが示す場合に付与されるビットストリーム要素ｂｓ＿ｎｏｉｓｅ＿ｂａｎｄｓのデフォルト値である。

ｄｆｌｔ＿ｌｉｍｉｔｅｒ＿ｂａｎｄｓ
これは、ＳｂｒＨｅａｄｅｒ（）要素のデフォルト値が想定されることをフラグｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒが示す場合に付与されるビットストリーム要素ｂｓ＿ｌｉｍｉｔｅｒ＿ｂａｎｄｓのデフォルト値である。

ｄｆｌｔ＿ｌｉｍｉｔｅｒ＿ｇａｉｎｓ
これは、ＳｂｒＨｅａｄｅｒ（）要素のデフォルト値が想定されることをフラグｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒが示す場合に付与されるビットストリーム要素ｂｓ＿ｌｉｍｉｔｅｒ＿ｇａｉｎｓのデフォルト値である。

ｄｆｌｔ＿ｉｎｔｅｒｐｏｌ＿ｆｒｅｑ
これは、ＳｂｒＨｅａｄｅｒ（）要素のデフォルト値が想定されることをフラグｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒが示す場合に付与されるビットストリーム要素ｂｓ＿ｉｎｔｅｒｐｏｌ＿ｆｒｅｑのデフォルト値である。

ｄｆｌｔ＿ｓｍｏｏｔｈｉｎｇ＿ｍｏｄｅ
これは、ＳｂｒＨｅａｄｅｒ（）要素のデフォルト値が想定されることをフラグｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒが示す場合に付与されるビットストリーム要素ｂｓ＿ｓｍｏｏｔｈｉｎｇ＿ｍｏｄｅのデフォルト値である。

ｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅ
この要素は、ビットストリーム拡張タイプの信号伝達を可能にする。ｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅの意味を、表Ｂにおいて定義する。

ｕｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇＬｅｎｇｔｈ
バイト（オクテット）で拡張コンフィギュレーションの長さを信号伝達する。

ｕｓａｃＥｘｔＥｌｅｍｅｎｔＤｅｆａｕｌｔＬｅｎｇｔｈＰｒｅｓｅｎｔ
このフラグはｕｓａｃＥｘｔＥｌｅｍｅｎｔＤｅｆａｕｌｔＬｅｎｇｔｈがＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇ（）で運ばれるかどうかを信号伝達する。

ｕｓａｃＥｘｔＥｌｅｍｅｎｔＤｅｆａｕｌｔＬｅｎｇｔｈ
拡張要素のデフォルト長をバイトで信号伝達する。所与のアクセス単位における拡張要素がこの値からそれている場合にのみ、ビットストリームにおいて追加の長さを伝送する必要がある。この要素が明示的に伝送されない場合（ｕｓａｃＥｘｔＥｌｅｍｅｎｔＤｅｆａｕｌｔＬｅｎｇｔｈＰｒｅｓｅｎｔ＝＝0）、ｕｓａｃＥｘｔＥｌｅｍｅｎｔＤｅｆａｕｌｔＬｅｎｇｔｈの値がゼロに設定される。

ｕｓａｃＥｘｔＥｌｅｍｅｎｔＰａｙｌｏａｄＦｒａｇ
このフラグは、この拡張要素のペイロードが分割されて連続するＵＳＡＣフレームにおいていくつかのセグメントとして送られ得るかどうかを示す。

ｎｕｍＣｏｎｆｉｇＥｘｔｅｎｓｉｏｎｓ
コンフィギュレーションへの拡張が、ＵｓａｃＣｏｎｆｉｇ（）に存在する場合には、この値は、信号伝達されるコンフィギュレーション拡張の数を示す。

ｃｏｎｆＥｘｔＩｄｘ
コンフィギュレーション拡張へのインデクス。

ｕｓａｃＣｏｎｆｉｇＥｘｔＴｙｐｅ
この要素は、コンフィギュレーション拡張タイプを信号伝達することを可能にする。ｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅの意味は、表Ｄにおいて定義される。

ｕｓａｃＣｏｎｆｉｇＥｘｔＬｅｎｇｔｈ
バイト（オクテット）でコンフィギュレーション拡張の長さを信号伝達する。

ｂｓＰｓｅｕｄｏＬｒ
このフラグは、逆ｍｉｄ／ｓｉｄｅ回転をＭｐｓ２１２処理の前にコア信号に適用すべきであることを信号伝達する。

ｂｓＳｔｅｒｅｏＳｂｒ
このフラグは、ＭＰＥＧサラウンド復号化と組み合わせたステレオＳＢＲの使用を信号伝達する。

ｂｓＲｅｓｉｄｕａｌＣｏｄｉｎｇ
残差符号化を下の表に従って適用するかどうかを示す。ｂｓＲｅｓｉｄｕａｌＣｏｄｉｎｇの値は、ｓｔｅｒｅｏＣｏｎｆｉｇＩｎｄｅｘ（Ｘを参照）により定義される。

ｓｂｒＲａｔｉｏＩｎｄｅｘ
コアサンプリングレートとｅＳＢＲ処理後のサンプリングレートとの比率を示す。同時に、下の表によるＳＢＲにおいて使用されるＱＭＦ解析および合成帯域の数を示す。

ｅｌｅｍＩｄｘ
ＵｓａｃＤｅｃｏｄｅｒＣｏｎｆｉｇ（）およびＵｓａｃＦｒａｍｅ（）に存在する要素へのインデクス。

ＵｓａｃＣｏｎｆｉｇ（）
ＵｓａｃＣｏｎｆｉｇ（）は、出力サンプリング周波数およびチャネルコンフィギュレーションについての情報を含む。この情報は、ＭＰＥＧ-４ＡｕｄｉｏＳｐｅｃｉｆｉｃＣｏｎｆｉｇ（）等におけるこの要素の外部に信号伝達される情報と同じになる。

Ｕｓａｃ出力サンプリング周波数
サンプリングレートが表１の右欄に列挙するレートの１つではない場合、サンプリング周波数に依拠する表（コード表、スケールファクタ帯域表等）を推定して、ビットストリームペイロードを構文解析する必要がある。所与のサンプリング周波数は１つのサンプリング周波数表とだけ関連付けられており、かつ、可能なサンプリング周波数の範囲においては最大の柔軟性が望まれるので、以下の表を使用して、暗示されるサンプリング周波数を希望のサンプリング周波数に依拠する表と関連付ける。

ＵｓａｃＣｈａｎｎｅｌＣｏｎｆｉｇ（）
チャネルコンフィギュレーション表は、最も一般的なラウドスピーカ位置をカバーする。他のフレキシビリティチャネルについては、様々なアプリケーションにおける現代のラウドスピーカセットアップに見られる全部で３２のラウドスピーカ一位置の選択肢へマッピングすることができる（図３ａ、図３ｂを参照）。

ビットストリームに含まれる各チャネルについては、ＵｓａｃＣｈａｎｎｅｌＣｏｎｆｉｇ（）が、この特定のチャネルをマッピングする関連のラウドスピーカ位置を特定する。ｂｓＯｕｔｐｕｔＣｈａｎｎｅｌＰｏｓが指し示すラウドスピーカ位置について、表Ｘに列挙する。複数のチャネル要素の場合には、ｂｓＯｕｔｐｕｔＣｈａｎｎｅｌＰｏｓ［ｉ］のインデクスｉが、ビットストリームにおいてチャネルが現れる位置を示す。図Ｙは、リスナに関係するラウドスピーカの位置に関する概略を示す。

より正確には、チャネルはそれらがビットストリームに現れる順に０（ゼロ）からナンバリングされる。ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔ（）またはＵｓａｃＬｆｅＥｌｅｍｅｎｔ（）の平凡な例では、チャネル番号がそのチャネルに割り当てられ、かつ、チャネルカウントは１つ増加する。ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔ（）の場合には、その要素における最初のチャネルが第１にナンバリングされ（インデクスｃｈ＝＝０）、同じ要素における第２のチャネル（インデクスｃｈ＝＝１）は、次のより高い番号を受け、かつ、チャネルカウントが２つ増加する。

次に、ｎｕｍＯｕｔＣｈａｎｎｅｌｓが、ビットストリームに含まれる全チャネルの累積合計以下になる。全チャネルの累積合計が、全ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔ（）’ｓの数＋全ＵｓａｃＬｆｅＥｌｅｍｅｎｔ（）’ｓの数＋２×全ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔ（）’ｓの数に等しい。

ビットストリームにおけるラウドスピーカの位置を二重に割り当てないように、アレイｂｓＯｕｔｐｕｔＣｈａｎｎｅｌＰｏｓにおける全エントリを相互に異ならせる。

ｃｈａｎｎｅｌＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘが０であり、かつ、ｎｕｍＯｕｔＣｈａｎｎｅｌｓがビットストリームに含まれる全チャネルの累積合計より小さいという特別な場合には、割り当てられていないチャネルの扱いは、本件明細書の範囲外のものとなる。これに関する情報については、たとえば、より高いアプリケーションレイヤにおける適切な手段により、または詳細に設計された（プライベートな）拡張ペイロードにより伝達できる。

ＵｓａｃＤｅｃｏｄｅｒＣｏｎｆｉｇ（）
ＵｓａｃＤｅｃｏｄｅｒＣｏｎｆｉｇ（）は、ビットストリームを解釈するのにデコーダが必要とする他の情報のすべてを含む。まず、ｓｂｒＲａｔｉｏＩｎｄｅｘの値がコアコーダフレーム長（ｃｃｆｌ）と出力フレーム長との比を決定する。ｓｂｒＲａｔｉｏＩｎｄｅｘの後は、現在のビットストリームにおいて全チャネル要素にわたるループが続く。各繰り返しについて、要素のタイプがｕｓａｃＥｌｅｍｅｎｔＴｙｐｅ［］において信号伝達され、直後に対応のコンフィギュレーション構造が続く。ＵｓａｃＤｅｃｏｄｅｒＣｏｎｆｉｇ（）において様々な要素が存在する順序は、ＵｓａｃＦｒａｍｅ（）における対応のペイロードの順序と同じになる。

要素の各インスタンスを独立して構成することができる。ＵｓａｃＦｒａｍｅ（）における各チャネル要素を読み出す際に、要素ごとに、そのインスタンスすなわち同じｅｌｅｍＩｄｘの対応のコンフィギュレーションを使用する。

ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔＣｏｎｆｉｇ（）
ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔＣｏｎｆｉｇ（）は、１つの単一チャネルを復号化するためのデコーダを構成するために必要な全情報を含む。ＳＢＲコンフィギュレーションデータは、ＳＢＲが実際に採用された場合にのみ送信される。

ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔＣｏｎｆｉｇ（）
ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔＣｏｎｆｉｇ（）は、コアコーダ関連のコンフィギュレーションデータおよびＳＢＲの使用に依拠するＳＢＲコンフィギュレーションデータを含む。ステレオ符号化アルゴリズムの正確なタイプについては、ｓｔｅｒｅｏＣｏｎｆｉｇＩｎｄｅｘにより示される。ＵＳＡＣにおいては、チャネル対が様々な態様で符号化できる。それらは、

１． ＭＤＣＴ領域において複雑予測の可能性により拡張される伝統的ジョイントステレオ符号化技術を使用するステレオコアコーダ対

２． 完全なパラメータステレオ符号化のためのＭＰＥＧサラウンドベースのＭＰＳ２１２と組み合わせたモノコアコーダチャネル。モノＳＢＲ処理をコア信号に適用する。

３． 第１のコアコーダチャネルがダウンミックス信号を保持し、かつ、第２のチャネルが残差信号を保持するＭＰＥＧサラウンドベースのＭＰＳ２１２と組み合わせたステレオコアコーダ対。残差部を帯域制限して部分残差符号化を実現してもよい。モノＳＢＲ処理は、ＭＰＳ２１２処理の前のダウンミックス信号にのみ適用される。

４． 第１のコアコーダチャネルがダウンミックス信号を保持し、かつ、第２のチャネルが残差信号を保持するＭＰＥＧサラウンドベースのＭＰＳ２１２と組み合わせるステレオコアコーダ対。残差部は、帯域を制限して部分残差符号化を実現してもよい。ステレオＳＢＲをＭＰＳ２１２処理後の再構成されたステレオ信号に適用する。

選択肢の３と４とをコアデコーダ後の疑似ＬＲチャネル回転とさらに組み合わせてもよい。

ＵｓａｃＬｆｅＥｌｅｍｅｎｔＣｏｎｆｉｇ（）
時間ワープしたＭＤＣＴおよびノイズフィリングの使用はＬＦＥチャネルについては許容されていないので、これらのツールについて通常のコアコーダフラグを送信する必要はない。その代り、これらはゼロに設定される。

また、ＬＦＥコンテクストにおけるＳＢＲの使用は、許容されておらず、意味もない。そのため、ＳＢＲコンフィギュレーションデータは送信されない。

ＵｓａｃＣｏｒｅＣｏｎｆｉｇ（）
ＵｓａｃＣｏｒｅＣｏｎｆｉｇ（）は、グローバルビットストリームレベルでの時間ワープしたＭＤＣＴおよびスペクトルノイズフィリングの使用を可能化または不能化するフラグのみを含む。ｔｗ＿ｍｄｃｔがゼロに設定されると、時間ワープは適用されない。ｎоｉｓｅＦｉｌｌｉｎｇがゼロに設定されると、スペクトルノイズフィリングは適用されない。

ＳｂｒＣｏｎｆｉｇ（）
ＳｂｒＣｏｎｆｉｇ（）ビットストリーム要素は、正確なｅＳＢＲセットアップパラメータを信号伝達する目的を果たす。一方、ＳｂｒＣｏｎｆｉｇ（）は、ｅＳＢＲツールの一般的な採用を信号伝達する。他方、ＳｂｒＣｏｎｆｉｇ（）は、ＳｂｒＨｅａｄｅｒ（）のデフォルトバージョンであるＳｂｒＤｆｌｔＨｅａｄｅｒ（）を含む。異なるＳｂｒＨｅａｄｅｒ（）がビットストリームにおいて送信されなければ、このデフォルトヘッダの値が想定されることになる。このメカニズムの背景には、１つのビットストリームにおいては、典型的には１セットのＳｂｒＨｅａｄｅｒ（）値しか付与されないことがある。ＳｂｒＤｆｌｔＨｅａｄｅｒ（）の送信で、ビットストリームにおける１つのビットのみを使用することにより非常に効率的にこのデフォルト値のセットを参照することが可能になる。ビットストリーム自体における新たなＳｂｒＨｅａｄｅｒをインバンドで送信できるようにすることで、依然として、実行中にＳｂｒＨｅａｄｅｒの値を変更する可能性は保持される。

ＳｂｒＤｆｌｔＨｅａｄｅｒ（）
ＳｂｒＤｆｌｔＨｅａｄｅｒ（）は、基本ＳｂｒＨｅａｄｅｒ（）テンプレートと呼んでもよいもので、主に使用されるｅＳＢＲコンフィギュレーションのための値を含む必要がある。ビットストリームにおいて、このコンフィギュレーションは、ｓｂｒＵｓｅＤｆｌｔＨｅａｄｅｒフラグを設定することにより参照することができる。ＳｂｒＤｆｌｔＨｅａｄｅｒ（）の構造は、ＳｂｒＨｅａｄｅｒ（）のものと同様である。ＳｂｒＤｆｌｔＨｅａｄｅｒ（）およびＳｂｒＨｅａｄｅｒ（）の値を区別できるように、ＳｂｒＤｆｌｔＨｅａｄｅｒ（）におけるビットフィールドは、「ｂｓ＿」の代わりに「ｄｆｌｔ」を接頭辞にする。ＳｂｒＤｆｌｔＨｅａｄｅｒ（）の使用が表示されると、ＳｂｒＨｅａｄｅｒ（）ビットフィールドは、対応のＳｂｒＤｆｌｔＨｅａｄｅｒ（）の値を想定する。すなわち、以下のとおりである。

ｂｓ＿ｓｔａｒｔ＿ｆｒｅｑ＝ｄｆｌｔ＿ｓｔａｒｔ＿ｆｒｅｑ；
ｂｓ＿ｓｔｏｐ＿ｆｒｅｑ＝ｄｆｌｔ＿ｓｔｏｐ＿ｆｒｅｑ；ｅｔｃ．
（ｂｓ＿ｘｘｘ＿ｙｙｙ＝ｄｆｌｔ＿ｘｘｘ＿ｙｙｙのように、ＳｂｒＨｅａｄｅｒ（）におけるすべての要素について続く）。

Ｍｐｓ２１２Ｃｏｎｆｉｇ（）
Ｍｐｓ２１２Ｃｏｎｆｉｇ（）は、ＭＰＥＧサラウンドのＳｐａｔｉａｌＳｐｅｃｉｆｉｃＣｏｎｆｉｇ（）に類似し、かつ、多くの部分において、それから推定されていた。しかしながら、ＵＳＡＣコンテクストにおけるモノからステレオへのアップミキシングについて関連のある情報のみを含むと言う範囲まで狭められる。結果として、ＭＰＳ２１２は、１つのＯＴＴボックスのみを構成する。

ＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇ（）
ＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇ（）は、ＵＳＡＣのための拡張要素のコンフィギュレーションデータ用の一般的なコンテナである。各ＵＳＡＣ拡張は、独自のタイプ識別子であるｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅを有し、これは表Ｘにおいて定義される。各ＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇ（）ごとに、含まれる拡張コンフィギュレーションの長さを可変ｕｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇＬｅｎｇｔｈにおいて送信し、含まれる拡張コンフィギュレーションの長さによって、デコーダが、そのｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅが未知である拡張要素を安全にスキップできる。

典型的に一定のペイロード長を有するＵＳＡＣ拡張については、ＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇ（）が、ｕｓａｃＥｘｔＥｌｅｍｅｎｔＤｅｆａｕｌｔＬｅｎｇｔｈの送信を可能にする。コンフィギュレーションにおいてデフォルトのペイロード長さを規定することで、ビット消費を低く抑える必要があるＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）内でｕｓａｃＥｘｔＥｌｅｍｅｎｔＰａｙｌｏａｄＬｅｎｇｔｈの高度に効率的な信号伝達が可能になる。

多量のデータを蓄積し、フレームごとではなくフレーム２つごとのみにまたはもっと頻度を低くして送信するＵＳＡＣ拡張の場合、このデータはいくつかのＵＳＡＣフレームにわたって広がるフラグメントまたはセグメントで送信されてもよい。これは、ビットレザバをより均一に保つために有用である。このメカニズムの使用は、ｕｓａｃＥｘｔＥｌｅｍｅｎｔＰａｙｌｏａｄＦｒａｇフラグにより信号伝達される。フラグメンテーションのメカニズムについては、６．２．ＸのｕｓａｃＥｘｔＥｌｅｍｅｎｔの記述においてさらに説明する。

ＵｓａｃＣｏｎｆｉｇＥｘｔｅｎｓｉｏｎ（）
ＵｓａｃＣｏｎｆｉｇＥｘｔｅｎｓｉｏｎ（）は、ＵｓａｃＣｏｎｆｉｇ（）の拡張のための一般的なコンテナである。デコーダ初期化またはセットアップ時に交換される情報を補正または拡張する便利な方法を提供する。ｃｏｎｆｉｇ拡張の存在はｕｓａｃＣｏｎｆｉｇＥｘｔｅｎｓｉｏｎＰｒｅｓｅｎｔにより示される。ｃｏｎｆｉｇ拡張が存在する場合（ｕｓａｃＣｏｎｆｉｇＥｘｔｅｎｓｉｏｎＰｒｅｓｅｎｔ＝＝1）、ビットフィールドｎｕｍＣｏｎｆｉｇＥｘｔｅｎｓｉｏｎｓにおいて、これらの拡張の正確な数が続く。各コンフィギュレーション拡張は、表Ｘで定義される独自のタイプ識別子ｕｓａｃＣｏｎｆｉｇＥｘｔＴｙｐｅを有する。各ＵｓａｃＣｏｎｆｉｇＥｘｔｅｎｓｉｏｎについて、含まれるコンフィギュレーション拡張の長さは、可変のｕｓａｃＣｏｎｆｉｇＥｘｔＬｅｎｇｔｈにおいて送信され、かつ、コンフィギュレーションビットストリーム構文解析部が、そのｕｓａｃＣｏｎｆｉｇＥｘｔＴｙｐｅが不明であるコンフィギュレーション拡張を安全にスキップできるようにする。

オーディオオブジェクトタイプＵＳＡＣのトップレベルペイロード
用語および定義

ＵｓａｃＦｒａｍｅ（）
このデータのブロックは、１つのＵＳＡＣフレームの期間についてのオーディオデータ、関連情報および他のデータを含む。ＵｓａｃＤｅｃｏｄｅｒＣｏｎｆｉｇ（）において信号伝達されるように、ＵｓａｃＦｒａｍｅ（）は、ｎｕｍＥｌｅｍｅｎｔ要素を含む。これらの要素は１また２チャネルについてのオーディオデータ、低周波数エンハンスメントのためのオーディオデータまたは拡張ペイロードを含み得る。

ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔ（）
略称はＳＣＥ。単一のオーディチャネルのための符号化データを含むビットストリームの構文要素。ｓｉｎｇｌｅ＿ｃｈａｎｎｅｌ＿ｅｌｅｍｅｎｔ（）は、基本的に、ＦＤまたはＬＰＤコアコーダのためのデータを含むＵｓａｃＣｏｒｅＣｏｄｅｒＤａｔａ（）からなる。ＳＢＲが活性の場合には、ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔもＳＢＲデータを含む。

ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔ（）
略称はＣＰＥ。チャネル対についてのデータを含むビットストリームペイロードの構文要素。チャネル対は、２つのディスクリートなチャネルを送信するかまたは１つのディスクリートなチャネルおよび関連のＭｐｓ２１２ペイロードのいずれかにより達成され得る。これは、ｓｔｅｒｅｏＣｏｎｆｉｇＩｎｄｅｘにより信号伝達される。ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔはＳＢＲが活性の場合にはＳＢＲデータをさらに含む。

ＵｓａｃＬｆｅＥｌｅｍｅｎｔ（）
略称はＬＦＥ。低サンプリング周波数エンハンスメントチャネルを含む構文要素。ＬＦＥは常にｆｄ＿ｃｈａｎｎｅｌ＿ｓｔｒｅａｍ（）要素を使用して符号化される。

ＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）
拡張ペイロードを含む構文要素。拡張要素の長さがコンフィギュレーション（ＵＳＡＣＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇ（））においてデフォルト長さとして信号伝達されるかまたはＵｓａｃＥｘｔＥｅｌｅｍｅｎｔ（）自体において信号伝達される。存在すれば、拡張ペイロードは、コンフィギュレーションにおいて信号伝達されるようなタイプｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅである。

ｕｓａｃＩｎｄｅｐｅｎｄｅｎｃｙＦｌａｇ
下の表に従って、現在のＵｓａｃＦｒａｍｅ（）が以前のフレームからの情報の知識なしに完全に復号化できるかどうかを表示する。

注：ｕｓａｃＩｎｄｅｐｅｎｄｅｎｃｙＦｌａｇの使用に関する推奨に関してはＸＹを参照ください。

ｕｓａｃＥｘｔＥｌｅｍｅｎｔＵｓｅＤｅｆａｕｌｔＬｅｎｇｔｈ
拡張要素の長さが、ＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇ（）に規定されたｕｓａｃＥｘｔＥｌｅｍｅｎｔＤｅｆａｕｌｔＬｅｎｇｔｈに対応するかどうかを示す。

ｕｓａｃＥｘｔＥｌｅｍｅｎｔＰａｙｌｏａｄＬｅｎｇｔｈ
バイトで表す拡張要素の長さを含む。この値は、現在のアクセス単位における拡張要素の長さがデフォルト値であるｕｓａｃＥｘｔＥｌｅｍｅｎｔＤｅｆａｕｌｔＬｅｎｇｔｈから偏移する場合、ビットストリームにおいて明示的に送信する必要があるのみである。

ｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｔａｒｔ
現在のｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｅｇｍｅｎｔＤａｔａがデータブロックを開始するかどうかを示す。

ｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｔｏｐ
現在のｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｅｇｍｅｎｔＤａｔａがデータブロックを終了するかどうかを示す。

ｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｅｇｍｅｎｔＤａｔａ
ｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｔａｒｔ＝＝１のＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）から始まり、ｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｔｏｐ＝＝１のＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）まで（これを含んで）連続するＵＳＡＣフレームのＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）からの全ｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｅｇｍｅｎｔＤａｔａの連結が１つのデータブロックを構成する。完全なデータブロックが１つのＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）に含まれる場合には、ｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｔａｒｔおよびｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｔｏｐの両方が１に設定される。データブロックは、下の表によるｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅに依存するバイト単位でそろえられた拡張ペイロードとして解釈される。

ｆｉｌｌ＿ｂｙｔｅ
情報を保持しないビットを有するビットストリームをパディングするために使用され得るビットのオクテット。ｆｉｌｌ＿ｂｙｔｅに使用される正確なビットパターンは、「１０１００１０１」である必要がある。

ヘルパー要素
ｎｒＣｏｒｅＣｏｄｅｒＣｈａｎｎｅｌｓ
チャネル対要素のコンテクストにおいては、この変数は、ステレオ符号化のための基礎を構成するコアコーダチャネルの数を示す。ｓｔｅｒｅｏＣｏｎｆｉｇＩｎｄｅｘの値によって、この値は１または２になる。

ｎｒＳｂｒＣｈａｎｎｅｌｓ
チャネル対要素のコンテクストにおいては、この変数はＳＢＲ処理が適用されるチャネルの数を示す。ｓｔｅｒｅｏＣｏｎｆｉｇＩｎｄｅｘの値によって、この値は１または２になる。

ＵＳＡＣについての補足的ペイロード
用語および定義

ＵｓａｃＣｏｒｅＣｏｄｅｒＤａｔａ（）
このデータブロックは、コアコーダオーディオデータを含む。ペイロード要素は、ＦＤまたはＬＰＤモード用のいずれかの１つまたは２つのコアコーダチャネルのためのデータを含む。特定のモードは、要素の開始にチャネルごとに信号伝達される。

ＳｔｅｒｅｏＣｏｒｅＴｏｏｌＩｎｆｏ（）
すべてのステレオ関連の情報は、この要素において捕捉される。ステレオ符号化モードにおけるビットフィールドの多数の依存性を扱う。

ヘルパー要素
ｃоｍｍоｎＣｏｒｅＭｏｄｅ
ＣＰＥにおいて、このフラグは、両方の符号化コアコーダチャネルが同じモードを使用するかどうか示す。

Ｍｐｓ２１２Ｄａｔａ（）
このデータブロックは、Ｍｐｓ２１２ステレオモジュールのためのペイロードを含む。このデータの存在は、ｓｔｅｒｅоＣｏｎｆｉｇＩｎｄｅｘに依存する。

ｃｏｍｍｏｎ＿ｗｉｎｄｏｗ
ＣＰＥのチャネル０およびチャネル１が同じウィンドウパラメータを使用するかどうかを示す。

ｃｏｍｍｏｎ＿ｔｗ
ＣＰＥのチャネル０およびチャネル１が時間ワープしたＭＤＣＴについて同じパラメータを使用するかどうかを示す。

ＵｓａｃＦｒａｍｅ（）の復号化
１つのＵｓａｃＦｒａｍｅ（）は、ＵＳＡＣビットストリームの１つのアクセス単位を構成する。各ＵｓａｃＦｒａｍｅが、表から決定されるｏｕｔｐｕｔＦｒａｍｅＬｅｎｇｔｈに従って、７６８、１０２４、２０４８または４０９６の出力サンプルに復号化する。

ＵｓａｃＦｒａｍｅ（）における第１のビットは、所与のフレームが以前のフレームについて何らの知識がなくても復号化され得るかどうかを決定するｕｓａｃＩｎｄｅｐｅｎｄｅｎｃｙＦｌａｇである。ｕｓａｃＩｎｄｅｐｅｎｄｅｎｃｙＦｌａｇが、０に設定されると、以前のフレームに対する依存性が現在のフレームのペイロード内に存在する可能性がある。

ＵｓａｃＦｒａｍｅ（）はさらに、ＵｓａｃＤｅｃｏｄｅｒＣｏｎｆｉｇ（）における対応のコンフィギュレーション要素と同じ順序でビットストリームに現れる１以上の構文要素からなる。全要素の連続における各要素の位置については、ｅｌｅｍＩｄｘにより指し示される。各要素については、そのインスタンスの、すなわち同じｅｌｅｍＩｄｘを有するＵｓａｃＤｅｃｏｄｅｒＣｏｎｆｉｇ（）において送信されるような対応のコンフィギュレーションを使用する。

これらの構文要素は、表Ｘに挙げる４つのタイプのうちの１つである。これらの要素の各々のタイプは、ｕｓａｃＥｌｅｍｅｎｔＴｙｐｅにより判別される。同じタイプの複数の要素が存在する可能性がある。異なるフレームの同じ位置ｅｌｅｍＩｄｘに生じる要素は、同じストリームに属することになる。

これらビットストリームペイロードが一定レートのチャネルにわたって送信される場合、それらはID＿ＥＸＴ＿ＥＬＥ＿ＦＩＬＬのｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅを有する拡張ペイロード要素を含んで、瞬間のビットレートを調整する可能性がある。この場合、符号化されたステレオ信号の例は、以下のとおりである。

ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔ（）の復号化
ＵｓａｃＳｉｎｇｌｅＣｈａｎｎｅｌＥｌｅｍｅｎｔ（）の単純な構造は、１に設定されたｎｒＣｏｒｅＣｏｄｅｒＣｈａｎｎｅｌｓを有するＵｓａｃＣｏｒｅＣｏｄｅｒＤａｔａ（）の１つのインスタンスから構成される。この要素のｓｂｒＲａｔｉｏＩｎｄｅｘにより、ＵｓａｃＳｂｒＤａｔａ（）要素はこれも１に設定されたｎｒＳｂｒＣｈａｎｎｅｌで続く。

ＵｓａｃＥｘｔＥｅｌｅｍｅｎｔ（）の復号化
ビットストリームにおけるＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）構造を、ＵＳＡＣデコーダにより復号化またはスキップすることができる。各拡張は、ＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）’ｓの関連のＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇ（）において伝達されるｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅにより識別される。各ｕｓａｃＥｘｔＥｌｅｍｅｎｔＴｙｐｅについては、特定のデコーダが存在し得る。

拡張のためのデコーダをＵＳＡＣデコーダが利用可能な場合、拡張のペイロードはＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）がＵＳＡＣデコーダにより構文解析された直後に拡張デコーダへ転送される。

ＵＳＡＣデコーダが利用可能な拡張のためのデコーダがない場合、最低限の構造がビットストリーム内に付与され、それによりＵＳＡＣデコーダが拡張を無視することができるようになる。

拡張要素の長さは、対応のＵｓａｃＥｘｔＥｌｅｍｅｎｔＣｏｎｆｉｇ（）内で信号伝達でき、かつ、ＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）内でオーバルールできるオクテットのデフォルト長により特定されるか、または構文要素ｅｓｃａｐｅｄＶａｌｕｅ（）を使用する１または３のオクテット長のＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）における明示的に付与される長さ情報により特定される。

１以上のＵｓａｃＦｒａｍｅ（）’ｓにまたがる拡張ペイロードを分割することができ、かつ、それらのペイロードをいくつかのＵｓａｃＦｒａｍｅ（）’ｓの間で配分することができる。この場合、ｕｓａｃＥｘｔＥｌｅｍｅｎｔＰａｙｌｏａｄＦｒａｇフラグを１にセットし、かつデコーダは、ｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｔａｒｔが１に設定されたＵｓａｃＦｒａｍｅ（）からｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｔｏｐが１に設定されたＵｓａｃＦｒａｍｅ（）まで（これを含む）の全フラグメントを集める必要がある。ｕｓａｃＥｘｔＥｌｅｍｅｎｔＳｔｏｐが１に設定されると、拡張は完了と考えられ、拡張デコーダへ送られる。

なお、分割された拡張ペイロードの保全性保護についてはこの明細書によっては提供されず、拡張ペイロードの完全性を確保するためには他の手段を用いる必要がある。

なお、全拡張ペイロードデータはバイト単位で揃えられると仮定する。

各ＵｓａｃＥｘｔＥｌｅｍｅｎｔ（）は、ｕｓａｃＩｎｄｅｐｅｎｄｅｎｃｙＦｌａｇの使用から結果として得られる要求にしたがう。より明示的には、ｕｓａｃＩｎｄｅｐｅｎｄｅｎｃｙＦｌａｇを設定（＝＝１）すれば、ＵｓａｃＥｘＥｌｅｍｅｎｔ（）が以前のフレーム（およびそれに含まれ得る拡張ペイロード）の知識なしで復号化可能になる。

復号化プロセス
ＵｓａｃＣｈａｎｎｅｌＰａｉｒＥｌｅｍｅｎｔＣｏｎｆｉｇ（）において送信されるｓｔｅｒｅｏＣｏｎｆｉｇＩｎｄｅｘは、所与のＣＰＥにおいて適用されるステレオ符号化の正確なタイプを決定する。ステレオ符号化のこのタイプに依存して、１または２のコアコーダチャネルが実際にビットストリームにおいて送信され、かつ、可変ｎｒＣｏｒｅＣｏｄｅｒＣｈａｎｎｅｌｓをこれに応じて設定する必要がある。構文要素ＵｓａｃＣｏｒｅＣｏｄｅｒＤａｔａ（）は、１または２のコアコーダチャネルのためのデータを付与する。

同様に、ステレオ符号化のタイプおよびｅＳＢＲの使用（すなわちｓｂｒＲａｔｉｏＩｎｄｅｘ＞０かどうか）に基づき１つまたは２つのチャネル用に使用可能なデータが存在し得る。ｎｒＳｂｒＣｈａｎｎｅｌｓの値はこれに応じて設定される必要があり、かつ構文要素ＵｓａｃＳｂｒＤａｔａ（）は、１つまたは２つのチャネルのためのｅＳＢＲデータを付与する。

最後に、Ｍｐｓ２１２Ｄａｔａ（）は、ｓｔｅｒｅｏＣｏｎｆｉｇＩｎｄｅｘの値に依存して送信される。

低周波数エンハンスメント（ＬＦＥ）チャネル要素ＵｓａｃＬｆｅＥｌｅｍｅｎｔ（）

概要
デコーダにおける規定の構造を維持するため、ＵｓａｃＬｆｅＥｌｅｍｅｎｔ（）を標準ｆｄ＿ｃｈａｎｎｅｌ＿ｓｔｒｅａｍ（０，０，０，０，ｘ）要素として規定し、すなわち、周波数領域コーダを使用してＵｓａｃＣｏｒｅＣｏｄｅｒＤａｔａ（）と等しくする。こうして、ＵｓａｃＣｏｒｅＣｏｄｅｒＤａｔａ（）要素を復号化するための標準的過程を利用して復号化を行うことができる。

しかしながら、ＬＦＥデコーダのより高いビットレートおよびハードウェア効率的実装に適応するため、この要素の符号化に使用される選択肢には、いくつかの制約が適用される。

・ｗｉｎｄｏｗ＿ｓｅｑｕｅｎｃｅフィールドは、常に０に設定される（ＯＮＬＹ＿ＬＯＮＧ＿ＳＥＱＵＥＮＣＥ）。
・ＬＦＥの最も低い２４のスペクトル係数のみが非ゼロになり得る。
・非時間雑音整形が使用される、すなわちｔｎｓ＿ｄａｔａ＿ｐｒｅｓｅｎｔがゼロに設定される。
・時間ワープが不活性である。
・ノイズフィリィングが適用されない。

ＵｓａｃＣｏｒｅＣｏｄｅｒＤａｔａ（）
ＵｓａｃＣｏｒｅＣｏｄｅｒＤａｔａ（）は、１または２のコアコーダチャネルを復号化するためのすべての情報を含む。

復号化の順序は以下のとおりである。
・チャネルごとのｃｏｒｅ＿ｍｏｄｅ［］を取得。
・２つのコア符号化チャネルの場合（ｎｒＣｈａｎｎｅｌｓ＝＝２）、ＳｔｅｒｅｏＣｏｒｅＴｏｏｌＩｎｆｏ（）を構文解析し、全ステレオ関連パラメータを決定。
・信号伝達されたｃｏｒｅ＿ｍｏｄｅに基づき、チャネルごとにｌｐｄ＿ｃｈａｎｎｅｌ＿ｓｔｒｅａｍ（）またはｆｄ＿ｃｈａｎｎｅｌ＿ｓｔｒｅａｍ（）を送信。

上記のリストからわかるとおり、１つのコアコーダチャネル（ｎｒＣｈａｎｎｅｌｓ＝＝１）を復号化すると、ｃｏｒｅ＿ｍｏｄｅビットが得られ、その後に、ｃｏｒｅ＿ｍｏｄｅに依存して、１つのｌｐｄ＿ｃｈａｎｎｅｌ＿ｓｔｒｅａｍまたはｆｄ＿ｃｈａｎｎｅｌ＿ｓｔｒｅａｍが続く。

２つのコアコーダチャネルの場合、両方のチャネルのｃｏｒｅ＿ｍｏｄｅが０であれば、特に、チャネル間のいくつかの信号伝達冗長性が利用され得る。詳細については、６．２Ｘ（ＳｔｅｒｅｏＣｏｒｅＴｏｏｌＩｎｆｏ（）の復号化）を参照。

ＳｔｅｒｅｏＣｏｒｅＴｏｏｌＩｎｆｏ（）
ＳｔｅｒｅｏＣｏｒｅＴｏｏｌＩｎｆｏ（）により、パラメータを効率的に符号化でき、その値は、両方のチャネルがＦＤモード（ｃｏｒｅ＿ｍｏｄｅ［０，１］＝０）で符号化される場合には、ＣＰＥのコアコーダチャネルを横断して共有され得る。ビットストリームにおける適切なフラグが１にセットされると、特に以下のデータ要素が共有される。

適切なフラグがセットされない場合、データ要素は、コアコーダチャネルごとにＳｔｅｒｅｏＣｏｒｅＴｏｏｌＩｎｆｏ（）（ｍａｘ＿ｓｆｂ，ｍａｘ＿ｓｆｂ１）またはＵｓａｃＣｏｒｅＣｏｄｅｒＤａｔａ（）要素においてＳｔｅｒｅｏＣｏｒｅＴｏｏｌＩｎｆｏ（）に追随するｆｄ＿ｃｈａｎｎｅｌ＿ｓｔｒｅａｍ（）のいずれかにおいて、個別に送信される。

ｃｏｍｍｏｎ＿ｗｉｎｄｏｗ＝＝１の場合、ＳｔｅｒｅｏＣｏｒｅＴｏｏｌＩｎｆｏ（）はＭ／Ｓステレオ符号化についての情報およびＭＤＣＴ領域における複雑予測データも含む（７．７.２を参照）。

ＵｓａｃＳｂｒＤａｔａ（）
このデータブロックは、１つまたは２つのチャネルについてのＳＢＲ帯域幅拡張のためのペイロードを含む。このデータの存在は、ｓｂｒＲａｔｉｏＩｎｄｅｘに依存する。

ＳｂｒＩｎｆｏ（）
この要素は、変更されてもデコーダリセットを必要としないＳＢＲ制御パラメータを含む。

ＳｂｒＨｅａｄｅｒ（）
この要素は、ＳＢＲコンフィギュレーションパラメータを有するＳＢＲヘッダデータを含み、これらパラメータは典型的にはビットストリームの持続時間にわたって変化しない。

ＵＳＡＣのためのＳＢＲペイロード
ＵＳＡＣにおいては、ＳＢＲペイロードは、ＵｓａｃＳｂｒＤａｔａ（）において送信され、これは、各単一チャネル要素またはチャネル対要素の不可欠な部分である。ＵｓａｃＳｂｒＤａｔａ（）は、ＵｓａｃＣｏｒｅＣｏｄｅｒＤａｔａ（）の直後に続く。ＬＦＥチャネルについては、ＳＢＲペイロードは存在しない。

ｎｕｍＳｌｏｔｓ
Ｍｐｓ２１２Ｄａｔａフレームにおける時間スロットの数。
装置に関連して、いくつかの特徴について説明したが、これらの特徴が、ブロックまたは装置が方法ステップまたは方法ステップの特徴に相当する対応の方法の記述にも相当することは明らかである。同様に、方法ステップに関連して説明した特徴は、対応のブロックもしくはアイテムまたは対応の装置の記述にも相当する。

いくつかの実行の要件に基づいて、本発明の実施例は、ハードウェアまたはソフトウェアにおいて実現することができる。実装は、それぞれの方法が実行されるようにプログラム可能なコンピュータシステムと協働する（または協働可能な）電子的に可読な制御信号を記憶したフロッピーディスク、ＤＶＤ、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭまたはフラッシュメモリ等のデジタル記憶媒体を用いて実行され得る。

本発明のいくつかの実施例は、本件に記載の方法の１つが実行されるように、プログラム可能コンピュータシステムと協働可能な電子的に可読な制御信号を有する非過渡性のデータキャリアを含む。

符号化されたオーディオ信号は、有線または無線の伝送媒体を経由して送信されるかまたは機械可読キャリアもしくは非過渡性記憶媒体上に記憶することができる。

一般に、本発明の実施例は、プログラムコードを有するコンピュータプログラム製品として実現され得るが、このプログラムコードは、コンピュータプログラム製品をコンピュータ上で実行すると、方法の１つを実行するよう動作する。プログラムコードは、たとえば、機械可読キャリア上に記憶されてもよい。

他の実施例は、機械可読キャリア上に記憶された、本件に記載の方法の１つを実行するためのコンピュータプログラムを含む。

したがって、言い換えれば、発明の方法の実施例は、コンピュータプログラムをコンピュータ上で実行した際、本件に記載の方法の１つを実行するためのプログラムコードを有するコンピュータプログラムである。

したがって、発明の方法の他の実施例は、本件に記載の方法の１つを実行するためのコンピュータプログラムを記録するデータキャリア（またはデジタル記憶媒体またはコンピュータ可読媒体）である。

したがって、発明の方法の他の実施例は、本件に記載の方法の１つを実行するためのコンピュータプログラムを表現するデータストリームまたは信号のシーケンスである。データストリームまたは信号のシーケンスは、インターネットを経由する等、データ通信接続を経由して伝送されるように構成され得る。

他の実施例は、本件に記載の方法の１つを実行するよう構成または適合されたコンピュータ、プログラム可能論理装置等の処理手段を含む。

他の実施例は、本件に記載の方法の１つを実行するためのコンピュータプログラムをインストールしたコンピュータを含む。

いくつかの実施例においては、プログラム可能論理装置（フィールドプログラマブルゲートアレイ等）を使用して、本件に記載の方法の機能性のいくつかまたはすべてを実行するようにしてもよい。いくつかの実施例においては、フィールドプログラマブルゲートアレイは、本件に記載の方法の１つを実行するためにマイクロプロセッサと協働し得る。一般に、これらの方法は、なんらかのハードウェア装置で実行することが好ましい。

上記の実施例は、本発明の原則を説明するためのものに過ぎない。本件に記載の構成および詳細の変形例および修正例が当業者に明らかになることは当然である。したがって、その主旨は請求項の範囲によってのみ限定され、本件に記載の実施例の記述および説明により提示される特定の詳細により限定されない。

Claims (27)

1. コンフィギュレーションブロック（２８）およびそれぞれがオーディオコンテント（１０）の連続する期間（１８）を表すフレーム（２０）のシーケンスを含むビットストリームであって、コンフィギュレーションブロック（２８）が、
   要素の数Ｎを示すフィールド（５０）と、
   Ｎ個の要素位置のシーケンスのうちの各要素位置について、複数の要素タイプの中から要素タイプを表示するタイプ表示構文部（５２）とを含み、
   フレーム（２０）のシーケンスの各々が、
   Ｎ個のフレーム要素（２２）のシーケンスを含み、
   各フレーム要素が、ビットストリーム（１２）においてそれぞれのフレーム（２０）のＮ個のフレーム要素のシーケンス内で、それぞれのフレーム要素（２２）が位置するそれぞれの要素位置について、タイプ表示構文部（５２）により表示される要素タイプである、ビットストリーム。
2. タイプ表示構文部（５２）が、Ｎ個の構文要素（５４）のシーケンスを含み、各構文要素（５４）が、それぞれの構文要素（５４）がタイプ表示構文部（５２）において位置するそれぞれの要素位置について要素タイプを表示する、請求項１に記載のビットストリーム。
3. コンフィギュレーションブロック（２８）が、Ｎ個のコンフィギュレーション要素５６のシーケンスを含み、各コンフィギュレーション要素５６が、それぞれのコンフィギュレーション要素５６がＮ個のコンフィギュレーション要素のシーケンスにおいて位置するそれぞれの要素位置について、要素タイプのコンフィギュレーション情報を含む、請求項１または２に記載のビットストリーム。
4. タイプ表示構文部（５２）が、Ｎ個の構文要素（５４）のシーケンスを含み、各構文要素（５４）が、それぞれの構文要素（５４）がタイプ表示構文部（５２）において位置するそれぞれの要素位置の要素タイプを表示し、かつコンフィギュレーション要素（５６）および構文要素がビットストリーム内で交互に配列される、請求項３に記載のビットストリーム。
5. 複数の要素タイプが、拡張要素タイプを含み、いずれかのフレーム（２０）の拡張要素タイプの各フレーム要素（２２）が、それぞれのフレーム要素の長さに関する長さ情報（５８）を含む、請求項１から４のいずれかに記載のビットストリーム。
6. コンフィギュレーションブロック（２８）が、タイプ表示部が拡張要素タイプを表示する各要素位置について、拡張要素タイプのコンフィギュレーション情報を含むコンフィギュレーション要素（５６）を含み、
   拡張要素タイプのいずれかのコンフィギュレーション情報が、デフォルト拡張ペイロード長さに関するデフォルトペイロード長さ情報（６０）を含み、かつデフォルトペイロード長さフラグ（６４）が設定されていなければ、拡張要素タイプのフレーム要素（２２）の長さ情報（５８）が、拡張ペイロード長さ値（６６）が後に続くデフォルト拡張ペイロード長さフラグ（６４）の形で条件構文部（６２）を含み、
   拡張要素タイプのそれぞれのフレーム要素（２２ｂ）の長さ情報（５８）のデフォルト拡張ペイロード長さフラグ（６４）が設定されている場合には、拡張要素タイプのいずれかのフレーム要素が、デフォルト拡張ペイロード長さを有し、かつ拡張要素タイプのそれぞれのフレーム（２２ｂ）の長さ情報（５８）のデフォルト拡張ペイロード長さフラグ（６４）が設定されていない場合には、拡張要素タイプのそれぞれのフレーム要素（２２ｂ）の長さ情報（５８）の拡張ペイロード長さ値（６０）に対応する拡張ペイロード長さを有する、請求項５に記載のビットストリーム。
7. 拡張要素タイプのいずれかのフレーム要素の長さ情報（５８）が、拡張ペイロードプレゼントフラグ（７０）を含み、その長さ情報（５８）の拡張ペイロードプレゼントフラグ（７０）が設定されていない拡張要素タイプのいずれかのフレーム要素（２２ｂ）は、拡張ペイロードプレゼントフラグ（７０）のみからなり、かつその長さ情報（５８）のペイロードデータプレゼントフラグ（７０）が設定されいる拡張要素タイプのいずれかのフレーム要素（２２ｂ）の長さ情報（５８）は、拡張要素タイプのそれぞれのフレーム（２２ｂ）の拡張ペイロード長さを示す構文部をさらに含む、請求項５または６に記載のビットストリーム。
8. コンフィギュレーションブロック（２８）が、タイプ表示部（５２）が拡張要素タイプを示す各要素位置について、拡張要素タイプのコンフィギュレーション情報を含むコンフィギュレーション要素（５６）を含み、コンフィギュレーション情報が、複数のペイロードデータタイプからペイロードデータタイプを表示する拡張要素タイプフィールド（７２）を含み、複数のペイロードデータタイプが、多チャネルサイド情報タイプおよび多オブジェクト符号化サイド情報タイプを含み、その拡張要素タイプフィールド（７２）が多チャネルサイド情報を表示するコンフィギュレーション要素の拡張要素タイプのコンフィギュレーション情報も多チャネルサイド情報コンフィギュレーションデータ（７４）を含み、かつその拡張要素タイプフィールド（７２）が多オブジェクトサイド情報タイプを表示するコンフィギュレーション要素の拡張要素タイプのコンフィギュレーション情報も多オブジェクトサイド情報コンフィギュレーションデータ（７４）を含み、かつタイプ表示部が拡張要素タイプを表示するいずれかの要素位置に位置する拡張要素タイプのフレーム要素（２２ｂ）が、それぞれの要素位置のコンフィギュレーション要素のコンフィギュレーション情報の拡張要素タイプフィールド（７２）により表示されるペイロードデータタイプのペイロードデータを伝達する、請求項５から７のいずれかに記載のビットデータ。
9. コンフィギュレーションブロック（２８）およびそれぞれがオーディオコンテント（１０）の連続する期間を表すフレーム（２０）のシーケンスを含むビットストリーム（１２）を復号化するためのデコーダであって、コンフィギュレーションブロック（ＵｓａｃＣｏｎｆｉｇ）が、要素の数Ｎを表示するフィールド（ｎｕｍＥｌｅｍｅｎｔｓ）およびＮ個の要素位置のシーケンスの各要素位置について、複数の要素タイプのうちから要素タイプを表示するタイプ表示構文部（５２）を含み、
   フレームのシーケンスの各々がＮ個のフレーム要素のシーケンスを含み、
   デコーダが、ビットストリーム（１２）におけるそれぞれのフレーム（２０）のＮ個のフレーム要素（２２）のシーケンスにおいてそれぞれのフレーム要素が位置するそれぞれの要素位置について、タイプ表示構文部により表示される要素タイプに従って各フレーム要素（２２）を復号化することにより各フレーム（２０）を復号化するよう構成される、デコーダ。
10. デコーダが、タイプ表示構文部（５２）からＮ個の構文要素（５４）のシーケンスを読み出すよう構成され、各要素が、Ｎ個の構文要素のシーケンスにおいてそれぞれの構文要素が位置するそれぞれの要素位置について要素タイプを表示する、請求項９に記載のデコーダ。
11. デコーダが、コンフィギュレーションブロック（２８）からＮ個のコンフィギュレーション要素（５６）のシーケンスを読み出すように構成され、各コンフィギュレーション要素が、Ｎ個のコンフィギュレーション要素のシーケンスにおいてそれぞれのコンフィギュレーション要素が位置するそれぞれの要素位置について要素タイプのコンフィギュレーション情報を含み、
    デコーダが、ビットストリーム（１２）におけるそれぞれのフレーム（２０）のＮ個のフレーム要素（２２）のシーケンス内でそれぞれのフレーム要素が位置するそれぞれの要素位置について、タイプ表示構文部により表示される要素タイプに従って各フレーム要素（２２）を復号化する上で、ビットストリーム（１２）におけるそれぞれのフレーム（２０）のＮ個のフレーム要素（２２）のシーケンス内でそれぞれのフレーム要素が位置するそれぞれの要素位置について、要素タイプのコンフィギュレーション情報を使用するよう構成される、請求項９または１０に記載のデコーダ。
12. タイプ表示構文部（５２）が、Ｎ個の構文要素（５４）のシーケンスを含み、各構文要素が、それぞれの構文要素がＮ個の構文要素のシーケンスにおいて位置するそれぞれの要素位置について構文タイプを表示し、かつデコーダが、ビットストリーム（１２）からコンフィギュレーション要素（５６）および構文要素（５４）を交互に読み出すように構成される、請求項１１に記載のデコーダ。
13. 複数の要素タイプが拡張要素タイプを含み、
    デコーダが、それぞれのフレーム要素の長さに関する長さ情報（５８）をいずれかのフレーム（２０）の拡張要素タイプの各フレーム要素（２２ｂ）から読出し、
    それぞれのフレーム要素の長さに関する長さ情報（５８）をスキップインターバル長さとして使用して、フレーム（２０）の拡張要素タイプのフレーム要素（２２）の少なくともいくつかの少なくとも一部分をスキップするよう構成される、請求項９から１２のいずれかに記載のデコーダ。
14. デコーダが、拡張要素タイプのコンフィギュレーション情報を読み出す上で、ビットストリームからデフォルト拡張ペイロード長さに関するデフォルトペイロード長さ情報（６０）を読み出して、タイプ表示部が拡張要素タイプを表示する各要素位置について、コンフィギュレーションブロック（２８）から拡張要素タイプのコンフィギュレーション情報を含むコンフィギュレーション要素（７４）を読出すよう構成され、
    デコーダが、また、拡張要素タイプのフレーム要素（２２）の長さ情報（５８）を読み出す上で、ビットストリーム（１２）から条件構文部（６２）のデフォルト拡張ペイロード長さフラグ（６４）を読出し、デフォルトペイロード長さフラグ（６４）が設定されているかどうかをチェックし、デフォルトペイロード長さフラグ（６４）が設定されていない場合には、ビットストリーム（１２）から条件構文部（６２）の拡張ペイロード長さ値（６６）を読み出しそれぞれのフレーム要素の拡張ペイロード長さを取得し、かつデフォルトペイロード長さフラグ（６４）が設定されている場合には、それぞれのフレーム要素の拡張ペイロード長さがデフォルト拡張ペイロード長さと等しくなるよう設定するよう構成され、
    デコーダが、また、それぞれのフレーム要素の拡張ペイロード長さをスキップインターバル長さとして使用して、フレーム（２０）の拡張要素タイプのフレーム要素（２２）の少なくともいくつかのペイロードセクション（６８）をスキップするよう構成される、請求項１３に記載のデコーダ。
15. デコーダが、フレームの拡張要素タイプのいずれかのフレーム要素の長さ情報（５８）を読み出す上で、ビットストリーム（１２）から拡張ペイロードプレゼントフラグ（７０）を読出し、拡張ペイロードプレゼントフラグ（７０）が、設定されているかどうかをチェックし、かつ拡張ペイロードプレゼントフラグ（７０）が設定されていない場合には、拡張要素タイプのそれぞれのフレーム要素（２２ｂ）の読出しを中止して、現在のフレーム（２０）の他のフレーム要素（２２）または後続のフレーム（２０）のフレーム要素の読出しを続け、
    ペイロードデータプレゼントフラグ（７０）が設定されている場合には、ビットストリームから拡張要素タイプのそれぞれのフレームの拡張ペイロード長さを表示する構文部を読出し、長さ情報の拡張ペイロードプレゼントフラグ（７０）が設定されているフレーム（２０）の拡張要素タイプのフレーム要素（２２）の少なくともいくつかについては、ビットストリームから読み出される拡張要素タイプのそれぞれのフレーム要素（２２ｂ）の拡張ペイロード長さをスキップインターバル長さとして使用することによりそのペイロードセクション（６８）をスキップするよう構成される、請求項１３または１４に記載のデコーダ。
16. デコーダが、デフォルトペイロード長さ情報（６０）を読み出す上で、
    ビットストリーム（１２）からデフォルトペイロード長さプレゼントフラグを読出し、
    デフォルトペイロード長さプレゼントフラグが設定されているかどうかをチェックし、
    デフォルトペイロード長さプレゼントフラグが設定されていなければ、デフォルト拡張ペイロード長さがゼロになるように設定し、かつ
    デフォルトペイロード長さプレゼントフラグが設定されていれば、ビットストリームからデフォルト拡張ペイロード長さを明示的に読み出すように構成される、請求項１３または１４に記載のデコーダ。
17. デコーダが、タイプ表示部（５２）が拡張要素タイプを表示する各要素位置について、コンフィギュレーションブロック（２８）を読み出す上で、
    ビットストリーム（１２）から拡張要素タイプのコンフィギュレーション情報を含むコンフィギュレーション要素（５６）を読出すよう構成され、コンフィギュレーション情報が、複数のペイロードデータタイプのうちのペイロードデータタイプを表示する拡張要素タイプフィールド（７２）を含む、請求項１３から１６のいずれかに記載のデコーダ。
18. 複数のペイロードデータタイプが、多チャネルサイド情報タイプおよび多オブジェクト符号化サイド情報タイプを含み、
    デコーダが、タイプ表示部（５２）が拡張要素タイプを表示する各要素位置について、コンフィギュレーションブロック（２８）を読み出す上で、
    拡張要素タイプフィールド（７２）が多チャネルサイド情報タイプを表示する場合には、データストリーム（１２）からコンフィギュレーション情報の一部として多チャネルサイド情報コンフィギュレーションデータ（７４）を読出し、かつ
    拡張要素タイプフィールド（７２）が、多チャネルサイド情報タイプを表示する場合には、データストリームからコンフィギュレーション情報の一部として多オブジェクトサイド情報コンフィギュレーションデータ（７４）を読出すよう構成され、
    デコーダが、各フレームを復号化する上で、
    タイプ表示部が拡張要素タイプを表示し、かつ、コンフィギュレーション要素（５６）の拡張要素タイプが多チャネルサイド情報タイプを表示する、いずれかの要素位置に位置する拡張要素タイプのフレーム要素を、多チャネルサイド情報コンフィギュレーションデータ（７４）を使用して多チャネルデコーダ（４４ｅ）を構成し、かつ、こうして構成した多チャネルデコーダ（４４ｅ）に多チャネルサイド情報として拡張要素タイプのそれぞれのフレーム要素（２２ｂ）のペイロードデータ（６８）をフィードすることにより、復号化し、かつ
    タイプ表示部が拡張要素タイプを表示し、かつ、コンフィギュレーション要素（５６）の拡張要素タイプが多オブジェクトサイド情報タイプを表示するいずれかの要素位置に位置する拡張要素タイプのフレーム要素を、多オブジェクトサイド情報コンフィギュレーションデータ（７４）を使用して多オブジェクトデコーダ（４４ｄ）を構成し、かつ、こうして構成した多オブジェクトデコーダ（４４ｄ）に多オブジェクト情報として拡張要素タイプのそれぞれのフレーム要素（２２）のペイロードデータ（６８）をフィードすることにより、復号化するよう構成される、請求項１７に記載のデコーダ。
19. デコーダが、タイプ表示部が拡張要素タイプを表示するいずれかの要素位置について、コンフィギュレーションデータ長さを取得するようにそれぞれの要素位置のコンフィギュレーション要素のコンフィギュレーション情報の一部としてビットストリーム（１２）からコンフィギュレーションデータ長フィード（７６）を読出し、
    それぞれの要素位置のコンフィギュレーション要素のコンフィギュレーション情報の拡張要素タイプフィールド（７２）により表示されるペイロードタイプが、複数のペイロードデータタイプのサブセットであるペイロードデータタイプの予め定められたセットに属しているかどうかをチェックし、
    それぞれの要素位置のコンフィギュレーション要素のコンフィギュレーション情報の拡張要素タイプフィールド（７２）により表示されるペイロードデータタイプが、ペイロードデータタイプの予め定められたセットに属している場合、
    データストリーム（１２）からそれぞれの要素位置のコンフィギュレーション要素のコンフィギュレーション情報の一部としてペイロードデータ依存のコンフィギュレーションデータ（７４）を読出し、
    ペイロードデータ依存のコンフィギュレーションデータ（７４）を使用して、フレーム（２０）におけるそれぞれの要素位置の拡張要素タイプのフレーム要素を復号化し、かつ
    それぞれの要素位置のコンフィギュレーション要素のコンフィギュレーション情報の拡張要素タイプフィールド（７２）により表示されるペイロードタイプが、ペイロードデータタイプの予め定められたセットに属さない場合、
    コンフィギュレーションデータ長を使用して、ペイロードデータ依存のコンフィギュレーションデータ（７４）をスキップし、かつ
    含まれる長さ情報（５８）を使用してフレーム（２０）におけるそれぞれの要素位置の拡張要素タイプのフレーム要素をスキップするよう構成される、請求項１７または１８に記載のデコーダ。
20. デコーダが、タイプ表示部（５２）が拡張要素タイプを表示する各要素位置について、コンフィギュレーションブロック（２８）を読み出す上で、
    ビットストリーム（１２）から拡張要素タイプのコンフィギュレーション情報を含むコンフィギュレーション要素（５６）を読出すよう構成され、
    コンフィギュレーション情報が、フラグメンテーション使用フラグ（７８）を含み、
    デコーダが、タイプ表示部が拡張要素タイプを表示し、かつ、コンフィギュレーション要素のフラグメンテーション使用フラグ（７８）が設定されているいずれかの要素位置に位置するフレーム要素（２２）を読み出す上で、
    ビットストリームからフラグメント情報を読出し、かつ
    連続するフレームのこれらのフレーム要素のペイロードデータを結合するためにフラグメント情報を使用するよう構成される、請求項１３から１９のいずれかに記載のデコーダ。
21. デコーダが、タイプ表示構文部が単一チャネル要素タイプを表示する要素位置のフレーム（２０）におけるフレーム要素（２２）を復号化する上で、オーディオ信号を再構成するよう構成される、請求項９から２０のいずれかに記載のデコーダ。
22. デコーダが、タイプ表示構文部がチャネル対要素タイプを表示する要素位置のフレーム（２０）におけるフレーム要素（２２）を復号化する上で、２つのオーディオ信号を再構成するよう構成される、請求項９から２１のいずれかに記載のデコーダ。
23. デコーダが、同じ可変長コードを使用して、長さ情報（８０）、拡張要素タイプフィールド（７２）、コンフィギュレーションデータ長フィールド（７６）を読み出すように構成される、請求項９から２２のいずれかに記載のデコーダ。
24. オーディオコンテントをビットストリームに符号化するためのエンコーダであって、エンコーダが、
    オーディオコンテント（１０）の連続する期間（１８）をそれぞれオーディオコンテント（１０）の連続する期間（１８）を表すフレーム（２０）のシーケンスに符号化し、それにより各フレーム（２０）が要素数Ｎのフレーム要素（２２）のシーケンスを含み、各フレーム要素（２２）が、フレーム要素のシーケンスのＮ個の要素位置のシーケンスのうちいずれかの共通の要素位置に位置するフレームのフレーム要素（２２）が等しい要素タイプになるように、複数の要素タイプのうちのそれぞれ１つであり、
    コンフィギュレーションブロック（２８）をビットストリーム（１２）に符号化し、コンフィギュレーションブロックが要素数Ｎを表示するフィールドおよびＮ個の要素位置のシーケンスの各要素位置について、それぞれの要素タイプを表示するタイプ表示構文部を含み、かつ
    ビットストリーム（１２）内のＮ個のフレーム要素（２２）のシーケンス内のそれぞれの要素位置に位置するＮ個のフレーム要素のシーケンスの各フレーム（２２）が、それぞれの要素位置についてタイプ表示部により表示される要素タイプになるように、各フレーム（２０）について、Ｎ個のフレーム要素（２２）のシーケンスをビットストリーム（１２）に符号化するよう構成される、エンコーダ。
25. コンフィギュレーションブロック（２８）およびそれぞれがオーディオコンテントの連続する期間を表すフレーム（２０）のシーケンスを含むビットストリーム（１２）を復号化する方法であって、コンフィギュレーションブロック（２８）が、要素数Ｎを表示するフィールド（５０）と、Ｎ個の要素位置のシーケンスの各要素位置について、複数の要素タイプのうちから要素タイプを表示するタイプ表示構文部（５２）とを含み、フレームのシーケンスの各々が、Ｎ個のフレーム要素のシーケンスを含み、
    方法が、
    それぞれのフレーム要素が、ビットストリーム（１２）内のそれぞれのフレーム（２０）のＮ個のフレーム要素（２２）のシーケンス内で位置するそれぞれの要素位置について、タイプ表示構文部により表示される要素タイプに従って各フレーム要素（２２）を復号化することにより各フレーム（２０）を復号化するステップを含む、方法。
26. オーディオコンテントをビットストリームに符号化する方法であって、
    オーディオコンテント（１０）の連続する期間（１８）を、オーディオコンテント（１０）の連続する期間（１８）をそれぞれ表すフレーム（２０）のシーケンスに符号化するステップを含み、それにより各フレーム（２０）が、要素数Ｎのフレーム要素（２２）のシーケンスを含み、各フレーム要素（２２）が、フレーム要素のシーケンスのＮ個の要素位置のシーケンスのうちのいずれか共通の要素位置にあるフレームのフレーム要素（２２）が等しい要素タイプになるように複数の要素タイプのうちのそれぞれ１つであり、
    要素数Ｎを表示するフィールドおよびＮ個の要素位置のシーケンスの各要素位置について、それぞれの要素タイプを表示するタイプ表示構文部を含むコンフィギュレーションブロック（２８）をビットストリーム（１２）に符号化するステップと、
    ビットストリーム（１２）内のＮ個のフレーム要素（２２）のシーケンス内でそれぞれの要素位置に位置するＮ個のフレーム要素のシーケンスの各フレーム要素（２２）が、それぞれの要素位置について、タイプ表示部が表示する要素タイプになるように、各フレーム（２０）について、Ｎ個のフレーム要素（２２）のシーケンスをビットストリーム（１２）に符号化するステップとを含む、方法。
27. コンピュータ上で実行した際に、請求項２５または２６に記載の方法を実行するためのコンピュータプログラム。

Images