(57)【要約】本発明は、高次アンビソニックスHOAオーディオ・データのためのデータ構造に関し、当該データ構造は一つまたは複数の異なるHOAオーディオ・データ・ストリーム記述についての2Dまたは3D空間的オーディオ・コンテンツ・データを含む。前記HOAオーディオ・データは「3」より大きな次数をもつことができ、当該データ構造はさらに、固定したまたは時間変化する空間位置からの単独オーディオ信号源データおよび／またはマイクロホン・アレイ・オーディオ・データを含むことができる。
2013545391.tif 000002
【特許請求の範囲】
【請求項１】
アンビソニックス係数を含む高次アンビソニックスHOAオーディオ・データのためのデータ構造であって、当該データ構造は一つまたは複数の異なるHOAオーディオ・データ・ストリーム記述についての2Dおよび／または3D空間的オーディオ・コンテンツ・データを含み、当該データ構造は「3」より大きな次数をもつHOAオーディオ・データについても好適であり、当該データ構造はさらに、固定したまたは時間変化する空間位置からの単独オーディオ信号源データおよび／またはマイクロホン・アレイ・オーディオ・データを含むことができ、
前記異なるHOAオーディオ・データ・ストリーム記述は、異なるスピーカー位置密度、符号化されたHOA波型、HOA次数およびHOA次元性のうち少なくとも二つに関係しており、
あるHOAオーディオ・データ・ストリーム記述は呈示サイトの明確に区別される領域に位置される密なスピーカー配置での呈示のためのオーディオ・データを含み、別のHOAオーディオ・データ・ストリーム記述は前記呈示サイトを囲むそれほど密でないスピーカー配置での呈示のためのオーディオ・データを含む、
データ構造。
【請求項２】
前記密なスピーカー配置のための前記オーディオ・データは球面波および第一のアンビソニックス次数を表し、前記それほど密でないスピーカー配置のための前記オーディオ・データは平面波および／または前記第一のアンビソニックス次数より小さな第二のアンビソニックス次数を表す、請求項２記載のデータ構造。
【請求項３】
前記データ構造は、オーディオ・シーンのトラックが任意の時点に開始および終了できるシーン記述のはたらきをする、請求項１または２記載のデータ構造。
【請求項４】
当該データ構造が：
・聴取領域の外側または内側のオーディオ源に関係する関心領域；
・球面基底関数の規格化；
・伝搬の方向性；
・アンビソニックス係数スケーリング情報；
・アンビソニックス波型、たとえば平面か球面か；
・球面波の場合、デコードのための基準半径
に関するデータ項目を含む、請求項１ないし３のうちいずれか一項記載のデータ構造。
【請求項５】
前記アンビソニックス係数が複素係数である、請求項１ないし４のうちいずれか一項記載のデータ構造。
【請求項６】
当該データ構造が、一つまたは複数のマイクロホンについての方向および特性に関するメタデータを含むおよび／または単独源入力信号についての少なくとも一つのエンコード・ベクトルを含む、請求項１ないし５のいずれか一項記載のデータ構造。
【請求項７】
前記アンビソニックス係数の少なくとも一部が帯域幅削減され、それにより異なるHOA次数について関係するアンビソニックス係数の帯域幅が異なる（１２２１−１２２Ｎ）、請求項１ないし６のうちいずれか一項記載のデータ構造。
【請求項８】
前記帯域幅削減がMDCT処理（１４３１−１４３Ｍ）に基づく、請求項７記載のデータ構造。
【請求項９】
請求項１ないし８のうちいずれか一項記載のデータ構造のためにデータをエンコードし、配置する方法。
【請求項１０】
オーディオ呈示の方法であって、少なくとも二つの異なるHOAオーディオ・データ信号を含むHOAオーディオ・データ・ストリームが受領され、前記信号のうち少なくとも第一のものが呈示サイトの明確に区別される領域に位置される密なスピーカー配置での呈示のために使われ（２３１、２３２）、前記信号のうち少なくとも第二の、異なるものが前記呈示サイトを囲むそれほど密でないスピーカー配置での呈示のために使われる（２４１、２４２、２４３）、方法。
【請求項１１】
前記密なスピーカー配置のための前記オーディオ・データは球面波および第一のアンビソニックス次数を表し、前記それほど密でないスピーカー配置のための前記オーディオ・データは平面波および／または前記第一のアンビソニックス次数より小さな第二のアンビソニックス次数を表す、請求項１０記載の方法。
【請求項１２】
前記呈示サイトが映画館における聴取領域または着席領域である、請求項１もしくは２記載のデータ構造または請求項１０または１１記載の方法。
【請求項１３】
請求項１０または１１記載の方法を実行するよう適応された装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、高次アンビソニックス・オーディオ・データ用のデータ構造に関する。これは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)2個（2Dについては(2N+1)個）の異なるオーディオ・オブジェクトの集合が、それらが空間的に均等に分布している限り、異なる音オブジェクトとして記録（エンコード）され、再生されることができる。これは、一次アンビソニックス信号は四つの3Dまたは三つの2Dオーディオ・オブジェクトを担持でき、これらのオブジェクトは3Dについては球のまわりに、2Dについては円のまわりに一様に離間している必要があることを意味する。空間的な重なりおよび記録におけるM個より多い信号は、ぼけを生じる――最も大きな信号だけがコヒーレントなオブジェクトとして再生されることができ、他の散漫な信号は、空間、周波数およびラウドネス類似性における重なりに依存して何らかの仕方でコヒーレントな信号を劣化させる。
【０００７】
映画館における音響状況に関しては、前方スクリーン領域については、視覚的なシーンに合うよう、高い空間的な音の定位精度が要求される。サラウンド・サウンド・オブジェクトの知覚はそれほど決定的ではない（残響、視覚的なシーンと関連のない音オブジェクト）。ここで、スピーカーの密度は、前方領域に比べて小さくてもよい。
【０００８】
前方領域について重要なHOAデータのHOA次数は、随意にホロフォニックな再生を可能にするよう、大きくなければならない。典型的な次数はN＝10である。これは、(N+1)2＝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ファイルは、周辺音Anm(t)についておよび視覚的な主たるアクションに関係した前方音Cnm(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（hn(krd_mic)での過剰な低周波数レベルを削減するために高域通過フィルタ処理される。式(34)参照。任意的に、距離符号化フィルタ処理が適用されてもよい。式(25)および(27)参照。記憶の前に、HOAフォーマット情報がトラック・ヘッダに追加される。
【００３５】
人工的な音場表現は通例、複数の方向性の単独源ストリームを使って生成される。図３のｂに示されるように、単独源信号はPCM記録として捕捉されることができる。これは、クローズアップ・マイクロホンによってまたは高い指向性をもつマイクロホンを使うことによってできる。さらに、仮想的な最良の聴取位置に対する音源の方向パラメータ（rs,Θs,φs）が記録される（HOA座標系またはのちのマッピングのための任意の基準点）。映画のためのシーンをレンダリングするときに、音を人工的に定位するために、距離情報も生成されてもよい。図３のｃに示されるように、その場合、方向情報（Θs,φs）はエンコード・ベクトルΨを生成するために使われ、方向性の音信号はアンビソニックス信号にエンコードされる。式(18)参照。これは、平面波表現と等価である。後続するフィルタ処理プロセスは、距離情報rsを使って、球面状の音特性をアンビソニックス信号にインプリントし（式(19)）、あるいは距離符号化フィルタ処理を適用、式(25)、(27)してもよい。記憶の前に、HOAフォーマット情報がトラック・ヘッダに追加される。
【００３６】
より複雑な音場記述が、図３のｄに描かれるようなアンビソニックス信号のHOA混合によって生成される。記憶の前に、HOAフォーマット情報がトラック・ヘッダに追加される。
【００３７】
3D映画館用のコンテンツ生成のプロセスが図４に描かれている。視覚的なアクションに関係する前方音は高い空間的精度でエンコードされ、HOA信号（音場）Cnm(t)に混合され、トラック２として記憶される。込み入ったエンコーダは、視覚的なシーンと最もよく合致するために必要な高い空間的精度および特殊な波の型をもってエンコードする。トラック１は、ソース方向の制約なしに、エンコードされる周辺音に関係する音場Anm(t)を含む。通例、周辺音の空間的精度は前方音ほど高い必要はなく（その結果、アンビソニックス次数はより小さいことができる）、波型のモデル化はそれほど決定的ではない。周辺音場はまた、前方音信号の残響部分をも含むことができる。両方のトラックは記憶および／または交換のために多重化される。
【００３８】
任意的に、方向性の音（たとえばトラック３）がファイルに多重化されることができる。これらの音は特殊効果音、対話または視覚障害者のためのナレーション音声のような補助情報であることができる。
【００３９】
図５は、デコードの原理を示している。上部に描かれるように、疎なスピーカー・セットアップをもつ映画館は、単純化されたHOAデコードの前にトラック１およびトラック２からのHOA信号両方を混合することができ、トラック２の次数を打ち切り、両トラックの次元を2Dに下げてもよい。方向性ストリームが存在する場合、そのストリームは2D  HOAにエンコードされている。その場合、三つのストリームすべてが混合されて単一のHOA表現を形成し、それが次いでデコードされ、再生される。
【００４０】
下部は図２に対応する。前方ステージのためのホロフォニック・システムおよびより粗い3Dサラウンド・システムを備える映画館は、専用の洗練されたデコーダを使い、スピーカー入力を混合する。トラック１データ・ストリームについては、周辺音を表すHOAデータが周辺音再生のために特化されたデコーダ１向けに変換される。トラック２データ・ストリームについては、HOA（視覚的なシーンに関係した前方音）は、専用のデコーダ２でのスクリーン領域のまわりの球状音源の最善の配置のため、変換され、距離補正される（式(26)）。方向性のデータ・ストリームはL個のスピーカーに直接パンされる。三つのスピーカー信号は3Dスピーカー・システムでの統合再生のためにPCM混合される。
【００４１】
高次アンビソニックスを使った音場記述
球面調和関数（SH）を使った音場記述
球面調和関数／ベッセル記述を使うとき、音響的な波の方程式の解は式(1)で与えられる。非特許文献４参照。音圧は球面座標r、Θ、Φ（定義については図７参照）および空間周波数k＝ω/c＝2πf/cの関数である。
【００４２】
その記述は、関心領域または有効性領域の外側のオーディオ音源についても有効であり（図６に示される内部領域問題）、正規直交化された球面調和関数
【００４３】
【数１】
2013545391.tif 000003
を想定している。Anm(k)はアンビソニック係数と呼ばれ、jn(kr)は第一種の球面ベッセル関数であり、Ynm(θ,φ)は球面調和関数（SH:  Spherical  Harmonics）と呼ばれ、nはアンビソニックス次数（order）インデックスであり、mは度数（degree）を示す。
【００４４】
小さなkr値（原点からの小さな距離または低周波数）についてのみ有意な値をもつベッセル関数の性質のため、この級数は、充分な精度をもって、何らかの次数nで止め、値Nに制約することができ、HOAデータを記憶する際、通例、アンビソニックス係数Anm,Bnmまたは何らかの派生物（詳細は後述）がその次数Nまで記憶される。Nはアンビソニックス次数と呼ばれる。
【００４５】
Nはアンビソニックス次数と呼ばれ、用語「次数」は通例、ベッセル関数jn(kr)およびハンケル関数hn(kr)と組み合わせても使われる。
【００４６】
図８に描かれるように源が関心領域または有効性領域の内側にある外部ケースについての波の方程式の解は、r＞rsource〔r源〕について、式(2)で表される。
【００４７】
【数２】
2013545391.tif 000004
Bnm(k)はやはりアンビソニックス係数と呼ばれ、h(1)n(kr)はn次の第一種の球面ハンケル関数である。この公式は正規直交化されたSHを想定している。
【００４８】
コメント：一般に、第一種の球面ハンケル関数h(1)n(kr)は、正の周波数について出ていく波（eikrに関係）を記述するために使われ、第二種の球面ハンケル関数h(2)nは、はいってくる波（e-ikrに関係）のために使われる。上述した非特許文献５参照。
【００４９】
球面調和関数
球面調和関数Ynmは複素数値であることも実数値であることもある。HOAのための一般的なケースは実数値の球面調和関数を使う。実および複素球面調和関数を使ったアンビソニックスの統一的な記述は非特許文献６で概観できる。
【００５０】
球面調和関数を規格化するには種々の方法がある（これは球面調和関数が実か複素かとは独立である）。非特許文献７参照。
【００５１】
規格化は、YnmとYn'm'*との間の直交関係に対応する。
【００５２】
コメント：
【００５３】
【数３】
2013545391.tif 000005
ここで、S2は単位球であり、クロネッカーのデルタδaa'はa＝a'については1、それ以外では0に等しい。
【００５４】
複素球面関数は
【００５５】
【数４】
2013545391.tif 000006
によって記述される。ここで、i＝√(−1)であり、smは先述した非特許文献５と同様に、正のmについては交互の符号を与えるようsm＝(−1)mであり、それ以外の場合にはsm＝1である。（コメント：smは慣例上の項であり、正のみのSHについては省略可。）Nn,mは規格化項であり、正規直交化された表現については次の形を取る（!は階乗を表す）。
【００５６】
【数５】
2013545391.tif 000007
下記の表１は、複素数値の球面調和関数についてのいくつかの一般的に使われる規格化方式を示す。Pn,|m|(x)はルジャンドル陪関数であり、上述の非特許文献６からの|m|を用いた記法に従っている。これは、コンドン・ショートリー（Condon-Shortley）位相と呼ばれ、他の記法ではPnmの表現内に含まれることがある位相項(−1)mを回避する。ルジャンドル陪関数
【００５７】
【数６】
2013545391.tif 000008
はロドリーグの公式を使って次のように表現できる。
【００５８】
【数７】
2013545391.tif 000009
【００５９】
【表１】
2013545391.tif 000010
数値的には、Pn,|m|(x)を再帰関係から漸進的に導出することが有利である。非特許文献９参照。n＝4までのルジャンドル陪関数を表２に与えておく。
【００６０】
【表２】
2013545391.tif 000011
実数値のSHはmの互いに反対の値に対応する複素共役Ynmを組み合わせることによって導かれる（定義(6)における項(−1)mは、アンビソニックスにおける通常のケースである実SHのための符号なしの表現を得るために導入されている）。
【００６１】
【数８】
2013545391.tif 000012
これは、方位角項のみを保持した
【００６２】
【数９】
2013545391.tif 000013
の円調和関数とのつながりをハイライトするために式(7)のように書き直すことができる。
【００６３】
【数１０】
2013545391.tif 000014
所与のアンビソニックス次数Nについての球面成分Snmの総数は(N＋1)2に等しい。実数値の球面調和関数の一般的な規格化方式を表３に与えておく。
【００６４】
【表３】
2013545391.tif 000015
円調和関数
二次元表現だけの場合には、調和関数のサブセットが必要とされる。SH度数はm∈{−n,n}の値のみを取ることができる。所与のNについての成分の総数は2N＋1に減る。傾斜角θを表す成分が不要になり、球面調和関数が式(8)で表される円調和関数で置き換えられるからである。
【００６５】
円調和関数については種々の規格化Nm方式があり、3Dアンビソニックス係数を2D係数に変換するときにはこれを考える必要がある。円調和関数についての一般的な公式は次のようになる。
【００６６】
【数１１】
2013545391.tif 000016
円調和関数についてのいくつかの一般的な規格化因子を表４に与えておく。ここで、規格化項は水平面内の項
【００６７】
【数１２】
2013545391.tif 000017
の前の因子によって導入される。
【００６８】
【表４】
2013545391.tif 000018
異なる規格化の間の変換はストレートなことである。一般に、規格化は圧力を記述する記法（式(1)、(2)参照）およびすべての派生する考察に対して効果をもつ。規格化の種類はアンビソニックス係数にも影響する。これらの係数をスケーリングするために適用できる重みもある。たとえば、AMBフォーマットを使ってファイルを記憶するときにアンビソニックス係数に適用されるファース・モーム（FuMa）重みである。
【００６９】
2D‐3D変換に関し、たとえば2Dスピーカー設定のための2Dデコーダで3Dアンビソニックス表現（記録）をデコードするとき、CHからSHへおよびその逆の変換はアンビソニックス係数にも適用できる。3D‐2D変換のための
【００７０】
【数１３】
2013545391.tif 000019
の間の関係は、アンビソニックス次数4までは、次の図式に描かれる。
【００７１】
【数１４】
2013545391.tif 000020
2Dから3Dの変換因子は、θ＝π/2にある水平ペインについて、次のように導出できる。
【００７２】
【数１５】
2013545391.tif 000021
3Dから2Dへの変換は
【００７３】
【数１６】
2013545391.tif 000022
を使う。詳細は下記で式(28)(29)(30)との関連で呈示する。
【００７４】
2D規格化から正規直交化への変換は
【００７５】
【数１７】
2013545391.tif 000023
となる。
【００７６】
アンビソニックス係数
アンビソニックス係数は音圧の単位スケール
【００７７】
【数１８】
2013545391.tif 000024
をもつ。アンビソニックス係数はアンビソニックス信号を形成し、一般に、離散時間の関数である。表５は、次元表現、アンビソニックス次数およびアンビソニックス係数（チャネル）の数の間の関係を示している。
【００７８】
【表５】
2013545391.tif 000025
離散時間表現を扱う際は、通例、アンビソニックス係数は、多チャネル記録のPCMチャネル表現のように（チャネル＝サンプルvのアンビソニックス係数Anm）インターリーブ式に記憶される。係数シーケンスは慣例の問題である。3D、N＝2についての一例は
【００７９】
【数１９】
2013545391.tif 000026
となり、2D、N＝2については、
【００８０】
【数２０】
2013545391.tif 000027
となる。
【００８１】
A00(n)信号は、アンビソニックス記録のモノ表現と見なすことができ、方向情報をもたず、記録の全般的な音質印象を表す。
【００８２】
アンビソニックス係数の規格化は一般に、SHの規格化に従って実行される（下記で明白となるであろう。式(15)参照）。外部記録をデコードするときにはこのことを考慮に入れる必要がある。（下記で、Anmは規格化因子Nn,mでのSHに基づき、ハチェック付きAnmは規格化因子ハチェック付きNn,mでのSHに基づく）
【００８３】
【数２１】
2013545391.tif 000028
これは、SN3DからN3Dの場合には
【００８４】
【数２２】
2013545391.tif 000029
となる。
【００８５】
BフォーマットおよびAMBフォーマットは、係数に適用される追加的な重み（ガーソン（Gerson）、ファース・モーム（FuMa）、MaxN重み）を使う。その際、基準となる規格化は通例SN3Dである。非特許文献１０、１１参照。
【００８６】
理想的な平面波または球面波のための波の方程式の次の二つの具体的な実現は、アンビソニックス係数についてのさらなる詳細を示す。
【００８７】
平面波
平面波Anmについて波の方程式を解くことは、kおよびrsとは独立である。θs、φsは源角度を記述し、「*」は複素共役を表す。
【００８８】
【数２３】
2013545391.tif 000030
ここで、Ps0は時間の関数であることのできる記述座標系の原点において測定された源のスケーリング信号圧を記述するために使われ、正規直交化された球面調和関数についてはA00plane/√(4π)となる。一般に、アンビソニックスは平面波を想定し、アンビソニックス係数
【００８９】
【数２４】
2013545391.tif 000031
が伝送または記憶される。この想定のおかげで、異なる方向性信号の重ね合わせおよび単純なデコーダ設計の可能性が提供される。これはまた、一次のBフォーマット（N＝1）で記録されたサウンドフィールド（Soundfield（商標））マイクロホンの信号についても成り立つ。このことは、等化フィルタの位相進行を比較すれば明らかになる。（理論的な進行については上述の非特許文献６の章2.1を参照。特許で保護されている進行については特許文献１を参照。）式(1)は次のようになる。
【００９０】
【数２５】
2013545391.tif 000032
係数dnmは後処理されたマイクロホン・アレイ信号によって導出されることができ、あるいはモノ信号Ps0(t)を使って合成的に生成されることができ、その場合は方向性の球面調和関数Ynm(θs,φs,t)*は時間依存（移動する源）にもなることができる。式(17)は、各時間的なサンプリング時点vについて有効である。合成的エンコードのプロセスは、選択されたアンビソニックス次数Nについて、ベクトル／行列形式で（すべてのサンプル時点vについて）書き直すことができる。
【００９１】
【数２６】
2013545391.tif 000033
ここで、dはアンビソニックス信号であり、dnm(θs,φs)を保持し、（N＝2についての例：
【００９２】
【数２７】
2013545391.tif 000034
）、dの大きさsize(d)＝(N+1)2x1＝Ox1であり、Ps0は基準となる原点での源信号圧であり、Ψはエンコード・ベクトル（encoding  vector）であり、Ynm(θs,φs)*を保持し、size(Ψ)＝Ox1である。エンコード・ベクトルは特定の源方向Θs,φs（平面波の方向に等しい）についての球面調和関数から導出できる。
【００９３】
球面波
r＜rsについて点源（近距離場の源）によって生成されるはいってくる球面波を記述するアンビソニックス係数は次のようになる。
【００９４】
【数２８】
2013545391.tif 000035
この式は下記の式(31)ないし(36)との関連で導出される。Ps0＝p(0|rs)は原点での音圧を記述し、やはりA00/√(4π)に等しくなる。hn(2)は次数nの第二種の球面ハンケル関数であり、h0(2)は0次の第二種の球面ハンケル関数である。式(19)は非特許文献１２の教示と同様である。ここで、
【００９５】
【数２９】
2013545391.tif 000036
であり、式(11)を念頭に置けば、これは非特許文献１３に見出すことができる。この文献で、ガーソンは度数1（first-degree）信号について近接効果を記述している。
【００９６】
球面アンビソニックス信号の合成的な生成は、より高いアンビソニックス次数Nについてはそれほど一般的ではない。hn(krs)/h0(krs)の周波数応答を低周波数について数値的に扱うのが難しいからである。これらの数値的な問題は、下記に述べるデコード／再生のための球面モデルを考えることによって克服できる。
【００９７】
音場再生
平面波デコード
一般に、アンビソニックスは、円上または球面上に一様に分布したL個のスピーカーによる音場の再生を想定する。スピーカーが聴取者位置から十分遠くに置かれている場合には、中心において平面波デコード・モデルが有効である（rs＞λ）。L個のスピーカーによって生成される音圧は次式によって記述される。
【００９８】
【数３０】
2013545391.tif 000037
ここで、wlはスピーカーlについての信号であり、音圧の単位スケール1Paをもつ。wlはしばしばスピーカーlの駆動関数と呼ばれる。
【００９９】
この式(20)の音圧が式(17)によって記述される圧力と同一であることが望ましい。すると次のようになる。
【０１００】
【数３１】
2013545391.tif 000038
これは「再エンコード公式（re-encoding  formula）」として知られる、行列形式に書き直すことができる（式(18)と比較）。
【０１０１】
【数３２】
2013545391.tif 000039
ここで、dはアンビソニックス信号であり、
【０１０２】
【数３３】
2013545391.tif 000040
を保持し（N＝2についての例：
【０１０３】
【数３４】
2013545391.tif 000041
）、dの大きさsize(d)＝(N+1)2x1＝Ox1であり、Ψは（再エンコード）行列であり、Ynm(θl,φl)*を保持し、size(Ψ)＝OxLであり、yはスピーカー信号wlであり、size(y(n),1)＝Lである。
【０１０４】
すると、yはいくつかの既知の方法、たとえばモード・マッチングあるいは特殊なスピーカー・パニング関数について最適化する諸方法を使って導出できる。
【０１０５】
球面波モデルについてのデコード
より一般的なデコード・モデルはやはり、原点のまわりに距離rlで均等に分布した、点状の球面波を放射するスピーカーを想定する。アンビソニックス係数Anmは式(1)からの一般的な記述によって与えられ、L個のスピーカーによって生成される音圧は式(19)に従って与えられる。
【０１０６】
【数３５】
2013545391.tif 000042
より洗練されたデコーダは、
【０１０７】
【数３６】
2013545391.tif 000043
を取得し、その後、スピーカー重みを導出するために
【０１０８】
【数３７】
2013545391.tif 000044
として式(17)を適用するために、アンビソニックス係数Anmをフィルタ処理することができる。このモデルでは、スピーカー信号wlは原点における圧力によって決定される。上述した非特許文献４で最初に記述された、単純な源アプローチを使う代替的な手法がある。スピーカーは球面上に均等に分布しており、二次的な源特性をもつと想定される。解は非特許文献１４、式(13)において導出され、それはアンビソニックス次数Nにおける打ち切りおよびスピーカー利得glについて、一般化
【０１０９】
【数３８】
2013545391.tif 000045
として書き直せる。
【０１１０】
距離符号化されたアンビソニックス（Distance  Coded  Ambisonics）信号
基準スピーカー距離rl_refを使ったアンビソニックス・エンコーダにおけるCnmの生成は、（式(18)を使って）球面波をモデル化または記録するときのAnmの数値上の問題を解決できる。
【０１１１】
【数３９】
2013545391.tif 000046
伝送ないし記憶されるのはCnm、基準距離rl_refおよび球面距離符号化係数が使われているとのインジケータである。デコーダ側では、真のスピーカー距離が
【０１１２】
【数４０】
2013545391.tif 000047
である限り、式(22)で与えられるような単純なデコード処理が実現可能である。その距離が大きすぎれば、アンビソニックス・デコード前のフィルタ処理による補正
【０１１３】
【数４１】
2013545391.tif 000048
が必要となる。
【０１１４】
式(24)のような他のデコード・モデルは距離符号化されたアンビソニックスについて異なる定式化につながる。
【０１１５】
【数４２】
2013545391.tif 000049
球面調和関数の規格化も距離符号化されたアンビソニックスの定式化に影響をもつことができる。すなわち、距離符号化されたアンビソニックス係数は明確なコンテキストを必要とする。
【０１１６】
上述した2D‐3D変換の詳細は次のとおり。
【０１１７】
乗算により2D円成分を3D球面成分に変換する変換因子α2D/3Dは次のように導出できる。
【０１１８】
【数４３】
2013545391.tif 000050
(2l−1)!!＝Πi=1l(2i−1)を二重階乗とし、一般的な恒等式（非特許文献１５参照）Pl,l(x)＝(2l−1)!!(1−x2)l/2を使うと、P|m|,|m|は
【０１１９】
【数４４】
2013545391.tif 000051
と表現でき、式(29)を式(28)に代入すると式(10)になる。
【０１２０】
2Dから直交3Dへの変換は、関係l!＝(l+1)!/(l+1)を使ってl＝2mを代入すると、
【０１２１】
【数４５】
2013545391.tif 000052
によって導出できる。
【０１２２】
上述した球面波展開の詳細は次のようになる。
【０１２３】
r＜rsについて点源によって生成される、はいってくる波である球面波について式(1)を解くことは、より複雑になる。0になる無限小の大きさをもつ点源は体積流Qsを使って記述する必要があるからである。ここで、源がrsに位置され、rにおけるフィールド点についての放射される圧力は
【０１２４】
【数４６】
2013545391.tif 000053
によって与えられる（上述した非特許文献５参照）。ρ0は比重であり、G(r|rs)はグリーン関数
【０１２５】
【数４７】
2013545391.tif 000054
である。G(r|rs)は、r＜rsについて、球面調和関数において次式によっても表現できる。
【０１２６】
【数４８】
2013545391.tif 000055
ここで、hn(2)は第二種のハンケル関数である。グリーン関数はメートルの逆数の単位のスケールをもつことを注意しておく（kのため1/m）。式(31)、(33)を式(1)と比べると、球面波のアンビソニックス係数を導出できる。
【０１２７】
【数４９】
2013545391.tif 000056
ここで、Qsは単位m3s-1の体積流であり、ρ0はkg・m-3を単位とする密度である。
【０１２８】
アンビソニックス信号を合成的に生成し、上記の平面波の考察に関係付けることができるには、式(34)を座標系の原点で生成される音圧を使って表しておくことが合理的である。
【０１２９】
【数５０】
2013545391.tif 000057
これから
【０１３０】
【数５１】
2013545391.tif 000058
が導かれる。
【０１３１】
交換記憶フォーマット
本発明に基づく記憶フォーマットは、二つ以上のHOA表現および追加的な方向性ストリームを、一つのデータ・コンテナ中に一緒に記憶することを許容する。これは、デコーダが再生を最適化できるようにするHOA記述の種々のフォーマットを可能にするとともに、＞4GBのサイズについて効率的なデータ記憶を提供する。さらなる利点は以下のとおり。
【０１３２】
Ａ）種々のフォーマットを使っていくつかのHOA記述を関係した記憶フォーマット情報とともに記憶することによって、アンビソニックス・デコーダは両方の表現を混合し、デコードすることができる。
【０１３３】
Ｂ）次世代HOAデコーダについて必要とされる情報項目がフォーマット情報として記憶される：
・次元性（dimensionality）、関心領域（聴取領域の外側または内部の源）、球面基底関数の規格化；
・アンビソニックス係数パッキングおよびスケーリング情報；
・アンビソニックス波型（平面、球面）、基準半径（球面波のデコードのため）；
・関係した方向性のモノ信号が記憶されうる。これらの方向性の信号の位置情報は角度と距離の情報またはアンビソニックス係数のエンコード・ベクトルを使って記述できる。
【０１３４】
Ｃ）アンビソニックス・データの記憶フォーマットが、データの柔軟かつ経済的な記憶を許容するために拡張される：
・異なるPCM語サイズ分解能をもつアンビソニックス成分（アンビソニックス・チャネル）に関係したアンビソニックス・データを記憶；
・再サンプリングまたはMDCT処理を使って、低下した帯域幅でアンビソニックス・データを記憶。
【０１３５】
Ｄ）メタデータ・フィールドが、トラックを特別なデコード（前方、周辺）のために関連付けるため、またマイクロホン信号についての録音情報のようなファイルについての付随情報の記憶を許容するために利用可能：
・記録基準座標系、マイクロホン、源および仮想聴取者位置、マイクロホン指向特性、部屋および源情報。
【０１３６】
Ｅ）本フォーマットは、種々のトラックを含む複数のフレームの記憶に好適であり、シーン記述なしにオーディオ・シーン変化を許容する。（コメント：一つのトラックはHOA音場記述または位置情報をもつ単一源を含む。フレームは一つまたは複数の並行トラックの組み合わせである。）トラックはフレームの先頭で始まってもよく、またはフレームの末尾で終わってもよい。よって、タイムコードは必要とされない。
【０１３７】
Ｆ）本フォーマットは、オーディオ・トラック・データへの高速アクセス（手がかり点への早送りまたはジャンプ）およびファイル・データの先頭の時刻に対するタイムコードの決定を容易にする。
【０１３８】
HOAデータ交換のためのHOAパラメータ
表６は、曖昧さのないHOA信号データ交換のために定義されることが必要なパラメータをまとめている。球面調和関数の定義は複素数値および実数値の場合について固定される。式(3)(6)参照。
【０１３９】
【表６】
2013545391.tif 000059
ファイル・フォーマットの詳細
以下では、高次アンビソニックス（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エンコード値を含む。トラック位置ベクトルは、中央の聴取位置に対する角度および距離として源の位置を含む。
【０１５２】
ファイル・ヘッダ
【０１５３】
【表７】
2013545391.tif 000060
FileHeader〔ファイル・ヘッダ〕は、完全なHOAファイルについてのすべての一定の情報を含む。FileIDはHOAファイル・フォーマットを識別するために使われる。サンプル・レートは、たとえサンプル・レートがFrameHeader中で送られる場合でも、すべてのトラックについて一定である。フレームによってサンプル・レートを変えるHOAファイルは無効である。フレーム数は、フレーム構造をデコーダに示すために、FileHeader中で示される。
【０１５４】
メタデータチャンク
【０１５５】
【表８】
2013545391.tif 000061
フレーム・ヘッダ
【０１５６】
【表９】
2013545391.tif 000062
FrameHeader〔フレーム・ヘッダ〕は、フレームのすべてのトラックの一定の情報を保持し、HOAファイル内の変化を示す。FrameIDおよびFrameSizeはフレームの先頭およびフレームの長さを示す。これら二つのフィールドは、各フレームへの簡単なアクセスおよびフレーム構造のクロスチェックを許容する。フレーム長が32ビットより多くを必要とする場合には、一つのフレームがいくつかのフレームに分離されることができる。各フレームは一意的なFrameNumberを有する。FrameNumberは0で始まり、新たなフレーム毎に1だけインクリメントされるべきである。フレームのサンプル数はフレームのすべてのトラックについて一定である。フレーム内のトラック数は当該フレームについては一定である。所望されるサンプル位置でトラックを終了または開始するためには新たなフレーム・ヘッダが送られる。各トラックのサンプルはパケットに格納される。これらのTrackPacketのサイズはサンプル単位で示され、すべてのトラックについて一定である。パケットの数は、フレームのサンプル数を記憶するために必要とされる整数に等しい。したがって、トラックの最後のパケットは、示されるパケット・サイズより少数のサンプルを含むことができる。フレームのサンプル・レートはFileSampleRateに等しく、FileHeaderを知ることなくフレームのデコードを許容するために、FrameHeaderにおいて示される。これは、たとえばストリーミング・アプリケーションのために、FileHeaderを知ることなく、マルチフレーム・ファイルの途中からデコードするときに使われることができる。
【０１５７】
トラック・ヘッダ
【０１５８】
【表１０】
2013545391.tif 000063
項「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トラック・ヘッダ
【０１６１】
【表１１】
2013545391.tif 000064
【０１６２】
【表１２】
2013545391.tif 000065
【０１６３】
【表１３】
2013545391.tif 000066
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モノ・トラックである。
【０１６８】
単独源固定位置トラック・ヘッダ
【０１６９】
【表１４】
2013545391.tif 000067
【０１７０】
【表１５】
2013545391.tif 000068
固定位置源型は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個の値からなる。
【０１７２】
単独源移動位置トラック・ヘッダ
【０１７３】
【表１６】
2013545391.tif 000069
移動位置源型は、'1'であるTrackMovingSourceFlagによって定義される。ヘッダは、源位置データ・フィールドTrackPositionTheta、TrackPositionPhi、TrackPositionRadiusおよびTrackHOAEncodingVectorの源位置データ・フィールドがないほかは、固定源ヘッダと同一である。移動源については、これらは各パケットにおいて新しい（動いている）源位置を示すために、TrackPackets内に位置される。
【０１７４】
特殊トラック表
トラックHOAパラメータ（TrackHOAParams）
【０１７５】
【表１７】
2013545391.tif 000070
【０１７６】
【表１８】
2013545391.tif 000071
【０１７７】
【表１９】
2013545391.tif 000072
HOAエンコードおよびデコードのためのいくつかのアプローチが過去に議論されているが、HOA係数を符号化するための結論や合意には至っていない。有利なことに、本発明に基づくフォーマットは、大半の既知のHOA表現の記憶を許容する。TrackHOAParamsは、どの種類の規格化および係数の順序シーケンスがエンコーダ側で使われたかを明確にするために定義される。これらの定義は、HOAトラックの混合およびデコーダ・マトリクスの適用のためにデコーダ側において考慮に入れる必要がある。
【０１７８】
HOA係数は完全な三次元音場について、または二次元のxy平面についてのみ、適用できる。HOAトラックの次元は、TrackHOAParamDimensionフィールドにおいて定義される。
【０１７９】
TrackHOAParamRegionOfInterestは、源が関心領域の内側または外側にあり、関心領域は全く源を含まない、二つの音圧級数展開を反映する。内部ケースおよび外部ケースについての音圧の計算はそれぞれ上記の式(1)および(2)において定義されている。ここで、HOA信号Anm(k)の方向性情報は球面調和関数の複素共役Ynm(θ,φ)*によって決定される。この関数は複素および実数版で定義される。エンコーダおよびデコーダは等価な数値型の球面調和関数を適用する必要がある。よって、TrackHOAParamSphericalHarmonicTypeが、どんな種類の球面調和関数がエンコーダ側で適用されたかを示す。
【０１８０】
上述したように、基本的に球面調和関数はルジャンドル陪関数および複素または実の三角関数によって定義される。ルジャンドル陪関数は式(5)によって定義される。複素数値の球面調和関数の表現は
【０１８１】
【数５２】
2013545391.tif 000073
となる。ここで、Nn,mはスケーリング因子（式(3)参照）である。この複素数値の表現は、次式を使って実数値の表現に変換できる。
【０１８２】
【数５３】
2013545391.tif 000074
ここで、実数値の球面調和関数のための修正されたスケーリング因子は次のようになる。
【０１８３】
【数５４】
2013545391.tif 000075
2D表現については、HOA係数のエンコードおよびデコードのために円調和関数を使う必要がある。円調和関数の複素数値の表現は次式で定義される。
【０１８４】
【数５５】
2013545391.tif 000076
円調和関数の実数値の表現は次式で定義される。
【０１８５】
【数５６】
2013545391.tif 000077
球面調和関数または円調和関数を特定の用途または要求に適応させるために、次のようないくつかの規格化因子が使用される。
【０１８６】
【数５７】
2013545391.tif 000078
HOA係数の正しいデコードを保証するために、エンコーダ側で使われた球面調和関数の規格化がデコーダ側で知られている必要がある。次の表７は、TrackHOAParamSphericalHarmonicNormフィールドを用いて選択できる規格化を定義している。
【０１８７】
【表２０】
2013545391.tif 000079
将来の規格化のために、TrackHOAParamSphericalHarmonicNormフィールドの専用の値が利用可能になっている。専用の規格化については、各HOA係数についてのスケーリング因子がTrackHOAParamsの末尾で定義される。専用のスケーリング因子TrackScalingFactorsは実または複素の「float32」または「float64」値として送信できる。スケーリング因子フォーマットは、専用スケーリングの場合、TrackComplexValueScalingFlagおよびTrackScalingFormatフィールドにおいて定義される。
【０１８８】
異なるHOA次数の係数の振幅を整数フォーマット型での送信のために「1」より小さい絶対値に等化するため、符号化されたHOA係数にファース・モーム規格化がさらに適用されることができる。ファース・モーム規格化は、三次までの係数のSN3D実数値球面調和関数のために設計された。よって、ファース・モーム規格化は、SN3D実数値球面調和関数との組み合わせでのみ使うことが推奨される。さらに、TrackHOAParamFurseMalhamFlagは3より大きなHOA次数をもつトラックについては無視される。HOA係数をデコードするためには、ファース・モーム規格化の逆をデコーダ側で行う必要がある。表８はファース・モーム係数を定義している。
【０１８９】
【表２１】
2013545391.tif 000080
TrackHOAParamDecoderTypeは、どの種類のデコーダがデコーダ側に存在するとエンコーダ側で想定されているかを定義する。デコーダ型は、音場をレンダリングするためにデコーダ側で使用されることになるスピーカー・モデル（球面波または平面波）を決定する。それにより、デコーダの式の一部をエンコーダの式に移すことによってデコーダの計算量を軽減できる。さらに、エンコーダ側での数値上の問題も軽減できる。さらに、デコーダ側でのすべての非一貫性はエンコーダに移すことができるので、デコーダは、すべてのHOA係数についての同一の処理に帰着できる。しかしながら、球面波については、聴取位置からのスピーカーの一定の距離を想定する必要がある。したがって、想定されるデコーダ型はトラック・ヘッダにおいて示され、球面波デコーダ型についてのスピーカー半径rlsは任意的なフィールドTrackHOAParamReferenceRadiusにおいてミリメートル単位で伝送される。デコーダ側での追加的なフィルタが、想定されたスピーカー半径と真のスピーカー半径との間の差を等化することができる。
【０１９０】
HOA係数CnmのTrackHOAParamDecoderType規格化は、TrackHOAParamRegionOfInterestで選択された内部または外部音場展開の使用に依存する。コメント：式(18)および後続の式におけるdnmは下記における係数Cnmに対応する。エンコーダ側では、係数Cnmは表９において定義される係数AnmまたはBnmから決定され、記憶される。使用される規格化はTrackHOAParamヘッダのTrackHOAParamDecoderTypeフィールドにおいて示される。
【０１９１】
【表２２】
2013545391.tif 000081
一つの時間サンプルについてのHOA係数はTrackHOAParamNumberOfCoeffs(O)個の係数Cnmを含む。NはHOA係数の次元に依存する。2D音場については、「O」は2N＋1に等しい。ここで、NはTrackHOAParamヘッダからのTrackHOAParamHorizontalOrderフィールドに等しい。2D  HOA係数は、−N≦m≦NとしてC|m|m＝Cmとして定義され、表１０に示されるような3D係数の部分集合として表現できる。
【０１９２】
3D音場については、Oは(N＋1)2に等しい。ここで、NはTrackHOAParamヘッダからのTrackHOAParamVerticalOrderフィールドに等しい。3D  HOA係数Cnmは、0≦n≦Nおよび−n≦m≦nについて定義される。HOA係数の一般的な表現は表１０に与えられる。
【０１９３】
【表２３】
2013545391.tif 000082
3D音場かつTrackHOAParamVerticalOrderより大きなTrackHOAParamHorizontalOrderの場合、混合次数のデコードが実行される。混合次数信号では、いくつかの高次係数は2Dでのみ伝送される。TrackHOAParamVerticalOrderフィールドはすべての係数が伝送される垂直方向次数を決定する。垂直方向次数からTrackHOAParamHorizontalOrderまでは、2D係数のみが使用される。このように、TrackHOAParamHorizontalOrderはTrackHOAParamVerticalOrder以上である。水平方向次数4および垂直方向次数2の混合次数表現の例が表１１に描かれている。
【０１９４】
【表２４】
2013545391.tif 000083
HOA係数Cnmはトラックのパケット中に記憶される。係数のシーケンス、たとえばどの係数が最初にきてどれがそれに続くか、は、過去に種々の仕方で定義されてきた。よって、TrackHOAParamCoeffSequence〔トラックHOAパラメータ係数シーケンス〕は三つの型の係数シーケンスを示す。三つのシーケンスは、表１０のHOA係数配置から導出される。
【０１９５】
Bフォーマット・シーケンスは、表１２に示されるように、三次までのHOA係数について特別な用語を使う。
【０１９６】
【表２５】
2013545391.tif 000084
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についての係数Cnmは最低から最高のHOA次数（n＝0…N）に数値的に昇順または降順にTrackHOAParamCoeffSequenceにおいて伝送される。数値的な昇順シーケンスはm＝−nで始まり、m＝nまで増大する（C00、C1-1、C10、C11、C2-2、C2-1、C20、C21、C22、…）。これは非特許文献１７で定義される「CG」シーケンスである。数値的に降順のシーケンスmは逆にm＝nからm＝−nに進み（C00、C11、C10、C1-1、C22、C21、C20、C2-1、C2-2、…）、これは非特許文献１７で定義される「QM」シーケンスである。
【０１９８】
2D  HOA係数については、TrackHOAParamCoeffSequenceの数値的に昇順および降順のシーケンスは3Dの場合と同様であるが、|m|≠nで不使用の係数（すなわち、表１０の扇形の（sectoral）HOA係数C|m|m＝Cmのみ）は省略される。よって、数値的に昇順のシーケンスは（C00、C1-1、C11、C2-2、C22、…）につながり、数値的に降順のシーケンスは（C00、C11、C1-1、C22、C2-2、…）につながる。
【０１９９】
トラック・パケット
HOAトラック・パケット
PCM符号化型パケット
【０２００】
【表２６】
2013545391.tif 000085
このパケットはHOA係数CnmをTrackHOAParamCoeffSequenceにおいて定義される順序で含んでいる。ここで、一つの時間サンプルのすべての係数が相続いて伝送される。このパケットは、0であるTrackSourceTypeおよび0であるTrackCodingTypeをもつ標準的なHOAトラックについて使われる。
【０２０１】
動的分解能符号化型パケット
【０２０２】
【表２７】
2013545391.tif 000086
動的分解能パッケージは「0」であるTrackSourceTypeおよび「1」であるTrackCodingTypeについて使用される。TrackOrderRegions〔トラック次数領域〕の異なる分解能は各TrackOrderRegionについての異なる記憶サイズにつながる。したがって、HOA係数はインターリーブ解除された仕方で記憶される。たとえば、あるHOA次数のすべての係数が相続いて記憶される。
【０２０３】
単独源トラック・パケット
単独源固定位置パケット
【０２０４】
【表２８】
2013545391.tif 000087
単独源固定位置パケットは「1」であるTrackSourceTypeおよび「0」であるTrackMovingSourceFlagについて使用される。パケットはモノ源のPCMサンプルを保持する。
【０２０５】
【表２９】
2013545391.tif 000088
単独源移動位置パケットは「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の一つの組み合わせについての諸係数Cnmが一つのバッファにグループ化されることを意味する。インターリーブ解除ステップまたは段１２１１から、インターリーブ解除されたHOA係数はトラック領域エンコード部に渡される。残りのインターリーブされたHOA係数は後続のトラック領域インターリーブ解除ステップまたは段に渡される、などとなり、インターリーブ解除ステップまたは段１２１Ｎまで続く。インターリーブ解除ステップまたは段の数NはTrackNumberOfOrderRegionsに「1」を加えたものに等しい。追加的なインターリーブ解除ステップまたは段１２５は、トラック領域の一部でない残りの係数をインターリーブ解除して、フォーマット変換ステップまたは段１２６を含む標準的な処理経路に入れる。
【０２１１】
トラック領域エンコード経路は、任意的な帯域幅削減ステップまたは段１２２１およびフォーマット変換ステップまたは段１２３１を含み、各HOA係数バッファについて並列処理を実行する。帯域幅削減は、TrackRegionUseBandwidthReduction〔トラック領域帯域幅削減使用〕フィールドが「1」に設定されていたら実行される。選択されたTrackBandwidthReductionType〔トラック帯域幅削減型〕に依存して、HOA係数の周波数範囲を制限するため、およびそれらの係数を臨界的にダウンサンプリングするための処理が選択される。これは、HOA係数の数を、最低限必要とされるサンプル数まで削減するために実行される。フォーマット変換は、現在のHOA係数フォーマットをHOAトラック・ヘッダにおいて定義されているTrackRegionSampleFormat〔トラック領域サンプル・フォーマット〕に変換する。これは、HOA係数をHOAトラック・ヘッダの指示されるTrackSampleFormat〔トラック・サンプル・フォーマット〕に変換する標準的な処理経路にある唯一のステップ／段である。
【０２１２】
マルチプレクサ・トラック・パケット・ステップまたは段１２４はHOA係数バッファを多重化して、選択されたTrackHOAParamCoeffSequenceフィールドにおいて定義されているトラック・パケット・データ・ファイル・ストリームにする。ここで、nとmのインデックスの一つの組み合わせについての諸係数Cnmは（一つのバッファ内で）インターリーブ解除されたままである。
【０２１３】
トラック領域デコード処理
図１３に示されるように、デコード処理はエンコード処理の逆である。デマルチプレクサ・ステップまたは段１３４はトラック・パケット・データ・ファイルまたはストリームを指示されるTrackHOAParamCoeffSequenceからインターリーブ解除されたHOA係数バッファ（図示せず）に多重分離する。各バッファはnとmの一つの組み合わせについてFramePacketLength個の係数Cnmを含む。
【０２１４】
ステップ／段１３４は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係数Cnmを含む。すなわち、一つのバッファは、
【０２１７】
【数５８】
2013545391.tif 000089
として定義される。バッファの数Mは、アンビソニックス成分の数（次数Nのフル3D音場については(N＋1)2）と同じである。バッファ処理は、前のバッファ内容を現在のバッファ内容と組み合わせて対応するステップまたは段１４３１におけるMDCT処理のための新しい内容にすることによって後続のMDCT処理について50%の重なりを実行し、後続のバッファ内容の処理のために現在のバッファ内容を保存しておく。MDCT処理は各フレームの先頭から改めて開始される。これはつまり、現在フレームのあるトラックのすべての係数が、前のフレームの知識なしにデコードでき、現在フレームの最後のバッファ内容に続いては、0からなる追加的なバッファ内容が処理されるということを意味する。したがって、MDCT処理されたトラック領域は一つの余計なトラック・パケットを生成する。
【０２１８】
窓掛けステップ／段では、対応するバッファ内容が選択された窓関数w(t)を乗算される。選択された窓関数は各トラック領域についてHOAトラック・ヘッダのフィールドTrackRegionWindowTypeにおいて定義されている。
【０２１９】
修正離散コサイン変換は非特許文献１８において最初に言及されたものである。MDCTは、FramePacketSize個のサブバンドの臨界的にサンプリングされたフィルタバンクを表すと考えることができ、50%の入力バッファの重なりを要求する。入力バッファはサブバンド・サイズの二倍の長さをもつ。MDCTは、TがFramePacketSizeに等しいとして、次の式によって定義される。
【０２２０】
【数５９】
2013545391.tif 000090
係数C'nm(k)はMDCTビンと呼ばれる。MDCT計算は高速フーリエ変換を使って実装できる。後続の周波数領域カットアウト・ステップまたは段１４４１ないし１４４Ｍでは、k＜TrackRegionFirstBinおよびk＞TrackRegionLastBinのすべてのMDCTビンC'nm(k)を除去することによって、帯域幅削減が実行される。バッファ長さのTrackRegionLastBin−TrackRegionFirstBin＋1への削減である。ここで、TrackRegionFirstBinは当該トラック領域についての下カットオフ周波数であり、TrackRegionLastBinは上カットオフ周波数である。MDCTビンを無視することは、TrackRegionLastBinおよびTrackRegionFirstBin周波数に対応するカットオフ周波数をもつ帯域通過フィルタを表していると見なすことができる。したがって、必要とされるMDCTビンのみが伝送される。
【０２２１】
デコード
図１５は、MDCT処理を使った帯域幅デコードまたは再構成を示している。ここでは、帯域幅制限されたトラック領域のHOA係数が当該トラックのフル帯域幅に再構成される。この帯域幅再構成は、時間的にインターリーブ解除されたHOA係数のバッファ内容を並列に処理する。ここで、各バッファは係数C'nm(k)のTrackRegionLastBin−TrackRegionFirstBin＋1個のMDCTビンを含む。欠けている周波数領域の追加ステップまたは段１５４１ないし１５４Ｍは、k＜TrackRegionFirstBinおよびk＞TrackRegionLastBinの欠けているMDCTビンを0を使って受領されたMDCTビンを補完することによって、サイズFramePacketLengthの完全なMDCTバッファ内容を再構成する。その後、時間領域のHOA係数Cnm(t)を再構成するために、対応する逆MDCTステップまたは段１５３１ないし１５３Ｍにおいて逆MDCTが実行される。逆MDCTは、FramePacketLength個のMDCTビンがFramePacketLengthの２倍の数の時間領域係数に変換される合成フィルタバンクと解釈されることができる。しかしながら、時間領域サンプルの完全な再構成は、エンコーダにおいて使用された窓関数w(t)の乗算と、現在のバッファ内容の前半と前のバッファ内容の後半の重複加算（overlap-add）とを必要とする。逆MDCTは次式によって定義される。
【０２２２】
【数６０】
2013545391.tif 000091
MDCTと同様に、逆MDCTは逆高速フーリエ変換を使って実装できる。
【０２２３】
MDCT窓掛けステップまたは段１５２１ないし１５２Ｍは、TrackRegionWindowTypeによって定義される窓関数を、再構成された時間領域係数に乗算する。後続のバッファ１５１１ないし１５１Ｍは、FramePacketSize個の時間領域係数を再構成するために、現在のトラック・パケット・バッファ内容の前半を直前のトラック・パケット・バッファ内容の後半に加える。現在のトラック・パケット・バッファ内容の後半は、次のトラック・パケットの処理のために保存される。この重複加算処理は、両バッファ内容の逆のエイリアシング成分を除去する。
【０２２４】
複数フレームHOAファイルについては、エンコーダは、新しいフレームの先頭における重複加算手順のために前のフレームの最後のバッファ内容を使うことを禁止される。したがって、フレーム境界においてまたは新しいフレームの先頭においては、重複加算バッファ内容が欠けていることになり、フレームの最初のトラック・パケットの再構成が、第二のトラック・パケットにおいて実行されることができる。それにより、帯域幅削減のない処理経路に比べ、一フレーム・パケットおよび一つの余計なトラック・パケットのデコードの遅延が導入される。この遅延は、図１３との関連で述べたインターリーブ・ステップ／段によって対処される。
【図１】
2013545391.tif 000092
【図２】
2013545391.tif 000093
【図３】
2013545391.tif 000094
【図４】
2013545391.tif 000095
【図５】
2013545391.tif 000096
【図６】
2013545391.tif 000097
【図７】
2013545391.tif 000098
【図８】
2013545391.tif 000099
【図９】
2013545391.tif 000100
【図１０】
2013545391.tif 000101
【図１１】
2013545391.tif 000102
【図１２】
2013545391.tif 000103
【図１３】
2013545391.tif 000104
【図１４】
2013545391.tif 000105
【図１５】
2013545391.tif 000106
【国際調査報告】
2013545391.tif 000107
2013545391.tif 000108
2013545391.tif 000109