JP2013545391A

JP2013545391A - 高次アンビソニックス・オーディオ・データ用のデータ構造

Info

Publication number: JP2013545391A
Application number: JP2013537071A
Authority: JP
Inventors: ケイラー，フロリアン; コルドン，スベン; ベーム，ヨハネス; クロップ，オルガー; バトケ，ヨハン−マルクス
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2010-11-05
Filing date: 2011-10-26
Publication date: 2013-12-19
Anticipated expiration: 2031-10-26
Also published as: US9241216B2; PT2636036E; BR112013010754A8; AU2011325335B8; EP2450880A1; US20130216070A1; KR101824287B1; BR112013010754A2; KR20140000240A; CN103250207A; BR112013010754B1; EP2636036A1; AU2011325335A8; HK1189297A1; CN103250207B; AU2011325335B2; EP2636036B1; WO2012059385A1; JP5823529B2; AU2011325335A1

Abstract

本発明は、高次アンビソニックスHOAオーディオ・データのためのデータ構造に関し、当該データ構造は一つまたは複数の異なるHOAオーディオ・データ・ストリーム記述についての2Dまたは3D空間的オーディオ・コンテンツ・データを含む。前記HOAオーディオ・データは「3」より大きな次数をもつことができ、当該データ構造はさらに、固定したまたは時間変化する空間位置からの単独オーディオ信号源データおよび／またはマイクロホン・アレイ・オーディオ・データを含むことができる。

Description

本発明は、高次アンビソニックス・オーディオ・データ用のデータ構造に関する。これは2Dおよび／または3Dの空間的オーディオ・コンテンツを含み、「3」より大きな次数をもつHOAオーディオ・データにも好適である。

3Dオーディオは、下記で述べる高次アンビソニックス（HOA: Higher Order Ambisonics）と呼ばれる技法による音場記述を使って実現されうる。HOAデータの記憶は、所与の再生スピーカー・セットアップにおける再生のためのスピーカー信号を生成できるために特別なデコーダによってどのようにこのデータが使用されなければならないかのいくつかの規約および規定を必要とする。既存の記憶フォーマットはどれも、HOAのためのこれらの規定すべてを定義するものではない。たとえば非特許文献１に記載される*.ambファイル・フォーマット実現をもつBフォーマット（拡張可能な「Riff/wav」構造に基づく）が今日利用可能な最も洗練されたフォーマットである。.ambファイル・フォーマットは2000年にICMC Berlin 2000においてR.W. Dobsonによって「Developments in Audio File Formats」において提示された。

2010年7月16日の時点では、非特許文献２で既存のファイル・フォーマットの概観が開示されており、同じサイトでアンビソニックス交換フォーマットについての提案も開示されている。

米国特許第4042779号国際公開第03/061336号

Martin Leese、"File Format for B-Format"、2009年3月30日、http://www.ambisonia.com/Members/etienne/Members/mleese/file-format-for-b-format Ambisonics Xchange Site、"Existing formats"、http://ambisonics.iem.at/xchange/format/existing-formats "A first proposal to specify, define and determine the parameters for an Ambisonics exchange format"、http://ambisonics.iem.at/xchange/format/a-first-proposal-for-the-format M.A. Poletti、"Three-dimensional surround sound systems based on spherical harmonics"、Journal of Audio Engineering Society、53(11)、pp.1004-1025、November 2005 Earl G. Williams、"Fourier Acoustics"、Academic Press、1999 Mark Poletti、"Unified description of Ambisonics using real and complex spherical harmonics"、Proceedings of the Ambisonics Symposium 2009、Gras、Austria、June 2009 http://www.ipgp.fr/~wiecsor/SHTOOLS/www/conventions.html http://en.citisendium.org/wiki/Spherical harmonics William H. Press、Saul A. Teukolsky、William T. Vetterling、Brian P. Flannery、"Numerical Recipes in C"、Cambridge University Press、1992 Jerome Daniel、"Repr´esentation de champs acoustiques, application ｀a la transmission et ｀a la reproduction de sc｀enes sonores complexes dans un contexte multim´edia"、博士論文、Universit´e Paris 6、2001 Dave Malham、"3-D acoustic space and its simulation using ambisonics"、http://www.dxarts.washington.edu/courses/567/current/malham 3d.pdf J´er＾ome Daniel、"Spatial sound encoding including near field effect: Introducing distance coding filters and a viable, new ambisonic format"、AES 23rd International Conference、Denmark、May 2003 M.A. Gerson、"General metatheory of auditory localisation"、92th AES Convention、1992、Preprint 3306 Jens Ahrens、Sascha Spors、"Analytical driving functions for higher order ambisonics"、Proceedings of the ICASSP、pp.373-376、2008 Wikipedia、2010年10月12日現在、"Associated Legendre polynomials"、http://en.wikipedia.org/w/index.php?title=Associated_Legendre_polynomials&oldid=363001511 IEEE-754、"Standard for binary floating-point arithmetic"、http://grouper.ieee.org/groups/754/ Chris Travis、"Four candidate component sequences"、http://ambisonics.googlegroups.com/web/Four+candidate+component+sequences+V09.pdf、2008年 J.P. Princen, A.B. Bradley、"Analysis/Synthesis Filter Band Design Based on Time Domain Aliasing Cancellation"、IEEE Transactions on Acoustics, Speech and Signal Processing, vol. ASSP-34, no.5, pp.1153-1161、October 1986

HOA信号に関し、3Dについては、種々の音源からのみな同じ周波数のM＝(N+1)²個（2Dについては(2N+1)個）の異なるオーディオ・オブジェクトの集合が、それらが空間的に均等に分布している限り、異なる音オブジェクトとして記録（エンコード）され、再生されることができる。これは、一次アンビソニックス信号は四つの3Dまたは三つの2Dオーディオ・オブジェクトを担持でき、これらのオブジェクトは3Dについては球のまわりに、2Dについては円のまわりに一様に離間している必要があることを意味する。空間的な重なりおよび記録におけるM個より多い信号は、ぼけを生じる――最も大きな信号だけがコヒーレントなオブジェクトとして再生されることができ、他の散漫な信号は、空間、周波数およびラウドネス類似性における重なりに依存して何らかの仕方でコヒーレントな信号を劣化させる。

映画館における音響状況に関しては、前方スクリーン領域については、視覚的なシーンに合うよう、高い空間的な音の定位精度が要求される。サラウンド・サウンド・オブジェクトの知覚はそれほど決定的ではない（残響、視覚的なシーンと関連のない音オブジェクト）。ここで、スピーカーの密度は、前方領域に比べて小さくてもよい。

前方領域について重要なHOAデータのHOA次数は、随意にホロフォニックな再生を可能にするよう、大きくなければならない。典型的な次数はN＝10である。これは、(N+1)²＝121個のHOA係数を必要とする。理論上は、オーディオ・オブジェクトが空間的に均等に分布されるのであれば、M＝121個のオーディオ・オブジェクトをエンコードすることもできる。しかしながら、我々のシナリオでは、それらのオブジェクトは前方領域に制約される（そのような高い次数が必要なのは前方だけなので）。実際には、我々は、約M＝60個のオーディオ・オブジェクトだけをぼけなしに符号化できる（前方領域は高々方向球の半分であり、よってM/2）。

上述したBフォーマットは三次までのアンビソニックスしか記述できず、ファイル・サイズは4GBに制約される。波の型または参照デコード体積のような、現代のデコーダにとって重要な他の特別な情報項目が欠けている。異なるアンビソニックス成分（チャネル）について異なるサンプル・フォーマット（語幅）および帯域幅を使うことはできない。また、アンビソニックスのための副情報およびメタデータを記憶する規格もない。

既知の技術では、マイクロホン・アレイを使ったアンビソニックス信号の記録は1のオーダーに制約される。これは、HOAマイクロホンの実験的なプロトタイプが開発されれば、将来変わるかもしれない。3Dコンテンツの生成のためには、周辺音場の記述が、マイクロホン・アレイを使って一次アンビソニックスにおいて記録されることができ、それにより指向性の源が、クローズアップ・モノ・マイクロホンまたは高度に指向性のマイクロホンを方向情報（すなわち源の位置）と一緒に使って、捕捉される。次いで指向性信号はHOA記述にエンコードされることができ、あるいはこれは洗練されたデコーダによって実行されてもよい。いずれにせよ、新しいアンビソニックス・ファイル・フォーマットは、二つ以上の音場記述を同時に記憶できることが必要であるが、既存のフォーマットには、二つ以上のアンビソニックス記述をカプセル化できるものはないと思われる。

本発明によって解決されるべき課題は、二つ以上の音場記述を同時に記憶することができ、アンビソニックス次数が3より大きいことができるアンビソニックス・ファイル・フォーマットを提供することである。

この課題は、請求項１に開示されるデータ構造および請求項１２に開示される方法によって解決される。

現実的な3Dオーディオを再現するために、次世代アンビソニックス・デコーダは、処理されるべき記憶されたデータとともに、多くの規約および規定を必要とするか、あるいはすべての関係したパラメータおよびデータ要素がコヒーレントに記憶できる単一のファイル・フォーマットを必要とするであろう。

空間的な音コンテンツのための本発明のファイル・フォーマットは、一つまたは複数のHOA信号および／または指向性モノ信号を方向情報と一緒に記憶することができ、3より大きいアンビソニックス次数および4GBより大きいファイルが実現可能である。さらに、本発明のファイル・フォーマットは、既存のフォーマットが提供しない追加的な要素を提供する。

１）次世代HOAデコーダのために必要とされる重要な情報がファイル・フォーマット内に記憶される：
・アンビソニックス波の情報（平面、球面、混合型）、関心領域（聴取領域外または内の源）および参照半径（球面波のデコードのため）
・関係した指向性モノ信号が記憶されることができる。これらの指向性信号の位置情報は、角度および距離情報を使って、あるいはアンビソニックス係数のエンコード・ベクトルを使って記述できる。

２）アンビソニックス・データを定義するすべてのパラメータが副情報内に含まれ、記録についての明瞭性が保証される：
・アンビソニックス・スケーリングおよび規格化（SN3D、N3D、ファース・モーム（Furse Malham）、Bフォーマット、……、ユーザー定義）、混合次数情報。

３）アンビソニックス・データのための記憶フォーマットが、柔軟かつ経済的なデータ記憶を許容するよう拡張される：
・本発明のフォーマットは、アンビソニックス次数（アンビソニックス・チャネル）に関係したデータを、異なるPCM語サイズ分解能で、また制約された帯域幅を使って記憶することを許容する。

