JP2007537464A - ツリー状階層データ構造を順に横断してゆくことによりビットストリームシンタックスを記述するオーディオビットストリームフォーマット - Google Patents

Abstract

ツリー状階層データ構造を順に横断してゆくことによりビットストリームシンタックスを記述するオーディオ情報を表示するビットストリームフォーマットは、それぞれが１以上のノードを持つ複数のツリー状階層レベルからなるツリー状階層を有し、ノードには、少なくともいくつかの徐々に小さくなるオーディオ情報のサブディビジョンが徐々にツリー状階層の低いレベルにおいて表示され、前記オーディオ情報は前記１以上のレベルにおけるノードに含まれる。

Description

本発明は、ツリー状階層データ構造を順に横断してゆくことによりビットストリームシンタックスを記述するオーディオ情報を表示するビットストリームフォーマットと、このようなビットストリームフォーマットに基づきフォーマットされたビットストリームと、このようなビットストリームを記憶又は伝達する媒体と、このようなビットストリームフォーマットに基づくフォーマットを有するビットストリームをエンコーディング及びデコーディングするシステムと、このようなビットストリームフォーマットに基づくフォーマットを有するビットストリームをエンコーディングするためのエンコーダと、このようなビットストリームフォーマットに基づくフォーマットを有するビットストリームをデコーディングするためのデコーダと、このようなビットストリームフォーマットに基づくフォーマットを有するビットストリームをエンコーディング及びデコーディングするプロセスと、このようなビットストリームフォーマットに基づきフォーマットされたビットストリームを作るためのプロセスと、このようなビットストリームフォーマットに基づくフォーマットを有するビットストリームをエンコーディングするためのプロセスと、このようなビットストリームフォーマットに基づくフォーマットを有するビットストリームをデコーディングするためのプロセスとに関する。

本発明の特徴に基づき、ツリー状階層データ構造を順に横断してゆくことによりビットストリームシンタックスを記述するオーディオ情報を表示するビットストリームフォーマットは、それぞれが１以上のノードを持つ複数のツリー状階層レベルからなるツリー状階層を有し、ノードには、少なくともいくつかの徐々に小さくなるオーディオ情報のサブディビジョンが徐々にツリー状階層の低いレベルにおいて表現され、前記オーディオ情報は前記１以上のレベルにおけるノードに含まれる。前記オーディオの前記徐々に小さくなるサブディビジョンには１以上の時間的サブディビジョン、空間的サブディビジョン、及び分解能サブディビジョンが含まれる。前記ツリー状階層の第１のレベルはオーディオ情報のすべてを表現するルートノードを具備してもよく、それより低い少なくとも１つのレベルではオーディオ情報の時間的細分を表現する複数のルートノードを具備してもよく、さらに低いレベルではオーディオ情報の空間的細分を表現する複数のルートノードを具備してもよい。あるいは、又は付加的に、基本分解能のオーディオ情報レイヤーが１つのレベルにあり、１以上のオーディオ情報分解能強化レイヤーが同じレイヤー又は１以上のの他のレベルに含まれるような、多重の分解能を提供させるためにオーディオ情報をレイヤー化してもよい。本発明の他の特徴は、ここに書かれた明細書及び請求の範囲に述べられている。

本発明の特徴に基づくビットストリームフォーマットは、以下のうちの１つ以上の点で有益である。

‐オーディオ処理待ち時間を最小限にする
‐ビットストリームに大規模な修正を加えることなくメタデータを付加し、動かし又は細工する
‐ビットストリームに含まれるオーディオ素材の具体的な形態と恣意的なメタデータとを関連付ける
‐ビットストリームの構造上のオーバーヘッドを最小限にする
‐前方互換性／後方互換性を持たせるフレキシブルなビットストリーム構成を提供する
‐種々のインターフェースで効率的に伝達することができる
‐フレームベースの編集を容易にする
‐エンコードされたオーディオ情報又はエンコードされていないオーディオ情報のカプセル化を容易にする

