アンビソニックス係数を含む高次アンビソニックスHOAオーディオデータのためのデータ構造であって、当該データ構造は一つまたは複数の異なるHOAオーディオデータストリーム記述についての2Dおよび/または3D空間的オーディオコンテンツデータを含み、当該データ構造は3より大きな次数をもつHOAオーディオデータについても好適であり、当該データ構造はさらに、固定したまたは時間変化する空間位置からの単独オーディオ信号源データおよび/またはマイクロホンアレイオーディオデータを含むことができ、前記異なるHOAオーディオデータストリーム記述は、異なるスピーカー位置密度、符号化されたHOA波型、HOA次数およびHOA次元性のうち少なくとも二つに関係しており、あるHOAオーディオデータストリーム記述は呈示サイトの明確に区別される領域に位置される密なスピーカー配置での呈示のためのオーディオデータを含み、別のHOAオーディオデータストリーム記述は前記呈示サイトを囲むそれほど密でないスピーカー配置での呈示のためのオーディオデータを含む、データ構造。前記密なスピーカー配置のための前記オーディオデータは球面波および第一のアンビソニックス次数を表し、前記それほど密でないスピーカー配置のための前記オーディオデータは平面波および/または前記第一のアンビソニックス次数より小さな第二のアンビソニックス次数を表す、請求項2記載のデータ構造。前記データ構造は、オーディオシーンのトラックが任意の時点に開始および終了できるシーン記述のはたらきをする、請求項1または2記載のデータ構造。当該データ構造が:聴取領域の外側または内側のオーディオ源に関係する関心領域;球面基底関数の規格化;伝搬の方向性;アンビソニックス係数スケーリング情報;アンビソニックス波型、たとえば平面か球面か;球面波の場合、デコードのための基準半径に関するデータ項目を含む、請求項1ないし3のうちいずれか一項記載のデータ構造。前記アンビソニックス係数が複素係数である、請求項1ないし4のうちいずれか一項記載のデータ構造。当該データ構造が、一つまたは複数のマイクロホンについての方向および特性に関するメタデータを含むおよび/または単独源入力信号についての少なくとも一つのエンコードベクトルを含む、請求項1ないし5のいずれか一項記載のデータ構造。前記アンビソニックス係数の少なくとも一部が帯域幅削減され、それにより異なるHOA次数について関係するアンビソニックス係数の帯域幅が異なる1221-122N、請求項1ないし6のうちいずれか一項記載のデータ構造。前記帯域幅削減がMDCT処理1431-143Mに基づく、請求項7記載のデータ構造。請求項1ないし8のうちいずれか一項記載のデータ構造のためにデータをエンコードし、配置する方法。オーディオ呈示の方法であって、少なくとも二つの異なるHOAオーディオデータ信号を含むHOAオーディオデータストリームが受領され、前記信号のうち少なくとも第一のものが呈示サイトの明確に区別される領域に位置される密なスピーカー配置での呈示のために使われ231、232、前記信号のうち少なくとも第二の、異なるものが前記呈示サイトを囲むそれほど密でないスピーカー配置での呈示のために使われる241、242、243、方法。前記密なスピーカー配置のための前記オーディオデータは球面波および第一のアンビソニックス次数を表し、前記それほど密でないスピーカー配置のための前記オーディオデータは平面波および/または前記第一のアンビソニックス次数より小さな第二のアンビソニックス次数を表す、請求項10記載の方法。前記呈示サイトが映画館における聴取領域または着席領域である、請求項1もしくは2記載のデータ構造または請求項10または11記載の方法。請求項10または11記載の方法を実行するよう適応された装置。HOA信号に関し、3Dについては、種々の音源からのみな同じ周波数のM=2個2Dについては個の異なるオーディオオブジェクトの集合が、それらが空間的に均等に分布している限り、異なる音オブジェクトとして記録エンコードされ、再生されることができる。これは、一次アンビソニックス信号は四つの3Dまたは三つの2Dオーディオオブジェクトを担持でき、これらのオブジェクトは3Dについては球のまわりに、2Dについては円のまわりに一様に離間している必要があることを意味する。空間的な重なりおよび記録におけるM個より多い信号は、ぼけを生じる――最も大きな信号だけがコヒーレントなオブジェクトとして再生されることができ、他の散漫な信号は、空間、周波数およびラウドネス類似性における重なりに依存して何らかの仕方でコヒーレントな信号を劣化させる。映画館における音響状況に関しては、前方スクリーン領域については、視覚的なシーンに合うよう、高い空間的な音の定位精度が要求される。サラウンドサウンドオブジェクトの知覚はそれほど決定的ではない残響、視覚的なシーンと関連のない音オブジェクト。ここで、スピーカーの密度は、前方領域に比べて小さくてもよい。前方領域について重要なHOAデータのHOA次数は、随意にホロフォニックな再生を可能にするよう、大きくなければならない。典型的な次数はN=10である。これは、2=121個のHOA係数を必要とする。理論上は、オーディオオブジェクトが空間的に均等に分布されるのであれば、M=121個のオーディオオブジェクトをエンコードすることもできる。しかしながら、我々のシナリオでは、それらのオブジェクトは前方領域に制約されるそのような高い次数が必要なのは前方だけなので。実際には、我々は、約M=60個のオーディオオブジェクトだけをぼけなしに符号化できる前方領域は高々方向球の半分であり、よってM2。上述したBフォーマットは三次までのアンビソニックスしか記述できず、ファイルサイズは4GBに制約される。波の型または参照デコード体積のような、現代のデコーダにとって重要な他の特別な情報項目が欠けている。異なるアンビソニックス成分チャネルについて異なるサンプルフォーマット語幅および帯域幅を使うことはできない。また、アンビソニックスのための副情報およびメタデータを記憶する規格もない。既知の技術では、マイクロホンアレイを使ったアンビソニックス信号の記録は1のオーダーに制約される。これは、HOAマイクロホンの実験的なプロトタイプが開発されれば、将来変わるかもしれない。3Dコンテンツの生成のためには、周辺音場の記述が、マイクロホンアレイを使って一次アンビソニックスにおいて記録されることができ、それにより指向性の源が、クローズアップモノマイクロホンまたは高度に指向性のマイクロホンを方向情報すなわち源の位置と一緒に使って、捕捉される。次いで指向性信号はHOA記述にエンコードされることができ、あるいはこれは洗練されたデコーダによって実行されてもよい。いずれにせよ、新しいアンビソニックスファイルフォーマットは、二つ以上の音場記述を同時に記憶できることが必要であるが、既存のフォーマットには、二つ以上のアンビソニックス記述をカプセル化できるものはないと思われる。本発明によって解決されるべき課題は、二つ以上の音場記述を同時に記憶することができ、アンビソニックス次数が3より大きいことができるアンビソニックスファイルフォーマットを提供することである。この課題は、請求項1に開示されるデータ構造および請求項12に開示される方法によって解決される。現実的な3Dオーディオを再現するために、次世代アンビソニックスデコーダは、処理されるべき記憶されたデータとともに、多くの規約および規定を必要とするか、あるいはすべての関係したパラメータおよびデータ要素がコヒーレントに記憶できる単一のファイルフォーマットを必要とするであろう。空間的な音コンテンツのための本発明のファイルフォーマットは、一つまたは複数のHOA信号および/または指向性モノ信号を方向情報と一緒に記憶することができ、3より大きいアンビソニックス次数および4GBより大きいファイルが実現可能である。さらに、本発明のファイルフォーマットは、既存のフォーマットが提供しない追加的な要素を提供する。1次世代HOAデコーダのために必要とされる重要な情報がファイルフォーマット内に記憶される:アンビソニックス波の情報平面、球面、混合型、関心領域聴取領域外または内の源および参照半径球面波のデコードのため関係した指向性モノ信号が記憶されることができる。これらの指向性信号の位置情報は、角度および距離情報を使って、あるいはアンビソニックス係数のエンコードベクトルを使って記述できる。2アンビソニックスデータを定義するすべてのパラメータが副情報内に含まれ、記録についての明瞭性が保証される:アンビソニックススケーリングおよび規格化SN3D、N3D、ファースモームFurseMalham、Bフォーマット、......、ユーザー定義、混合次数情報。3アンビソニックスデータのための記憶フォーマットが、柔軟かつ経済的なデータ記憶を許容するよう拡張される:本発明のフォーマットは、アンビソニックス次数アンビソニックスチャネルに関係したデータを、異なるPCM語サイズ分解能で、また制約された帯域幅を使って記憶することを許容する。4メタフィールドが、マイクロホン信号のための記録情報のような、ファイルについての付随情報を記憶することを許容する:記録基準座標系、マイクロホン、源および仮想聴取者位置、マイクロホン方向特性、部屋および源の情報。2Dおよび3Dオーディオコンテンツのためのファイルフォーマットは、高次アンビソニックス記述HOAおよび固定したもしくは時間変動する位置をもつ単一の源の両方の記憶をカバーし、次世代オーディオデコーダが現実的な3Dオーディオを提供できるようにするすべての情報を含む。適切な設定を使えば、本発明のファイルフォーマットは、オーディオコンテンツのストリーミングにも好適である。こうして、コンテンツ依存の副情報ヘッダデータが、ファイルの作成者によって選択された時点において、送られることができる。本発明のファイルフォーマットは、オーディオシーンのトラックが任意の時点で開始および終了できるシーン記述のはたらきもする。原理的には、本発明のデータ構造は高次アンビソニックスHOAオーディオデータに好適である。このデータ構造は、一つまたは複数の異なるHOAオーディオデータストリーム記述のための2Dおよび/または3D空間的オーディオコンテンツデータを含み、このデータ構造はまた、3より大きな次数をもつHOAオーディオデータにも好適であり、このデータ構造はさらに、固定したまたは時間変動する空間位置からの単一オーディオ信号源データおよび/またはマイクロホンアレイオーディオデータを含むことができる。原理的には、本発明の方法は、少なくとも二つの異なるHOAオーディオデータ信号を含むHOAオーディオデータストリームが受領され、それらの信号のうち少なくとも第一のものが、呈示サイトの明確に区別される領域に位置される密なスピーカー配置での呈示のために使われ、それらの信号のうち少なくとも第二の異なるものが前記呈示サイトを取り囲むそれほど密でないスピーカー配置での呈示のために使われる。本発明のさらなる有利な実施形態は、それぞれの従属請求項において開示される。3Dビデオのますますの普及とともに、没入型オーディオ技術が差別化のための興味深い機能となりつつある。高次アンビソニックスHOAは、段階的な仕方で映画館に3Dオーディオを導入する方法を提供できる、そうした技術の一つである。HOAサウンドトラックおよびHOAデコーダを使えば、映画館は、既存のオーディオサラウンドスピーカーセットアップから出発して、徐々により多くのスピーカーに投資して段階ごとに没入型の経験を改善することができる。図1のaは、前方領域における密なスピーカー配置11および聴取もしくは着席領域10を取り囲むより疎なスピーカー密度12をもつ、映画館におけるホロフォニック再生を示している。これは、視覚的アクションに関係した正確な音再生および再生される周辺音の充分な精度の方法を提供する。図1のbは、再生される前方音波の到着の知覚される方向を示している。平面波の到着方向は種々のスクリーン位置にマッチする。すなわち、平面波は奥行きを再現するのに好適である。図1のcは、再生される球面波の到着の知覚される方向を示している。これは、知覚される音方向とスクリーンのまわりの3D視覚的アクションとのよりよい一貫性につながる。二つの異なるHOAストリームの必要性は、映画館における主たる視覚的なアクションは聴取者の前方領域で起こるという事実に由来する。また、音の方向検出の知覚上の精度は、サラウンド源よりも前方音源について高い。よって、前方の空間的な音再生の精度は、再生される周辺音についての空間的精度よりも高い必要がある。ホロフォニックholophonicは、音再生について、より多数のスピーカー、専用のデコーダおよび関係したスピーカードライバが前方スクリーン領域のために必要とされ、一方、周辺音再生についてはより安価な技術聴取領域を囲むスピーカーのより低い密度およびより完全度が低いデコード技術が必要とされることを意味する。コンテンツ作成および音再生技術のため、周辺音について一つのHOA表現、前景アクション音について一つのHOA表現を与えることが有利である。図4参照。単純な粗い再生音設備をもつ単純なセットアップを使う映画館は、デコード前に両方のストリームを混合することができる図5の上部参照。完全な没入型再生手段を備えるより洗練された映画館は、二つのデコーダ――周辺音をデコードするために一つ、前景の主たるアクションのための仮想音源の高精度の位置決めのために一つの特化したデコーダ――を使うことができる。これは、図2の洗練されたデコードシステムおよび図5の下部に示されている。特殊なHOAファイルは、周辺音Anmについておよび視覚的な主たるアクションに関係した前方音CnmについてのHOA音場を表す少なくとも二つのトラックを含む。方向効果のための任意的なストリームが提供されてもよい。二つの対応するデコーダシステムがパニング器pannerと一緒になって、密な前方3Dホロフォニックスピーカーシステム21およびそれほど密でないすなわち疎な3Dサラウンドシステム22のための信号を提供する。トラック1ストリームのHOAデータ信号は周辺音を表し、HOA変換器231において、周辺音再生のために特化されたデコーダ1232への入力のために変換される。トラック2データストリームについては、HOA信号データ視覚的なシーンに関係した前方音は、HOA変換器241において、専用のデコーダ2243でのスクリーン領域のまわりの球状音源の最善の配置のため、距離補正された式フィルタ242への入力のために、変換される。方向性のデータストリームはL個のスピーカーに直接パンされる。三つのスピーカー信号は3Dスピーカーシステムでの統合再生のためにPCM混合される。そのようなシナリオ専用の既知のファイルフォーマットはないと思われる。既知の3D音場記録は、のちの再生のために記録する際、関係したサウンドトラックをもつ完全なシーン記述または単一の音場記述のいずれかを使う。第一の種類の例はWFSWaveFieldSynthesis[波面合成]フォーマットおよび数多くのコンテナフォーマットである。第二の種類の例は、BまたはAMBフォーマットのようなアンビソニックスフォーマットである。前述した非特許文献1参照。これはアンビソニックス次数3、固定した伝送フォーマット、固定したデコーダモデルおよび単一の音場に制約している。HOAコンテンツ生成および再生HOA音場記述を生成するための処理が図3に描かれている。図3のaでは、音場の自然な記録が、マイクロホンアレイを使って生成される。カプセル信号は、HOA信号を形成するためにマトリクス化され等化される。高次の信号アンビソニックス次数>1は通例、カプセル距離効果に起因するアーチファクトを削減するために帯域通過フィルタ処理される:高周波数で空間的エイリアスを削減するために低域通過フィルタ処理され、増大するアンビソニックス次数nhnでの過剰な低周波数レベルを削減するために高域通過フィルタ処理される。式参照。任意的に、距離符号化フィルタ処理が適用されてもよい。式および参照。記憶の前に、HOAフォーマット情報がトラックヘッダに追加される。人工的な音場表現は通例、複数の方向性の単独源ストリームを使って生成される。図3のbに示されるように、単独源信号はPCM記録として捕捉されることができる。これは、クローズアップマイクロホンによってまたは高い指向性をもつマイクロホンを使うことによってできる。さらに、仮想的な最良の聴取位置に対する音源の方向パラメータrsΘsφsが記録されるHOA座標系またはのちのマッピングのための任意の基準点。映画のためのシーンをレンダリングするときに、音を人工的に定位するために、距離情報も生成されてもよい。図3のcに示されるように、その場合、方向情報ΘsφsはエンコードベクトルΨを生成するために使われ、方向性の音信号はアンビソニックス信号にエンコードされる。式参照。これは、平面波表現と等価である。後続するフィルタ処理プロセスは、距離情報rsを使って、球面状の音特性をアンビソニックス信号にインプリントし式、あるいは距離符号化フィルタ処理を適用、式、してもよい。記憶の前に、HOAフォーマット情報がトラックヘッダに追加される。より複雑な音場記述が、図3のdに描かれるようなアンビソニックス信号のHOA混合によって生成される。記憶の前に、HOAフォーマット情報がトラックヘッダに追加される。3D映画館用のコンテンツ生成のプロセスが図4に描かれている。視覚的なアクションに関係する前方音は高い空間的精度でエンコードされ、HOA信号音場Cnmに混合され、トラック2として記憶される。込み入ったエンコーダは、視覚的なシーンと最もよく合致するために必要な高い空間的精度および特殊な波の型をもってエンコードする。トラック1は、ソース方向の制約なしに、エンコードされる周辺音に関係する音場Anmを含む。通例、周辺音の空間的精度は前方音ほど高い必要はなくその結果、アンビソニックス次数はより小さいことができる、波型のモデル化はそれほど決定的ではない。周辺音場はまた、前方音信号の残響部分をも含むことができる。両方のトラックは記憶および/または交換のために多重化される。任意的に、方向性の音たとえばトラック3がファイルに多重化されることができる。これらの音は特殊効果音、対話または視覚障害者のためのナレーション音声のような補助情報であることができる。図5は、デコードの原理を示している。上部に描かれるように、疎なスピーカーセットアップをもつ映画館は、単純化されたHOAデコードの前にトラック1およびトラック2からのHOA信号両方を混合することができ、トラック2の次数を打ち切り、両トラックの次元を2Dに下げてもよい。方向性ストリームが存在する場合、そのストリームは2DHOAにエンコードされている。その場合、三つのストリームすべてが混合されて単一のHOA表現を形成し、それが次いでデコードされ、再生される。下部は図2に対応する。前方ステージのためのホロフォニックシステムおよびより粗い3Dサラウンドシステムを備える映画館は、専用の洗練されたデコーダを使い、スピーカー入力を混合する。トラック1データストリームについては、周辺音を表すHOAデータが周辺音再生のために特化されたデコーダ1向けに変換される。トラック2データストリームについては、HOA視覚的なシーンに関係した前方音は、専用のデコーダ2でのスクリーン領域のまわりの球状音源の最善の配置のため、変換され、距離補正される式。方向性のデータストリームはL個のスピーカーに直接パンされる。三つのスピーカー信号は3Dスピーカーシステムでの統合再生のためにPCM混合される。高次アンビソニックスを使った音場記述球面調和関数SHを使った音場記述球面調和関数/ベッセル記述を使うとき、音響的な波の方程式の解は式で与えられる。非特許文献4参照。音圧は球面座標r、Θ、Φ定義については図7参照および空間周波数k=ωc=2πfcの関数である。その記述は、関心領域または有効性領域の外側のオーディオ音源についても有効であり図6に示される内部領域問題、正規直交化された球面調和関数を想定している。Anmはアンビソニック係数と呼ばれ、jnは第一種の球面ベッセル関数であり、Ynmは球面調和関数SHSphericalHarmonicsと呼ばれ、nはアンビソニックス次数orderインデックスであり、mは度数degreeを示す。小さなkr値原点からの小さな距離または低周波数についてのみ有意な値をもつベッセル関数の性質のため、この級数は、充分な精度をもって、何らかの次数nで止め、値Nに制約することができ、HOAデータを記憶する際、通例、アンビソニックス係数AnmBnmまたは何らかの派生物詳細は後述がその次数Nまで記憶される。Nはアンビソニックス次数と呼ばれる。Nはアンビソニックス次数と呼ばれ、用語次数は通例、ベッセル関数jnおよびハンケル関数hnと組み合わせても使われる。図8に描かれるように源が関心領域または有効性領域の内側にある外部ケースについての波の方程式の解は、r>rsourcer源について、式で表される。Bnmはやはりアンビソニックス係数と呼ばれ、hnはn次の第一種の球面ハンケル関数である。この公式は正規直交化されたSHを想定している。コメント:一般に、第一種の球面ハンケル関数hnは、正の周波数について出ていく波eikrに関係を記述するために使われ、第二種の球面ハンケル関数hnは、はいってくる波eikrに関係のために使われる。上述した非特許文献5参照。球面調和関数球面調和関数Ynmは複素数値であることも実数値であることもある。HOAのための一般的なケースは実数値の球面調和関数を使う。実および複素球面調和関数を使ったアンビソニックスの統一的な記述は非特許文献6で概観できる。球面調和関数を規格化するには種々の方法があるこれは球面調和関数が実か複素かとは独立である。非特許文献7参照。規格化は、YnmとYnmとの間の直交関係に対応する。コメント:ここで、S2は単位球であり、クロネッカーのデルタδaaはa=aについては1、それ以外では0に等しい。複素球面関数はによって記述される。ここで、i=√であり、smは先述した非特許文献5と同様に、正のmについては交互の符号を与えるようsm=mであり、それ以外の場合にはsm=1である。コメント:smは慣例上の項であり、正のみのSHについては省略可。Nnmは規格化項であり、正規直交化された表現については次の形を取るは階乗を表す。下記の表1は、複素数値の球面調和関数についてのいくつかの一般的に使われる規格化方式を示す。Pnmはルジャンドル陪関数であり、上述の非特許文献6からのmを用いた記法に従っている。これは、コンドンショートリーCondonShortley位相と呼ばれ、他の記法ではPnmの表現内に含まれることがある位相項mを回避する。ルジャンドル陪関数はロドリーグの公式を使って次のように表現できる。数値的には、Pnmを再帰関係から漸進的に導出することが有利である。非特許文献9参照。n=4までのルジャンドル陪関数を表2に与えておく。実数値のSHはmの互いに反対の値に対応する複素共役Ynmを組み合わせることによって導かれる定義における項mは、アンビソニックスにおける通常のケースである実SHのための符号なしの表現を得るために導入されている。これは、方位角項のみを保持したの円調和関数とのつながりをハイライトするために式のように書き直すことができる。所与のアンビソニックス次数Nについての球面成分Snmの総数は2に等しい。実数値の球面調和関数の一般的な規格化方式を表3に与えておく。円調和関数二次元表現だけの場合には、調和関数のサブセットが必要とされる。SH度数はm∈-nnの値のみを取ることができる。所与のNについての成分の総数は2N1に減る。傾斜角θを表す成分が不要になり、球面調和関数が式で表される円調和関数で置き換えられるからである。円調和関数については種々の規格化Nm方式があり、3Dアンビソニックス係数を2D係数に変換するときにはこれを考える必要がある。円調和関数についての一般的な公式は次のようになる。円調和関数についてのいくつかの一般的な規格化因子を表4に与えておく。ここで、規格化項は水平面内の項の前の因子によって導入される。異なる規格化の間の変換はストレートなことである。一般に、規格化は圧力を記述する記法式、参照およびすべての派生する考察に対して効果をもつ。規格化の種類はアンビソニックス係数にも影響する。これらの係数をスケーリングするために適用できる重みもある。たとえば、AMBフォーマットを使ってファイルを記憶するときにアンビソニックス係数に適用されるファースモームFuMa重みである。2D‐3D変換に関し、たとえば2Dスピーカー設定のための2Dデコーダで3Dアンビソニックス表現記録をデコードするとき、CHからSHへおよびその逆の変換はアンビソニックス係数にも適用できる。3D‐2D変換のためのの間の関係は、アンビソニックス次数4までは、次の図式に描かれる。2Dから3Dの変換因子は、θ=π2にある水平ペインについて、次のように導出できる。3Dから2Dへの変換はを使う。詳細は下記で式との関連で呈示する。2D規格化から正規直交化への変換はとなる。アンビソニックス係数アンビソニックス係数は音圧の単位スケールをもつ。アンビソニックス係数はアンビソニックス信号を形成し、一般に、離散時間の関数である。表5は、次元表現、アンビソニックス次数およびアンビソニックス係数チャネルの数の間の関係を示している。離散時間表現を扱う際は、通例、アンビソニックス係数は、多チャネル記録のPCMチャネル表現のようにチャネル=サンプルvのアンビソニックス係数Anmインターリーブ式に記憶される。係数シーケンスは慣例の問題である。3D、N=2についての一例はとなり、2D、N=2については、となる。A00信号は、アンビソニックス記録のモノ表現と見なすことができ、方向情報をもたず、記録の全般的な音質印象を表す。アンビソニックス係数の規格化は一般に、SHの規格化に従って実行される下記で明白となるであろう。式参照。外部記録をデコードするときにはこのことを考慮に入れる必要がある。下記で、Anmは規格化因子NnmでのSHに基づき、ハチェック付きAnmは規格化因子ハチェック付きNnmでのSHに基づくこれは、SN3DからN3Dの場合にはとなる。BフォーマットおよびAMBフォーマットは、係数に適用される追加的な重みガーソンGerson、ファースモームFuMa、MaxN重みを使う。その際、基準となる規格化は通例SN3Dである。非特許文献10、11参照。理想的な平面波または球面波のための波の方程式の次の二つの具体的な実現は、アンビソニックス係数についてのさらなる詳細を示す。平面波平面波Anmについて波の方程式を解くことは、kおよびrsとは独立である。θs、φsは源角度を記述し、は複素共役を表す。ここで、Ps0は時間の関数であることのできる記述座標系の原点において測定された源のスケーリング信号圧を記述するために使われ、正規直交化された球面調和関数についてはA00plane√となる。一般に、アンビソニックスは平面波を想定し、アンビソニックス係数が伝送または記憶される。この想定のおかげで、異なる方向性信号の重ね合わせおよび単純なデコーダ設計の可能性が提供される。これはまた、一次のBフォーマットN=1で記録されたサウンドフィールドSoundfield商標マイクロホンの信号についても成り立つ。このことは、等化フィルタの位相進行を比較すれば明らかになる。理論的な進行については上述の非特許文献6の章21を参照。特許で保護されている進行については特許文献1を参照。式は次のようになる。係数dnmは後処理されたマイクロホンアレイ信号によって導出されることができ、あるいはモノ信号Ps0を使って合成的に生成されることができ、その場合は方向性の球面調和関数Ynmは時間依存移動する源にもなることができる。式は、各時間的なサンプリング時点vについて有効である。合成的エンコードのプロセスは、選択されたアンビソニックス次数Nについて、ベクトル/行列形式ですべてのサンプル時点vについて書き直すことができる。ここで、dはアンビソニックス信号であり、dnmを保持し、N=2についての例:、dの大きさsize=2x1=Ox1であり、Ps0は基準となる原点での源信号圧であり、Ψはエンコードベクトルencodingvectorであり、Ynmを保持し、size=Ox1である。エンコードベクトルは特定の源方向Θsφs平面波の方向に等しいについての球面調和関数から導出できる。球面波r<rsについて点源近距離場の源によって生成されるはいってくる球面波を記述するアンビソニックス係数は次のようになる。この式は下記の式ないしとの関連で導出される。Ps0=pは原点での音圧を記述し、やはりA00√に等しくなる。hnは次数nの第二種の球面ハンケル関数であり、h0は0次の第二種の球面ハンケル関数である。式は非特許文献12の教示と同様である。ここで、であり、式を念頭に置けば、これは非特許文献13に見出すことができる。この文献で、ガーソンは度数1firstdegree信号について近接効果を記述している。球面アンビソニックス信号の合成的な生成は、より高いアンビソニックス次数Nについてはそれほど一般的ではない。hnh0の周波数応答を低周波数について数値的に扱うのが難しいからである。これらの数値的な問題は、下記に述べるデコード/再生のための球面モデルを考えることによって克服できる。音場再生平面波デコード一般に、アンビソニックスは、円上または球面上に一様に分布したL個のスピーカーによる音場の再生を想定する。スピーカーが聴取者位置から十分遠くに置かれている場合には、中心において平面波デコードモデルが有効であるrs>λ。L個のスピーカーによって生成される音圧は次式によって記述される。ここで、wlはスピーカーlについての信号であり、音圧の単位スケール1Paをもつ。wlはしばしばスピーカーlの駆動関数と呼ばれる。この式の音圧が式によって記述される圧力と同一であることが望ましい。すると次のようになる。これは再エンコード公式reencodingformulaとして知られる、行列形式に書き直すことができる式と比較。ここで、dはアンビソニックス信号であり、を保持しN=2についての例:、dの大きさsize=2x1=Ox1であり、Ψは再エンコード行列であり、Ynmを保持し、size=OxLであり、yはスピーカー信号wlであり、size1=Lである。すると、yはいくつかの既知の方法、たとえばモードマッチングあるいは特殊なスピーカーパニング関数について最適化する諸方法を使って導出できる。球面波モデルについてのデコードより一般的なデコードモデルはやはり、原点のまわりに距離rlで均等に分布した、点状の球面波を放射するスピーカーを想定する。アンビソニックス係数Anmは式からの一般的な記述によって与えられ、L個のスピーカーによって生成される音圧は式に従って与えられる。より洗練されたデコーダは、を取得し、その後、スピーカー重みを導出するためにとして式を適用するために、アンビソニックス係数Anmをフィルタ処理することができる。このモデルでは、スピーカー信号wlは原点における圧力によって決定される。上述した非特許文献4で最初に記述された、単純な源アプローチを使う代替的な手法がある。スピーカーは球面上に均等に分布しており、二次的な源特性をもつと想定される。解は非特許文献14、式において導出され、それはアンビソニックス次数Nにおける打ち切りおよびスピーカー利得glについて、一般化として書き直せる。距離符号化されたアンビソニックスDistanceCodedAmbisonics信号基準スピーカー距離rlrefを使ったアンビソニックスエンコーダにおけるCnmの生成は、式を使って球面波をモデル化または記録するときのAnmの数値上の問題を解決できる。伝送ないし記憶されるのはCnm、基準距離rlrefおよび球面距離符号化係数が使われているとのインジケータである。デコーダ側では、真のスピーカー距離がである限り、式で与えられるような単純なデコード処理が実現可能である。その距離が大きすぎれば、アンビソニックスデコード前のフィルタ処理による補正が必要となる。式のような他のデコードモデルは距離符号化されたアンビソニックスについて異なる定式化につながる。球面調和関数の規格化も距離符号化されたアンビソニックスの定式化に影響をもつことができる。すなわち、距離符号化されたアンビソニックス係数は明確なコンテキストを必要とする。上述した2D‐3D変換の詳細は次のとおり。乗算により2D円成分を3D球面成分に変換する変換因子α2D3Dは次のように導出できる。=Πi1lを二重階乗とし、一般的な恒等式非特許文献15参照Pll=l2を使うと、Pmmはと表現でき、式を式に代入すると式になる。2Dから直交3Dへの変換は、関係l=を使ってl=2mを代入すると、によって導出できる。上述した球面波展開の詳細は次のようになる。r<rsについて点源によって生成される、はいってくる波である球面波について式を解くことは、より複雑になる。0になる無限小の大きさをもつ点源は体積流Qsを使って記述する必要があるからである。ここで、源がrsに位置され、rにおけるフィールド点についての放射される圧力はによって与えられる上述した非特許文献5参照。ρ0は比重であり、Gはグリーン関数である。Gは、r<rsについて、球面調和関数において次式によっても表現できる。ここで、hnは第二種のハンケル関数である。グリーン関数はメートルの逆数の単位のスケールをもつことを注意しておくkのため1m。式、を式と比べると、球面波のアンビソニックス係数を導出できる。ここで、Qsは単位m3s1の体積流であり、ρ0はkgm3を単位とする密度である。アンビソニックス信号を合成的に生成し、上記の平面波の考察に関係付けることができるには、式を座標系の原点で生成される音圧を使って表しておくことが合理的である。これからが導かれる。交換記憶フォーマット本発明に基づく記憶フォーマットは、二つ以上のHOA表現および追加的な方向性ストリームを、一つのデータコンテナ中に一緒に記憶することを許容する。これは、デコーダが再生を最適化できるようにするHOA記述の種々のフォーマットを可能にするとともに、>4GBのサイズについて効率的なデータ記憶を提供する。さらなる利点は以下のとおり。A種々のフォーマットを使っていくつかのHOA記述を関係した記憶フォーマット情報とともに記憶することによって、アンビソニックスデコーダは両方の表現を混合し、デコードすることができる。B次世代HOAデコーダについて必要とされる情報項目がフォーマット情報として記憶される:次元性dimensionality、関心領域聴取領域の外側または内部の源、球面基底関数の規格化;アンビソニックス係数パッキングおよびスケーリング情報;アンビソニックス波型平面、球面、基準半径球面波のデコードのため;関係した方向性のモノ信号が記憶されうる。これらの方向性の信号の位置情報は角度と距離の情報またはアンビソニックス係数のエンコードベクトルを使って記述できる。Cアンビソニックスデータの記憶フォーマットが、データの柔軟かつ経済的な記憶を許容するために拡張される:異なるPCM語サイズ分解能をもつアンビソニックス成分アンビソニックスチャネルに関係したアンビソニックスデータを記憶;再サンプリングまたはMDCT処理を使って、低下した帯域幅でアンビソニックスデータを記憶。Dメタデータフィールドが、トラックを特別なデコード前方、周辺のために関連付けるため、またマイクロホン信号についての録音情報のようなファイルについての付随情報の記憶を許容するために利用可能:記録基準座標系、マイクロホン、源および仮想聴取者位置、マイクロホン指向特性、部屋および源情報。E本フォーマットは、種々のトラックを含む複数のフレームの記憶に好適であり、シーン記述なしにオーディオシーン変化を許容する。コメント:一つのトラックはHOA音場記述または位置情報をもつ単一源を含む。フレームは一つまたは複数の並行トラックの組み合わせである。トラックはフレームの先頭で始まってもよく、またはフレームの末尾で終わってもよい。よって、タイムコードは必要とされない。F本フォーマットは、オーディオトラックデータへの高速アクセス手がかり点への早送りまたはジャンプおよびファイルデータの先頭の時刻に対するタイムコードの決定を容易にする。HOAデータ交換のためのHOAパラメータ表6は、曖昧さのないHOA信号データ交換のために定義されることが必要なパラメータをまとめている。球面調和関数の定義は複素数値および実数値の場合について固定される。式参照。ファイルフォーマットの詳細以下では、高次アンビソニックスHOAまたは位置情報のある単独源から構成されるオーディオシーンを記憶するためのファイルフォーマットについて詳細に述べる。オーディオシーンは、異なる規格化方式を使うことができる複数のHOAシーケンスを含むことができる。よって、デコーダは、所望されるスピーカーセットアップについて対応するスピーカー信号を、現在のファイルからのすべてのオーディオトラックの重ね合わせとして計算できる。ファイルはオーディオコンテンツをデコードするために必要とされるすべてのデータを含む。本発明に基づくファイルフォーマットは単一ファイル中に二つ以上のHOAまたは単独源信号を記憶する機能を提供する。本ファイルフォーマットは、諸フレームの合成compositionを使い、各フレームはいくつかのトラックを含むことができ、トラックのデータはトラックパケットTrackPacketsと呼ばれる一つまたは複数のパケットに記憶される。すべての整数型はリトルエンディアン型のバイト順で記憶されるので、最下位バイトが最初にくる。ビット順は、常に、最上位ビットが先である。整数データ型についての記法はintである。先頭のuが付くと符号なし整数を示す。ビット単位での分解能が定義の末尾に書かれる。たとえば、符号なし16ビット整数フィールドはuint16として定義される。整数フォーマットでのPCMサンプルおよびHOA係数は固定小数点数として表現され、小数点は最上位ビットにある。すべての浮動小数点データ型はIEEE規格IEEE754非特許文献16に準拠する。浮動小数点データ型についての記法はfloatである。ビット単位での分解能が定義の末尾に書かれる。たとえば、32ビット浮動小数点フィールドはfloat32と定義される。フレーム、トラックまたはチャンクの先頭を同定する一定の識別子IDおよびストリングはデータ型バイトとして定義される。バイト配列のバイト順は最上位のバイトおよびビットが先である。したがって、TRCKというIDは32ビットのバイトフィールドにおいて定義され、バイトは物理的な順TRCおよびKで書かれる。十六進値は0xで始まるたとえば0xAB64C5。単独ビットは引用符中に入れられたとえば1、複数の二進値は0bで始まるたとえば0b0011=0x3。ヘッダフィールド名は常にヘッダ名で始まり、それにフィールド名が続く。ここで、各語の最初の文字は大文字化される例:TrackHeaderSize。フィールド名またはヘッダ名の略称は大文字だけを使って作られる例:TrackHeaderSize=THS。HOAファイルフォーマットは二つ以上のフレーム、パケットまたはトラックを含むことができる。複数のヘッダフィールドの弁別のため、フィールドまたはヘッダ名のあとに数字が続くことができる。たとえば、三番目のTrackの二番目のTrackPacketはTrack3Packet2と名付けられる。HOAファイルフォーマットは複素数値のフィールドを含むことができる。これらの複素数値は実部および虚部として記憶され、実部が先に書かれる。int8フォーマットでの複素数1i2は0x01のあとに0x02が続くものとして記憶される。よって、複素数値フォーマット型でのフィールドまたは係数は、対応する実数値フォーマット型に比べて二倍の記憶サイズを必要とする。高次アンビソニックスファイルフォーマット構造単独トラックフォーマット高次アンビソニックスファイルフォーマットは、図9に描かれるように、少なくとも一つのFileHeaderファイルヘッダ、一つのFrameHeaderフレームヘッダ、一つのTrackHeaderトラックヘッダおよび一つのTrackPacketトラックパケットを含む。図9は、一つまたは複数のPacketパケットにおいて一つのTrackトラックを担持する単純な例示的なHOAファイルフォーマットを示している。よって、HOAファイルの基本構造は、一つのFileHeaderのあとに少なくとも一つのTrackを含むFrameが続くというものである。Trackは常にTrackHeaderおよび一つまたは複数のTrackPacketを含む。複数フレームおよびトラックのフォーマットFileHeaderとは対照的に、HOAファイルは二つ以上のフレームを含むことができ、フレームは二つ以上のトラックを含むことができる。フレームの最大サイズを超過した場合またはトラックが追加されるか、あるフレームから他に移された場合に新たなFrameHeaderが使用される。複数トラックおよびフレームのHOAファイルの構造は図10に示されている。複数トラックのフレームの構造はFrameHeaderで始まり、当該フレームのすべてのTrackHeaderが続く。結果として、各トラックのTrackPacketは逐次的にFrameHeaderに送られる。ここで、TrackPacketはTrackHeaderと同じ順序にインターリーブされる。複数トラックフレームにおいては、サンプル単位でのパケットの長さはFrameHeaderにおいて定義され、すべてのトラックについて一定である。さらに、各トラックのサンプルは同期されている。たとえば、Track1Packet1のサンプルはTrack2Packet1のサンプルと同期している。特定のTrackCodingTypeトラック符号化種別がデコーダ側で遅延を引き起こすことができ、そのような特定の遅延はデコーダ側で知られている、またはTrackHeaderのTrackCodingType従属部分に含められる必要がある。デコーダは、フレームのすべてのトラックの最大遅延にすべてのTrackPacketを同期させるからである。ファイル依存のメタデータ完全なHOAファイルを参照するメタデータは任意的に、MetaDataChunkメタデータチャンク中のFileHeader後に加えられることができる。MetaDataChunkは特定の一般的ユーザーIDGUIDで始まり、それにMetaDataChunkSizeメタデータチャンクサイズが続く。MetaDataChunk、たとえばMetaData情報の本質は、XMLフォーマットまたは任意のユーザー定義されるフォーマット中にパッキングされる。図11は、いくつかのMetaDataChunkを使ったHOAファイルフォーマットの構造を示している。トラック型HOAフォーマットのTrackトラックは、一般的なHOATrackHOAトラックとSingleSourceTrack単独源トラックとの区別をする。HOAトラックはHOACoefficientHOA係数として符号化された完全な音場を含む。したがって、シーン記述、たとえばエンコードされた源の位置は、デコーダ側で係数をデコードするために必要とされない。換言すれば、オーディオシーンは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に依存して、HOATrackHeaderHOAトラックヘッダまたはSingleSourceTrackHeader単独源トラックヘッダが設けられる。HOATrackHeaderは、完全な音場を記述する標準的なHOA係数のための副情報を提供する。SingleSourceTrackHeaderはモノPCMトラックのサンプルおよび源の位置についての情報を保持する。SingleSourceTrack単独源トラックについては、デコーダはトラックをシーン中に含める必要がある。TrackHeaderの末尾には、任意的なTrackMetaDataフィールドが定義される。これはトラックに依存するメタデータ、たとえばAフォーマット伝送のための追加的情報マイクロホンアレイ信号を提供するためにXMLフォーマットを使う。HOAトラックヘッダHOATrackHeaderHOAトラックヘッダは、HOAトラックを復号するための情報を保持するTrackHeaderの一部である。HOATrackのTrackPacketは、トラックの音場全体を符号化するHOA係数を伝達する。基本的には、HOATrackHeaderは、所与のスピーカーセットアップのためにHOA係数をデコードするためのデコーダ側で必要になるすべてのHOAパラメータを保持する。TrackComplexValueFlagおよびTrackSampleFormatは各TrackPacketのHOA係数のフォーマット型を定義する。エンコードされたまたは圧縮された係数については、TrackSampleFormatがデコードされたまたは圧縮解除された係数のフォーマットを定義する。すべてのフォーマット型は実数または複素数であることができる。複素数についてのさらなる情報は上記のファイルフォーマットの詳細の節で与えてある。すべてのHOAに依存する情報はTrackHOAParamsにおいて定義される。TrackHOAParamsは他のTrackSourceTypesにおいて再利用される。したがって、TrackHOAParamsのフィールドはトラックHOAパラメータの節で定義され、説明される。TrackCodingTypeフィールドは、HOA係数の符号化圧縮フォーマットを示す。HOAファイルフォーマットの基本的なバージョンはたとえば二つの符号化型を含む。一つの符号化型はPCM符号化型であるTrackCodingType0。ここでは、圧縮解除された実または複素係数が選択されたTrackSampleFormatでパケット中に書き込まれる。HOA係数の順序および規格化はTrackHOAParamsフィールドにおいて定義される。第二の符号化型は、サンプルフォーマットの変更と、各HOA次数の係数の帯域幅を制限することを許容する。CodingTypeの詳細な説明は、トラック領域符号化の節で与えられるが、簡単に説明しておく。TrackBandwidthReductionTypeは各HOA次数の帯域幅を制限するために使われた処理の型を決定する。すべての係数の帯域幅が変更されていない場合、TrackBandwidthReductionTypeフィールドを0に設定することによって帯域幅削減をオフにできる。他の二つの帯域幅削減処理型が定義される。本フォーマットは、周波数領域のMDCT処理と、任意的に、時間領域のフィルタ処理を含む。MDCT処理についてのさらなる情報は、MDCTによる帯域幅削減の節を参照。HOA次数は、同じサンプルフォーマットおよび帯域幅の諸領域に組み合わされることができる。領域の数はTrackNumberOfOrderRegionsフィールドによって示される。各領域について、最初と最後の次数インデックス、サンプルフォーマットおよび任意的な帯域幅削減情報が定義される必要がある。領域は少なくとも一つの次数を得る。どの領域によってもカバーされない次数は、TrackSampleFormatフィールドで示される標準的なフォーマットを使って完全帯域幅で符号化される。特別な場合は、領域なしの使用であるTrackNumberOfOrderRegions0。この場合は、PCMフォーマットにおけるインターリーブ解除されたHOA係数について使用できる。ここで、HOA成分はサンプル毎にインラーリーブされない。ある領域の諸次数のHOA係数はTrackRegionSampleFormatにおいて符号化される。TrackRegionUseBandwidthReductionは、その領域の諸次数の係数についての帯域幅削減処理の使用を示す。TrackRegionUseBandwidthReductionフラグがセットされている場合、帯域幅削減副情報があとに続く。MDCT処理については、窓型および最初と最後の符号化されたMDCTビンが定義される。ここで、最初のビンは下のカットオフ周波数と等価であり、最後のビンは上のカットオフ周波数を定義する。MDCTビンもTrackRegionSampleFormatで符号化される。MDCTによる帯域幅削減の節を参照。単独源型単独源は固定位置および移動位置源に細分される。源型はTrackMovingSourceFlagにおいて示される。移動位置源型と固定位置源型の間の違いは、固定源の位置はトラックヘッダにおいて一度だけ示され、移動源についてはトラックパッケージ毎にであるということである。源の位置は球面座標での位置ベクトルを用いて明示的に、あるいはHOAエンコードベクトルとして暗黙的に示されることができる。源自身は、再生のためにアンビソニックスデコーダを使う場合、デコーダ側でHOA係数にエンコードされる必要があるPCMモノトラックである。単独源固定位置トラックヘッダ固定位置源型は0であるTrackMovingSourceFlagトラック移動源フラグによって定義される。第二のフィールドは、源位置の符号化を球面座標でのベクトルとしてまたはHOAエンコードベクトルとして与えるTrackPositionTypeトラック位置型を示す。モノPCMサンプルの符号化フォーマットはTrackSampleFormatトラックサンプルフォーマットフィールドによって示される。源位置がTrackPositionVectorトラック位置ベクトルとして送られる場合、源位置の球面座標はTrackPositionThetas軸からxy平面への傾斜、TrackPositionPhix軸から始まり反時計回りの方位角およびTrackPositionRadiusのフィールドにおいて定義される。源位置がHOAエンコードベクトルとして定義される場合、TrackHOAParamsトラックHOAパラメータがまず定義される。これらのパラメータはトラックHOAパラメータの節で定義され、HOAエンコードベクトルの使用される規格化および定義を示す。TrackEncodeVectorComplexFlagトラックエンコードベクトル複素数フラグおよびTrackEncodeVectorFormatトラックエンコードベクトルフォーマットフィールドは、後続のTrackHOAEncodingVectorトラックHOAエンコードベクトルのフォーマット型を定義する。TrackHOAEncodingVectorは、float32またはfloat64フォーマットで符号化されている、TrackHOAParamNumberOfCoeffs個の値からなる。単独源移動位置トラックヘッダ移動位置源型は、1であるTrackMovingSourceFlagによって定義される。ヘッダは、源位置データフィールドTrackPositionTheta、TrackPositionPhi、TrackPositionRadiusおよびTrackHOAEncodingVectorの源位置データフィールドがないほかは、固定源ヘッダと同一である。移動源については、これらは各パケットにおいて新しい動いている源位置を示すために、TrackPackets内に位置される。特殊トラック表トラックHOAパラメータTrackHOAParamsHOAエンコードおよびデコードのためのいくつかのアプローチが過去に議論されているが、HOA係数を符号化するための結論や合意には至っていない。有利なことに、本発明に基づくフォーマットは、大半の既知のHOA表現の記憶を許容する。TrackHOAParamsは、どの種類の規格化および係数の順序シーケンスがエンコーダ側で使われたかを明確にするために定義される。これらの定義は、HOAトラックの混合およびデコーダマトリクスの適用のためにデコーダ側において考慮に入れる必要がある。HOA係数は完全な三次元音場について、または二次元のxy平面についてのみ、適用できる。HOAトラックの次元は、TrackHOAParamDimensionフィールドにおいて定義される。TrackHOAParamRegionOfInterestは、源が関心領域の内側または外側にあり、関心領域は全く源を含まない、二つの音圧級数展開を反映する。内部ケースおよび外部ケースについての音圧の計算はそれぞれ上記の式およびにおいて定義されている。ここで、HOA信号Anmの方向性情報は球面調和関数の複素共役Ynmによって決定される。この関数は複素および実数版で定義される。エンコーダおよびデコーダは等価な数値型の球面調和関数を適用する必要がある。よって、TrackHOAParamSphericalHarmonicTypeが、どんな種類の球面調和関数がエンコーダ側で適用されたかを示す。上述したように、基本的に球面調和関数はルジャンドル陪関数および複素または実の三角関数によって定義される。ルジャンドル陪関数は式によって定義される。複素数値の球面調和関数の表現はとなる。ここで、Nnmはスケーリング因子式参照である。この複素数値の表現は、次式を使って実数値の表現に変換できる。ここで、実数値の球面調和関数のための修正されたスケーリング因子は次のようになる。2D表現については、HOA係数のエンコードおよびデコードのために円調和関数を使う必要がある。円調和関数の複素数値の表現は次式で定義される。円調和関数の実数値の表現は次式で定義される。球面調和関数または円調和関数を特定の用途または要求に適応させるために、次のようないくつかの規格化因子が使用される。HOA係数の正しいデコードを保証するために、エンコーダ側で使われた球面調和関数の規格化がデコーダ側で知られている必要がある。次の表7は、TrackHOAParamSphericalHarmonicNormフィールドを用いて選択できる規格化を定義している。将来の規格化のために、TrackHOAParamSphericalHarmonicNormフィールドの専用の値が利用可能になっている。専用の規格化については、各HOA係数についてのスケーリング因子がTrackHOAParamsの末尾で定義される。専用のスケーリング因子TrackScalingFactorsは実または複素のfloat32またはfloat64値として送信できる。スケーリング因子フォーマットは、専用スケーリングの場合、TrackComplexValueScalingFlagおよびTrackScalingFormatフィールドにおいて定義される。異なるHOA次数の係数の振幅を整数フォーマット型での送信のために1より小さい絶対値に等化するため、符号化されたHOA係数にファースモーム規格化がさらに適用されることができる。ファースモーム規格化は、三次までの係数のSN3D実数値球面調和関数のために設計された。よって、ファースモーム規格化は、SN3D実数値球面調和関数との組み合わせでのみ使うことが推奨される。さらに、TrackHOAParamFurseMalhamFlagは3より大きなHOA次数をもつトラックについては無視される。HOA係数をデコードするためには、ファースモーム規格化の逆をデコーダ側で行う必要がある。表8はファースモーム係数を定義している。TrackHOAParamDecoderTypeは、どの種類のデコーダがデコーダ側に存在するとエンコーダ側で想定されているかを定義する。デコーダ型は、音場をレンダリングするためにデコーダ側で使用されることになるスピーカーモデル球面波または平面波を決定する。それにより、デコーダの式の一部をエンコーダの式に移すことによってデコーダの計算量を軽減できる。さらに、エンコーダ側での数値上の問題も軽減できる。さらに、デコーダ側でのすべての非一貫性はエンコーダに移すことができるので、デコーダは、すべてのHOA係数についての同一の処理に帰着できる。しかしながら、球面波については、聴取位置からのスピーカーの一定の距離を想定する必要がある。したがって、想定されるデコーダ型はトラックヘッダにおいて示され、球面波デコーダ型についてのスピーカー半径rlsは任意的なフィールドTrackHOAParamReferenceRadiusにおいてミリメートル単位で伝送される。デコーダ側での追加的なフィルタが、想定されたスピーカー半径と真のスピーカー半径との間の差を等化することができる。HOA係数CnmのTrackHOAParamDecoderType規格化は、TrackHOAParamRegionOfInterestで選択された内部または外部音場展開の使用に依存する。コメント:式および後続の式におけるdnmは下記における係数Cnmに対応する。エンコーダ側では、係数Cnmは表9において定義される係数AnmまたはBnmから決定され、記憶される。使用される規格化はTrackHOAParamヘッダのTrackHOAParamDecoderTypeフィールドにおいて示される。一つの時間サンプルについてのHOA係数はTrackHOAParamNumberOfCoeffs個の係数Cnmを含む。NはHOA係数の次元に依存する。2D音場については、Oは2N1に等しい。ここで、NはTrackHOAParamヘッダからのTrackHOAParamHorizontalOrderフィールドに等しい。2DHOA係数は、-N≦m≦NとしてCmm=Cmとして定義され、表10に示されるような3D係数の部分集合として表現できる。3D音場については、Oは2に等しい。ここで、NはTrackHOAParamヘッダからのTrackHOAParamVerticalOrderフィールドに等しい。3DHOA係数Cnmは、0≦n≦Nおよび-n≦m≦nについて定義される。HOA係数の一般的な表現は表10に与えられる。3D音場かつTrackHOAParamVerticalOrderより大きなTrackHOAParamHorizontalOrderの場合、混合次数のデコードが実行される。混合次数信号では、いくつかの高次係数は2Dでのみ伝送される。TrackHOAParamVerticalOrderフィールドはすべての係数が伝送される垂直方向次数を決定する。垂直方向次数からTrackHOAParamHorizontalOrderまでは、2D係数のみが使用される。このように、TrackHOAParamHorizontalOrderはTrackHOAParamVerticalOrder以上である。水平方向次数4および垂直方向次数2の混合次数表現の例が表11に描かれている。HOA係数Cnmはトラックのパケット中に記憶される。係数のシーケンス、たとえばどの係数が最初にきてどれがそれに続くか、は、過去に種々の仕方で定義されてきた。よって、TrackHOAParamCoeffSequenceトラックHOAパラメータ係数シーケンスは三つの型の係数シーケンスを示す。三つのシーケンスは、表10のHOA係数配置から導出される。Bフォーマットシーケンスは、表12に示されるように、三次までの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となる。3DHOAについての係数Cnmは最低から最高のHOA次数n=0...Nに数値的に昇順または降順にTrackHOAParamCoeffSequenceにおいて伝送される。数値的な昇順シーケンスはm=-nで始まり、m=nまで増大するC00、C11、C10、C11、C22、C21、C20、C21、C22、...。これは非特許文献17で定義されるCGシーケンスである。数値的に降順のシーケンスmは逆にm=nからm=-nに進みC00、C11、C10、C11、C22、C21、C20、C21、C22、...、これは非特許文献17で定義されるQMシーケンスである。2DHOA係数については、TrackHOAParamCoeffSequenceの数値的に昇順および降順のシーケンスは3Dの場合と同様であるが、m≠nで不使用の係数すなわち、表10の扇形のsectoralHOA係数Cmm=Cmのみは省略される。よって、数値的に昇順のシーケンスはC00、C11、C11、C22、C22、...につながり、数値的に降順のシーケンスはC00、C11、C11、C22、C22、...につながる。トラックパケットHOAトラックパケットPCM符号化型パケットこのパケットはHOA係数Cnmを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モノサンプルが伝送される。符号化処理トラック領域符号化TrackRegionCodingHOA信号は、マイクロホンアレイによる音場記録から導出できる。たとえば、特許文献2においてEigenmikeは三次のHOA記録を得るために使用できることを開示した。しかしながら、マイクロホンアレイの有限な大きさのため、記録されるHOA係数に制約が生じる。特許文献2および上述した非特許文献4では、有限なマイクロホンアレイによって引き起こされる問題が論じられている。マイクロホンカプセルの距離は、空間的サンプリング定理によって与えられる上限周波数につながる。この上限周波数より上では、マイクロホンアレイは正しいHOA係数を生成できない。さらに、HOA聴取位置からのマイクロホンの有限な距離は等化フィルタを必要とする。これらのフィルタは、低周波数について高い利得を得、該利得はHOA次数毎にさらに増大する。特許文献2では、等化フィルタのダイナミックレンジを扱うために、高次係数についてのより低いカットオフ周波数が導入される。これは、異なるHOA次数のHOA係数の帯域幅が異なることができることを示している。したがって、HOAファイルフォーマットは、トラック領域帯域幅削減を提供している。これは、各HOA次数について必要とされる周波数帯域幅のみを伝送することを許容する。等化フィルタの高いダイナミックレンジのため、またゼロ次の係数が基本的にはすべてのマイクロホン信号の和であるという事実のため、異なるHOA次数の係数は異なるダイナミックレンジをもつことができる。したがって、HOAファイルフォーマットは、フォーマット型を各HOA次数のダイナミックレンジに適応させる特徴をも提供する。トラック領域エンコード処理図12に示されるように、インターリーブされたHOA係数は第一のインターリーブ解除ステップまたは段1211に入力される。このステップまたは段1211は第一のトラック領域に割り当てられており、該トラック領域のすべてのHOA係数を、FramePacketSize個のサンプルへのインターリーブ解除されたバッファに分離する。このトラック領域の係数はHOAトラックヘッダのTrackRegionLastOrderおよびTrackRegionFirstOrderフィールドから導出される。インターリーブ解除は、nとmの一つの組み合わせについての諸係数Cnmが一つのバッファにグループ化されることを意味する。インターリーブ解除ステップまたは段1211から、インターリーブ解除されたHOA係数はトラック領域エンコード部に渡される。残りのインターリーブされたHOA係数は後続のトラック領域インターリーブ解除ステップまたは段に渡される、などとなり、インターリーブ解除ステップまたは段121Nまで続く。インターリーブ解除ステップまたは段の数NはTrackNumberOfOrderRegionsに1を加えたものに等しい。追加的なインターリーブ解除ステップまたは段125は、トラック領域の一部でない残りの係数をインターリーブ解除して、フォーマット変換ステップまたは段126を含む標準的な処理経路に入れる。トラック領域エンコード経路は、任意的な帯域幅削減ステップまたは段1221およびフォーマット変換ステップまたは段1231を含み、各HOA係数バッファについて並列処理を実行する。帯域幅削減は、TrackRegionUseBandwidthReductionトラック領域帯域幅削減使用フィールドが1に設定されていたら実行される。選択されたTrackBandwidthReductionTypeトラック帯域幅削減型に依存して、HOA係数の周波数範囲を制限するため、およびそれらの係数を臨界的にダウンサンプリングするための処理が選択される。これは、HOA係数の数を、最低限必要とされるサンプル数まで削減するために実行される。フォーマット変換は、現在のHOA係数フォーマットをHOAトラックヘッダにおいて定義されているTrackRegionSampleFormatトラック領域サンプルフォーマットに変換する。これは、HOA係数をHOAトラックヘッダの指示されるTrackSampleFormatトラックサンプルフォーマットに変換する標準的な処理経路にある唯一のステップ/段である。マルチプレクサトラックパケットステップまたは段124はHOA係数バッファを多重化して、選択されたTrackHOAParamCoeffSequenceフィールドにおいて定義されているトラックパケットデータファイルストリームにする。ここで、nとmのインデックスの一つの組み合わせについての諸係数Cnmは一つのバッファ内でインターリーブ解除されたままである。トラック領域デコード処理図13に示されるように、デコード処理はエンコード処理の逆である。デマルチプレクサステップまたは段134はトラックパケットデータファイルまたはストリームを指示されるTrackHOAParamCoeffSequenceからインターリーブ解除されたHOA係数バッファ図示せずに多重分離する。各バッファはnとmの一つの組み合わせについてFramePacketLength個の係数Cnmを含む。ステップ/段134はTrackNumberOfOrderRegionに1を加えた数の処理経路を初期化し、インターリーブ解除されたHOA係数バッファの内容を適切な処理経路に渡す。各トラック領域の係数はHOAトラックヘッダのTrackRegionLastOrderおよびTrackRegionFirstOrderフィールドによって定義される。選択された諸トラック領域によってカバーされないHOA次数は、フォーマット変換ステップまたは段136および残りの係数インターリーブステップまたは段135を含む標準的な処理経路において処理される。標準的な処理経路は、帯域幅削減ステップまたは段のないトラック処理経路に対応する。これらのトラック処理経路において、フォーマット変換ステップ/段1331ないし133Nは、TrackRegionSampleFormatでエンコードされているHOA係数をデコーダの処理のために使われるデータフォーマットに変換する。TrackRegionUseBandwidthReductionデータフィールドに依存して、任意的な帯域幅再構成ステップまたは段1321ないし132Nが続く。ここでは、帯域幅制限され臨界的にサンプリングされたHOA係数がトラックのフル帯域幅に再構成される。再構成処理の種類はHOAトラックヘッダのTrackBandwidthReductionTypeフィールドにおいて定義される。後続のインターリーブステップまたは段1311ないし131Nでは、HOA係数のインターリーブ解除されたバッファの内容が、一つの時間サンプルのHOA係数をグループ化することによってインターリーブされ、現在のトラック領域のHOA係数が先行する諸トラック領域のHOA係数と組み合わされる。結果として得られるHOA係数のシーケンスは、当該トラックの処理に適応されることができる。さらに、インターリーブステップ/段は、帯域幅削減を使っているトラック領域と帯域幅削減を使っていないトラック領域との間の遅延に対処する。この遅延は、選択されたTrackBandwidthReductionTypeの処理に依存する。たとえば、MDCT処理はFramPacketSize個のサンプルの遅延を加え、よって帯域幅削減のない処理経路のインターリーブステップ/段はその出力を1パケットだけ遅らせる。MDCTによる帯域幅削減エンコード図14は、MDCTmodifieddiscretecosinetransform[修正離散コサイン変換]処理を使った帯域幅削減を示している。FramePacketSize個のサンプルのトラック領域の各HOA係数はバッファ1411ないし141Mを介して、対応するMDCT窓掛けステップまたは段1421ないし142Mを通る。各入力バッファは、nとmの一つの組み合わせの時間的な相続くHOA係数Cnmを含む。すなわち、一つのバッファは、として定義される。バッファの数Mは、アンビソニックス成分の数次数Nのフル3D音場については2と同じである。バッファ処理は、前のバッファ内容を現在のバッファ内容と組み合わせて対応するステップまたは段1431におけるMDCT処理のための新しい内容にすることによって後続のMDCT処理について50の重なりを実行し、後続のバッファ内容の処理のために現在のバッファ内容を保存しておく。MDCT処理は各フレームの先頭から改めて開始される。これはつまり、現在フレームのあるトラックのすべての係数が、前のフレームの知識なしにデコードでき、現在フレームの最後のバッファ内容に続いては、0からなる追加的なバッファ内容が処理されるということを意味する。したがって、MDCT処理されたトラック領域は一つの余計なトラックパケットを生成する。窓掛けステップ/段では、対応するバッファ内容が選択された窓関数wを乗算される。選択された窓関数は各トラック領域についてHOAトラックヘッダのフィールドTrackRegionWindowTypeにおいて定義されている。修正離散コサイン変換は非特許文献18において最初に言及されたものである。MDCTは、FramePacketSize個のサブバンドの臨界的にサンプリングされたフィルタバンクを表すと考えることができ、50の入力バッファの重なりを要求する。入力バッファはサブバンドサイズの二倍の長さをもつ。MDCTは、TがFramePacketSizeに等しいとして、次の式によって定義される。係数CnmはMDCTビンと呼ばれる。MDCT計算は高速フーリエ変換を使って実装できる。後続の周波数領域カットアウトステップまたは段1441ないし144Mでは、k<TrackRegionFirstBinおよびk>TrackRegionLastBinのすべてのMDCTビンCnmを除去することによって、帯域幅削減が実行される。バッファ長さのTrackRegionLastBin-TrackRegionFirstBin1への削減である。ここで、TrackRegionFirstBinは当該トラック領域についての下カットオフ周波数であり、TrackRegionLastBinは上カットオフ周波数である。MDCTビンを無視することは、TrackRegionLastBinおよびTrackRegionFirstBin周波数に対応するカットオフ周波数をもつ帯域通過フィルタを表していると見なすことができる。したがって、必要とされるMDCTビンのみが伝送される。デコード図15は、MDCT処理を使った帯域幅デコードまたは再構成を示している。ここでは、帯域幅制限されたトラック領域のHOA係数が当該トラックのフル帯域幅に再構成される。この帯域幅再構成は、時間的にインターリーブ解除されたHOA係数のバッファ内容を並列に処理する。ここで、各バッファは係数CnmのTrackRegionLastBin-TrackRegionFirstBin1個のMDCTビンを含む。欠けている周波数領域の追加ステップまたは段1541ないし154Mは、k<TrackRegionFirstBinおよびk>TrackRegionLastBinの欠けているMDCTビンを0を使って受領されたMDCTビンを補完することによって、サイズFramePacketLengthの完全なMDCTバッファ内容を再構成する。その後、時間領域のHOA係数Cnmを再構成するために、対応する逆MDCTステップまたは段1531ないし153Mにおいて逆MDCTが実行される。逆MDCTは、FramePacketLength個のMDCTビンがFramePacketLengthの2倍の数の時間領域係数に変換される合成フィルタバンクと解釈されることができる。しかしながら、時間領域サンプルの完全な再構成は、エンコーダにおいて使用された窓関数wの乗算と、現在のバッファ内容の前半と前のバッファ内容の後半の重複加算overlapaddとを必要とする。逆MDCTは次式によって定義される。MDCTと同様に、逆MDCTは逆高速フーリエ変換を使って実装できる。MDCT窓掛けステップまたは段1521ないし152Mは、TrackRegionWindowTypeによって定義される窓関数を、再構成された時間領域係数に乗算する。後続のバッファ1511ないし151Mは、FramePacketSize個の時間領域係数を再構成するために、現在のトラックパケットバッファ内容の前半を直前のトラックパケットバッファ内容の後半に加える。現在のトラックパケットバッファ内容の後半は、次のトラックパケットの処理のために保存される。この重複加算処理は、両バッファ内容の逆のエイリアシング成分を除去する。複数フレームHOAファイルについては、エンコーダは、新しいフレームの先頭における重複加算手順のために前のフレームの最後のバッファ内容を使うことを禁止される。したがって、フレーム境界においてまたは新しいフレームの先頭においては、重複加算バッファ内容が欠けていることになり、フレームの最初のトラックパケットの再構成が、第二のトラックパケットにおいて実行されることができる。それにより、帯域幅削減のない処理経路に比べ、一フレームパケットおよび一つの余計なトラックパケットのデコードの遅延が導入される。この遅延は、図13との関連で述べたインターリーブステップ/段によって対処される。