４）メタフィールドが、マイクロホン信号のための記録情報のような、ファイルについての付随情報を記憶することを許容する：
・記録基準座標系、マイクロホン、源および仮想聴取者位置、マイクロホン方向特性、部屋および源の情報。

2Dおよび3Dオーディオ・コンテンツのためのファイル・フォーマットは、高次アンビソニックス記述（HOA）および固定したもしくは時間変動する位置をもつ単一の源の両方の記憶をカバーし、次世代オーディオ・デコーダが現実的な3Dオーディオを提供できるようにするすべての情報を含む。

適切な設定を使えば、本発明のファイル・フォーマットは、オーディオ・コンテンツのストリーミングにも好適である。こうして、コンテンツ依存の副情報（ヘッダ・データ）が、ファイルの作成者によって選択された時点において、送られることができる。本発明のファイル・フォーマットは、オーディオ・シーンのトラックが任意の時点で開始および終了できるシーン記述のはたらきもする。

原理的には、本発明のデータ構造は高次アンビソニックスHOAオーディオ・データに好適である。このデータ構造は、一つまたは複数の異なるHOAオーディオ・データ・ストリーム記述のための2Dおよび／または3D空間的オーディオ・コンテンツ・データを含み、このデータ構造はまた、「3」より大きな次数をもつHOAオーディオ・データにも好適であり、このデータ構造はさらに、固定したまたは時間変動する空間位置からの単一オーディオ信号源データおよび／またはマイクロホン・アレイ・オーディオ・データを含むことができる。

原理的には、本発明の方法は、少なくとも二つの異なるHOAオーディオ・データ信号を含むHOAオーディオ・データ・ストリームが受領され、それらの信号のうち少なくとも第一のものが、呈示サイトの明確に区別される領域に位置される密なスピーカー配置での呈示のために使われ、それらの信号のうち少なくとも第二の異なるものが前記呈示サイトを取り囲むそれほど密でないスピーカー配置での呈示のために使われる。

本発明のさらなる有利な実施形態は、それぞれの従属請求項において開示される。

本発明の例示的な実施形態について、付属の図面を参照しつつ述べる。
前方領域における密なスピーカー配置および聴取領域を取り囲む疎なスピーカー密度をもつ映画館でのホロフォニック再生を示す図である。洗練されたデコード・システムを示す図である。マイクロホン・アレイ記録、単一源記録、単純および複雑な音場生成からのHOAコンテンツ生成を示す図である。次世代の没入型コンテンツ生成を示す図である。単純なサラウンド・スピーカー・セットアップのためのHOA信号の2Dデコードと、前方ステージのためのホロフォニックなスピーカー・セットアップおよびより疎な3Dサラウンド・スピーカー・セットアップのためのHOA信号の3Dデコードとを示す図である。源が関心／有効性の領域の外側（outside）にある内部（interior）領域問題を示す図である。球面座標の定義を示す図である。源が関心／有効性の領域の内側（inside）にある外部（exterior）領域問題を示す図である。単純な例示的なHOAファイル・フォーマットを示す図である。複数のトラックをもつ複数のフレームを含むHOAファイルの例を示す図である。複数の「メタデータチャンク」をもつHOAファイルを示す図である。「トラック領域」エンコード処理を示す図である。「トラック領域」デコード処理を示す図である。 MDCT処理を使った帯域幅削減の実装を示す図である。 MDCT処理を使った帯域幅再構成の実装を示す図である。

3Dビデオのますますの普及とともに、没入型オーディオ技術が差別化のための興味深い機能となりつつある。高次アンビソニックス（HOA）は、段階的な仕方で映画館に3Dオーディオを導入する方法を提供できる、そうした技術の一つである。HOAサウンドトラックおよびHOAデコーダを使えば、映画館は、既存のオーディオ・サラウンド・スピーカー・セットアップから出発して、徐々により多くのスピーカーに投資して段階ごとに没入型の経験を改善することができる。

図１のａは、前方領域における密なスピーカー配置１１および聴取もしくは着席領域１０を取り囲むより疎なスピーカー密度１２をもつ、映画館におけるホロフォニック再生を示している。これは、視覚的アクションに関係した正確な音再生および再生される周辺音の充分な精度の方法を提供する。

図１のｂは、再生される前方音波の到着の知覚される方向を示している。平面波の到着方向は種々のスクリーン位置にマッチする。すなわち、平面波は奥行きを再現するのに好適である。

図１のｃは、再生される球面波の到着の知覚される方向を示している。これは、知覚される音方向とスクリーンのまわりの3D視覚的アクションとのよりよい一貫性につながる。

二つの異なるHOAストリームの必要性は、映画館における主たる視覚的なアクションは聴取者の前方領域で起こるという事実に由来する。また、音の方向検出の知覚上の精度は、サラウンド源よりも前方音源について高い。よって、前方の空間的な音再生の精度は、再生される周辺音についての空間的精度よりも高い必要がある。ホロフォニック（holophonic）は、音再生について、より多数のスピーカー、専用のデコーダおよび関係したスピーカー・ドライバが前方スクリーン領域のために必要とされ、一方、周辺音再生についてはより安価な技術（聴取領域を囲むスピーカーのより低い密度およびより完全度が低いデコード技術）が必要とされることを意味する。

コンテンツ作成および音再生技術のため、周辺音について一つのHOA表現、前景アクション音について一つのHOA表現を与えることが有利である。図４参照。単純な粗い再生音設備をもつ単純なセットアップを使う映画館は、デコード前に両方のストリームを混合することができる（図５の上部参照）。完全な没入型再生手段を備えるより洗練された映画館は、二つのデコーダ――周辺音をデコードするために一つ、前景の主たるアクションのための仮想音源の高精度の位置決めのために一つの特化したデコーダ――を使うことができる。これは、図２の洗練されたデコード・システムおよび図５の下部に示されている。

特殊なHOAファイルは、周辺音A_n ^m(t)についておよび視覚的な主たるアクションに関係した前方音C_n ^m(t)についてのHOA音場を表す少なくとも二つのトラックを含む。方向効果のための任意的なストリームが提供されてもよい。二つの対応するデコーダ・システムがパニング器（panner）と一緒になって、密な前方3Dホロフォニック・スピーカー・システム２１およびそれほど密でない（すなわち疎な）3Dサラウンド・システム２２のための信号を提供する。トラック１ストリームのHOAデータ信号は周辺音を表し、HOA変換器２３１において、周辺音再生のために特化されたデコーダ１２３２への入力のために変換される。トラック２データ・ストリームについては、HOA信号データ（視覚的なシーンに関係した前方音）は、HOA変換器２４１において、専用のデコーダ２２４３でのスクリーン領域のまわりの球状音源の最善の配置のため、距離補正された（式(26)）フィルタ２４２への入力のために、変換される。方向性のデータ・ストリームはL個のスピーカーに直接パンされる。三つのスピーカー信号は3Dスピーカー・システムでの統合再生のためにPCM混合される。

そのようなシナリオ専用の既知のファイル・フォーマットはないと思われる。既知の3D音場記録は、のちの再生のために記録する際、関係したサウンドトラックをもつ完全なシーン記述または単一の音場記述のいずれかを使う。第一の種類の例はWFS（Wave Field Synthesis［波面合成］）フォーマットおよび数多くのコンテナ・フォーマットである。第二の種類の例は、BまたはAMBフォーマットのようなアンビソニックス・フォーマットである。前述した非特許文献１参照。これはアンビソニックス次数3、固定した伝送フォーマット、固定したデコーダ・モデルおよび単一の音場に制約している。

HOAコンテンツ生成および再生
HOA音場記述を生成するための処理が図３に描かれている。

図３のａでは、音場の自然な記録が、マイクロホン・アレイを使って生成される。カプセル信号は、HOA信号を形成するためにマトリクス化され等化される。高次の信号（アンビソニックス次数＞1）は通例、カプセル距離効果に起因するアーチファクトを削減するために帯域通過フィルタ処理される：高周波数で空間的エイリアスを削減するために低域通過フィルタ処理され、増大するアンビソニックス次数n（h_n(kr_{d_mic})での過剰な低周波数レベルを削減するために高域通過フィルタ処理される。式(34)参照。任意的に、距離符号化フィルタ処理が適用されてもよい。式(25)および(27)参照。記憶の前に、HOAフォーマット情報がトラック・ヘッダに追加される。

人工的な音場表現は通例、複数の方向性の単独源ストリームを使って生成される。図３のｂに示されるように、単独源信号はPCM記録として捕捉されることができる。これは、クローズアップ・マイクロホンによってまたは高い指向性をもつマイクロホンを使うことによってできる。さらに、仮想的な最良の聴取位置に対する音源の方向パラメータ（r_s,Θ_s,φ_s）が記録される（HOA座標系またはのちのマッピングのための任意の基準点）。映画のためのシーンをレンダリングするときに、音を人工的に定位するために、距離情報も生成されてもよい。図３のｃに示されるように、その場合、方向情報（Θ_s,φ_s）はエンコード・ベクトルΨを生成するために使われ、方向性の音信号はアンビソニックス信号にエンコードされる。式(18)参照。これは、平面波表現と等価である。後続するフィルタ処理プロセスは、距離情報rsを使って、球面状の音特性をアンビソニックス信号にインプリントし（式(19)）、あるいは距離符号化フィルタ処理を適用、式(25)、(27)してもよい。記憶の前に、HOAフォーマット情報がトラック・ヘッダに追加される。

より複雑な音場記述が、図３のｄに描かれるようなアンビソニックス信号のHOA混合によって生成される。記憶の前に、HOAフォーマット情報がトラック・ヘッダに追加される。

3D映画館用のコンテンツ生成のプロセスが図４に描かれている。視覚的なアクションに関係する前方音は高い空間的精度でエンコードされ、HOA信号（音場）C_n ^m(t)に混合され、トラック２として記憶される。込み入ったエンコーダは、視覚的なシーンと最もよく合致するために必要な高い空間的精度および特殊な波の型をもってエンコードする。トラック１は、ソース方向の制約なしに、エンコードされる周辺音に関係する音場A_n ^m(t)を含む。通例、周辺音の空間的精度は前方音ほど高い必要はなく（その結果、アンビソニックス次数はより小さいことができる）、波型のモデル化はそれほど決定的ではない。周辺音場はまた、前方音信号の残響部分をも含むことができる。両方のトラックは記憶および／または交換のために多重化される。

任意的に、方向性の音（たとえばトラック３）がファイルに多重化されることができる。これらの音は特殊効果音、対話または視覚障害者のためのナレーション音声のような補助情報であることができる。