ツリー状階層データ構造の定義及び例はＮＩＳＴ、すなわち（米国）国立標準技術研究所、ウェブサイト「Dictionary of Algorithms and Data Structures」(http://ist.gov/dads/)、で見つけることができる。ツリー状階層データ構造の先行順トラバーサルのデモンストレーションは、カンタベリー大学（ニュージーランド）のウェブサイトデータ構造、アルゴリズム、２分木トラバーサルアルゴリズム(http://www.cosc.canterbury.ac.nz/people/mukundan/dsal/BTree.html)で見つけることができる。

図１ａと図１ｂは、それぞれ、本発明の特徴に基づくビットストリームのオーディオ情報（ここではしばしば「オーディオエッセンス」と称す）成分とツリー状階層を示した簡略化した図式表現である。図１ａのビットストリーム表現は２つの連続するオーディオフレームを示し、その各々が第１のチャンネルと第２のチャンネル、すなわちチャンネル１及びチャンネル２を有する。後者は、例えば、それぞれ左右のスピーカにより再生されたオーディオ情報に該当する。チャンネル１及びチャンネル２は第１のフレームで１ａ及び２ａと名づけられ、第２のフレームで１ｂ及び２ｂと名づけられる。図１ａにおいて、垂直方向はチャンネルを表し、水平方向はフレームと時間を表す。

図１ｂの例において、本発明の特徴に基づく図１ａのビットストリームの下にあるツリー状階層は、３つのレベルすなわち、レベル１，レベル２，及びレベル３、を有する。レベル１における単一のルートノード３は全ビットストリームのオーディオ素材を表す。実際には、以下に説明するとおり、ビットストリームフォーマットとその下の「オーディオ素材」のツリー状階層データ構造表現には、オーディオエッセンスと他のデータについての情報である、オーディオ情報つまりオーディオ「エッセンス」、及び「メタデータ」が含まれる。しかし、この簡単な例においては、オーディオエッセンスのみがビットストリームのツリー状階層で示されている。

この例のレベル２の階層において、それぞれが固定期間又は固定ビット長さ又は可変期間又は可変ビット長さの個々のオーディオフレームにオーディオ素材を分解することができる（簡単にするため、図１ａと図１ｂの例では２つのフレームのみが示されている）。フレームノード４と５は、それぞれ親としてノード３を有し、この例の階層におけるレベル２にて、第１のオーディオフレームと第２のオーディオフレームを表している。各オーディオフレームは、オーディオチャンネルに分解することができ（簡単にするため、図１ａと図１ｂの例では１つのフレームに２つのチャンネルのみが記載されている）、各々は、例えば、「右」や「左」のような空間的な方向に対応する。チャンネルノード６，７，８及び９は、各々親に属するフレームノードを有し、それぞれレベル３の階層での連続するフレームにおけるオーディオチャンネルｌａ，２ａ，１ｂ及び２ｂを表している。

図１ｂの例では、チャンネルノード６〜９はリーフノードであり、各々少なくとも１つのエッセンスエレメントの形でオーディオエッセンスを含有している。原則として、オーディオエッセンスがリーフノードに含まれている必要はないが、実際にはリーフノードにオーディオエッセンスを置くこと（及び、オーディオの基本分解のレイヤーが１以上のより高い分解能の強化されたレイヤーと一緒に提供されるような「レイヤー化された」オーディオの場合に、リーフノード及び次に高い１以上の階層のレイヤーのノードにオーディオエッセンスを置くこと）は好都合であり、また、本発明の明細書を読み理解するうえで好ましい。

どの階層に置かれたとしても、階層の１以上のノードにオーディオエッセンスがあり、したがって、オーディオエッセンスが、結果として生じるビットストリーム中に存在することは、本発明の１つの特徴である。このことは、例えば、エンコーディング又はデコーディング又はオーディオエッセンスに関する情報をビットストリーム及びその下にある階層以外に置く可能性を除外するものではない。例えば、オーディオエッセンスに関するメタデータ内のポインタが、ビットストリームの外部の特定のデコーディングプロセスとその下の階層を指定することも可能である。

上述のように、「オーディオ素材」のビットストリームフォーマットとその下のツリー状階層データ構造表現には、ディオ情報又はオーディオ「エッセンス」が含まれるのみならず、オーディオエッセンス及び他のデータについての情報である「メタデータ」が含まれる。

オーディオメタデータについて役に立つ説明には、http://tvtechnology.com/features/audio_notes/f-TC-AC3-06.26.02.shtmlにある、２００２年６月２６日付のティム・キャロルのオーディオノート中の、「ＡＴＳＣのＡＣ-３オーディオスタンダードの探求（Exploring the AC-3 Audio Standard for ATSC）」と、http://tvtechnology.com/features/audio_notes/f-tc-metadata.shtmlにある２００２年７月２４日付のティム・キャロルのオーディオノート中の、「オーディオメタデータの詳細（A Closer Look at Audio Metadata）」、及び、http://tvtechnology.com/features/audio_notes/f-TC-metadata-08.21.02.shtmlにある２００２年８月２１日付のティム・キャロルのオーディオノート中の、「オーディオメタデータ：ここからそれが分かる（You Can Get There From Here）」が含まれる。各書類はそのすべてが参照として本明細書に組み込まれる。

本発明の特徴による階層的な表現に基づくビットストリームは、任意のメタデータ情報を正確に関連付けさせ、それによりそのオーディオエッセンスに同期させる。これは、オーディオエッセンスと同じノード中又はオーディオエッセンスを含有するノードの親ノード中の特定のオーディオエッセンスと関連づけするためにメタデータを置くことにより達成することができる。本発明の実施の形態によれば、さらに以下に説明するように、１以上のメタデータエレメントをその階層内のノードの開始部又は終了部に付加することができる。したがって、図１ｂの例のような３つの階層レベルにおいて、特定のオーディオエッセンスと関連づけられたメタデータを、レベル１のルートノード中の全ビットストリームのオーディオ素材の開始部又は終了部、特定のオーディオエッセンスを含むチャンネルの親であるレベル２内のフレームノード中の個々のフレームの開始部又は終了部、及び／又は特定のオーディオエッセンスを含むレベル３中のチャンネル（リーフ）ノード内のチャンネルの開始部又は終了部に付加することができる。このような構成例を図２の例の下部に示した。

メタデータは、個々のノードの「意味的な独立」に寄与するような方法で階層レベルに分配することが好ましい。例えば、図１ｂの構成において、ルートノードのメタデータは、オーディオ素材全体にのみ適用することが好ましく、フレームノードのメタデータは特定のフレーム及びそのチャンネルにのみ適用することが好ましく、チャンネルノード中のメタデータは特定のチャンネルのみに適用することが好ましい。メタデータ情報を適切に定義することにより、他のノードに運び込まれたメタデータを変更させることなくノードの操作を確実に行うことができる。例えば、もしフレームノードが特定のチャンネルノードに固有のメタデータがなく、他のチャンネルノードに必要とされるメタデータがチャンネルノードに含まれないならば、チャンネルノード中のメタデータだけでなくチャンネルノード全体も、他のノードにあるメタデータを変更することなく、付加、削除、又は変更することができる。この意味で、本発明はノードを意味的に独立にする。言い換えれば、メタデータとエッセンスの観点から、所定のどのノードも、それ自身とその子（もしあれば）に等しく適用可能であれば、そのシブリングから独立することができる。したがって、本発明による、適切に分配されたメタデータを有するビットストリームは、以下に説明するようにトランスコーディングが容易になる。

本発明に基づくビットストリームは、オーディオ素材を順番に並べた階層表現とするためにツリー状階層データ構造を順序付けられたトラーバーサルを用いることにより作られる。順序付けられたトラーバーサルは、先行順トラーバーサル（しばしば「プレフィックストラバーサル（prefix traversal）」と称される）の特性をもつことが好ましい。先行順トラーバーサルアルゴリズムは、ルートノードを処理し、そして、再帰的にすべてのサブツリーを処理することによりすべてのツリーを処理するプロセスであると定義することができる。特に、ボディタグが全く採用されない場合（以下の「ボディタグ」に関する記載を参照のこと）、本発明の特徴に基づく階層の順序付けに用いる適切な先行順トラーバーサルアルゴリズムは、ルートノードから始まる以下のアルゴリズム適用することにより記述することができる。すなわち、
ａ）ノードの開始を示す「開始タグ」をビットストリームに書き込む、
ｂ）ノードの開始部に付加された１以上のメタデータ又はエッセンスエレメントの各々を個々のセグメントとして書き込む、
ｃ）ステップ「ａ」から始まるアルゴリズムを、計画中のノードの各子ノードに適用する、
ｄ）ノードの終了部に付加された１以上のメタデータ又はエッセンスエレメントの各々を個々のセグメントとして書き込む、そして
ｅ）ノードの終了示す「終了タグ」セグメントをビットストリームに書き込む。

トラバーサルアルゴリズムはまた、簡略化したＣ言語の擬似コードで以下のように表現することができる。すなわち、

visit(root);
where
visit(node){
for segment in node.header.segments do{
write(segment);
}

for child in all node.children do{
visit(child);
}

fore segment in node.footer.sigments do{
write(segmet);
}
}

もしボディタグを採用するならば、適切な先行順トラーバーサルアルゴリズムは、ルートノードから始まる以下のアルゴリズム適用することにより記述することができる。すなわち、
ａ）ノードの開始を示す「開始タグ」をビットストリームに書き込む、
ｂ）ノードの開始部に付加された１以上のメタデータ又はエッセンスエレメントの各々を個々のセグメントとして書き込む、
ｃ）もしルートノードが子ノードを全く持たず、その終端にメタデータもエッセンスエレメントも全く持たないならば、ステップｄ）からステップｇ）までを省略する、
ｄ）ノードの子ノードの開始を示す「ボディタグ開始」セグメントをビットストリームに書き込む、
ｅ）ステップ「ａ」から始まるアルゴリズムを、計画中のノードの各子ノードに適用する、
ｆ）ノードの子ノードの終了示す「終了タグ」セグメントをビットストリームに書き込む、
ｇ）ノードの終端に添付した１以上のメタデータ又はエンセンスエレメントの各々を個々のセグメントとして書き込む、そして、
ｈ）ノードの終了示す「終了タグ」セグメントをビットストリームに書き込む。

図２は、図１ｂに類似するがメタデータを含むツリー状階層表現の簡単な例を示す。図３は、図２のツリー状階層に順にトラバーサルを行った結果、本発明の特徴に基づき順番に並べられたビットストリームを示す。

図２は、各ノードの開始ノード／終了ノードに付加されたメタデータのセグメントも示している点で図１ｂと異なっている。ノードが図１ｂのノードを修正したものであることを示すためにプライム符号を付けた参照番号を図２で用いている。したがって、ルートノード３´は、例えば、その開始部に付加されたメタデータの表題と版権を有する。フレーム
ノード４´及び５´は、例えば、各ノードの開始部に付加された時間コードと書くノードの終了部に付加された音量メタデータを有する。チャンネルノード６´，７´，８´及び９´は、例えば、各ノードの開始部に付加されたメタデータのダウンミックスを有する。

図３は、本発明によるアルゴリズムと階層に基づき順序付けられたビットストリームの例を示す。ビットストリームは、上述の「ボディタグなし」アルゴリズムに基づいて、図２の階層に順序付けられたトラーバーサルを行った結果得られた１０から３７までのセグメント（セグメントは「アトミックエレメント（atomic element）」とも称される）を有する。各エレメントは、オーディオエッセンス、メタデータ、又は他のデータを含んでいるとしても、その内容を示す一意的な識別子を用いて表示することが好ましい。適切な識別子について以下に記載する。

さらに以下に記載するとおり、ルートノード３´には、すべてオーディオ素材であるセグメント１０から３７までが含まれる。ルートノード３´内のフレームノード４´及び５´のネスティング及び、同様にフレームノードの各々に含まれるチャンネルノードのネスティングを図３で見ることができる。図３の例のビットストリームは、オーディオ素材の開始を示す、ルートノード開始タグセグメント１０から始まり、ルートノードの開始部に添付されたメタデータ（表題）セグメント１１とメタデータ（版権）セグメント１２が続く。次いで、フレームノード４´の開始部にフレームノード開始タグ１３と、それに続くメタデータ（時間コード）セグメント１４とが示された状態で、第１の子、フレームノード４´が現れる。次に、チャンネルノード開始タグ１５を表示させて、フレームノードの第１の子、チャンネルノード６´が現れる。このチャンネルノード開始タグセグメントに、チャンネルノード６´の開始部に付加されたメタデータ（ダウンミックス）セグメント１６が続く。このメタデータセグメント１６に、チャンネルノード６´の（チャンネル１）オーディオエッセンス１７とチャンネルノード終了タグ１８が続く。次に、チャンネルノード開始タグ１９を表示させて、フレームノード４´の第２の子、チャンネルノード７´が現れる。チャンネルノード開始タグセグメントに、チャンネルノード７´の開始部に付加されたメタデータ（ダウンミックス）セグメント２０が続く。このメタデータセグメント２０には、チャンネルノード７´の（チャンネル２）オーディオエッセンス２１とチャンネルノード終了タグ２２とが続く。フレームノード４´にはこれ以外に子はなく、またチャンネルノード６´とチャンネルノード７´はリーフノードなので、大きさのメタデータ２３を記載してフレームノード４´が再び現れる（この大きさのメタデータは、大きさのメタデータの値を決めるためにチャンネル１とチャンネル２のオーディオエッセンスを訪れるプロセスに依存する）。次いで、フレームタグセグメント２４の終了部がビットストリームに書き込まれる。そして、次のノード５´が現れる。

フレームノード４´について説明したのと同じようにして、フレーム５´とその子、ノード８´及びノード９´、から生じるビットストリームが書き込まれ、フレーム開始セグメント２５、メタデータ（時間コード）セグメント２６、チャンネルノード開始タグ２７、チャンネルノードメタデータ（ダウンミックス）セグメント２８、（チャンネル１）チャンネルノードオーディオエッセンスセグメント２９、チャンネルノード終了タグ３０、チャンネルノード開始タグ３１、チャンネルノードメタデータ（ダウンミックス）セグメント３２、（チャンネル２）チャンネルノードオーディオエッセンスセグメント３３、チャンネルノード終了タグ３４、フレームノード終了メタデータ（音量）３５、及びフレームタグセグメント３６が作られる。この簡単な例では２つのフレームしかないため、続いてルートノードが再度現れる。ルートノードの終了部にメタデータがない限り、オーディオ素材の終了を示すルートノード終了タグセグメント３７が書き込まれる。

意味的に独立であることに加えて、上述の通り、各セグメントは、各セグメントがそれぞれの形式と長さを持ち、他のセグメントを含まずまた他のセグメント内に入れ子になっていないという意味で構造的に独立している。したがって、他のセグメントについての知識をあらかじめ持つことなくセグメントを処理することができ、したがって必然的に、ビットストリームは１度に１つのセグメントが構文解析され、それにより、短い待ち時間の動作が可能となる。さらに、ノード又はセグメントの削除及び変更により、必ずしも他のノード又はセグメントの操作を必要としない。

そのような構造的なフレキシビリティーが与えられたとすると、セグメント、及び実際の全ノードは、メタデータとオーディオエッセンスが最適に配分されたなら、他のセグメント及びノードに影響を与えることなく、付加、削除、及び操作を行うことができる。このことは例えば、ビットストリームをそっくりそのまま再マスタリングする必要なしにオーディオ素材から特定のオーディオチャンネルを取り出すことを可能とする。特に、ノードは、システムの変更（すなわち、ビットストリームの他のノードにおける変更）を必要とする、長さ又は同期情報を含まないことが好ましい。長さ情報は、開始タグと終了タグがノードの境界を定めるので必要でない。ノード内にセグメントが存在するので、ノードの内容とセグメントが明らかに同期するので、同期情報の必要はない。一方、メタデータ及び／又はオーディオエッセンスは、例えば特定の階層レベルでノード間の相互依存させるような方法で配分することができ、この場合、待ち時間は増えることになる。例えば、発明の特徴の特定の実施の形態では、各フレームノードがタイムスタンプを持つこと及びタイムスタンプは連続するものであることを必要とする。１つのフレームノードを削除することにより、それに続くすべてのフレームノードの修正と、不快な設計判断が必要となる。

上述の通り、オーディオエッセンス、メタデータ、又は他のデータを含むか否かにかかわらず、その内容を示す一意的な識別子を用いて、階層内の各エレメントを表示することが好ましい。したがって、本発明に基づきフォーマットされたビットストリームを受け取った所定のアプリケーションは、アプリケーションが認識しないエレメントを無視する。このことにより、既存のアプリケーションに外乱を与えることなくビットストリームに新しい形式のエレメントを導入することができる。例えば、１以上のオーディオエッセンス強化レイヤーを、関連するメタデータとともに、前方互換性及び後方互換性をともに維持しながらビットストリームに付加することができる。あるいは１以上の強化レイヤーを、メタデータ内に含ませることができる。

図４ａから４ｄは、本発明の特徴に基づくビットストリームを用いたトランスコーディングプロセスを図解したものである。セグメントはビットストリーム中に現れたとき連続的に処理される。図４ａは、トランスコーディング処理に先立つ本発明による２チャンネルビットストリームを示す。セグメント（ａ）及び（ｂ）はフレーム１のチャンネル１及びチャンネル２に対応するオーディオ情報を有している。セグメント（ｃ）
及び（ｄ）はフレーム２のチャンネル１及びチャンネル２に対応するオーディオ情報を有している。図４ｂにおいて、トランスコーディングプロセスがオーディオ情報を含有するセグメント（ａ）に遭遇したとき、６つのセグメントがすでに読み込まれている。このプロセスで、ビットストリームからセグメントを読み込み、オーディオ情報を導き出し、このオーディオ情報を目的のフォーマットにトランスコードし、そして、このオーディオ情報をラップして（ａ）の代わりにビットストリームに書き込むセグメント（ａ´）に戻す。チャンネルノードがお互いにトランスコーディングの文脈で互いに依存していない限り、これまでのあるいはこれからのノードについての知識を必要としない。このことは待ち時間の短い操作で、すなわち、すべてのビットストリーム又はビットストリームの大部分で行われるトランスコーディングがトランスコーディングプロセスにより受け取られる操作で、重要である。図４ｃにおいて、図４ｂとの関連において記載したような方法で、セグメント（ｂ´）として書き込まれるセグメント（ｂ）にトランスコーディングプロセスが至っている。図４ｄは、すべてトランスコードされたビットストリームを示す。

以下に本発明の特徴の一実施の形態を記載する。本発明はこの実施の形態又は他の実施の形態に限定されるものではないことは理解されよう。以下の明細書はビットストリームの構文と文法、ビットストリームのアトミックエレメントの構造、及び、これらのエレメントに合致する構成を記述しているが、これは、メタデータとオーディオエッセンスの関係のような、ビットストリームの意味的な内容を記載するものではない。これらの関係は本発明の範囲を超えている。

ここで用いられている専門用語、特に本実施の形態との関連で用いられるものは以下に定義される。

下にあるオーディオ素材：
自己完結したビットストリームにより表され、本発明の特徴に基づきフォーマットされ、ノード及びセグメントからなるオーディオ情報である。

ノード：
開始タグと終了タグの対のタグにより区分けされた、１つの階層レベルに属する、ゼロ以上の連続するビットストリームセグメントである。ノードは入れ子になってもよい。

セグメント（アトミックエレメント）：
明確に独立したものとして操作（例えば、パッケージ化、又は暗号化）することのできる最小のビットストリームエレメントである。ここには３つのタイプのセグメントがある。すなわち、オーディオエッセンスセグメント、メタデータセグメント（オーディオエッセンスセグメントとメタデータセグメントは「内容」セグメントである）、及びタグセグメント（タグセグメントは「構造的」セグメントであり、例えば、ビットストリームとツリー状階層とをお互いに関連付けるのを手助けする）。セグメントは、その長さ、型式、及び／又は内容の情報を持っている。

オーディオエッセンスセグメント：
オーディオエッセンス（オーディオ情報）を持つ内容セグメントである。オーディオエッセンスセグメントは、例えば、エンコードされていないパルスコードモジュレーション（ＰＣＭ）オーディオデータ又はエンコードされたＰＣＭオーディオデータ（例えば、知覚的にエンコードされたＰＣＭ）であることもある。

メタデータセグメント：
対応するオーディオエッセンスと関連するメタデータ情報を持つ内容セグメントである。

タグセグメント：
ノードを区分けするために用いられる内容を持たないセグメントである。

フレーム：
オーディオ素材と、このようなオーディオエッセンスセグメントに関連する１以上のメタデータセグメントとの時間間隔を表す１以上のオーディオエッセンスセグメントからなるビットストリームノードである。

フレームのグループ：
１以上のメタデータセグメント分だけ先行するフレームのシーケンスであり、任意的に、１以上のメタデータセグメントが後に続く。

本発明に基づきフォーマットされたビットストリームは、オーディオコーディング、オーディオメタデータ、及び伝送方法とは独立に定義され、それ自体は、エラー修正や圧縮固有のメタデータを含まなくてもよい。

［セグメント］
以上に示したように、セグメントつまりアトミックエレメントは、明確に独立したものとして操作（例えば、パッケージ化、又は暗号化）することのできる最小のビットストリームエレメントである。実際には、各セグメントは、ヘッダ、収容形式及び大きさの情報、及び、オーディオの場合に、メタデータセグメント及びペイロードからなる、バイトで並べた構造とすることができる。タグセグメントは構造的な情報を有し、ペイロードは持たない。内容セグメントは、ペイロードとしてメタデータ又はエッセンス情報を有する。セグメントの型式とその意味的重要性は、一意的な識別子を用いることによりさらに正確にすることができる。セグメントの構文については、以下にさらに詳細に説明する。

［ノード］
セグメントはさらに、階層的にネスト構造のノードに配列される。本実施の形態において、ノードは開始セグメントと終了セグメントの制約を受けるシーケンスにより構成される。図５に示すように、ツリー状階層におけるノードの構造は３つの明確な文脈（又は部分）、すなわち、ヘッダ（header）コンテキスト４０、本体（body）コンテキスト４１、及びトレイラ（trailer）コンテキスト４２、により成り立つ。ヘッダコンテキストとトレイラコンテキストは各々１以上の内容セグメントを含み、本体コンテキストはゼロ又は１以上の子ノードを含む。任意的に、本体部は本体開始タグセグメントと終了タグセグメントの制約を受けることもある。

図５を詳細に参照して、ノード構造は開始タグセグメント４３で始まり、終了タグセグメント４４で終了する。タグセグメント４３と４４は、タグのタイプが階層におけるノードの位置に依存するので、それぞれ「Ｘ」で印している。本実施の形態のルートノードの場合、タグセグメントはフレームタグのグループ（ＧＯＦ ｔａｇ）であってもよい。開始タグセグメント４３の後に、ヘッダコンテキスト４０が続き、ヘッダコンテキスト４０は１以上の内容セグメント４５を持つことができる。続いて、本体開始タグ４６により、図５に示したノードの下の１以上の階層レベルでネスト化された１以上のノード４７を含む本体部４１の開始部を定めることができる。本体終了タグ４８により、本体コンテキスト４１の終了部を定めることができる。本体終了タグ４８の後に、トレイラコンテキスト４２が続き、トレイラコンテキスト４２は１以上の内容セグメント４９を持つことができる。最後に、ノード構造は終了タグセグメント４４により終了する。

リーフノードがオーディオエッセンスとそれに関連するメタデータを含むような場合、もし本体コンテキストと終了コンテキストの両方が空であるならば、本体タグを省略することができ、図６に示すように、ノードは短いノードになる。本体タグが無い場合、ヘッダコンテキストとフッタコンテキストとは区別することができないので、短いノードは開始部４０´のみに限定される。図６を詳細に参照して、ノード構造は開始タグセグメント５０で始まり終了タグセグメント５１で終わる。図５の例の場合は、タグセグメントは、タグのタイプが階層におけるノードの位置に依存するので、「Ｘ」で印している。本実施の形態においてリーフノードの場合、タグセグメントはチャンネルタグでもよい。ヘッダコンテキスト４０´は開始タグとエンドタグとの間にあり１以上の内容セグメント４５´からなる。

［階層構造］
ビットストリームの階層構造は、ノードの本体部の構造により定めることができる。ノードと係わり合いのあるヘッダコンテキストとトレイラコンテキストの意味及び内容は、本発明のビットストリームフォーマットが採用されるが本発明を形成するものではない環境において、特有のものである。

拡張性を良くするために、内容セグメントとノードから外れた部分は省略してもよく、本発明の特徴に基づきフォーマットされたビットストリームを受け取り処理するアプリケーションはこれを無視してもよい。しかし、コンテキスト内にあって異常なノードはエラーとして扱うことができる。「コンテキスト内」とは、特定のノード部に属すと定義されたセグメント及びノードを意味する。例えば、以下に説明するように、先端チャンネル（ＴＯＣ）ノードは、フレーム本体にあるときはコンテキスト内であるが、ＧＯＦノード内にあるときはコンテキスト外である。このようなアプローチにより、古いアプリケーションと互換性を保ちながら、付加的な内容セグメントとノードを挿入することにより前方互換性を容易に持たせることができる。

図７に示すように、本発明によるビットストリームは、そのルートに１以上のフレームのグループ（ＧＯＦ）ノードの階層構造となっている。ＧＯＦノードのみがこの例のルートノードの文脈内である。

［フレームのグループ（ＧＯＦ）ノード］
ＧＯＦノード６０，・・・，６１（図７）は、ビットストリームにより運ばれるオーディオ素材の部分を正確に再現するのに必要な情報が含まれる構成要素である。フレームノードは、各ＧＯＦノード内にネスト化される。ＧＯＦノードは、ＧＯＦの境界でビットストリームが簡単に操作（例えば、接合）できるよう、十分な情報を持つことが理想である。

［フレームノード］
フレームノード６２，・・・，６３（図７）は、オーディオエッセンスと時間区間に相当するメタデータ情報により成り立つ。１つのチャンネル先端（ＴＯＣ）ノードと１つのチャンネル下端（ＢＯＣ）ノードを各フレームノード内にネスト化することができる。フレームレベルにあるメタデータは、すでにＧＯＦレベルで見つかるものを補完することができ、フレームノードでの変化に影響を受けるようにすることができる。フレームレベルのメタデータがフレームを横切って変化しなければ、フレームノードは独立となるであろう。要求がなくても、フレームをピクチャーエッセンスと同期化させてもよい。あるいは、チャンネルを３以上のノードにグループ化するか又は、チャンネルをチャンネルノードがインコンテキストノードとなるように各フレームノードの下に直接ネスト化してもよい。

［ＴＯＣノード及びＢＯＣノード］
ＴＯＣノード及びＢＯＣノードは、それぞれフレームに含まれる情報のほぼ半分に相当するメタデータとエッセンス情報とを有することができる。このように構成することにより、そのすべてを受信又は伝送する前にエンコーダとデコーダにフレームの処理を開始させることができるので、待ち時間を減らすことができる。ＴＯＣ本体部とＢＯＣ本体部とはゼロ又は１以上のチャンネルノードを有することができる。

［チャンネルノード］
各チャンネルノードは、単一の独立の本質的な存在を表現し、ゼロ又は１以上のメタデータセグメントとともに一般に１以上のエッセンスセグメントを含有する。このビットストリームフォーマットの実施の形態において、チャンネルノードの本体は空であり、もし終了部が定義されない場合は、ノード構造は短いノードフォームを取ることができる。

［セグメント仕様］
セグメントは、簡易Ｃ言語構文に基づく以下の仮のコードにより詳細仕様を定めることができる。２ビットより大きな大量の要素に対しては、ビットの到着順序はいつも最上位ビット（ＭＳＢ）が最初である。フレーム中の領域又は要素は太い活字で示される。

///
///
///
///
///
///
///
///

［タグセグメントパラメータ］

「ｉｓ_ｔａｇ」パラメータ
語長：１
有効範囲：１
タグセグメントは常に１のｉｓ_ｔａｇパラメータを持つ。

「ｓｔａｒｔ_ｏｒ_ｅｎｄ」パラメータ
語長：１
有効範囲：０（開始），１（終了）
このパラメータの値は、タグが開始タグ（０）なのか終了タグ（１）なのかを示す。

「ｉｓ_ｌｏｎｇ_ｉｄ」パラメータ
語長：１
有効範囲：０（５ビット ｉｄ ｆｉｅｌｄ），１（１３ビット ｉｄ ｆｉｅｌｄ）
このパラメータの値は、ｔａｇ_ｉｄ ｆｉｅｌｄが５ビットなのか１３ビットなのかを示す。

「ｔａｇ_ｉｄ」パラメータ
語長：５又は１３（前記パラメータ参照）
有効範囲：［０．．３１］又は［０．．２^１３−１］
このパラメータの値は、セグメントはどのタグを表示しているかを示す。以下のタグを定義することができる。

［内容セグメントパラメータ］
「ｉｓ_ｔａｇ」パラメータ
語長：１
有効範囲：０
内容セグメントは常に０のｉｓ_ｔａｇ値を持つ。

「ｍｅｔａｄａｔａ_ｏｒ_ｅｓｓｅｎｃｅ」パラメータ
語長：１
有効範囲：０（メタデータ），１（エッセンス）
このパラメータの値は、セグメントがメタデータ（０）を有しているのかエッセンス（１）を有しているのかを示す。

「ｉｓ_ｌｏｎｇ_ｉｄ」パラメータ
語長：１
有効範囲：０（５ビット ｉｄ ｆｉｅｌｄ），１（１３ビット ｉｄ ｆｉｅｌｄ）
このパラメータの値は、ｃｏｎｔｅｎｔ_ｉｄ ｆｉｅｌｄが５ビットなのか１３ビットなのかを示す。

「ｃｏｎｔｅｎｔ_ｉｄ」パラメータ
語長：５又は１３（前記パラメータ参照）
有効範囲：［０．．３１］又は［０．．２^１３−１］
このパラメータの値は、セグメント内に含まれる情報の型式を一意的に特定する。

「ｃｏｎｔｅｎｔ_ｌｅｎｇｔｈ_ｃｌａｓｓ」パラメータ
語長：２
有効範囲：［０．．３１］
このｃｏｎｔｅｎｔ_ｌｅｎｇｔｈ_ｃｌａｓｓパラメータは、以下の表により、セグメントの最大長さを定めることができる。

「ｃｏｎｔｅｎｔ_ｌｅｎｇｔｈ」パラメータ
語長：（content_length_class＋１）＊８−２
有効範囲：［０．．６３］（content_length_class＝＝０）
［０．．１６３８３］（content_length_class＝＝１）
［０．．２^２２］（content_length_class＝＝２）
［０．．２^３０］（content_length_class＝＝３）
このｃｏｎｔｅｎｔ_ｌｅｎｇｔｈパラメータは、ペイロードのトータル長さをバイト単位で定める。

［ＡＣ−３シリアルコーディッドオーディオビットストリームのカプセル化の例］
上述のように、エンコードされたオーディオ情報を、本発明の特徴に従ってフォーマットされたビットストリームのセグメントとしてカプセル化することができる。この例として、ＡＣ−３シリアルコーディッドオーディオビットストリーム（AC-3 serial coded audio bit stream）の本質的部分を、以下のようにカプセル化することができる。

ＡＣ−３ディジタルオーディオ圧縮標準は、ＡＴＳＣ標準、ディジタルオーディオ圧縮（ＡＣ−３），改定Ａ，ドキュメントＡ／５２Ａ，次世代テレビジョンシステム協会（Advanced Television Systems Committee），２００１年８月２０日発行（Ａ／５２Ａドキュメント）に記載されている。このＡ／５２Ａドキュメントは参照としてそのすべてを本明細書に組み込む。

このＡＣ−３ビットストリームシンタックスは、Ａ／５２Ａドキュメントの第５節（その他）に記載されている。ＡＣ−３シリアルコーディッドオーディオビットストリームは、同期したフレーム（「同期フレーム（sync flames）」）のシーケンスとして作られる。図８Ａは、本発明の特徴に基づきＡＣ−３の２つの同期フレームをビットストリームへマッピングしたものを示す。各ＡＣ−３の同期フレームは、各々が２５６の新しいオーディオサンプルを表す６つのコード化されたオーディオブロック（ＡＢ０からＡＢ５まで）を有する。各フレームの開始部の同期情報（ＳＩ）ヘッダは同期を行い保持するために必要な情報を有する。ＳＩの後にビットストリーム
情報（ＢＳＩ）ヘッダが続き、コード化されたオーディオサービスを記述するパラメータを有する。コード化されたオーディオブロックの後に補助データ（Ａｕｘ）領域を続けることができる。しばしば補助データは、ＡＣ−３フレームのビット長さを調整するための、空の「詰め物（padding）」ビットにより構成される。しかし、補助データに情報が含まれる場合もある。各フレームの終了部は、エラー検出のためのＣＲＣワードを含む、エラーチェック領域となっている。付加的なＣＲＣワードはＳＩヘッダにあり、この使用は任意的である。

図８ａは、それ自身は２つのフレームノードからなり、各々が１以上のＡＣ３チャンネルを表現するフレームノードのグループからなるビットストリームにＡＣ−３の同期フレームをマッピングしたものを描いたものである。ＳＩヘッダとＢＳＩヘッダとに含まれるメタデータアイテムは、２つのグループに分割される。すなわち（１）フレームに対して一般的なメタデータ、例えば、時間コード、及び（２）ＡＣ３及びそのチャンネルに特有のメタデータである。一般的なメタデータは、「ＧＦＭ」メタデータセグメントにラップされ、特有のメタデータは「ＡＣ３Ｍ」メタデータセグメントにラップされる。ユーザビットが含まれる場合、この補助ブロックは補助セグメントにラップされ、詰め物としてのみ使われる場合は、削除される。所定のビットストリームは、自分でエラー検出機構を有するさまざまなインターフェースを横切って動くので、エラー訂正及び検出情報は省略してもよい（ＣＲＣブロックは省略できる）（省略したものが示されている）。

より詳しくは、図８ａに２つのＡＣ−３の同期フレームが示されており、各々、順番にＳＩ，ＡＢ０からＡＢ５，Ａｕｘ及びＣＲＣ要素を含んでいる。カプセル化のために２つのＡＣ−３同期フレームがマッピングされている本発明の特徴に従ったビットストリームには、第１のＧＯＦ開始タグとそれに続いて、フレーム開始タグ（ＦＲＭ），一般的なフレームメタデータ（ＧＦＭ），ＡＣ−３チャンネル開始タグ（ＡＣ３），ＡＣ−３特有のメタデータ（ＡＣ３Ｍ），ＡＣ−３内容セグメント（ＡＢ０からＡＢ５及びＡｕｘ），ＡＣ−３チャンネル終了タグ（ＡＣ３），フレーム終了タグ（ＦＲＭ），及び第２のＡＣ−３同期フレームからマッピングされた同じシーケンスが含まれている。

図８ｂは、図８ａに２つの補助的なオーディオチャンネルを追加したカプセル化したビットストリームが描かれている。各チャンネルを一般的なチャンネル（ＧＣＨ）ノードに含ませることができる。第１のチャンネルには、線形ＰＣＭサンプルからなる管理者指示（ＤＣ）チャンネルを含ませることができる。一般チャンネルメタデータ（ＧＣＭ）セグメントはこのチャンネルをＤＣチャンネルを含むものとして識別する。第２のチャンネルには、符号励振型線形予測（Code-Excited Linear Prediction）（「ＣＥＬＰ」）（損失のあるエンコードされた音声オーディオフォーマット）でエンコードされたオーディオを含むことのある視覚障害者（ＶＩ）チャンネルが含まれていてもよい。また一方、一般チャンネルメタデータ（ＧＣＭ）セグメントはこのチャンネルをＶＩ素材を含むものとして識別する。各付加的なチャンネルに含まれるオーディオ内容の持続期間は、持続期間が一定である、ＡＣ３ノード中のオーディオ内容と一致していることが好ましい。さらに、ビットストリームを識別するメタデータをメタデータセグメントフレームのグループ（ＧＯＦＭ）に追加してもよい。

さらに詳しくは、図８ｂに、補助的な管理者指示と視覚障害者オーディオチャンネルが付け加えられたマッピングされた第１のＡＣ−３同期フレームの詳細が示されている。このビットストリームには、第１のＧＯＦ開始タグとそれに続くビットストリームを識別するメタデータ（ＧＯＦＭ），フレーム開始タグ（ＦＲＭ），一般的フレームメタデータ（ＧＦＭ），ＡＣ−３チャンネル開始タグ（ＡＣ３），ＡＣ−３特有のメタデータ（ＡＣ３Ｍ），ＡＣ−３内容セグメント（ＡＢ０からＡＢ５及びＡｕｘ），ＡＣ−３チャンネル終了タグ（ＡＣ３），一般的チャンネル開始タグ（ＧＣＨ），一般的チャンネルメタデータ（ＧＣＭ），線形ＰＣＭオーディオエッセンスセグメント（ＰＣＭ），一般的チャンネル終了タグ（ＧＣＨ），一般的チャンネル開始タグ（ＧＣＨ），一般的チャンネルメタデータ（ＧＣＭ），ＣＥＬＰエンコードされたオーディオエッセンス（ＣＥＬＰ），一般的チャンネル終了タグ（ＧＣＨ），及びフレーム終了タグ（ＦＲＭ）が含まれている。第２のフレーム（一部だけ図示）には、第２のフレーム情報を含む同じシーケンスが繰り返される。

本発明によるフォーマットの利点は、２つの追加のチャンネルを挿入するためにＡＣ３データの修正を必要としないことであり、元のビットストリームが流れているかのようにチャンネルの挿入がなされることである。すなわち、第２のフレーム（不図示）にＶＩチャンネルを挿入するのに、第１のフレームの内容についての知識を必要としない。さらに、ＶＩ及び／又はＤＣチャンネルを中断することのできないデコーダがこれらのチャンネルを無視することができる。例えば、ＶＩ及びＤＣチャンネルを、ビットストリームの内容を指示する仕様書の改訂版に追加していてもよい。このようにして、ビットストリームは、後方互換性を持つ。

図９は、本発明の特徴に基づき、図３の例と同様のビットストリームを作るためのエンコーダ又はエンコーディングプロセスのさまざまな機能的特徴を、フローチャート又は機能ブロック線図の形式で示したものである。線形ＰＣＭエンコードされたオーディオのサンプルとすることのできるオーディオエッセンス９１のストリームは、例えば、オーディオを適切な（固定された又は可変の）持続時間のブロックに区分けし、圧縮（例えば、ビットレート縮減エンコーディング）のような追加の処理を行うことのできる、オーディオ分割及び処理機能又は装置９３に適用される。その結果出来たオーディオデータを、オーディオ内容セグメントにラップすることができ、その一例９５が図解的に示されている。オーディオ
エッセンス上の情報はメタデータ発生器９７に送られる。後者は、このような情報、及び、オーディオエッセンスと同期又は非同期のビットストリームに挿入するメタデータセグメントを作るための、ユーザ又は他の機能又は装置（不図示）からの情報のような他の情報に用いられる。

オーディオ内容セグメントは、次に、１以上のオーディオ内容セグメントと、１以上のそれに付随する、メタデータ発生装置から取得したメタデータセグメント（本例では、ダウンミックス（ＤＭ）した１つのメタデータ）とをチャンネルノード開始タグ及び終了タグとともに含むチャンネルノード（図２の階層レベル２と比較せよ）を発生させるチャンネルノード直列変換機能又は直列変換器９９に送られる。チャンネル開始タグ（ＣＨＡＮ），ダウンミックスメタデータ（ＤＭ），オーディオエッセンスセグメント，及びチャンネル終了タグ（ＣＨＡＮ）を含んだものとして、チャンネルノードの一例１０１が図解的に示されている。

チャンネルノードは、入力チャンネルノードと、それに付随する、メタデータ発生器９７から取得したフレームレベルメタデータ（本例では、時間コード（ＴＣ）メタデータの１セグメント）と、フレームノード開始タグ及び終了タグとを、ともに含むフレームノード（図２の階層レベル２と比較せよ）発生させるフレームノード直列変換器１０３へ送られる。フレーム開始タグ（ＦＲＡＭ），時間コードメタデータ（ＴＣ），チャンネルノードシーケンス，及びフレーム終了タグ（ＦＲＡＭ）を含んだものとして、フレームノードの一例１０５が図解的に示されている。

フレームノードは、フレームグループ開始タグ及び終了タグとともに連続するフレームノードとそれに付随するメタデータ発生器９７から取得したメタデータ（本例では、タイトル（ＴＩＴＬ）メタデータの１セグメント）とを１つの完全なビットストリームに結合させる（図２の階層レベル１と比較せよ）、フレームグループ（ｇｏｆ）ノード直列変換機能又は装置１０７に送られる。フレームグループ開始タグ（ＧＯＦ），タイトルメタデータ（ＴＩＴＬ），２つのフレームシーケンス，及びフレームグループの終了タグ（ＧＯＦ）を含んだものとして完全なビットストリームの一例が図解的に示されている。

図１０は、本発明の特徴に基づき図３と図９の例のようなビットストリームからオーディオ及びメタデータを導き出すためのデンコーダ又はデコーディングプロセスのさまざまな機能的特徴を、フローチャート又は機能ブロック線図の形式で示したものである。

図９の例で作られたようなビットストリームは、フレームグループ（ｇｏｆ）ノード並列変換器１２１に送られる。このｇｏｆノード並列変換器は、ｇｏｆ開始タグと終了タグ及びメタデータ（本例では、タイトル（ＴＩＴＬ）メタデータ）を認識して除去し、このメタデータをメタデータインタープリタ１２３に送り、フレームノードをフレームノード並列変換器１２５に送る。図９のフレームノード１０５と本質的に同じであるフレームノード１０５の一例が図解的に示されている。

フレームノード並列変換器１２５は、フレームノード開始タグと終了タグ及びメタデータ（本例では、時間コードメタデータ（ＴＣ））を認識して除去し、このメタデータをメタデータインタープリタ１２３に送り、チャンネルノードをチャンネルノード並列変換器１２７に送る。図９のチャンネルノード１０１と本質的に同じであるチャンネルノード１０１の一例が図解的に示されている。

チャンネルノード並列変換器１２７は、チャンネルノード開始タグと終了タグ及びメタデータ（本例では、ダウンミックス（ＤＭ）メタデータ）を認識して除去し、このメタデータをメタデータインタープリタ１２３に送り、オーディオエッセンスセグメントを、図９のエンコーダ又はエンコーディングプロセスに適用されたオーディオエッセンスと本質的に同じオーディオエッセンス９１のストリームに類似するオーディオレンダリングプロセス又は装置１２９に送る。

メタデータインタープリタ１２３は、さまざまなメタデータを解釈し、それを（不図示の）機能及び／又は装置及びオーディオレンダリング１２９に適用する。

本発明とその種々の形態はディジタル信号プロセッサ、プログラムされた汎用ディジタルコンピュータ、及び／又は特定目的のディジタルコンピュータにおけるソフトウェアのようなさまざまな方法で実施することができる。アナログ信号ストリーム及び／又はディジタル信号ストリーム同士のインターフェースは適切なハードウエア及び／又はソフトウエアの機能及び／又はファームウエアの機能として実施することができる。本発明とその種々の形態は、その元の信号としてアナログオーディオ信号を用いるが、実際の応用例では、おそらくほとんどの処理機能は、オーディオ信号がサンプルとして表現されるディジタル信号ストリームのディジタル領域で実施されるであろう。

本発明の特徴に基づきフォーマットされたビットストリームは、１以上の既知のデータ記憶媒体及び伝送手段により記憶又は伝送することができる。

本発明を変形又は修正した他の実施例及びその様々な形態は当業者には明らかであり、上記にて説明した発明の具体的実施形態に限定されるものではないことは了解されよう。したがって、本発明のすべての変形、修正、又はここに開示し請求した基本的な原則及び思想の範囲内と同等のものは、本発明に含まれると考える。

本発明の特徴に基づくビットストリームのオーディオ情報（ここではしばしば「オーディオエッセンス」と称す）成分とツリー状階層を示した簡略化した図式表現である。 本発明の特徴に基づくビットストリームのオーディオ情報（ここではしばしば「オーディオエッセンス」と称す）成分とツリー状階層表現を示した簡略化した図式表現である。 図１ｂに類似するがメタデータを含むツリー状階層表現を示した簡略化した図式表現である。 図２のツリー状階層に順にトラバーサルを行った結果、本発明の特徴に基づき順番に並べられたビットストリームを示した簡略化した図式表現である。ここで、図２は、各ノードの開始部及び／又は終了部に添付されたメタデータのセグメントも示している点で異なる。 本発明の特徴に基づくビットストリームを用いたトランスコーディングプロセスを示した簡略化した図式表現である。 本発明の特徴に基づくビットストリームを用いたトランスコーディングプロセスを示した簡略化した図式表現である。 本発明の特徴に基づくビットストリームを用いたトランスコーディングプロセスを示した簡略化した図式表現である。 本発明の特徴に基づくビットストリームを用いたトランスコーディングプロセスを示した簡略化した図式表現である。 本発明の特徴に基づくツリー状階層のノードの構造の簡略化した図式表現である。 短いノードの構造の簡略化した図式表現である。 本発明に基づく階層ツリーの一例の簡略化した図式表現である。 本発明の特徴に基づくビットストリームへ２つのＡＣ-３同期フレームをマッピングしたものを示す簡略化した図式表現である。 ２つの補助的なオーディオチャンネルを加えた図８ａのカプセル化したＡＣ-３ビットストリームを示す簡略化した図式表現である。 本発明の特徴に基づき、図３の例に類似するビットストリームを作るためのエンコーダ又はエンコーディングプロセスの種々の機能的特徴をフローチャート又は機能ブロック線図で示した簡略化した図式表現である。 本発明の特徴に基づき、図３及び図９の例のようなビットストリームからオーディオエッセンスとメタデータを導き出すためのデコーダ又はデコーディングプロセスの機能的特徴をフローチャート又は機能ブロック線図で示した簡略化した図式表現である。

Claims (19)

1. ツリー状階層データ構造を順に横断してゆくことによりビットストリームシンタックスを記述する、オーディオ情報を表示するビットストリームフォーマットであって、該ツリー状階層は、
   それぞれが１以上のノードを持つ複数のツリー状階層レベルであって、少なくともいくつかの徐々に小さくなるオーディオ情報のサブディビジョンが徐々に前記ツリー状階層の低いレベルにおいて表示されることを特徴とするツリー状階層レベルを具備し、前記オーディオ情報は、前記１以上のレベルにおけるノードに含まれることを特徴とするビットストリームフォーマット。
2. 前記ビットストリームシンタックスが請求項１に記載のツリー状階層で記述されるビットストリームフォーマットであって、前記徐々に小さくなるオーディオのサブディビジョンには、１以上の時間的サブディビジョン、空間的サブディビジョン、及び分解能的サブディビジョンが含まれることを特徴とするビットストリームフォーマット。
3. 前記ビットストリームシンタックスが請求項１に記載のツリー状階層で記述されるビットストリームフォーマットであって、前記ツリー状階層の第１のレベルは前記オーディオ情報のすべてを表示するルートノードを具備し、それより低い少なくとも１つのレベルは前記オーディオ情報の時間間隔を表示する複数のノードを具備することを特徴とするビットストリームフォーマット。
4. 前記ビットストリームシンタックスが請求項３に記載のツリー状階層で記述されるビットストリームフォーマットであって、さらに低い少なくとも１つのレベルは前記オーディオ情報の空間的サブディビジョンを具備することを特徴とするビットストリームフォーマット。
5. 請求項１乃至請求項４のいずれか１項に記載のビットストリームフォーマットであって、該ビットストリームは独立したタグセグメントとコンテントセグメントのシーケンスを具備し、各タグセグメントはデリミタとして機能し、各コンテントセグメントはオーディオ情報又はオーディオ情報に関するメタデータを持つペイロードを有し、前記セグメントは前記ツリー状階層レベルにて構造的に独立して階層的にネストされた構成となっていることを特徴とするビットストリームフォーマット。
6. 請求項５に記載のビットストリームフォーマットであって、各ノードが開始タグセグメント及び終了タグセグメントにより区切られることを特徴とするビットストリームフォーマット。
7. 請求項６に記載のビットストリームフォーマットであって、開始タグセグメント及び終了タグセグメントにより、ノード内のヘッダコンテキストとフッタコンテキストが区切られることを特徴とするビットストリームフォーマット。
8. 請求項１乃至請求項７のいずれか１項に記載のビットストリームフォーマットであって、オーディオ情報を持つ１以上のコンテントセグメントを有するノードが、オーディオ情報を持つ前記１以上のコンテントセグメント中の前記オーディオ情報に関するメタデータを持つ１以上のコンテントセグメントを有することを特徴とするビットストリームフォーマット。
9. 請求項１乃至請求項８のいずれか１項に記載のビットストリームフォーマットに基づきフォーマットされたビットストリーム。
10. 請求項１乃至請求項８のいずれか１項に記載のビットストリームフォーマットに基づくフォーマットを有するビットストリームをエンコーディング及びデコーディングするシステム。
11. 請求項１乃至請求項８のいずれか１項に記載のビットストリームフォーマットに基づくフォーマットを有するビットストリームをエンコーディングするエンコーダ。
12. 請求項１乃至請求項８のいずれか１項に記載のビットストリームフォーマットに基づくフォーマットを有するビットストリームをデコーディングするデコーダ。
13. 請求項１乃至請求項８のいずれか１項に記載のビットストリームフォーマットに基づくフォーマットを有するビットストリームをトランスコーディングする装置。
14. 請求項１乃至請求項８のいずれか１項に記載のビットストリームフォーマットに基づきフォーマットされたビットストリームを作る工程。
15. 請求項１乃至請求項８のいずれか１項に記載のビットストリームフォーマットに基づくフォーマットを有するビットストリームをエンコーディング及びデコーディングする工程。
16. 請求項１乃至請求項８のいずれか１項に記載のビットストリームフォーマットに基づくフォーマットを有するビットストリームをエンコーディングする工程。
17. 請求項１乃至請求項８のいずれか１項に記載のビットストリームフォーマットに基づくフォーマットを有するビットストリームをデコーディングする工程。
18. 請求項１乃至請求項８のいずれか１項に記載のビットストリームフォーマットに基づくフォーマットを有するビットストリームをトランスコーディングする工程。
19. 請求項９に記載のビットストリームを記憶又は伝送するための媒体。

Images