図５は、デコードの原理を示している。上部に描かれるように、疎なスピーカー・セットアップをもつ映画館は、単純化されたHOAデコードの前にトラック１およびトラック２からのHOA信号両方を混合することができ、トラック２の次数を打ち切り、両トラックの次元を2Dに下げてもよい。方向性ストリームが存在する場合、そのストリームは2D HOAにエンコードされている。その場合、三つのストリームすべてが混合されて単一のHOA表現を形成し、それが次いでデコードされ、再生される。

下部は図２に対応する。前方ステージのためのホロフォニック・システムおよびより粗い3Dサラウンド・システムを備える映画館は、専用の洗練されたデコーダを使い、スピーカー入力を混合する。トラック１データ・ストリームについては、周辺音を表すHOAデータが周辺音再生のために特化されたデコーダ１向けに変換される。トラック２データ・ストリームについては、HOA（視覚的なシーンに関係した前方音）は、専用のデコーダ２でのスクリーン領域のまわりの球状音源の最善の配置のため、変換され、距離補正される（式(26)）。方向性のデータ・ストリームはL個のスピーカーに直接パンされる。三つのスピーカー信号は3Dスピーカー・システムでの統合再生のためにPCM混合される。

高次アンビソニックスを使った音場記述
球面調和関数（SH）を使った音場記述
球面調和関数／ベッセル記述を使うとき、音響的な波の方程式の解は式(1)で与えられる。非特許文献４参照。音圧は球面座標r、Θ、Φ（定義については図７参照）および空間周波数k＝ω/c＝2πf/cの関数である。

その記述は、関心領域または有効性領域の外側のオーディオ音源についても有効であり（図６に示される内部領域問題）、正規直交化された球面調和関数

を想定している。A_n ^m(k)はアンビソニック係数と呼ばれ、j_n(kr)は第一種の球面ベッセル関数であり、Y_n ^m(θ,φ)は球面調和関数（SH: Spherical Harmonics）と呼ばれ、nはアンビソニックス次数（order）インデックスであり、mは度数（degree）を示す。

小さなkr値（原点からの小さな距離または低周波数）についてのみ有意な値をもつベッセル関数の性質のため、この級数は、充分な精度をもって、何らかの次数nで止め、値Nに制約することができ、HOAデータを記憶する際、通例、アンビソニックス係数A_n ^m,B_n ^mまたは何らかの派生物（詳細は後述）がその次数Nまで記憶される。Nはアンビソニックス次数と呼ばれる。

Nはアンビソニックス次数と呼ばれ、用語「次数」は通例、ベッセル関数j_n(kr)およびハンケル関数h_n(kr)と組み合わせても使われる。

図８に描かれるように源が関心領域または有効性領域の内側にある外部ケースについての波の方程式の解は、r＞r_source〔r_源〕について、式(2)で表される。

B_n ^m(k)はやはりアンビソニックス係数と呼ばれ、h⁽¹⁾ _n(kr)はn次の第一種の球面ハンケル関数である。この公式は正規直交化されたSHを想定している。

コメント：一般に、第一種の球面ハンケル関数h⁽¹⁾ _n(kr)は、正の周波数について出ていく波（e^ikrに関係）を記述するために使われ、第二種の球面ハンケル関数h⁽²⁾ _nは、はいってくる波（e^-ikrに関係）のために使われる。上述した非特許文献５参照。

球面調和関数
球面調和関数Y_n ^mは複素数値であることも実数値であることもある。HOAのための一般的なケースは実数値の球面調和関数を使う。実および複素球面調和関数を使ったアンビソニックスの統一的な記述は非特許文献６で概観できる。

球面調和関数を規格化するには種々の方法がある（これは球面調和関数が実か複素かとは独立である）。非特許文献７参照。

規格化は、Y_nmとY_n' ^m'*との間の直交関係に対応する。

コメント：

ここで、S²は単位球であり、クロネッカーのデルタδ_aa'はa＝a'については1、それ以外では0に等しい。

複素球面関数は

によって記述される。ここで、i＝√(−1)であり、s_mは先述した非特許文献５と同様に、正のmについては交互の符号を与えるようs_m＝(−1)^mであり、それ以外の場合にはs_m＝1である。（コメント：s_mは慣例上の項であり、正のみのSHについては省略可。）N_n,mは規格化項であり、正規直交化された表現については次の形を取る（!は階乗を表す）。

下記の表１は、複素数値の球面調和関数についてのいくつかの一般的に使われる規格化方式を示す。P_n,|m|(x)はルジャンドル陪関数であり、上述の非特許文献６からの|m|を用いた記法に従っている。これは、コンドン・ショートリー（Condon-Shortley）位相と呼ばれ、他の記法ではP_n ^mの表現内に含まれることがある位相項(−1)^mを回避する。ルジャンドル陪関数

はロドリーグの公式を使って次のように表現できる。

数値的には、P_n,|m|(x)を再帰関係から漸進的に導出することが有利である。非特許文献９参照。n＝4までのルジャンドル陪関数を表２に与えておく。

実数値のSHはmの互いに反対の値に対応する複素共役Y_n ^mを組み合わせることによって導かれる（定義(6)における項(−1)^mは、アンビソニックスにおける通常のケースである実SHのための符号なしの表現を得るために導入されている）。

これは、方位角項のみを保持した

の円調和関数とのつながりをハイライトするために式(7)のように書き直すことができる。

所与のアンビソニックス次数Nについての球面成分S_n ^mの総数は(N＋1)²に等しい。実数値の球面調和関数の一般的な規格化方式を表３に与えておく。

円調和関数
二次元表現だけの場合には、調和関数のサブセットが必要とされる。SH度数はm∈{−n,n}の値のみを取ることができる。所与のNについての成分の総数は2N＋1に減る。傾斜角θを表す成分が不要になり、球面調和関数が式(8)で表される円調和関数で置き換えられるからである。

円調和関数については種々の規格化N_m方式があり、3Dアンビソニックス係数を2D係数に変換するときにはこれを考える必要がある。円調和関数についての一般的な公式は次のようになる。

円調和関数についてのいくつかの一般的な規格化因子を表４に与えておく。ここで、規格化項は水平面内の項

の前の因子によって導入される。

異なる規格化の間の変換はストレートなことである。一般に、規格化は圧力を記述する記法（式(1)、(2)参照）およびすべての派生する考察に対して効果をもつ。規格化の種類はアンビソニックス係数にも影響する。これらの係数をスケーリングするために適用できる重みもある。たとえば、AMBフォーマットを使ってファイルを記憶するときにアンビソニックス係数に適用されるファース・モーム（FuMa）重みである。

2D‐3D変換に関し、たとえば2Dスピーカー設定のための2Dデコーダで3Dアンビソニックス表現（記録）をデコードするとき、CHからSHへおよびその逆の変換はアンビソニックス係数にも適用できる。3D‐2D変換のための

の間の関係は、アンビソニックス次数4までは、次の図式に描かれる。

2Dから3Dの変換因子は、θ＝π/2にある水平ペインについて、次のように導出できる。

3Dから2Dへの変換は

を使う。詳細は下記で式(28)(29)(30)との関連で呈示する。

2D規格化から正規直交化への変換は

となる。

アンビソニックス係数
アンビソニックス係数は音圧の単位スケール

をもつ。アンビソニックス係数はアンビソニックス信号を形成し、一般に、離散時間の関数である。表５は、次元表現、アンビソニックス次数およびアンビソニックス係数（チャネル）の数の間の関係を示している。

離散時間表現を扱う際は、通例、アンビソニックス係数は、多チャネル記録のPCMチャネル表現のように（チャネル＝サンプルvのアンビソニックス係数A_n ^m）インターリーブ式に記憶される。係数シーケンスは慣例の問題である。3D、N＝2についての一例は

となり、2D、N＝2については、

となる。

A₀ ⁰(n)信号は、アンビソニックス記録のモノ表現と見なすことができ、方向情報をもたず、記録の全般的な音質印象を表す。

アンビソニックス係数の規格化は一般に、SHの規格化に従って実行される（下記で明白となるであろう。式(15)参照）。外部記録をデコードするときにはこのことを考慮に入れる必要がある。（下記で、A_nmは規格化因子N_n,mでのSHに基づき、ハチェック付きA_nmは規格化因子ハチェック付きN_n,mでのSHに基づく）

これは、SN3DからN3Dの場合には

となる。

BフォーマットおよびAMBフォーマットは、係数に適用される追加的な重み（ガーソン（Gerson）、ファース・モーム（FuMa）、MaxN重み）を使う。その際、基準となる規格化は通例SN3Dである。非特許文献１０、１１参照。

理想的な平面波または球面波のための波の方程式の次の二つの具体的な実現は、アンビソニックス係数についてのさらなる詳細を示す。

平面波
平面波A_n ^mについて波の方程式を解くことは、kおよびr_sとは独立である。θ_s、φ_sは源角度を記述し、「*」は複素共役を表す。

ここで、P_s0は時間の関数であることのできる記述座標系の原点において測定された源のスケーリング信号圧を記述するために使われ、正規直交化された球面調和関数についてはA₀ ⁰ _plane/√(4π)となる。一般に、アンビソニックスは平面波を想定し、アンビソニックス係数

が伝送または記憶される。この想定のおかげで、異なる方向性信号の重ね合わせおよび単純なデコーダ設計の可能性が提供される。これはまた、一次のBフォーマット（N＝1）で記録されたサウンドフィールド（Soundfield（商標））マイクロホンの信号についても成り立つ。このことは、等化フィルタの位相進行を比較すれば明らかになる。（理論的な進行については上述の非特許文献６の章2.1を参照。特許で保護されている進行については特許文献１を参照。）式(1)は次のようになる。

係数d_n ^mは後処理されたマイクロホン・アレイ信号によって導出されることができ、あるいはモノ信号P_s0(t)を使って合成的に生成されることができ、その場合は方向性の球面調和関数Y_n ^m(θ_s,φ_s,t)*は時間依存（移動する源）にもなることができる。式(17)は、各時間的なサンプリング時点vについて有効である。合成的エンコードのプロセスは、選択されたアンビソニックス次数Nについて、ベクトル／行列形式で（すべてのサンプル時点vについて）書き直すことができる。

ここで、dはアンビソニックス信号であり、d_n ^m(θ_s,φ_s)を保持し、（N＝2についての例：

）、dの大きさsize(d)＝(N+1)²x1＝Ox1であり、P_s0は基準となる原点での源信号圧であり、Ψはエンコード・ベクトル（encoding vector）であり、Y_n ^m(θ_s,φ_s)*を保持し、size(Ψ)＝Ox1である。エンコード・ベクトルは特定の源方向Θ_s,φ_s（平面波の方向に等しい）についての球面調和関数から導出できる。

球面波
r＜r_sについて点源（近距離場の源）によって生成されるはいってくる球面波を記述するアンビソニックス係数は次のようになる。

この式は下記の式(31)ないし(36)との関連で導出される。P_s0＝p(0|r_s)は原点での音圧を記述し、やはりA₀ ⁰/√(4π)に等しくなる。h_n ⁽²⁾は次数nの第二種の球面ハンケル関数であり、h₀ ⁽²⁾は0次の第二種の球面ハンケル関数である。式(19)は非特許文献１２の教示と同様である。ここで、

であり、式(11)を念頭に置けば、これは非特許文献１３に見出すことができる。この文献で、ガーソンは度数1（first-degree）信号について近接効果を記述している。

球面アンビソニックス信号の合成的な生成は、より高いアンビソニックス次数Nについてはそれほど一般的ではない。h_n(kr_s)/h₀(kr_s)の周波数応答を低周波数について数値的に扱うのが難しいからである。これらの数値的な問題は、下記に述べるデコード／再生のための球面モデルを考えることによって克服できる。

音場再生
平面波デコード
一般に、アンビソニックスは、円上または球面上に一様に分布したL個のスピーカーによる音場の再生を想定する。スピーカーが聴取者位置から十分遠くに置かれている場合には、中心において平面波デコード・モデルが有効である（r_s＞λ）。L個のスピーカーによって生成される音圧は次式によって記述される。

ここで、w_lはスピーカーlについての信号であり、音圧の単位スケール1Paをもつ。w_lはしばしばスピーカーlの駆動関数と呼ばれる。

この式(20)の音圧が式(17)によって記述される圧力と同一であることが望ましい。すると次のようになる。

これは「再エンコード公式（re-encoding formula）」として知られる、行列形式に書き直すことができる（式(18)と比較）。

ここで、dはアンビソニックス信号であり、

を保持し（N＝2についての例：

）、dの大きさsize(d)＝(N+1)²x1＝Ox1であり、Ψは（再エンコード）行列であり、Y_n ^m(θ_l,φ_l)*を保持し、size(Ψ)＝OxLであり、yはスピーカー信号w_lであり、size(y(n),1)＝Lである。

すると、yはいくつかの既知の方法、たとえばモード・マッチングあるいは特殊なスピーカー・パニング関数について最適化する諸方法を使って導出できる。

球面波モデルについてのデコード
より一般的なデコード・モデルはやはり、原点のまわりに距離r_lで均等に分布した、点状の球面波を放射するスピーカーを想定する。アンビソニックス係数A_n ^mは式(1)からの一般的な記述によって与えられ、L個のスピーカーによって生成される音圧は式(19)に従って与えられる。

より洗練されたデコーダは、

を取得し、その後、スピーカー重みを導出するために

として式(17)を適用するために、アンビソニックス係数A_n ^mをフィルタ処理することができる。このモデルでは、スピーカー信号w_lは原点における圧力によって決定される。上述した非特許文献４で最初に記述された、単純な源アプローチを使う代替的な手法がある。スピーカーは球面上に均等に分布しており、二次的な源特性をもつと想定される。解は非特許文献１４、式(13)において導出され、それはアンビソニックス次数Nにおける打ち切りおよびスピーカー利得g_lについて、一般化

として書き直せる。

距離符号化されたアンビソニックス（Distance Coded Ambisonics）信号
基準スピーカー距離r_{l_ref}を使ったアンビソニックス・エンコーダにおけるC_n ^mの生成は、（式(18)を使って）球面波をモデル化または記録するときのA_n ^mの数値上の問題を解決できる。

伝送ないし記憶されるのはC_n ^m、基準距離r_{l_ref}および球面距離符号化係数が使われているとのインジケータである。デコーダ側では、真のスピーカー距離が

である限り、式(22)で与えられるような単純なデコード処理が実現可能である。その距離が大きすぎれば、アンビソニックス・デコード前のフィルタ処理による補正

が必要となる。

式(24)のような他のデコード・モデルは距離符号化されたアンビソニックスについて異なる定式化につながる。

球面調和関数の規格化も距離符号化されたアンビソニックスの定式化に影響をもつことができる。すなわち、距離符号化されたアンビソニックス係数は明確なコンテキストを必要とする。

上述した2D‐3D変換の詳細は次のとおり。

乗算により2D円成分を3D球面成分に変換する変換因子α_2D/3Dは次のように導出できる。

(2l−1)!!＝Π_i=1 ^l(2i−1)を二重階乗とし、一般的な恒等式（非特許文献１５参照）P_l,l(x)＝(2l−1)!!(1−x²)^l/2を使うと、P_|m|,|m|は

と表現でき、式(29)を式(28)に代入すると式(10)になる。

2Dから直交3Dへの変換は、関係l!＝(l+1)!/(l+1)を使ってl＝2mを代入すると、

によって導出できる。

上述した球面波展開の詳細は次のようになる。

r＜r_sについて点源によって生成される、はいってくる波である球面波について式(1)を解くことは、より複雑になる。0になる無限小の大きさをもつ点源は体積流Q_sを使って記述する必要があるからである。ここで、源がr_sに位置され、rにおけるフィールド点についての放射される圧力は

によって与えられる（上述した非特許文献５参照）。ρ₀は比重であり、G(r|r_s)はグリーン関数

である。G(r|r_s)は、r＜r_sについて、球面調和関数において次式によっても表現できる。

ここで、h_n ⁽²⁾は第二種のハンケル関数である。グリーン関数はメートルの逆数の単位のスケールをもつことを注意しておく（kのため1/m）。式(31)、(33)を式(1)と比べると、球面波のアンビソニックス係数を導出できる。

ここで、Qsは単位m³s^-1の体積流であり、ρ₀はkg・m^-3を単位とする密度である。

アンビソニックス信号を合成的に生成し、上記の平面波の考察に関係付けることができるには、式(34)を座標系の原点で生成される音圧を使って表しておくことが合理的である。

これから

が導かれる。

交換記憶フォーマット
本発明に基づく記憶フォーマットは、二つ以上のHOA表現および追加的な方向性ストリームを、一つのデータ・コンテナ中に一緒に記憶することを許容する。これは、デコーダが再生を最適化できるようにするHOA記述の種々のフォーマットを可能にするとともに、＞4GBのサイズについて効率的なデータ記憶を提供する。さらなる利点は以下のとおり。

Ａ）種々のフォーマットを使っていくつかのHOA記述を関係した記憶フォーマット情報とともに記憶することによって、アンビソニックス・デコーダは両方の表現を混合し、デコードすることができる。

Ｂ）次世代HOAデコーダについて必要とされる情報項目がフォーマット情報として記憶される：
・次元性（dimensionality）、関心領域（聴取領域の外側または内部の源）、球面基底関数の規格化；
・アンビソニックス係数パッキングおよびスケーリング情報；
・アンビソニックス波型（平面、球面）、基準半径（球面波のデコードのため）；
・関係した方向性のモノ信号が記憶されうる。これらの方向性の信号の位置情報は角度と距離の情報またはアンビソニックス係数のエンコード・ベクトルを使って記述できる。

Ｃ）アンビソニックス・データの記憶フォーマットが、データの柔軟かつ経済的な記憶を許容するために拡張される：
・異なるPCM語サイズ分解能をもつアンビソニックス成分（アンビソニックス・チャネル）に関係したアンビソニックス・データを記憶；
・再サンプリングまたはMDCT処理を使って、低下した帯域幅でアンビソニックス・データを記憶。

Ｄ）メタデータ・フィールドが、トラックを特別なデコード（前方、周辺）のために関連付けるため、またマイクロホン信号についての録音情報のようなファイルについての付随情報の記憶を許容するために利用可能：
・記録基準座標系、マイクロホン、源および仮想聴取者位置、マイクロホン指向特性、部屋および源情報。

Ｅ）本フォーマットは、種々のトラックを含む複数のフレームの記憶に好適であり、シーン記述なしにオーディオ・シーン変化を許容する。（コメント：一つのトラックはHOA音場記述または位置情報をもつ単一源を含む。フレームは一つまたは複数の並行トラックの組み合わせである。）トラックはフレームの先頭で始まってもよく、またはフレームの末尾で終わってもよい。よって、タイムコードは必要とされない。

Ｆ）本フォーマットは、オーディオ・トラック・データへの高速アクセス（手がかり点への早送りまたはジャンプ）およびファイル・データの先頭の時刻に対するタイムコードの決定を容易にする。

HOAデータ交換のためのHOAパラメータ
表６は、曖昧さのないHOA信号データ交換のために定義されることが必要なパラメータをまとめている。球面調和関数の定義は複素数値および実数値の場合について固定される。式(3)(6)参照。

ファイル・フォーマットの詳細
以下では、高次アンビソニックス（HOA）または位置情報のある単独源から構成されるオーディオ・シーンを記憶するためのファイル・フォーマットについて詳細に述べる。オーディオ・シーンは、異なる規格化方式を使うことができる複数のHOAシーケンスを含むことができる。よって、デコーダは、所望されるスピーカー・セットアップについて対応するスピーカー信号を、現在のファイルからのすべてのオーディオ・トラックの重ね合わせとして計算できる。ファイルはオーディオ・コンテンツをデコードするために必要とされるすべてのデータを含む。本発明に基づくファイル・フォーマットは単一ファイル中に二つ以上のHOAまたは単独源信号を記憶する機能を提供する。本ファイル・フォーマットは、諸フレームの合成（composition）を使い、各フレームはいくつかのトラックを含むことができ、トラックのデータはトラック・パケット（TrackPackets）と呼ばれる一つまたは複数のパケットに記憶される。

すべての整数型はリトルエンディアン型のバイト順で記憶されるので、最下位バイトが最初にくる。ビット順は、常に、最上位ビットが先である。整数データ型についての記法は「int」である。先頭の「u」が付くと符号なし整数を示す。ビット単位での分解能が定義の末尾に書かれる。たとえば、符号なし16ビット整数フィールドは「uint16」として定義される。整数フォーマットでのPCMサンプルおよびHOA係数は固定小数点数として表現され、小数点は最上位ビットにある。

すべての浮動小数点データ型はIEEE規格IEEE754（非特許文献１６）に準拠する。浮動小数点データ型についての記法は「float」である。ビット単位での分解能が定義の末尾に書かれる。たとえば、32ビット浮動小数点フィールドは「float32」と定義される。フレーム、トラックまたはチャンクの先頭を同定する一定の識別子IDおよびストリングはデータ型バイトとして定義される。バイト配列のバイト順は最上位のバイトおよびビットが先である。したがって、「TRCK」というIDは32ビットのバイト・フィールドにおいて定義され、バイトは物理的な順「T」「R」「C」および「K」で書かれる（<0x54;0x52;0x42;0x4b>）。十六進値は「0x」で始まる（たとえば0xAB64C5）。単独ビットは引用符中に入れられ（たとえば'1'）、複数の二進値は「0b」で始まる（たとえば0b0011＝0x3）。

ヘッダ・フィールド名は常にヘッダ名で始まり、それにフィールド名が続く。ここで、各語の最初の文字は大文字化される（例：TrackHeaderSize）。フィールド名またはヘッダ名の略称は大文字だけを使って作られる（例：TrackHeaderSize＝THS）。

HOAファイル・フォーマットは二つ以上のフレーム、パケットまたはトラックを含むことができる。複数のヘッダ・フィールドの弁別のため、フィールドまたはヘッダ名のあとに数字が続くことができる。たとえば、三番目のTrackの二番目のTrackPacketは「Track3Packet2」と名付けられる。

HOAファイル・フォーマットは複素数値のフィールドを含むことができる。これらの複素数値は実部および虚部として記憶され、実部が先に書かれる。「int8」フォーマットでの複素数1+i2は「0x01」のあとに「0x02」が続くものとして記憶される。よって、複素数値フォーマット型でのフィールドまたは係数は、対応する実数値フォーマット型に比べて二倍の記憶サイズを必要とする。

高次アンビソニックス・ファイル・フォーマット構造
単独トラック・フォーマット
高次アンビソニックス・ファイル・フォーマットは、図９に描かれるように、少なくとも一つのFileHeader〔ファイル・ヘッダ〕、一つのFrameHeader〔フレーム・ヘッダ〕、一つのTrackHeader〔トラック・ヘッダ〕および一つのTrackPacket〔トラック・パケット〕を含む。図９は、一つまたは複数のPacket〔パケット〕において一つのTrack〔トラック〕を担持する単純な例示的なHOAファイル・フォーマットを示している。

よって、HOAファイルの基本構造は、一つのFileHeaderのあとに少なくとも一つのTrackを含むFrameが続くというものである。Trackは常にTrackHeaderおよび一つまたは複数のTrackPacketを含む。

複数フレームおよびトラックのフォーマット
FileHeaderとは対照的に、HOAファイルは二つ以上のフレームを含むことができ、フレームは二つ以上のトラックを含むことができる。フレームの最大サイズを超過した場合またはトラックが追加されるか、あるフレームから他に移された場合に新たなFrameHeaderが使用される。複数トラックおよびフレームのHOAファイルの構造は図１０に示されている。

複数トラックのフレームの構造はFrameHeaderで始まり、当該フレームのすべてのTrackHeaderが続く。結果として、各トラックのTrackPacketは逐次的にFrameHeaderに送られる。ここで、TrackPacketはTrackHeaderと同じ順序にインターリーブされる。複数トラック・フレームにおいては、サンプル単位でのパケットの長さはFrameHeaderにおいて定義され、すべてのトラックについて一定である。さらに、各トラックのサンプルは同期されている。たとえば、Track1Packet1のサンプルはTrack2Packet1のサンプルと同期している。特定のTrackCodingType〔トラック符号化種別〕がデコーダ側で遅延を引き起こすことができ、そのような特定の遅延はデコーダ側で知られている、またはTrackHeaderのTrackCodingType従属部分に含められる必要がある。デコーダは、フレームのすべてのトラックの最大遅延にすべてのTrackPacketを同期させるからである。

ファイル依存のメタデータ
完全なHOAファイルを参照するメタデータは任意的に、MetaDataChunk〔メタデータチャンク〕中のFileHeader後に加えられることができる。MetaDataChunkは特定の一般的ユーザーID（GUID）で始まり、それにMetaDataChunkSize〔メタデータチャンク・サイズ〕が続く。MetaDataChunk、たとえばMetaData情報の本質は、XMLフォーマットまたは任意のユーザー定義されるフォーマット中にパッキングされる。図１１は、いくつかのMetaDataChunkを使ったHOAファイル・フォーマットの構造を示している。

トラック型
HOAフォーマットのTrack〔トラック〕は、一般的なHOATrack〔HOAトラック〕とSingleSourceTrack〔単独源トラック〕との区別をする。HOAトラックはHOACoefficient〔HOA係数〕として符号化された完全な音場を含む。したがって、シーン記述、たとえばエンコードされた源の位置は、デコーダ側で係数をデコードするために必要とされない。換言すれば、オーディオ・シーンはHOA係数内に記憶されるのである。

HOAトラックとは逆に、単独源トラックはPCMサンプルとして符号化される一つの源のみを、オーディオ・シーン内のその源の位置とともに含む。時間的に、単独源トラックの位置は固定であっても、可変であってもよい。源位置はTrackHOAEncodingVector〔トラックHOAエンコード・ベクトル〕またはTrackPositionVector〔トラック位置ベクトル〕として送られる。トラックHOAエンコード・ベクトルは、各サンプルについてのHOA係数を得るためのHOAエンコード値を含む。トラック位置ベクトルは、中央の聴取位置に対する角度および距離として源の位置を含む。

ファイル・ヘッダ

FileHeader〔ファイル・ヘッダ〕は、完全なHOAファイルについてのすべての一定の情報を含む。FileIDはHOAファイル・フォーマットを識別するために使われる。サンプル・レートは、たとえサンプル・レートがFrameHeader中で送られる場合でも、すべてのトラックについて一定である。フレームによってサンプル・レートを変えるHOAファイルは無効である。フレーム数は、フレーム構造をデコーダに示すために、FileHeader中で示される。

メタデータチャンク

フレーム・ヘッダ

FrameHeader〔フレーム・ヘッダ〕は、フレームのすべてのトラックの一定の情報を保持し、HOAファイル内の変化を示す。FrameIDおよびFrameSizeはフレームの先頭およびフレームの長さを示す。これら二つのフィールドは、各フレームへの簡単なアクセスおよびフレーム構造のクロスチェックを許容する。フレーム長が32ビットより多くを必要とする場合には、一つのフレームがいくつかのフレームに分離されることができる。各フレームは一意的なFrameNumberを有する。FrameNumberは0で始まり、新たなフレーム毎に1だけインクリメントされるべきである。フレームのサンプル数はフレームのすべてのトラックについて一定である。フレーム内のトラック数は当該フレームについては一定である。所望されるサンプル位置でトラックを終了または開始するためには新たなフレーム・ヘッダが送られる。各トラックのサンプルはパケットに格納される。これらのTrackPacketのサイズはサンプル単位で示され、すべてのトラックについて一定である。パケットの数は、フレームのサンプル数を記憶するために必要とされる整数に等しい。したがって、トラックの最後のパケットは、示されるパケット・サイズより少数のサンプルを含むことができる。フレームのサンプル・レートはFileSampleRateに等しく、FileHeaderを知ることなくフレームのデコードを許容するために、FrameHeaderにおいて示される。これは、たとえばストリーミング・アプリケーションのために、FileHeaderを知ることなく、マルチフレーム・ファイルの途中からデコードするときに使われることができる。

トラック・ヘッダ

項「dyn」は条件付きのフィールドに起因する動的（dynamic）なフィールド・サイズをいう。TrackHeader〔トラック・ヘッダ〕は、その特定のトラックのパケットについての一定の情報を保持する。TrackHeaderは二つのTrackSourceType〔トラック源型〕について一定の部分と可変の部分に分けられる。TrackHeaderはTrackHeaderの先頭の検証および識別のための一定のTrackIDで始まる。フレーム境界をまたいでコヒーレントな諸トラックを示すために、各トラックに一意的なTrackNumberが割り当てられる。こうして、同じTrackNumberをもつトラックが後続フレームにおいて生じることがある。TrackHeaderSizeは、次のTrackHeaderまでスキップするために与えられており、TrackHeaderSizeフィールドの末尾からのオフセットとして示される。TrackMetaDataOffsetはTrackMetaDataフィールドの先頭に直接ジャンプするためのサンプル数を与える。これは、TrackHeaderの可変長部分をスキップするために使用できる。TrackMetaDataOffsetが0ということは、TrackMetaDataフィールドが存在しないことを示す。TrackSourceTypeに依存して、HOATrackHeader〔HOAトラック・ヘッダ〕またはSingleSourceTrackHeader〔単独源トラック・ヘッダ〕が設けられる。HOATrackHeaderは、完全な音場を記述する標準的なHOA係数のための副情報を提供する。SingleSourceTrackHeaderはモノPCMトラックのサンプルおよび源の位置についての情報を保持する。SingleSourceTrack〔単独源トラック〕については、デコーダはトラックをシーン中に含める必要がある。

TrackHeaderの末尾には、任意的なTrackMetaDataフィールドが定義される。これはトラックに依存するメタデータ、たとえばAフォーマット伝送のための追加的情報（マイクロホン・アレイ信号）を提供するためにXMLフォーマットを使う。

HOAトラック・ヘッダ

HOATrackHeader〔HOAトラック・ヘッダ〕は、HOAトラックを復号するための情報を保持するTrackHeaderの一部である。HOATrackのTrackPacketは、トラックの音場全体を符号化するHOA係数を伝達する。基本的には、HOATrackHeaderは、所与のスピーカー・セットアップのためにHOA係数をデコードするためのデコーダ側で必要になるすべてのHOAパラメータを保持する。TrackComplexValueFlagおよびTrackSampleFormatは各TrackPacketのHOA係数のフォーマット型を定義する。エンコードされたまたは圧縮された係数については、TrackSampleFormatがデコードされたまたは圧縮解除された係数のフォーマットを定義する。すべてのフォーマット型は実数または複素数であることができる。複素数についてのさらなる情報は上記の「ファイル・フォーマットの詳細」の節で与えてある。

すべてのHOAに依存する情報はTrackHOAParamsにおいて定義される。TrackHOAParamsは他のTrackSourceTypesにおいて再利用される。したがって、TrackHOAParamsのフィールドは「トラックHOAパラメータ」の節で定義され、説明される。

TrackCodingTypeフィールドは、HOA係数の符号化（圧縮）フォーマットを示す。HOAファイル・フォーマットの基本的なバージョンはたとえば二つの符号化型を含む。一つの符号化型はPCM符号化型である（TrackCodingType='0'）。ここでは、圧縮解除された実または複素係数が選択されたTrackSampleFormatでパケット中に書き込まれる。HOA係数の順序および規格化はTrackHOAParamsフィールドにおいて定義される。

第二の符号化型は、サンプル・フォーマットの変更と、各HOA次数の係数の帯域幅を制限することを許容する。CodingTypeの詳細な説明は、「トラック領域符号化」の節で与えられるが、簡単に説明しておく。TrackBandwidthReductionTypeは各HOA次数の帯域幅を制限するために使われた処理の型を決定する。すべての係数の帯域幅が変更されていない場合、TrackBandwidthReductionTypeフィールドを0に設定することによって帯域幅削減をオフにできる。他の二つの帯域幅削減処理型が定義される。本フォーマットは、周波数領域のMDCT処理と、任意的に、時間領域のフィルタ処理を含む。MDCT処理についてのさらなる情報は、「MDCTによる帯域幅削減」の節を参照。HOA次数は、同じサンプル・フォーマットおよび帯域幅の諸領域に組み合わされることができる。領域の数はTrackNumberOfOrderRegionsフィールドによって示される。各領域について、最初と最後の次数インデックス、サンプル・フォーマットおよび任意的な帯域幅削減情報が定義される必要がある。領域は少なくとも一つの次数を得る。どの領域によってもカバーされない次数は、TrackSampleFormatフィールドで示される標準的なフォーマットを使って完全帯域幅で符号化される。特別な場合は、領域なしの使用である（TrackNumberOfOrderRegions==0）。この場合は、PCMフォーマットにおけるインターリーブ解除されたHOA係数について使用できる。ここで、HOA成分はサンプル毎にインラーリーブされない。ある領域の諸次数のHOA係数はTrackRegionSampleFormatにおいて符号化される。TrackRegionUseBandwidthReductionは、その領域の諸次数の係数についての帯域幅削減処理の使用を示す。TrackRegionUseBandwidthReductionフラグがセットされている場合、帯域幅削減副情報があとに続く。MDCT処理については、窓型および最初と最後の符号化されたMDCTビンが定義される。ここで、最初のビンは下のカットオフ周波数と等価であり、最後のビンは上のカットオフ周波数を定義する。MDCTビンもTrackRegionSampleFormatで符号化される。「MDCTによる帯域幅削減」の節を参照。

単独源型
単独源は固定位置および移動位置源に細分される。源型はTrackMovingSourceFlagにおいて示される。移動位置源型と固定位置源型の間の違いは、固定源の位置はトラック・ヘッダにおいて一度だけ示され、移動源についてはトラック・パッケージ毎にであるということである。源の位置は球面座標での位置ベクトルを用いて明示的に、あるいはHOAエンコード・ベクトルとして暗黙的に示されることができる。源自身は、再生のためにアンビソニックス・デコーダを使う場合、デコーダ側でHOA係数にエンコードされる必要があるPCMモノ・トラックである。

単独源固定位置トラック・ヘッダ

固定位置源型は0であるTrackMovingSourceFlag〔トラック移動源フラグ〕によって定義される。第二のフィールドは、源位置の符号化を球面座標でのベクトルとしてまたはHOAエンコード・ベクトルとして与えるTrackPositionType〔トラック位置型〕を示す。モノPCMサンプルの符号化フォーマットはTrackSampleFormat〔トラック・サンプル・フォーマット〕フィールドによって示される。源位置がTrackPositionVector〔トラック位置ベクトル〕として送られる場合、源位置の球面座標はTrackPositionTheta（s軸からxy平面への傾斜）、TrackPositionPhi（x軸から始まり反時計回りの方位角）およびTrackPositionRadiusのフィールドにおいて定義される。

源位置がHOAエンコード・ベクトルとして定義される場合、TrackHOAParams〔トラックHOAパラメータ〕がまず定義される。これらのパラメータは「トラックHOAパラメータ」の節で定義され、HOAエンコード・ベクトルの使用される規格化および定義を示す。TrackEncodeVectorComplexFlag〔トラック・エンコード・ベクトル複素数フラグ〕およびTrackEncodeVectorFormat〔トラック・エンコード・ベクトル・フォーマット〕フィールドは、後続のTrackHOAEncodingVector〔トラックHOAエンコード・ベクトル〕のフォーマット型を定義する。TrackHOAEncodingVectorは、「float32」または「float64」フォーマットで符号化されている、TrackHOAParamNumberOfCoeffs個の値からなる。

単独源移動位置トラック・ヘッダ

移動位置源型は、'1'であるTrackMovingSourceFlagによって定義される。ヘッダは、源位置データ・フィールドTrackPositionTheta、TrackPositionPhi、TrackPositionRadiusおよびTrackHOAEncodingVectorの源位置データ・フィールドがないほかは、固定源ヘッダと同一である。移動源については、これらは各パケットにおいて新しい（動いている）源位置を示すために、TrackPackets内に位置される。

特殊トラック表
トラックHOAパラメータ（TrackHOAParams）

HOAエンコードおよびデコードのためのいくつかのアプローチが過去に議論されているが、HOA係数を符号化するための結論や合意には至っていない。有利なことに、本発明に基づくフォーマットは、大半の既知のHOA表現の記憶を許容する。TrackHOAParamsは、どの種類の規格化および係数の順序シーケンスがエンコーダ側で使われたかを明確にするために定義される。これらの定義は、HOAトラックの混合およびデコーダ・マトリクスの適用のためにデコーダ側において考慮に入れる必要がある。

HOA係数は完全な三次元音場について、または二次元のxy平面についてのみ、適用できる。HOAトラックの次元は、TrackHOAParamDimensionフィールドにおいて定義される。

TrackHOAParamRegionOfInterestは、源が関心領域の内側または外側にあり、関心領域は全く源を含まない、二つの音圧級数展開を反映する。内部ケースおよび外部ケースについての音圧の計算はそれぞれ上記の式(1)および(2)において定義されている。ここで、HOA信号A_n ^m(k)の方向性情報は球面調和関数の複素共役Y_n ^m(θ,φ)^*によって決定される。この関数は複素および実数版で定義される。エンコーダおよびデコーダは等価な数値型の球面調和関数を適用する必要がある。よって、TrackHOAParamSphericalHarmonicTypeが、どんな種類の球面調和関数がエンコーダ側で適用されたかを示す。

上述したように、基本的に球面調和関数はルジャンドル陪関数および複素または実の三角関数によって定義される。ルジャンドル陪関数は式(5)によって定義される。複素数値の球面調和関数の表現は

となる。ここで、N_n,mはスケーリング因子（式(3)参照）である。この複素数値の表現は、次式を使って実数値の表現に変換できる。

ここで、実数値の球面調和関数のための修正されたスケーリング因子は次のようになる。

2D表現については、HOA係数のエンコードおよびデコードのために円調和関数を使う必要がある。円調和関数の複素数値の表現は次式で定義される。

円調和関数の実数値の表現は次式で定義される。

球面調和関数または円調和関数を特定の用途または要求に適応させるために、次のようないくつかの規格化因子が使用される。

HOA係数の正しいデコードを保証するために、エンコーダ側で使われた球面調和関数の規格化がデコーダ側で知られている必要がある。次の表７は、TrackHOAParamSphericalHarmonicNormフィールドを用いて選択できる規格化を定義している。

将来の規格化のために、TrackHOAParamSphericalHarmonicNormフィールドの専用の値が利用可能になっている。専用の規格化については、各HOA係数についてのスケーリング因子がTrackHOAParamsの末尾で定義される。専用のスケーリング因子TrackScalingFactorsは実または複素の「float32」または「float64」値として送信できる。スケーリング因子フォーマットは、専用スケーリングの場合、TrackComplexValueScalingFlagおよびTrackScalingFormatフィールドにおいて定義される。

異なるHOA次数の係数の振幅を整数フォーマット型での送信のために「1」より小さい絶対値に等化するため、符号化されたHOA係数にファース・モーム規格化がさらに適用されることができる。ファース・モーム規格化は、三次までの係数のSN3D実数値球面調和関数のために設計された。よって、ファース・モーム規格化は、SN3D実数値球面調和関数との組み合わせでのみ使うことが推奨される。さらに、TrackHOAParamFurseMalhamFlagは3より大きなHOA次数をもつトラックについては無視される。HOA係数をデコードするためには、ファース・モーム規格化の逆をデコーダ側で行う必要がある。表８はファース・モーム係数を定義している。

TrackHOAParamDecoderTypeは、どの種類のデコーダがデコーダ側に存在するとエンコーダ側で想定されているかを定義する。デコーダ型は、音場をレンダリングするためにデコーダ側で使用されることになるスピーカー・モデル（球面波または平面波）を決定する。それにより、デコーダの式の一部をエンコーダの式に移すことによってデコーダの計算量を軽減できる。さらに、エンコーダ側での数値上の問題も軽減できる。さらに、デコーダ側でのすべての非一貫性はエンコーダに移すことができるので、デコーダは、すべてのHOA係数についての同一の処理に帰着できる。しかしながら、球面波については、聴取位置からのスピーカーの一定の距離を想定する必要がある。したがって、想定されるデコーダ型はトラック・ヘッダにおいて示され、球面波デコーダ型についてのスピーカー半径r_lsは任意的なフィールドTrackHOAParamReferenceRadiusにおいてミリメートル単位で伝送される。デコーダ側での追加的なフィルタが、想定されたスピーカー半径と真のスピーカー半径との間の差を等化することができる。

HOA係数C_n ^mのTrackHOAParamDecoderType規格化は、TrackHOAParamRegionOfInterestで選択された内部または外部音場展開の使用に依存する。コメント：式(18)および後続の式におけるd_n ^mは下記における係数C_n ^mに対応する。エンコーダ側では、係数C_n ^mは表９において定義される係数A_n ^mまたはB_n ^mから決定され、記憶される。使用される規格化はTrackHOAParamヘッダのTrackHOAParamDecoderTypeフィールドにおいて示される。

一つの時間サンプルについてのHOA係数はTrackHOAParamNumberOfCoeffs(O)個の係数C_n ^mを含む。NはHOA係数の次元に依存する。2D音場については、「O」は2N＋1に等しい。ここで、NはTrackHOAParamヘッダからのTrackHOAParamHorizontalOrderフィールドに等しい。2D HOA係数は、−N≦m≦NとしてC_|m| ^m＝C_mとして定義され、表１０に示されるような3D係数の部分集合として表現できる。

3D音場については、Oは(N＋1)²に等しい。ここで、NはTrackHOAParamヘッダからのTrackHOAParamVerticalOrderフィールドに等しい。3D HOA係数C_n ^mは、0≦n≦Nおよび−n≦m≦nについて定義される。HOA係数の一般的な表現は表１０に与えられる。

3D音場かつTrackHOAParamVerticalOrderより大きなTrackHOAParamHorizontalOrderの場合、混合次数のデコードが実行される。混合次数信号では、いくつかの高次係数は2Dでのみ伝送される。TrackHOAParamVerticalOrderフィールドはすべての係数が伝送される垂直方向次数を決定する。垂直方向次数からTrackHOAParamHorizontalOrderまでは、2D係数のみが使用される。このように、TrackHOAParamHorizontalOrderはTrackHOAParamVerticalOrder以上である。水平方向次数4および垂直方向次数2の混合次数表現の例が表１１に描かれている。

HOA係数C_n ^mはトラックのパケット中に記憶される。係数のシーケンス、たとえばどの係数が最初にきてどれがそれに続くか、は、過去に種々の仕方で定義されてきた。よって、TrackHOAParamCoeffSequence〔トラックHOAパラメータ係数シーケンス〕は三つの型の係数シーケンスを示す。三つのシーケンスは、表１０のHOA係数配置から導出される。

Bフォーマット・シーケンスは、表１２に示されるように、三次までのHOA係数について特別な用語を使う。

Bフォーマットについては、HOA係数は最低次から最高次に伝送される。ここで、各次数のHOA係数はアルファベット順に伝送される。たとえば、HOA次数3の3Dセットアップの係数は、W、X、Y、S、R、S、T、U、V、K、L、M、N、O、P、Qのシーケンスで記憶される。Bフォーマットは、HOA次数3まで定義されているだけである。水平方向（2D）係数の伝送のために、補足的3D係数は無視される。たとえば、W、X、Y、U、V、P、Qとなる。

3D HOAについての係数C_n ^mは最低から最高のHOA次数（n＝0…N）に数値的に昇順または降順にTrackHOAParamCoeffSequenceにおいて伝送される。数値的な昇順シーケンスはm＝−nで始まり、m＝nまで増大する（C₀ ⁰、C₁ ^-1、C₁ ⁰、C₁ ¹、C₂ ^-2、C₂ ^-1、C₂ ⁰、C₂ ¹、C₂ ²、…）。これは非特許文献１７で定義される「CG」シーケンスである。数値的に降順のシーケンスmは逆にm＝nからm＝−nに進み（C₀ ⁰、C₁ ¹、C₁ ⁰、C₁ ^-1、C₂ ²、C₂ ¹、C₂ ⁰、C₂ ^-1、C₂ ^-2、…）、これは非特許文献１７で定義される「QM」シーケンスである。

2D HOA係数については、TrackHOAParamCoeffSequenceの数値的に昇順および降順のシーケンスは3Dの場合と同様であるが、|m|≠nで不使用の係数（すなわち、表１０の扇形の（sectoral）HOA係数C_|m| ^m＝Cmのみ）は省略される。よって、数値的に昇順のシーケンスは（C₀ ⁰、C₁ ^-1、C₁ ¹、C₂ ^-2、C₂ ²、…）につながり、数値的に降順のシーケンスは（C₀ ⁰、C₁ ¹、C₁ ^-1、C₂ ²、C₂ ^-2、…）につながる。

トラック・パケット
HOAトラック・パケット
PCM符号化型パケット

このパケットはHOA係数C_n ^mをTrackHOAParamCoeffSequenceにおいて定義される順序で含んでいる。ここで、一つの時間サンプルのすべての係数が相続いて伝送される。このパケットは、0であるTrackSourceTypeおよび0であるTrackCodingTypeをもつ標準的なHOAトラックについて使われる。

動的分解能符号化型パケット

動的分解能パッケージは「0」であるTrackSourceTypeおよび「1」であるTrackCodingTypeについて使用される。TrackOrderRegions〔トラック次数領域〕の異なる分解能は各TrackOrderRegionについての異なる記憶サイズにつながる。したがって、HOA係数はインターリーブ解除された仕方で記憶される。たとえば、あるHOA次数のすべての係数が相続いて記憶される。

単独源トラック・パケット
単独源固定位置パケット

単独源固定位置パケットは「1」であるTrackSourceTypeおよび「0」であるTrackMovingSourceFlagについて使用される。パケットはモノ源のPCMサンプルを保持する。

単独源移動位置パケットは「1」であるTrackSourceTypeおよび「1」であるTrackMovingSourceFlagについて使用される。これはモノPCMサンプルおよびトラック・パケットのサンプルについての位置情報を保持する。

PacketDirectionFlagは、パケットの方向が変わったか、直前のパケットの方向が使われるべきかを示す。各フレームの先頭からのデコードを保証するために、フレームの最初の移動源トラック・パケットについてはPacketDirectionFlagは「1」に等しい。

「1」であるPacketDirectionFlagについては、後続のPCMサンプル源の方向情報が伝送される。TrackPositionTypeに依存して、方向情報は球面座標でのTrackPositionVector〔トラック位置ベクトル〕として、あるいは定義されたTrackEncodingVectorFormatをもつTrackHOAEncodingVector〔トラックHOAエンコード・ベクトル〕として送られる。TrackEncodingVector〔トラック・エンコード・ベクトル〕は、HOAParamHeaderフィールド定義に従うHOA係数を生成する。方向情報に続いて、トラック・パケットのPCMモノサンプルが伝送される。

符号化処理
トラック領域符号化（TrackRegion Coding）
HOA信号は、マイクロホン・アレイによる音場記録から導出できる。たとえば、特許文献２においてEigenmikeは三次のHOA記録を得るために使用できることを開示した。しかしながら、マイクロホン・アレイの有限な大きさのため、記録されるHOA係数に制約が生じる。特許文献２および上述した非特許文献４では、有限なマイクロホン・アレイによって引き起こされる問題が論じられている。

マイクロホン・カプセルの距離は、空間的サンプリング定理によって与えられる上限周波数につながる。この上限周波数より上では、マイクロホン・アレイは正しいHOA係数を生成できない。さらに、HOA聴取位置からのマイクロホンの有限な距離は等化フィルタを必要とする。これらのフィルタは、低周波数について高い利得を得、該利得はHOA次数毎にさらに増大する。特許文献２では、等化フィルタのダイナミックレンジを扱うために、高次係数についてのより低いカットオフ周波数が導入される。これは、異なるHOA次数のHOA係数の帯域幅が異なることができることを示している。したがって、HOAファイル・フォーマットは、トラック領域帯域幅削減を提供している。これは、各HOA次数について必要とされる周波数帯域幅のみを伝送することを許容する。等化フィルタの高いダイナミックレンジのため、またゼロ次の係数が基本的にはすべてのマイクロホン信号の和であるという事実のため、異なるHOA次数の係数は異なるダイナミックレンジをもつことができる。したがって、HOAファイル・フォーマットは、フォーマット型を各HOA次数のダイナミックレンジに適応させる特徴をも提供する。

トラック領域エンコード処理
図１２に示されるように、インターリーブされたHOA係数は第一のインターリーブ解除ステップまたは段１２１１に入力される。このステップまたは段１２１１は第一のトラック領域に割り当てられており、該トラック領域のすべてのHOA係数を、FramePacketSize個のサンプルへのインターリーブ解除されたバッファに分離する。このトラック領域の係数はHOAトラック・ヘッダのTrackRegionLastOrderおよびTrackRegionFirstOrderフィールドから導出される。インターリーブ解除は、nとmの一つの組み合わせについての諸係数C_n ^mが一つのバッファにグループ化されることを意味する。インターリーブ解除ステップまたは段１２１１から、インターリーブ解除されたHOA係数はトラック領域エンコード部に渡される。残りのインターリーブされたHOA係数は後続のトラック領域インターリーブ解除ステップまたは段に渡される、などとなり、インターリーブ解除ステップまたは段１２１Ｎまで続く。インターリーブ解除ステップまたは段の数NはTrackNumberOfOrderRegionsに「1」を加えたものに等しい。追加的なインターリーブ解除ステップまたは段１２５は、トラック領域の一部でない残りの係数をインターリーブ解除して、フォーマット変換ステップまたは段１２６を含む標準的な処理経路に入れる。

トラック領域エンコード経路は、任意的な帯域幅削減ステップまたは段１２２１およびフォーマット変換ステップまたは段１２３１を含み、各HOA係数バッファについて並列処理を実行する。帯域幅削減は、TrackRegionUseBandwidthReduction〔トラック領域帯域幅削減使用〕フィールドが「1」に設定されていたら実行される。選択されたTrackBandwidthReductionType〔トラック帯域幅削減型〕に依存して、HOA係数の周波数範囲を制限するため、およびそれらの係数を臨界的にダウンサンプリングするための処理が選択される。これは、HOA係数の数を、最低限必要とされるサンプル数まで削減するために実行される。フォーマット変換は、現在のHOA係数フォーマットをHOAトラック・ヘッダにおいて定義されているTrackRegionSampleFormat〔トラック領域サンプル・フォーマット〕に変換する。これは、HOA係数をHOAトラック・ヘッダの指示されるTrackSampleFormat〔トラック・サンプル・フォーマット〕に変換する標準的な処理経路にある唯一のステップ／段である。

マルチプレクサ・トラック・パケット・ステップまたは段１２４はHOA係数バッファを多重化して、選択されたTrackHOAParamCoeffSequenceフィールドにおいて定義されているトラック・パケット・データ・ファイル・ストリームにする。ここで、nとmのインデックスの一つの組み合わせについての諸係数C_n ^mは（一つのバッファ内で）インターリーブ解除されたままである。

トラック領域デコード処理
図１３に示されるように、デコード処理はエンコード処理の逆である。デマルチプレクサ・ステップまたは段１３４はトラック・パケット・データ・ファイルまたはストリームを指示されるTrackHOAParamCoeffSequenceからインターリーブ解除されたHOA係数バッファ（図示せず）に多重分離する。各バッファはnとmの一つの組み合わせについてFramePacketLength個の係数C_n ^mを含む。

ステップ／段１３４はTrackNumberOfOrderRegionに「1」を加えた数の処理経路を初期化し、インターリーブ解除されたHOA係数バッファの内容を適切な処理経路に渡す。各トラック領域の係数はHOAトラック・ヘッダのTrackRegionLastOrderおよびTrackRegionFirstOrderフィールドによって定義される。選択された諸トラック領域によってカバーされないHOA次数は、フォーマット変換ステップまたは段１３６および残りの係数インターリーブ・ステップまたは段１３５を含む標準的な処理経路において処理される。標準的な処理経路は、帯域幅削減ステップまたは段のないトラック処理経路に対応する。

これらのトラック処理経路において、フォーマット変換ステップ／段１３３１ないし１３３Ｎは、TrackRegionSampleFormatでエンコードされているHOA係数をデコーダの処理のために使われるデータ・フォーマットに変換する。TrackRegionUseBandwidthReductionデータ・フィールドに依存して、任意的な帯域幅再構成ステップまたは段１３２１ないし１３２Ｎが続く。ここでは、帯域幅制限され臨界的にサンプリングされたHOA係数がトラックのフル帯域幅に再構成される。再構成処理の種類はHOAトラック・ヘッダのTrackBandwidthReductionTypeフィールドにおいて定義される。後続のインターリーブ・ステップまたは段１３１１ないし１３１Ｎでは、HOA係数のインターリーブ解除されたバッファの内容が、一つの時間サンプルのHOA係数をグループ化することによってインターリーブされ、現在のトラック領域のHOA係数が先行する諸トラック領域のHOA係数と組み合わされる。結果として得られるHOA係数のシーケンスは、当該トラックの処理に適応されることができる。さらに、インターリーブ・ステップ／段は、帯域幅削減を使っているトラック領域と帯域幅削減を使っていないトラック領域との間の遅延に対処する。この遅延は、選択されたTrackBandwidthReductionTypeの処理に依存する。たとえば、MDCT処理はFramPacketSize個のサンプルの遅延を加え、よって帯域幅削減のない処理経路のインターリーブ・ステップ／段はその出力を１パケットだけ遅らせる。

MDCTによる帯域幅削減
エンコード
図１４は、MDCT（modified discrete cosine transform［修正離散コサイン変換］）処理を使った帯域幅削減を示している。FramePacketSize個のサンプルのトラック領域の各HOA係数はバッファ１４１１ないし１４１Ｍを介して、対応するMDCT窓掛けステップまたは段１４２１ないし１４２Ｍを通る。各入力バッファは、nとmの一つの組み合わせの時間的な相続くHOA係数C_n ^mを含む。すなわち、一つのバッファは、

として定義される。バッファの数Mは、アンビソニックス成分の数（次数Nのフル3D音場については(N＋1)²）と同じである。バッファ処理は、前のバッファ内容を現在のバッファ内容と組み合わせて対応するステップまたは段１４３１におけるMDCT処理のための新しい内容にすることによって後続のMDCT処理について50%の重なりを実行し、後続のバッファ内容の処理のために現在のバッファ内容を保存しておく。MDCT処理は各フレームの先頭から改めて開始される。これはつまり、現在フレームのあるトラックのすべての係数が、前のフレームの知識なしにデコードでき、現在フレームの最後のバッファ内容に続いては、0からなる追加的なバッファ内容が処理されるということを意味する。したがって、MDCT処理されたトラック領域は一つの余計なトラック・パケットを生成する。

窓掛けステップ／段では、対応するバッファ内容が選択された窓関数w(t)を乗算される。選択された窓関数は各トラック領域についてHOAトラック・ヘッダのフィールドTrackRegionWindowTypeにおいて定義されている。

修正離散コサイン変換は非特許文献１８において最初に言及されたものである。MDCTは、FramePacketSize個のサブバンドの臨界的にサンプリングされたフィルタバンクを表すと考えることができ、50%の入力バッファの重なりを要求する。入力バッファはサブバンド・サイズの二倍の長さをもつ。MDCTは、TがFramePacketSizeに等しいとして、次の式によって定義される。

係数C'_n ^m(k)はMDCTビンと呼ばれる。MDCT計算は高速フーリエ変換を使って実装できる。後続の周波数領域カットアウト・ステップまたは段１４４１ないし１４４Ｍでは、k＜TrackRegionFirstBinおよびk＞TrackRegionLastBinのすべてのMDCTビンC'_n ^m(k)を除去することによって、帯域幅削減が実行される。バッファ長さのTrackRegionLastBin−TrackRegionFirstBin＋1への削減である。ここで、TrackRegionFirstBinは当該トラック領域についての下カットオフ周波数であり、TrackRegionLastBinは上カットオフ周波数である。MDCTビンを無視することは、TrackRegionLastBinおよびTrackRegionFirstBin周波数に対応するカットオフ周波数をもつ帯域通過フィルタを表していると見なすことができる。したがって、必要とされるMDCTビンのみが伝送される。

デコード
図１５は、MDCT処理を使った帯域幅デコードまたは再構成を示している。ここでは、帯域幅制限されたトラック領域のHOA係数が当該トラックのフル帯域幅に再構成される。この帯域幅再構成は、時間的にインターリーブ解除されたHOA係数のバッファ内容を並列に処理する。ここで、各バッファは係数C'_n ^m(k)のTrackRegionLastBin−TrackRegionFirstBin＋1個のMDCTビンを含む。欠けている周波数領域の追加ステップまたは段１５４１ないし１５４Ｍは、k＜TrackRegionFirstBinおよびk＞TrackRegionLastBinの欠けているMDCTビンを0を使って受領されたMDCTビンを補完することによって、サイズFramePacketLengthの完全なMDCTバッファ内容を再構成する。その後、時間領域のHOA係数C_n ^m(t)を再構成するために、対応する逆MDCTステップまたは段１５３１ないし１５３Ｍにおいて逆MDCTが実行される。逆MDCTは、FramePacketLength個のMDCTビンがFramePacketLengthの２倍の数の時間領域係数に変換される合成フィルタバンクと解釈されることができる。しかしながら、時間領域サンプルの完全な再構成は、エンコーダにおいて使用された窓関数w(t)の乗算と、現在のバッファ内容の前半と前のバッファ内容の後半の重複加算（overlap-add）とを必要とする。逆MDCTは次式によって定義される。

MDCTと同様に、逆MDCTは逆高速フーリエ変換を使って実装できる。

MDCT窓掛けステップまたは段１５２１ないし１５２Ｍは、TrackRegionWindowTypeによって定義される窓関数を、再構成された時間領域係数に乗算する。後続のバッファ１５１１ないし１５１Ｍは、FramePacketSize個の時間領域係数を再構成するために、現在のトラック・パケット・バッファ内容の前半を直前のトラック・パケット・バッファ内容の後半に加える。現在のトラック・パケット・バッファ内容の後半は、次のトラック・パケットの処理のために保存される。この重複加算処理は、両バッファ内容の逆のエイリアシング成分を除去する。

複数フレームHOAファイルについては、エンコーダは、新しいフレームの先頭における重複加算手順のために前のフレームの最後のバッファ内容を使うことを禁止される。したがって、フレーム境界においてまたは新しいフレームの先頭においては、重複加算バッファ内容が欠けていることになり、フレームの最初のトラック・パケットの再構成が、第二のトラック・パケットにおいて実行されることができる。それにより、帯域幅削減のない処理経路に比べ、一フレーム・パケットおよび一つの余計なトラック・パケットのデコードの遅延が導入される。この遅延は、図１３との関連で述べたインターリーブ・ステップ／段によって対処される。

Claims

アンビソニックス係数を含む高次アンビソニックスHOAオーディオ・データのためのデータ構造であって、当該データ構造は一つまたは複数の異なるHOAオーディオ・データ・ストリーム記述についての2Dおよび／または3D空間的オーディオ・コンテンツ・データを含み、当該データ構造は「3」より大きな次数をもつHOAオーディオ・データについても好適であり、当該データ構造はさらに、固定したまたは時間変化する空間位置からの単独オーディオ信号源データおよび／またはマイクロホン・アレイ・オーディオ・データを含むことができ、
前記異なるHOAオーディオ・データ・ストリーム記述は、異なるスピーカー位置密度、符号化されたHOA波型、HOA次数およびHOA次元性のうち少なくとも二つに関係しており、
あるHOAオーディオ・データ・ストリーム記述は呈示サイトの明確に区別される領域に位置される密なスピーカー配置での呈示のためのオーディオ・データを含み、別のHOAオーディオ・データ・ストリーム記述は前記呈示サイトを囲むそれほど密でないスピーカー配置での呈示のためのオーディオ・データを含む、
データ構造。
前記密なスピーカー配置のための前記オーディオ・データは球面波および第一のアンビソニックス次数を表し、前記それほど密でないスピーカー配置のための前記オーディオ・データは平面波および／または前記第一のアンビソニックス次数より小さな第二のアンビソニックス次数を表す、請求項２記載のデータ構造。
前記データ構造は、オーディオ・シーンのトラックが任意の時点に開始および終了できるシーン記述のはたらきをする、請求項１または２記載のデータ構造。
当該データ構造が：
・聴取領域の外側または内側のオーディオ源に関係する関心領域；
・球面基底関数の規格化；
・伝搬の方向性；
・アンビソニックス係数スケーリング情報；
・アンビソニックス波型、たとえば平面か球面か；
・球面波の場合、デコードのための基準半径
に関するデータ項目を含む、請求項１ないし３のうちいずれか一項記載のデータ構造。
前記アンビソニックス係数が複素係数である、請求項１ないし４のうちいずれか一項記載のデータ構造。
当該データ構造が、一つまたは複数のマイクロホンについての方向および特性に関するメタデータを含むおよび／または単独源入力信号についての少なくとも一つのエンコード・ベクトルを含む、請求項１ないし５のいずれか一項記載のデータ構造。
前記アンビソニックス係数の少なくとも一部が帯域幅削減され、それにより異なるHOA次数について関係するアンビソニックス係数の帯域幅が異なる（１２２１−１２２Ｎ）、請求項１ないし６のうちいずれか一項記載のデータ構造。
前記帯域幅削減がMDCT処理（１４３１−１４３Ｍ）に基づく、請求項７記載のデータ構造。
請求項１ないし８のうちいずれか一項記載のデータ構造のためにデータをエンコードし、配置する方法。
オーディオ呈示の方法であって、少なくとも二つの異なるHOAオーディオ・データ信号を含むHOAオーディオ・データ・ストリームが受領され、前記信号のうち少なくとも第一のものが呈示サイトの明確に区別される領域に位置される密なスピーカー配置での呈示のために使われ（２３１、２３２）、前記信号のうち少なくとも第二の、異なるものが前記呈示サイトを囲むそれほど密でないスピーカー配置での呈示のために使われる（２４１、２４２、２４３）、方法。
前記密なスピーカー配置のための前記オーディオ・データは球面波および第一のアンビソニックス次数を表し、前記それほど密でないスピーカー配置のための前記オーディオ・データは平面波および／または前記第一のアンビソニックス次数より小さな第二のアンビソニックス次数を表す、請求項１０記載の方法。
前記呈示サイトが映画館における聴取領域または着席領域である、請求項１もしくは２記載のデータ構造または請求項１０または１１記載の方法。
請求項１０または１１記載の方法を実行するよう適応された装置。