特表 2024-537429 環境内の音声を表すビットストリーム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-10-10

(54)【発明の名称】環境内の音声を表すビットストリーム

(51)【国際特許分類】

   G10L 19/00 20130101AFI20241003BHJP

   H04S 7/00 20060101ALI20241003BHJP

【ＦＩ】

G10L19/00 330B

H04S7/00 320

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024523595

(86)(22)【出願日】2022-10-20

(85)【翻訳文提出日】2024-04-19

(86)【国際出願番号】 EP2022079285

(87)【国際公開番号】W WO2023072739

(87)【国際公開日】2023-05-04

(31)【優先権主張番号】21204639.5

(32)【優先日】2021-10-26

(33)【優先権主張国・地域又は機関】EP

(81)【指定国・地域】

(71)【出願人】

【識別番号】590000248

【氏名又は名称】コーニンクレッカ フィリップス エヌ ヴェ

【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ．

【住所又は居所原語表記】Ｈｉｇｈ Ｔｅｃｈ Ｃａｍｐｕｓ ５２， ５６５６ ＡＧ Ｅｉｎｄｈｏｖｅｎ，Ｎｅｔｈｅｒｌａｎｄｓ

(74)【代理人】

【識別番号】110001690

【氏名又は名称】弁理士法人Ｍ＆Ｓパートナーズ

(72)【発明者】

【氏名】コッペンス イェルーン ジェラルドゥス ヘンリクス

【テーマコード（参考）】

5D162

【Ｆターム（参考）】

5D162AA06

5D162AA07

5D162AA09

5D162AA11

5D162CC19

5D162CC36

5D162CD07

5D162DA16

(57)【要約】

（符号化）装置は、環境内の音源を表す複数の音声要素の音声データのメタデータを生成するメタデータ生成器２０３を含む。メタデータは、環境の音響環境データを含み、音響環境データは、環境内の音源の音の伝播影響を与える特性を記述する。音響環境データの少なくとも一部は、環境内の複数のリスニングポーズに適用可能であり、特性は、静的特性および動的特性の両方を含む。ビットストリーム生成器２０５は、メタデータを含むビットストリームを生成し、ビットストリームは多くの場合、環境内の音源の音声要素を表す音声データをさらに含む。復号装置は、ビットストリームを受信する受信機と、音響環境データおよび音声要素の音声データに基づいて音声環境の音声をレンダリングするレンダラーとを含み得る。

【特許請求の範囲】

【請求項1】

ビットストリームを生成するための装置であって、前記装置は、
環境内の音源を表す複数の音声要素の音声データのメタデータを生成するメタデータ生成器であって、前記メタデータは前記環境の音響環境データを含み、前記音響環境データは、前記環境内の前記音源の音の伝播に影響を及ぼす特性を記述し、前記音響環境データの少なくとも一部は、前記環境内の複数のリスニングポーズに適用可能であり、前記特性は静的特性および動的特性の両方を含む、メタデータ生成器と、
前記メタデータを含む前記ビットストリームを生成するビットストリーム生成器とを備える、装置。

【請求項2】

前記音響環境データは、音の伝播に影響を及ぼす前記特性のうちの少なくとも１つの特性の特性値の表現の少なくとも一部のデータフォーマットを記述するデータグループと、前記表現を使用して少なくとも１つの特性値を記述するデータをそれぞれが含む複数のデータグループとを含む、請求項１に記載の装置。

【請求項3】

前記音響環境データは、周波数グリッドを記述するデータグループと、前記周波数グリッドを使用して、前記特性のうちの周波数依存特性を記述するデータをそれぞれが含む複数のデータグループとを含み、前記ビットストリームは、前記周波数グリッドを記述する前記データグループを前記ビットストリームが含むか否かを示すインジケータを含み、前記データグループは、前記周波数グリッドを記述するデータのフォーマットのインジケーションを含み、前記データグループは、
所定のデフォルトグリッドを示すデータと、
前記周波数グリッドの少なくともいくつかの部分範囲の開始周波数および周波数範囲を示すデータと、
個別の周波数を示すデータと
のうちの少なくとも１つを含む、請求項１または２に記載の装置。

【請求項4】

前記音響環境データは、向き特性を表すための向き表現フォーマットを記述するデータグループと、前記向き表現フォーマットを使用して、前記特性のうちの向き特性を記述するデータを含む少なくとも１つのデータグループとを含み、前記データグループは、
所定のデフォルト向き表現を示すデータと、
所定の角度のセットを示すデータと、
量子化グリッド上で角度を示すデータと
のうちの少なくとも１つを含む、請求項１から３のいずれか一項に記載の装置。

【請求項5】

前記音響環境データは、音の伝播に影響を及ぼす前記特性のうちの第１の特性の値を表す第１のビットのための第１のデータフィールドと、前記第１の特性の前記値を表す第２のビットのための拡張データを前記音響環境データが含むか否かを示す第２のデータフィールドとを含む、請求項１から４のいずれか一項に記載の装置。

【請求項6】

前記第２のビットは、前記第１の特性が取り得る値の範囲を拡張する、請求項５に記載の装置。

【請求項7】

前記第２のビットは、前記第１の特性が取り得る値の分解能を高める、請求項５または６に記載の装置。

【請求項8】

前記メタデータ生成器は、前記環境が空間的に制約された環境であることを示すグローバルインジケータを含むように前記音響環境データを生成し、前記メタデータ生成器は、前記環境が空間的に制約されていることを示す前記グローバルインジケータについてのデータ値のための所定の制限付きフォーマットに従うように、前記音響環境データのデータ値を制限する、請求項１から７のいずれか一項に記載の装置。

【請求項9】

前記音響環境データは、少なくとも第１の音声要素のアニメーションインジケーションを含み、前記アニメーションインジケーションは、前記第１の音声要素の少なくとも１つの特性が時間間隔中に変化するかを示し、前記第１の音声要素が少なくとも１つの変化する特性を有することを示すアニメーションインジケーションのために、前記音響環境データは、前記少なくとも１つの変化する特性の変動を記述するデータを含む、請求項１から８のいずれか一項に記載の装置。

【請求項10】

前記音声要素は複数の音響効果要素を含み、前記音響環境データは、ユーザによって制御される前記環境への変化を、前記複数の音響効果要素のうちの第１の音響効果要素とリンクさせるデータを含む、請求項１から９のいずれか一項に記載の装置。

【請求項11】

前記音響環境データは複数の連続したデータセットとして配置され、各データセットは、時間間隔にわたるデータを含み、前記連続したデータセットのうちの第１のデータセットは、音に影響を及ぼす前記特性のうちの少なくとも１つの特性の第１の特性値と、前記第１のデータセットによって表される時間間隔内の時間を示す、前記第１の特性値の時間インジケーションとを含む、請求項１から１０のいずれか一項に記載の装置。

【請求項12】

前記音響環境データは複数の連続したデータセットとして配置され、各データセットは、時間間隔にわたるデータを含み、前記ビットストリーム生成器は、音の伝播に影響を及ぼす前記特性のうちの第１の特性の特性値が、第１のデータセットによって表される時間間隔内のデフォルト時間のために提供されているかを判定し、提供されている場合は、時間インジケーションなしで前記第１のデータセット内に第１の特性値を含め、提供されてない場合は、前記第１の特性値のための時間インジケーションとともに前記第１のデータセット内に前記第１の特性値を含める、請求項１から１１のいずれか一項に記載の装置。

【請求項13】

第１の音声要素の前記音響環境データは、音の伝播に影響を及ぼす前記特性のうちの第１の特性の第１の特性値についての第１の適用可能性領域および第２の適用可能性領域のインジケーションを含み、前記第１の適用可能性領域は、前記第１の特性値が適用される前記第１の音声要素の位置の領域を示し、前記第２の適用可能性領域は、前記第１の特性値が適用されるリスニング位置の領域を示す、請求項１から１２のいずれか一項に記載の装置。

【請求項14】

レンダリング音声を生成するための装置であって、前記装置は、
環境内の音源を表す複数の音声要素の音声データを受信する第１の受信機と、
前記環境内の音源を表す前記複数の音声要素の前記音声データのメタデータを含むビットストリームを受信する第２の受信機であって、前記メタデータは前記環境の音響環境データを含み、前記音響環境データは、前記環境内の前記音源の音の伝播に影響を及ぼす特性を記述し、前記音響環境データの少なくとも一部は、前記環境内の複数のリスニングポーズに適用可能であり、前記特性は静的特性および動的特性の両方を含む、第２の受信機と、
前記音声データおよび前記音響環境データに応答して前記環境の出力音声データを生成するレンダラーとを備える、装置。

【請求項15】

環境内の音源を表す複数の音声要素の音声データのメタデータを含むビットストリームであって、前記メタデータは前記環境の音響環境データを含み、前記音響環境データは、前記環境内の前記音源の音の伝播に影響を及ぼす特性を記述し、前記音響環境データの少なくとも一部は、前記環境内の複数のリスニングポーズに適用可能であり、前記特性は静的特性および動的特性の両方を含む、ビットストリーム。

【請求項16】

ビットストリームを生成する方法であって、前記方法は、
環境内の音源を表す複数の音声要素の音声データのメタデータを生成するステップであって、前記メタデータは前記環境の音響環境データを含み、前記音響環境データは、前記環境内の前記音源の音の伝播に影響を及ぼす特性を記述し、前記音響環境データの少なくとも一部は、前記環境内の複数のリスニングポーズに適用可能であり、前記特性は静的特性および動的特性の両方を含む、生成するステップと、
前記メタデータを含む前記ビットストリームを生成するステップとを含む、方法。

【請求項17】

レンダリング音声を生成する方法であって、前記方法は、
環境内の音源を表す複数の音声要素の音声データを受信するステップと、
前記環境内の音源を表す前記複数の音声要素の前記音声データのメタデータを含むビットストリームを受信するステップであって、前記メタデータは前記環境の音響環境データを含み、前記音響環境データは、前記環境内の前記音源の音の伝播に影響を及ぼす特性を記述し、前記音響環境データの少なくとも一部は、前記環境内の複数のリスニングポーズに適用可能であり、前記特性は静的特性および動的特性の両方を含む、受信するステップと、
前記音声データおよび前記音響環境データに応答して前記環境の出力音声データを生成するステップとを含む、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、音声環境を表すビットストリーム、ならびにそのようなビットストリームを生成するための装置およびそのようなビットストリームを処理するための装置に関し、特に、限定はされないが、例えば仮想現実アプリケーション用の仮想音声環境を表すビットストリームに関する。

【背景技術】

【0002】

近年、視聴覚コンテンツに基づく体験の多様性および範囲が大きく増大しており、そのようなコンテンツを利用および消費する新しいサービスや方法が継続的に開発および導入されている。特に、関与性や没入感がより高い体験をユーザに提供するために、多くの空間的インタラクティブサービス、アプリケーション、および体験が開発されている。

【0003】

このようなアプリケーションの例としては、仮想現実（ＶＲ）アプリケーション、拡張現実（ＡＲ）アプリケーション、および急速に主流になりつつある複合現実（ＭＲ）アプリケーションがあり、多くのソリューションが消費者市場を標的としている。また、様々な標準化団体によって様々な規格が開発されている。そのような標準化活動は、例えばストリーミング、ブロードキャスト、およびレンダリングなど、ＶＲ／ＡＲ／ＭＲシステムの様々な側面のための規格を積極的に開発している。

【0004】

ＶＲアプリケーションは、異なる世界／環境／シーンにいるユーザに対応するユーザ体験を提供する傾向がある一方、ＡＲ（複合現実ＭＲを含む）アプリケーションは、追加情報または仮想オブジェクトもしくは情報が追加された現在の環境にいるユーザに対応するユーザ体験を提供する傾向がある。したがって、ＶＲアプリケーションは完全に没入型の人工世界／シーンを提供する傾向がある一方、ＡＲアプリケーションは、ユーザが物理的に存在する現実のシーンに重ねられた部分的に人工の世界／シーンを提供する傾向がある。しかし、これらの用語はしばしば同義で使用され、大きく重複している。以下では、仮想現実／ＶＲという用語は仮想現実および拡張／複合現実の両方を表すために使用される。

【0005】

例えばＶＲ体験を提供するためにユーザ側の適応を可能にする柔軟な表現を提供できるように、環境、特に音声環境を表す視聴覚データ、特に音声データを通信することは、非常に困難なタスクである。通信されるデータは、（仮想）リスニング位置の変化および環境自体の変化を反映する動的な体験をレンダリングするためにローカル使用できるように、環境を表すことが好ましい。

【0006】

このような環境を表すデータを効率的に通信するための有利なアプローチを得るために、多くの研究が行われてきた。適切なデータストリームおよびフォーマットに関する様々な提案がなされており、そのほとんどが、個々の音源が別々に提示され、音源の位置などの様々な特性を記述するメタデータに関連づけられている、個別化されたモデルを含む。また、残響や減衰などを記述するデータなど、音声環境を記述する一般的データが提供される可能性がある。

【0007】

しかし、そのような情報の効率的な（例えば、低減されたデータレート）通信を提供するビットストリームフォーマットを定義することは非常に困難であり、有利なアプローチを実現するには、多くの問題、特性、およびトレードオフを慎重に検討し、これらのバランスを取る必要がある。ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）は、ＶＲおよび同様の体験に適したビットストリーム用のＭＰＥＧ－Ｉと呼ばれる規格を開発するための標準化アプローチを開始した。

【0008】

したがって、ＶＲおよびＡＲなどの没入型アプリケーションおよびサービスにおいて音声をサポートするための改善されたアプローチおよびデータフォーマット／ビットストリームは有利であろう。特に、動作の向上、柔軟性の増加、複雑さの軽減、実装の容易化、音声体験の向上、複雑さの軽減、計算負荷の軽減、音声品質の向上、データレートの低下、トレードオフの向上、ならびに／またはパフォーマンスおよび／もしくは動作の向上を可能にするアプローチ／ビッドストリーム／フォーマットは有利であろう。

【発明の概要】

【0009】

したがって、本発明は、上記欠点の１つ以上を単独で、または任意の組み合わせで好適に緩和、低減、または排除することを目的とする。

【0010】

本発明の態様および任意選択の特徴によれば、ビットストリームを生成するための装置が提供され、装置は、環境内の音源を表す複数の音声要素の音声データのメタデータを生成するメタデータ生成器（２０３）であって、メタデータは環境の音響環境データを含み、音響環境データは、環境内の音源の音の伝播に影響を及ぼす特性を記述し、音響環境データの少なくとも一部は、環境内の複数のリスニングポーズに適用可能であり、特性は静的特性および動的特性の両方を含む、メタデータ生成器と、メタデータを含むビットストリームを生成するビットストリーム生成器とを含む。

【0011】

このアプローチは、没入型で、柔軟で、かつ変化に富んだ視聴覚アプリケーションを含む多くのアプリケーション（例えば、多くのＶＲおよびＡＲアプリケーション）のパファーマンスおよび動作を改善することができる。このアプローチは、多くの場合において異なる要望間のトレードオフ、例えば、環境の正確、完全、かつ／または動的なデータを提供するという要望と、低いデータレートのビットストリームを提供するという要望との間のトレードオフを改善することができる。このアプローチは、多くの場合において高度な柔軟性を提供し、レンダリング側の適合およびカスタマイズを容易にし、改善し、さらには可能にする可能性がある。このアプローチは、環境の音声のレンダリングを容易化および／または改善する可能性があり、具体的には、変化する環境および／または変化するリスニング位置の動的レンダリングを容易化および／または改善する可能性がある。

【0012】

このアプローチは、具体的には、動的アプリケーションに特に適した、注意深く適合された視聴覚ビットストリームを提供する可能性があり、ビットストリームは、注意深く選択され、かつ少なくとも部分的に最適化された、音声環境のデータ表現を提供する。このデータ表現は、音源および環境の音響特性の両方を含み、場合によってはさらに環境内の個別のオブジェクトを含む。

【0013】

一部の実施形態では、装置はさらに、環境内の音源を表す複数の音声要素の音声データを生成するように構成された音声データ生成器を含み得、ビットストリーム生成器は、ビットストリーム内に音声データを含めるように構成され得る。

【0014】

静的特性は、（少なくとも特性値が対象とする時間間隔では）時不変の特性であり得る。動的特性は、（少なくとも特性値が対象とする時間間隔では）時変の特性であり得る。

【0015】

多くの実施形態では、少なくとも１つの特性は位置および向きに依存する。多くの実施形態では、少なくとも１つの特性の音響環境データは、位置および／または向き依存性を示す。位置および／または向き依存性は、音源の向きおよび／もしくは位置、ならびに／またはリスナーポーズの向きおよび／または位置への依存性であり得る。

【0016】

一部の実施形態では、ビットストリーム内の音響環境データは、複数の一連のデータグループに分割され、少なくとも一部のグループは、それぞれ、音の伝播に影響を及ぼす特性の特性値を提供する。

【0017】

本発明の任意選択の特徴によれば、音響環境データは、音の伝播に影響を及ぼす特性のうちの少なくとも１つの特性の特性値の表現の少なくとも一部のデータフォーマットを記述するデータグループと、表現を使用して少なくとも１つの特性値を記述するデータをそれぞれが含む複数のデータグループとを含む。

【0018】

一部の実施形態では、音響環境データは、音の伝播に影響を及ぼす特性のうちの特性のデータフォーマットを記述するデータグループと、データフォーマットに従ってその特性の特性値を記述するデータをそれぞれが含む複数のデータグループとを含む。

【0019】

データグループは１つ以上のデータ値であり得、具体的にはビットのセットであり得る。データグループはデータのセットであり得、具体的にはビットストリームの１つ以上のデータフィールドであり得る。

【0020】

一部の実施形態では、音響環境データは、周波数グリッドを記述するデータグループと、周波数グリッドを使用して特性のうちの周波数依存特性を記述するデータをそれぞれが含む複数のデータグループとを含む。

【0021】

周波数グリッドは、例えば周波数部分範囲の中心周波数を定義することによって、周波数範囲を周波数部分範囲に細分化したものであってもよい。

【0022】

一部の実施形態では、ビットストリームは、ビットストリームが、周波数グリッドを記述するデータグループを含むか否かを示すインジケータを含む。

【0023】

一部の実施形態では、データグループは、周波数グリッドを記述するデータのフォーマットのインジケーションを含む。

【0024】

一部の実施形態では、音響環境データは、周波数グリッドを記述するデータグループと、周波数グリッドを使用して、特性のうちの周波数依存特性を記述するデータをそれぞれが含む複数のデータグループとを含み、ビットストリームは、周波数グリッドを記述するデータグループをビットストリームが含むか否かを示すインジケータを含み、データグループは、周波数グリッドを記述するデータのフォーマットのインジケーションを含む。

【0025】

一部の実施形態では、データグループは、所定のデフォルトグリッドを示すデータと、周波数グリッドの少なくともいくつかの部分範囲の開始周波数および周波数範囲を示すデータと、個別の周波数を示すデータとのうちの少なくとも１つを含む。

【0026】

データグループのデータによって示される少なくとも１つの部分範囲または個別の周波数は、オクターブバンドの分数と位置合わせされる。

【0027】

本発明の任意選択の特徴によれば、音響環境データは、周波数グリッドを記述するデータグループと、周波数グリッドを使用して、特性のうちの周波数依存特性を記述するデータをそれぞれが含む複数のデータグループとを含み、ビットストリームは、周波数グリッドを記述するデータグループをビットストリームが含むか否かを示すインジケータを含み、データグループは、周波数グリッドを記述するデータのフォーマットのインジケーションを含み、データグループは、所定のデフォルトグリッドを示すデータと、周波数グリッドの少なくともいくつかの部分範囲の開始周波数および周波数範囲を示すデータと、個別の周波数を示すデータとのうちの少なくとも１つを含む。

【0028】

一部の実施形態では、音響環境データは、向き特性を表すための向き表現フォーマットを記述するデータグループと、向き表現フォーマットを使用して、特性のうちの向き特性を記述するデータを含む少なくとも１つのデータグループとを含む。

【0029】

ビットストリームは、向き表現フォーマットを記述するデータグループをビットストリームが含むか否かを示すインジケータを含む可能性がある。

【0030】

一部の実施形態では、データグループは、所定のデフォルト向き表現を示すデータと、所定の角度のセットを示すデータと、量子化グリッド上で角度を示すデータと、のうちの少なくとも１つを含む。

【0031】

本発明の任意選択の特徴によれば、音響環境データは、向き特性を表すための向き表現フォーマットを記述するデータグループと、向き表現フォーマットを使用して、特性のうちの向き特性を記述するデータを含む少なくとも１つのデータグループとを含み、データグループは、所定のデフォルト向き表現を示すデータと、所定の角度のセットを示すデータと、量子化グリッド上で角度を示すデータとのうちの少なくとも１つを含む。

【0032】

本発明の任意選択の特徴によれば、音響環境データは、音の伝播に影響を及ぼす特性のうちの第１の特性の値を表す第１のビットのための第１のデータフィールドと、第１の特性の値を表す第２のビットのための拡張データを音響環境データが含むか否かを示す第２のデータフィールドとを含む。

【0033】

本発明の任意選択の特徴によれば、第２のビットは、第１の特性が取り得る値の範囲を拡張する。

【0034】

第２のビットは、第１の特性の値を表す、データワードの第１のビットよりも上位のビットであってもよい。

【0035】

本発明の任意選択の特徴によれば、第２のビットは、第１の特性が取り得る値の分解能を高める。

【0036】

第２のビットは、第１の特性の値を表す、データワードの第１のビットよりも下位のビットであってもよい。第２のビットは、第１の特性が取り得る値の精度を拡張し得る。

【0037】

一部の実施形態では、第１の特性は、時間的特性、空間的特性、量、ゲイン特性、容量特性、周波数特性、インデックス特性、および識別特性を含む群から選択される特性である。

【0038】

本発明の任意選択の特徴によれば、メタデータ生成器（２０３）は、環境が空間的に制約された環境であることを示すグローバルインジケータを含むように音響環境データを生成し、メタデータ生成器は、環境が空間的に制約されていることを示すグローバルインジケータについてのデータ値のための所定の制限付きフォーマットに従うように、音響環境データの（少なくとも１つの）データ値を制限する。

【0039】

空間的に制限された環境は、閾値未満の空間的広がりを有する環境であり得る。所定の制限付きフォーマットは、環境が空間的に制限された環境でない場合にビットストリームに使用されるデータフォーマットよりも少ないビットを使用する、音の伝播に影響する特性の少なくともいくつかの値のデータフォーマットであり得る。

【0040】

グローバルインジケータは任意選択のインジケータであり得る。一部の実施形態では、グローバルインジケータは、環境が空間的に制約された環境であるか、または空間的に制約がより少ない環境（または空間的な制約がない環境）であるかを示し得る。

【0041】

一部の実施形態では、音響環境データは、少なくとも第１の音声要素のアニメーションインジケーションを含み、アニメーションインジケーションは、第１の音声要素の少なくとも１つの特性が時間間隔中に変化するか否かを示す。

【0042】

本発明の任意選択の特徴によれば、音響環境データは、少なくとも第１の音声要素のアニメーションインジケーションを含み、アニメーションインジケーションは、第１の音声要素の少なくとも１つの特性が時間間隔中に変化するかを示し、第１の音声要素が少なくとも１つの変化する特性を有することを示すアニメーションインジケーションのために、音響環境データは、少なくとも１つの変化する特性の変動を記述するデータを含む。

【0043】

一部の実施形態では、アニメーションインジケーションが、第１の音声要素の少なくとも１つの特性が時間間隔中に変化することを示す場合、音響環境データはさらに、少なくとも２つの特性のそれぞれのためのさらなるアニメーションインジケーションを含み、さらなるアニメーションインジケーションは、対応する特性がアニメーション化されているか否かを示し、アニメーションインジケーションが、時間間隔中に変化する第１の音声要素の特性が存在しないことを示す場合、音響環境データは、上記少なくとも２つの特性のさらなるアニメーションインジケーションを含まない。

【0044】

一部の実施形態では、アニメーションインジケーションが、第１の音声要素の少なくとも１つの特性が時間間隔中に変化することを示す場合、少なくとも２つの特性のためのさらなるアニメーションインジケーションが存在し、さらなるアニメーションインジケーションは、対応する特性がアニメーション化されているか否かを示し、アニメーションインジケーションが、時間間隔中に変化する、第１の音声要素の少なくとも１つの特性が存在しないことを示す場合、アニメーションインジケーションは除外される。

【0045】

一部の実施形態では、音響環境データは、時間間隔中に変化する少なくとも１つの特性の少なくとも２つの値と、これらの少なくとも２つの値の間を補間するための時間的補間を記述する補間データとを含む。

【0046】

本発明の任意選択の特徴によれば、音声要素は複数の音響効果要素を含み、音響環境データは、ユーザによって制御される環境への変化を、複数の音響効果要素のうちの第１の音響効果要素とリンクさせるデータを含む。

【0047】

一部の実施形態では、音響環境データは連続したデータセットとして配置され、各データセットは時間間隔にわたるデータを含む。

【0048】

時間間隔はデータセットごとに異なる。

【0049】

本発明の任意選択の特徴によれば、音響環境データは複数の連続したデータセットとして配置され、各データセットは、時間間隔にわたるデータを含み、連続したデータセットのうちの第１のデータセットは、音に影響を及ぼす特性のうちの少なくとも１つの特性の第１の特性値と、第１のデータセットによって表される時間間隔内の時間を示す、第１の特性値の時間インジケーションとを含む。

【0050】

一部の実施形態では、連続したデータセットのうちの第１のデータセットは、音に影響を及ぼす特性のうちの少なくとも１つの特性の少なくとも２つの特性値と、これらの少なくとも２つの特性値の時間インジケーションとを含み、時間インジケーションは、第１のデータセットによって表される時間間隔内の時間を示す。

【0051】

本発明の任意選択の特徴によれば、音響環境データは複数の連続したデータセットとして配置され、各データセットは、時間間隔にわたるデータを含み、ビットストリーム生成器は、音の伝播に影響を及ぼす特性のうちの第１の特性の特性値が、第１のデータセットによって表される時間間隔内のデフォルト時間のために提供されているかを判定し、そうである場合は、時間インジケーションなしで第１のデータセット内に第１の特性値を含め、そうでない場合は、第１の特性値のための時間インジケーションとともに第１のデータセット内に第１の特性値を含める。

【0052】

一部の実施形態では、音響環境データは、環境の音声をレンダリングするために必要なデータを全て含むいくつかの完全なレンダリングデータセットと、環境の音声をレンダリングするために他のデータセットからのデータを追加で必要とするいくつかの部分的レンダリングデータセットとを含む。

【0053】

一部の実施形態では、環境の少なくとも一部の要素の音響環境データは、環境のシーングラフの要素の識別データおよび親識別データを含む。

【0054】

これらの少なくとも一部の要素は、例えば、オブジェクト、音源（音声要素）、および／または環境の音響特性であり得る。

【0055】

本発明の任意選択の特徴によれば、第１の音声要素の音響環境データは、音の伝播に影響を及ぼす特性のうちの第１の特性の第１の特性値についての第１の適用可能性領域および第２の適用可能性領域のインジケーションを含み、第１の適用可能性領域は、第１の特性値が適用される第１の音声要素の位置の領域を示し、第２の適用可能性領域は、第１の特性値が適用されるリスニング位置の領域を示す。

【0056】

本発明の態様および任意選択の特徴によれば、レンダリング音声を生成するための装置が提供され、装置は、環境内の音源を表す複数の音声要素の音声データを受信する第１の受信機（３０３）と、環境内の音源を表す複数の音声要素の音声データのメタデータを含むビットストリームを受信する第２の受信機（３０５）であって、メタデータは環境の音響環境データを含み、音響環境データは、環境内の音源の音の伝播に影響を及ぼす特性を記述し、音響環境データの少なくとも一部は、環境内の複数のリスニングポーズに適用可能であり、特性は静的特性および動的特性の両方を含む、第２の受信機と、音声データおよび音響環境データに応答して環境の出力音声データを生成するレンダラー（３０７）とを含む。

【0057】

本発明の態様および任意選択の特徴によれば、環境内の音源を表す複数の音声要素の音声データのメタデータを含むビットストリームが提供され、メタデータは環境の音響環境データを含み、音響環境データは、環境内の音源の音の伝播に影響を及ぼす特性を記述し、音響環境データの少なくとも一部は、環境内の複数のリスニングポーズに適用可能であり、特性は静的特性および動的特性の両方を含む。

【0058】

本発明の態様および任意選択の特徴によれば、ビットストリームを生成する方法が提供され、方法は、環境内の音源を表す複数の音声要素の音声データのメタデータを生成するステップであって、メタデータは環境の音響環境データを含み、音響環境データは、環境内の音源の音の伝播に影響を及ぼす特性を記述し、音響環境データの少なくとも一部は、環境内の複数のリスニングポーズに適用可能であり、特性は静的特性および動的特性の両方を含む、生成するステップと、メタデータを含むビットストリームを生成するステップと、を含む。

【0059】

本発明の態様および任意選択の特徴によれば、レンダリング音声を生成する方法が提供され、方法は、環境内の音源を表す複数の音声要素の音声データを受信するステップと、環境内の音源を表す複数の音声要素の音声データのメタデータを含むビットストリームを受信するステップであって、メタデータは環境の音響環境データを含み、音響環境データは、環境内の音源の音の伝播に影響を及ぼす特性を記述し、音響環境データの少なくとも一部は、環境内の複数のリスニングポーズに適用可能であり、特性は静的特性および動的特性の両方を含む、受信するステップと、音声データおよび音響環境データに応答して環境の出力音声データを生成するステップと、を含む。

【0060】

本発明の上記および他の側面、特徴、および利点は、以下に記載される実施形態を参照しながら説明され、明らかになるであろう。

【図面の簡単な説明】

【0061】

以下、本発明の単なる例に過ぎない実施形態について、以下の図面を参照しながら説明する。

【図1】図１は、視聴覚分配システムの例を示す。

【図2】図２は、本発明の一部の実施形態に係る符号化装置の要素の例を示す。

【図3】図３は、本発明の一部の実施形態に係る復号装置の要素の例を示す。

【図4】図４は、本発明の一部の実施形態に係るビットストリームのデータ構造の例を示す。

【図5】図５は、本発明の一部の実施形態に係る、ビットストリーム内で表される変化する特性値の例を示す。

【図6】図６は、本発明の一部の実施形態に係るビットストリームのデータ構造を示す。

【発明を実施するための形態】

【0062】

以下の説明は、仮想現実（ＶＲ）アプリケーションなどの視聴覚アプリケーションに焦点を当てるが、説明される原理および概念は他の多くのアプリケーションおよび実施形態でも使用できることが理解されるであろう。

【0063】

以下の説明は、環境の音声の表現を提供するビットストリームの生成に焦点を当てる。多くの例では、音声表現は視覚環境の表現によって補完され、ＶＲアプリケーションは、ユーザに提示する音声および映像の両方を生成するように構成されている。音声表現が、仮想シーン／環境の視覚表現を補足するか、またはビットストリームが、例えば、現実世界もしくはハイブリッド環境の表現を提供し得る。ビットストリームは、例えば音源やオブジェクトなどの環境／シーン内の個々の要素を表すデータを含む可能性がある。さらに、一般的な音響または視覚データ（例えば、残響や背景色などを記述するデータ）など、より一般的な情報が提供されてもよい。

【0064】

しかし、説明される原理および概念が他の多くのアプリケーションおよび実施形態でも使用できることが理解されるであろう。

【0065】

仮想現実体験は、コンピュータなどのデバイスが、仮想シーン用の３次元音声および映像をレンダリングし、それをユーザに提示することにより、ユーザに対して仮想体験を生成することを可能にし得る。ユーザは通常、動き回る可能性があるため、観察者／リスニングポーズが動的に変化する可能性がある。多くの実施形態では、仮想シーン／環境は、例えばオブジェクトが移動するか、またはその形状を変化させ、複数の音源が異なる時点で音声を発する動的なシーンであってもよい。

【0066】

当該技術分野では、配置およびポーズという用語が、位置および／または方向／向きを表す一般的な用語として使用される。例えばオブジェクト、カメラ、頭部、またはビューの位置および方向／向きの組み合わせがポーズまたは配置と呼ばれ得る。したがって、配置またはポーズのインジケーションは６つの値／成分／自由度を備え得る。各値／成分は典型的には、対応するオブジェクトの位置／場所または方向／向きの個々の特性を記述する。当然ながら、多くの状況において、配置またはポーズはより少ない成分で考慮または表現され得、例えば、１つ以上の成分が一定または無関係であると見なされる場合が該当する（例えば、全てのオブジェクトが同じ高さを有し、かつ向きが水平であると見なされる場合、４つの成分でオブジェクトのポーズを完全に表現することが可能であり得る）。以下、ポーズという用語は１～６個（可能な最大自由度に対応）の値で表すことができる位置および／または向きを指すために使用される。ポーズという用語は、配置という用語に置き換えることができる。ポーズという用語は、位置および／または向きという用語に置き換えることができる。ポーズという用語は、位置および向きという用語（ポーズが位置および向きの両方の情報を提供する場合）、位置という用語（ポーズが位置の情報（場合によってはそれのみ）を提供する場合）、または向き（ポーズが向きの情報（場合によってはそれのみ）を提供する場合）に置き換えることができる。

【0067】

多くのアプローチにおいて、ＶＲアプリケーションは例えば、リモートＶＲサーバを一切使用しないか、または、場合によってはリモートＶＲサーバへのアクセスすら有さないスタンドアロンデバイスによって視聴者にローカルに提供され得る。しかし、他のアプリケーションでは、ＶＲアプリケーションはリモートサーバまたは中央サーバから受信したデータに基づき得る。例えば、リモート中央サーバから音声または視覚データがＶＲデバイスに提供され、ローカル処理されて、所望のＶＲ体験が生成されてもよい。

【0068】

図１は、リモートＶＲクライアントデバイス１０１が、例えばインターネットなどのネットワーク１０５を介してＶＲサーバ１０３と連絡するＶＲシステムの例を示す。サーバ１０３は、多数存在する可能性があるクライアントデバイス１０１を同時にサポートするように構成され得る。

【0069】

ＶＲサーバ１０３は、例えば、仮想環境の要素、および仮想オブジェクトを定義するデータをクライアントデバイス１０１に送信することによって、仮想現実体験をサポートすることができる。データは、ユーザに提示可能なグラフィックスを生成するためにクライアントデバイス１０１によって使用され得る多数の仮想オブジェクトの視覚的特徴および幾何学的特性を具体的に記述し得る。一部の実施形態では、データはまた、ユーザに提示可能な様々な情報を含み得る。さらに、サーバ１０３は、ユーザ体験、特に没入感をさらに高める可能性がわる仮想サウンド／音声をローカルに生成するために使用できる音声データをクライアントデバイス１０３に提供することができる。

【0070】

以下の説明は、音響シーンおよび環境の表現（典型的には、音源の表現および環境の音響特性の表現の両方を含む）を提供する音声ビットストリームの生成に焦点を当てる。

【0071】

図２は、ビットストリームを生成する装置の一例を示しており、具体的には、装置は図１のサーバ１０３であってもよい（に含まれてもよい）。装置は、具体的にはエンコーダ／送信機であってもよい。図３は、図２の装置によって生成されたビットストリームなどのビットストリームを受信して処理する装置の一例を示す。図３の装置はデコーダ／受信機であってもよく、具体的には、図１のクライアントデバイス１０１（の一部）であってもよい。以下において、図２の装置はエンコーダとも呼ばれ、図３の装置はデコーダとも呼ばれる。

【0072】

この例では、エンコーダは音声環境を記述するビットストリームを生成する。この具体例では、ビットストリームは、環境内の音源によって生成される音声の音声データと、音響環境を記述するメタデータ（典型的には、個々の音源用のメタデータおよび音響環境用のメタデータの両方を含む）との両方を含む。しかし、一部の実施形態では、音声データおよびメタデータは別々のビットストリームで提供されてもよく、具体的には、音声データ用のメタデータのみを含む別個のビットストリームが生成され、実際の音声データは別のビットストリームで別個に提供されてもよい。実際、一部の実施形態では、音声データは１つのソース／プロバイダから提供され、追加のメタデータは別のソース／プロバイダから提供され得る。

【0073】

エンコーダは、環境内の複数の音源を表す複数の音声要素用の音声データを生成するように構成された音声データ生成器２０１を含む。音声生成器は、例えば、個々の音源もしくは例えばマイクが拾った音を表す音声要素からの音声を記述する受信音声データから音声データを生成するか、または、例えばそのシーンの音声モデルに基づいて、音声データ自体を生成してもよい。一部の実施形態では、音声データ生成器２０１は、例えば、様々な音源からの音声の適切な表現を含むローカルストアから特定の音源用の音声データを抽出することができる。他の実施形態では、代わりにまたは追加で、音声データは、例えばライブ音声を取得するマイク入力から生成されてもよい。

【0074】

音声データ生成器２０１は、任意の適切なデータフォーマットに従うように音声データを生成することができ、任意の適切な符号化および表現などが使用され得る。したがって、音声データは任意の適切な方法で生成され得、任意の適切な方法で音声要素を表し得る。

【0075】

音声要素は、音声オブジェクト、音声クリップ、音声チャネル、一次もしくは高次アンビソニックス（ＦＯＡ、ＨＯＡ）、または他の音声要素であり得る。具体的には、各音声要素は、環境内で生成され得る音声を特徴付ける音声データのセットによって表されてもよい。音声データは一般に、複数の異なる音声要素の音声データのセットを複数組含むように生成され、具体的には、個々の音声要素によって表される複数の異なる音源の音声データのセットを複数組含む。

【0076】

エンコーダは、メタデータを生成するように構成されたメタデータ生成器２０３をさらに含む。メタデータは、環境の音響環境データを含み、音響環境データは、環境内の音源の音の伝播に影響を与える特性を記述する。音響環境データの特性は、環境の音響特性（例えば、残響、反射特性など）、音の伝播に影響を与える可能性がある環境内のオブジェクトの特性（例えば、オブジェクトの位置、向き、サイズ、材料、減衰、反射など）、または音源／音声要素の特性（例えば、位置、向き、サイズ、音量など）を含み得る。

【0077】

ビットストリームは、環境内で知覚される音声に影響を与える様々な特性の特性値のインジケーションを一緒に提供するいくつかのデータシンボル／ビットのデータグループを含み得る。また、様々な他のデータ、例えば、音響環境データの他のデータ用の補助パラメータまたはフォーマットの定義などを提供するデータグループが含まれてもよい。

【0078】

データグループは、データ値／フォーマットなどを示す単純なビットシーケンスであってもよく、または適切な情報を提供するデータのより複雑な組み合わせであってもよい。データグループは、例えば、多くのシナリオにおいて、ビットストリームの１つ以上のデータフィールドに対応するとみなされ得る。データフィールドはサブデータフィールドを含んでもよく、すなわち、それら自体がデータフィールドの組み合わせであるデータフィールドの階層的構成が適用されてもよい。

【0079】

音響環境データは、例えば、音声要素によって表される１つ以上の音源のポーズ（位置および／または向き）、環境または環境内の個々のオブジェクトの音響特性（例えば、（場合によっては周波数に依存する）減衰、残響特性、音波の伝播に影響を与える可能性のあるオブジェクトの形状、吸音、音響反射、音響散乱、音響結合、または音響伝達パラメータなどの材料特性など）、信号リファレンス、リファレンス距離、レンダリング制御フラグ、音響効果特性、ユーザインタラクションメタデータなどを記述するメタデータを含むことができる。

【0080】

音響環境データは、複数のリスニングポーズに適用可能であり得るデータを含み得、具体的には、異なるリスナーポーズ（具体的には、異なる位置および／または向き）に依存するように（リスナーポーズごとに異なるように）、レンダラーが音声要素のレンダリングを適合させるために使用できるデータを含み得る。さらに、音響環境データは、静的特性および動的特性の両方のデータを含み得る。具体的には、音響環境データは、時間に依存せず、少なくとも、データが提供される時間間隔において時不変特性（値）を記述するデータを含むことができる（したがって、そのような特性は静的であり得る）。音響環境データは、時間に依存し、少なくとも、データが提供される時間間隔において時変特性（値）を記述するデータをさらに含むことができる（したがって、そのような特性は動的であり得る）。少なくとも１つの特性について、音響環境データは、特性（の値）の時間変化を記述するデータを含むことができる。特性は、環境内の音源、音声要素、および／または音響伝播／音の伝播のうちの１つの特性であってもよい。

【0081】

エンコーダは、音声データおよびメタデータ（または一部の実施形態ではメタデータのみ）を含むビットストリームを生成するように構成されたビットストリーム生成器２０５をさらに含む。ビットストリームは、後に詳細に説明する特定のデータフォーマットの１つ以上の側面および特徴を満たすように生成され得る。

【0082】

ビットストリーム生成器２０５は、生成されたビットストリームを出力するように構成された出力プロセッサ２０７に結合される。出力プロセッサ２０７は、特定のアプリケーションの要望に応じてビットストリームを通信するために必要な機能を有し得る。例えば、出力プロセッサは、ネットワークインターフェース、無線機能、ＷｉＦｉ回路、インターネット接続機能などを有することができる。

【0083】

図３に示すデコーダは、エンコーダによって生成されたビットストリームを受信するように構成された受信機または入力プロセッサ３０１を含む。入力プロセッサ３０１は、特定のアプリケーションの要望に応じてビットストリームを受信するために必要な機能を有し得る。例えば、入力プロセッサ３０１は、ネットワークインターフェース、無線機能、ＷｉＦｉ回路、インターネット結合機能などを有し得る。多くの実施形態において、入力プロセッサ３０１は、エンコーダの出力プロセッサ２０７の機能に対して補完的な機能を有し得る。

【0084】

入力プロセッサ３０１は、ビットストリームから音声データを抽出するように構成された音声データプロセッサ３０３に結合される。したがって、音声データプロセッサ３０３は、環境の多数の音声要素を表す音声データを抽出し、そして多くの場合、処理するように構成される。通常、各音声要素は環境内の１つ以上の音源に対応し得る。

【0085】

説明されている例では、ビットストリームは、音声要素を記述する音声データを含む。他の実施形態では、音声データはビットストリームに含まれておらず、別のソースから受信されてもよく、例えば場合によっては、デコーダ／クライアントデバイスの内部ソースなどであってもよい。例えば、内部メモリは音声データを保存し得、サーバ１０３は、例えば、環境内で音源が移動する動的なアニメーションを提示するために音声を強化する情報を提供することによって、強化された体験を提供し得る追加のメタデータを提供することができる。一部の実施形態では、入力プロセッサ３０１は、サーバとは異なる外部ソースから音声データを受信するように構成されてもよく、例えば、音声データは、メタデータを提供するサーバ１０３とは異なるサーバによって提供される異なるビットストリームの一部として受信されてもよい。

【0086】

デコーダは、ビットストリームからメタデータを抽出するように構成されたメタデータプロセッサ３０５をさらに含む。したがって、メタデータプロセッサ３０５は、音声要素／環境のメタデータを抽出し、そして多くの場合、処理するように構成される。メタデータプロセッサ３０５は、データを抽出し、メタデータによって記述される特性の１つ、複数、または全てに対して適切な特性値を生成するように構成され得る。

【0087】

この例におけるデコーダは、メタデータおよび特性値に基づいて音声データを処理するプロセッサを有する。具体的には、デコーダは、メタデータによって表される特性のうちの少なくとも１つの特性の値に基づいて１つ以上の音声要素をレンダリングするように構成されたレンダラー３０７を有し得、ここで、特性の値はメタデータから決定される。通常、レンダラー３０７は、メタデータに基づいて１つ以上の音声要素をレンダリングすることによって、環境に対応する音声シーンをレンダリングするように構成され得、例えば、メタデータによって決定されるポーズ（およびその変化）、環境および環境内のオブジェクトを記述するメタデータに基づく周波数依存減衰、メタデータによって記述される環境の残響特性を表す残響などが使用され得る。

【0088】

環境データおよびコンテキストデータに基づいて音声データをレンダリングするための多くのアルゴリズム、アプローチ、および技術が当業者に知られており（例えば、ＨＲＴＦレンダリング、残響モデリングなどを含む）、簡潔かつ明確にするために、これについてはこれ以上詳細に説明しないことを理解されたい。

【0089】

以下に説明する特徴および側面のうちの１つ以上を含むデータフォーマットに従って、エンコーダはビットストリームを生成するように構成され、デコーダはビットストリームを受信、復号、および処理するように構成される。具体的な特徴および特性のうちの大部分または全てを含み得る特定のビットストリーム／フォーマットを参照してアプローチを説明するが、多くの実施形態では、例えば一部の特徴またはアプローチしか含まない可能性があるビットストリームが生成されることが理解されよう。実際、説明されるビットストリームの複数の異なる機能および要素は必ずしも併用されず、個別に使用されるか、または他の説明される機能と任意の方法で組み合わせることができる個別の機能である。

【0090】

具体例では、連続した複数のデータセット（データセットはデータフレームとも呼ばれ得る）として構成された音響環境データを含むメタデータビットストリームが生成される。各データセットは、ある時間間隔についてのデータを含む。音響環境データは、ある時間間隔のデータ値がグループ化されるように構成され得、具体的には、単一の時間間隔にのみ適用される全ての符号化された音声データストリームがそのデータセットに含まれる連続データセットとしてグループ化され得、データセットは、その単一の時間間隔とは異なる時間間隔にのみ適用される音響環境データを含まない。所与の時間間隔に固有の全てのデータを取得するには、デコーダはそのデータセットを復号するだけで済む。一部の実施形態では、所与の時間間隔の音響環境データは他の時間間隔にも適用され得る（例えば、一部の静的音響環境データは全ての時間間隔に適用され得る）。そのようなマルチ間隔データは、複数の時間間隔のうちの１つの時間間隔のデータセット内、複数の時間間隔のうちの２つ以上の時間間隔のデータセット内、全てのデータセット内、またはデータセット外（例えば、個々の時間間隔のデータセットとは別に提供される共通データセットなど）に含まれ得る。

【0091】

したがって、ビットストリームは、複数の異なる時間間隔のデータセットを含み得る。以下では、各データセットはビットストリームのデータポイントとも呼ばれる。

【0092】

生成されるメタデータビットストリームは、多くの場合比較的静的なメタデータであって、特性（例えば、位置、向き、信号ゲイン）のアニメーション／変化が比較的遅いメタデータを含む可能性がある。したがって、この例では、ビットストリームは、数ミリ秒の範囲の継続時間を有するフレームとして編成されず、はるかに長い時間スケールの時間間隔を表すデータセットまたはデータポイントに編成される。データセット／データポイントの時間間隔は、例えば０．５秒、１秒、２秒、または５秒以上であってもよい。

【0093】

ビットストリームは、ランダムに読み取りを始める場合、または複数のビットストリームが結合されている場合にビットストリームの復号を開始するのに十分なデータを含む独立したデータポイントを含み得る。このような独立したデータポイントのデータは、先行するデータポイントのデータに依存しない。このアプローチを使用したビットストリームの例を図４に示す。

【0094】

各データセット／ポイントによって表される時間間隔の継続時間はフレキシブルであってもよく、グループごとに異なってもよい。典型的には、継続時間は数秒程度であってもよい。データポイントはタイムスタンプに対して定義されてもよく、具体的には、データポイントのための始点、終点、または中間点であってもよい。データポイントのメタデータは、時間間隔の音響環境データの特性に関するデータ（例えば、具体的には、具体的な特性値を示すデータ）を表すことができる。例えば、示される値は、時間間隔の終わり（例えば、次のデータポイントに引き継がれる場所、またはシーンが終了する場所）の値であってもよい。さらに、値が時間間隔内で時間変化する場合、時間間隔内の他の時点での特性値を再構成することを可能にするデータが含まれてもよい。例えば、時間間隔内の値は補間によって決定され得る。

【0095】

この具体例では、時間間隔は、ビットストリームのデータ値によって示され得る。同様に、データフィールド／値によって示される特定の時間間隔に適用されるように、時間間隔内のデータ値が参照され、示されてもよい。具体的には、ｔａｒｇｅｔＯｆｆｓｅｔ［ｎ］として参照される値が使用されてもよく、ここで、ｎはインデックスである。

【0096】

このアプローチでは、時間変化が起こるとき、例えばアニメーションが開始するとき、停止するとき、またはその範囲内で速度が変更するとき、以下のような様々なアプローチを使用してこれをサポートすることができる。
－ ウェイポイント
－ データポイントを更新する

【0097】

メタデータフィールドがアニメーション化され、データポイントの時間間隔内でアニメーションを複数回更新する必要がある場合、データポイントの時間間隔内に複数のｔａｒｇｅｔＯｆｆｓｅｔを含めることによって複数のウェイポイントを含めることができる。例えば、
－ ＴａｒｇｅｔＯｆｆｓｅｔ［０］＝４８０００
－ ＴａｒｇｅｔＯｆｆｓｅｔ［１］＝２００００
－ ＴａｒｇｅｔＯｆｆｓｅｔ［２］＝３８６４３

【0098】

データポイントは、時間間隔内の特定の時点にリンクされた１つ以上の特性のターゲット値を含み得る。その時点は、時間インジケーションによって示され、具体的にはｔａｒｇｅｔＯｆｆｓｅｔフィールドの形態の時間インジケーションで示される。それぞれがｔａｒｇｅｔＯｆｆｓｅｔリファレンスとペアにされた複数のターゲット値を提供することにより、値が補間される複数のウェイポイントを生成できる。図５は、これを使用して変化するパラメータ値を提供する方法を示す。

【0099】

代わりにまたは追加で、独立していない複数のデータポイントであり得る複数の更新データポイントによって、動的な変化がサポートされてもよい。更新データポイントは、その時間間隔の完全なレンダリングを可能にするのに十分なデータを提供せず、ビットストリーム内の他の場所に設けられたデータに依拠する可能性がある。更新データポイントは、更新データポイントによって表される時間間隔中の特性を記述する音響環境データのサブセットのみを含む可能性がある。一部の実施形態では、更新データポイントは常に、少なくとも１つの独立したデータポイントとリンクされ得る。

【0100】

更新データポイントは、場合によっては、時変特性（時間間隔中に変化する）に関するデータのみを含み得る。また、更新データポイントは、更新データポイントが適用される時間間隔を示すデータ、例えば開始時点、終了時点、中間点などの関連付けられたデータを有してもよい。更新データポイントは、次の独立したデータポイントを越さない最大時間間隔継続時間を有してもよい。

【0101】

更新データポイントの利点は、対応するフィールドが独立したデータポイントよりも高いレートで送信されるシーン要素のライブストリーミング（例えば、他のユーザの動きおよびアクション）に有用であることであり得る。

【0102】

したがって、ビットストリームは、音の伝播に影響を及ぼす環境の特性についての１つ以上の特性値を含む複数の連続したデータセット／データポイントを含むことができる。さらに、ある特性値が適切である時間を示すための時間インジケーション（例えば、ｔａｒｇｅｔＯｆｆｓｅｔ）が含まれてもよい。一部の実施形態では、データセットは、１つ以上の特性について２つ以上の特性値を含むことができる。データセットは、可変特性について、複数の特性値がいつ適用されるべきかを示す時間インジケーションを含むことができる。

【0103】

一部の実施形態では、時間インジケーションは、時間間隔内のデフォルト時間と異なる場合にのみ含められてもよい。例えば、特性値はデフォルトでは時間間隔の終了時について示されており、時間間隔の終了時に提供される特性値には特定の時間インジケーションは提供されない可能性がある。しかし、時間間隔内の別の時間について提供される特性値は時間インジケーションに関連付けられ得る。

【0104】

したがって、一部の実施形態では、ビットストリーム生成器２０５は、所与の特性の特性値が、表される時間間隔内のデフォルト時間のために提供されたものであるか否かを判定するように構成される。そうである場合、第１の特性値は時間インジケーションなしでデータポイントに含められ、そうでない場合は、特性値に時間インジケーションが含まれる。

【0105】

ビットストリームは、それぞれ独立していて、レンダリングに追加のデータを必要としないデータセットと、それぞれ独立しておらず、音響環境の完全なレンダリングを可能にするために他のデータセットからの音響環境データを必要とするデータセットとの両方を含むように生成されてもよい。したがって、音響環境データは、環境の音声をレンダリングするために必要なデータを全て含むいくつかの完全なレンダリングデータセットと、環境の音声をレンダリングするために他のデータセットからのデータに追加で依拠し、そのようなデータを必要とするいくつかの部分的レンダリングデータセットとを含む可能性がある。

【0106】

データポイントが独立しており、最大数秒のギャップをカバーする可能性があるという概念によれば、データポイントの時間間隔の始点および終点の両方を含むと有用である可能性がある（例えば、データポイントの開始位置と、補間間隔の終了位置とを示す）。多くの場合で終点のみを指定することが許容され、また、デコーダがストリームに割り込むとき、最初に復号されるデータポイントの間隔の継続時間にかけてのみ潜在的な逸脱が発生する可能性があることから、これは任意選択である。

【0107】

多くの場合、ソースポーズの終点が最も重要な情報とみなされる可能性があり、これは位置および向きのデータを含み得る。加えて、任意選択の開始位置／向きが提供されてもよい。より効率的なコード化によってビットレートを節約するために、これは終点に対して差動コード化されてもよい。補間不可能なデータ（例えば、フラグ、識別子、インデックス）の場合、変化が瞬時に発生するオフセットが存在する可能性があり、データポイントの開始時の値が示される可能性がある（したがって、差動ではない）。フラグの場合、開始時の値は、提供されたインジケーションに続く値の反対であるとみなされるため、示されない可能性がある。

【0108】

ＪＳＯＮ構造では、このようなアプローチの例は次の通りである。
－ ＯｂｊｅｃｔＳｏｕｒｃｅ［］
・ＩＤ
・ＳｉｇｎａｌＩｎｄｅｘ
・ＰｒｅＧａｉｎ
・ＰｒｅＧａｉｎＩｎｔｅｒｐＭｅｔｈｏｄ（任意選択）
・ＰｒｅＧａｉｎＩｎｔｅｒｐＬｅｎｇｔｈＩｄｘ（任意選択）
・ＰｒｅＧａｉｎＤｅｌｔａ（任意選択） ％存在はそのデータポイント内にアニメーションがあることを伝える
・位置
・ＰｏｓｉｔｉｏｎＩｎｔｅｒｐＭｅｔｈｏｄ（任意選択）
・ＰｏｓｉｔｉｏｎＩｎｔｅｒｐＬｅｎｇｔｈＩｄｘ（任意選択）
・ＰｏｓｉｔｉｏｎＤｅｌｔａ（任意選択） ％存在はそのデータポイント内にアニメーションがあることを伝える
・向き
・ＯｒｉｅｎｔａｔｉｏｎＩｎｔｅｒｐＭｅｔｈｏｄ（任意選択）
・ＯｒｉｅｎｔａｔｉｏｎＩｎｔｅｒｐＬｅｎｇｔｈＩｄｘ（任意選択）
・ＯｒｉｅｎｔａｔｉｏｎＤｅｌｔａ（任意選択） ％存在はそのデータポイント内にアニメーションがあることを伝える
・レンダリング
・ＲｅｎｄｅｒＵｐｄａｔｅＯｆｆｓｅｔＩｄｘ（任意選択） ％存在はそのデータポイント内にアニメーションがあることを伝える
・指向性ＩＤ
・ＤｉｒｅｃｔｉｖｉｔｙＩＤＵｐｄａｔｅＯｆｆｓｅｔＩｄｘ（任意選択）
・ＤｉｒｅｃｔｉｖｉｔｙＩＤＳｔａｒｔ（任意選択） ％存在はそのデータポイント内にアニメーションがあることを伝える

【0109】

ここで、終点は［位置，方向］であり、始点は［位置－ＰｏｓｉｔｉｏｎＤｅｌｔａ，向き－ＯｒｉｅｎｔａｔｉｏｎＤｅｌｔａ］である。これは、終了位置が、必要に応じて開始位置を再構築することを可能にする絶対値としても相対値としても提供され得ることを意味する。

【0110】

例えば、次のいずれかを定義するフィールドＩｎｔｅｒｐＭｅｔｈｏｄなどによって、様々な補間方法を指し示すことができる。
－ ‘ｌｉｎｅａｒ’＜デフォルト＞
－ ‘ｉｎｓｔａｎｔ’（ターゲットのタイムスタンプにおいて、補間なしで瞬時に変化させる。例えば、ＳｉｇｎａｌＩｎｄｅｘ、ＥｘｔｅｎｔＩＤ、または任意のＢｏｏｌｅａｎフィールドの変形に有用である）
－ ‘ｓｐｈｅｒｉｃａｌ’
－ ‘ｌｏｇａｒｉｔｈｍｉｃ’

【0111】

終点のターゲットは、次の独立したデータポイントの始点、任意の中間更新データポイント、または中間ウェイポイントであり得る。ビットストリームの一般部分の中に複数の潜在的なターゲットが列挙され、ビットストリームの他の部分がそれを効率的に参照することで、他の部分がカバーするデータのために妥当なターゲットが示されてもよい。ターゲットは、所与の時点でのターゲット値／意図された値であってもよい。

【0112】

以下、単一のデータポイント／データセットのデータのフォーマットおよび構文の例を説明する。この説明は、ＭＰＥＧ－Ｈ ３Ｄ Ａｕｄｉｏ（ＩＳＯ／ＩＥＣ２３００８－３）などのＭＰＥＧ Ａｕｄｉｏ規格で使用されるビットストリームフォーマットを記述するアプローチに沿ったものである。構文記述は疑似コードとして構造化されており、関数呼び出しは、その関数の下で記述された構文が、関数呼び出しが行われた場所に挿入されることを示す。ビットストリーム内のビットを占めるフィールドは太字で表示されており、２列目および３列目はニーモニックを使用してビット数およびビットフォーマットを示している。一部のフィールドは、表される値に応じて、可変数ｎｒのビットを有し得る。これらのフィールドは、コードワードおよび対応する値を記述するルックアップテーブルに関連付けられている。コードワードは、ビットごとに読み取りを開始するときに、より短いコードワードがより長いコードワードの最初の方のビットと決して重ならないように設計されている。これは、可逆データ符号化またはエントロピー符号化として当業者に知られており、例えば、ハフマン符号化、ランレングス符号化、または算術符号化が挙げられる。構文の前半で読み取られたデータが、他の部分の復号を制御するために、構文の後半の部分で使用されてもよい。例えば、ビット数、要素数、符号化の方法、特定のデータの存在などを通知することによってである。

【0113】

記述では、以下の特定の頭字語が使用される（ＩＳＯ／ＩＥＣ２３００８－３、ＭＰＥＧ－Ｈ ３Ｄ Ａｕｄｉｏ仕様から引用）。
－ ｂｓｌｂｆ － ビット列、左ビットが最初（ｂｉｔ ｓｔｒｉｎｇ， ｌｅｆｔ ｂｉｔ ｆｉｒｓｔ）。「左」は、ＩＳＯ／ＩＥＣ１４４９６でビット列が書き込まれる順序である。ビット列は、例えば‘１０００ ０００１’のように、一重引用符で囲まれた１と０の文字列として記述される。ビット列内の空白は読みやすくするためのものであり、特に意味はない。
・ｂｏｏｌｅａｎに使用される
－ ｔｃｉｍｓｂｆ － ２の補数の整数、最上位（符号）ビットが最初（ｔｗｏ’ｓ ｃｏｍｐｌｅｍｅｎｔ ｉｎｔｅｇｅｒ， ｍｏｓｔ ｓｉｇｎｉｆｉｃａｎｔ （ｓｉｇｎ） ｂｉｔ ｆｉｒｓｔ）。
－ ｕｉｍｓｂｆ － 符号なし整数最上位ビットが最初（Ｕｎｓｉｇｎｅｄ Ｉｎｔｅｇｅｒ Ｍｏｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｉｔ Ｆｉｒｓｔ）。
・ｕｉｎｔに使用される
－ ｖｌｃｌｂｆ － 可変長コード、左ビットが最初（ｖａｒｉａｂｌｅ ｌｅｎｇｔｈ ｃｏｄｅ， ｌｅｆｔ ｂｉｔ ｆｉｒｓｔ）。「左」は可変長コードが書き込まれる順序を指す。

【0114】

データセット／ポイントは、次のフォーマット／構文に従って提供され得る。
ＤａｔａＰｏｉｎｔ（）

【表1】

【0115】

以下では、そのようなデータポイントの様々なフィールド／部分／要素がより詳細に説明されるが、説明されるフィールド／部分／要素は具体的なデータポイントまたは構文に限定されず、音響環境データを含む任意のビットストリーム内で個別に、または任意の組み合わせで使用され得ることが理解されるであろう。

【0116】

データポイントの機能／フィールド／部分要素のさらなる説明。

【0117】

ｄｐＴｙｐｅ
データポイントのタイプ。データポイントのタイプを示す。

【表2】

【0118】

ｒｅｓｅｒｖｅｄＢｉｔｓ
予約済みビット。これらを使用して、拡張機構を導入することができる。

【0119】

したがって、データポイントは、データポイントの特定のタイプを示す２つのビットで始まり得る。２つのビットは、具体的には、データポイントが独立したデータポイントであるか、または更新ポイントであるかを示す。

【0120】

ＧｅｎｅｒａｌＤａｔａ（）
フィールドＧｅｎｅｒａｌＤａｔａ（）は、一般的な構成またはレンダリングデータでいくつかのパラメータに関する情報を提供するデータを提供し得る。

【表3】

【0121】

ｂｓＶｅｒｓｉｏｎ
ビットストリームバージョン。

【表4】

【0122】

ｉｓＳｍａｌｌＳｃｅｎｅ
真に設定されている場合、［－１００．．１００］メートルの範囲外の座標が存在しないことを示す。

【0123】

一部の実施形態では、メタデータ生成器２０３は、環境が、空間的に制約された環境であることを示すグローバルインジケータを含む音響環境データを生成するように構成される。例えば、グローバルインジケータは、真または偽に設定され得るｉｓＳｍａｌｌＳｃｅｎｅの形態であり得る。真に設定すると、ｉｓＳｍａｌｌＳｃｅｎｅは［－１００．．１００］メートルを超えない座標で表現されるように制限される。

【0124】

空間的に制限された環境を示すグローバルインジケータが設定されている場合、データ値の所定の制限付きフォーマットに準拠するように、多くのデータ値が制限される。具体的には、空間座標（具体的には位置値）は、［－１００．．１００］メートルの間隔に制限されるなど、閾値を超えないように制限され得る。一部の実施形態では、空間的に制限された環境を示すようにグローバルインジケータが設定されているとき、他のパラメータが、限定された範囲に制限され得る。例えば、小さい環境の場合、残響の最大継続時間または時定数（例えば、Ｔ_６０値）が制限される可能性がある。

【0125】

空間的に制限された環境は、閾値未満の空間的広がりを有する環境であり得る。所定の制限付きフォーマットは、環境が空間的に制限された環境でない場合にビットストリームに使用されるデータフォーマットよりも少ないビットを使用する、音の伝播に影響する特性の少なくともいくつかの値のデータフォーマットであり得る。

【0126】

一部の実施形態では、１つ以上のパラメータ値の制限を示すグローバルフラグまたはインジケータが含まれてもよい。

【0127】

ｕｓａｃＳａｍｐｌｉｎｇＦｒｅｑｕｅｎｃｙＩｎｄｅｘ
音声信号に使用されるサンプルレートのインデックス。２３００３－３の定義に基づき、

【表5】

【0128】

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

【0129】

ｕｓｅＤｅｆａｕｌｔＳｐｅｅｄＯｆＳｏｕｎｄ
材料なし媒体に対してデフォルトの音速（２０°Ｃでの値である３４３ｍ／ｓ）を使用するか、またはカスタム値を指定するかを示すフラグ。

【0130】

ｓｐｅｅｄＯｆＳｏｕｎｄ
材料なし媒体用のカスタム音速値。材料なし媒体は、異なる材料が割り当てられたジオメトリによって占有されていない空間とみなされる。

【0131】

ＴａｒｇｅｔＤａｔａ（）
フィールドＴａｒｇｅｔＤａｔａ（）は、データポイントの他の部分からインデックスによって参照される、属性のアニメーションのターゲットオフセットを含み得る。

【表6】

【0132】

ＦｒｅｑＧｒｉｄＤａｔａ（）
フィールドは、データポイントの他の部分からインデックスによって参照される周波数グリッド定義を含み得る。これは通常、一部のビットストリームパーサに、次にコード化される周波数依存要素の数を通知する。

【0133】

フィールドＦｒｅｑＧｒｉｄＤａｔａ（）は、データポイントの他の部分からインデックスによって参照される周波数グリッド定義に関する情報を提供するデータを提供し得る。具体的には、周波数グリッド／複数の周波数範囲への細分割が記述されてもよく、定義された周波数グリッドに従って、ビットストリームの他のパラメータ／他のデータが提供され得る。例えば、周波数グリッドの定義された周波数の複数の異なる範囲に対して減衰を示すことによって、異なる周波数依存フィルタリングを提供することができる。したがって、これらの減衰値に対応する周波数を明示的に記述する必要なく、フィルタを単純に減衰値のセットとして記述することができる。

【0134】

一部の実施形態では、音響環境データは、周波数グリッドを記述する１つ以上のデータグループ／データフィールドと、周波数グリッドを使用して特性のうちの周波数依存特性を記述するデータをそれぞれが含む複数のデータグループ／データフィールドとを含むように構成され得る。周波数グリッドを使用して特性のうちの周波数依存特性を記述するデータは、例えば、周波数値および／または周波数グリッドによって定義される周波数値のうちの１つ以上の周波数値についてデータ値を提供することによって、これを行うことができる。

【0135】

周波数グリッドは、例えば周波数部分範囲の中心周波数を定義することによって、周波数範囲を周波数部分範囲に細分化したものであってもよい。

【0136】

一部の実施形態では、ビットストリームは、ビットストリームが、周波数グリッドを記述するデータグループを含むか否かを示すインジケータを含むことができる。例えば、単一のビットであるｂＦｇｄＰｒｅｓｅｎｔが、周波数グリッド定義が（例えば、次のビットに）含まれているか否かを示し得る。

【0137】

一部の実施形態では、ビットストリームは、周波数グリッドを記述するデータのフォーマットのインジケーションを含むことができる。例えば、ビットストリームは、例えば所定の／事前定義された周波数グリッドのセットのうちのグリッドのインデックスを示すことによって、周波数グリッドが事前定義されたグリッドへの参照によって記述されているか否かを記述するインジケーションを含むことができる。別の例として、ビットストリームは、周波数グリッドの少なくとも一部の部分範囲について、典型的には周波数グリッドの全ての部分範囲について、開始周波数および周波数範囲を示すデータを含むことができる。一部の実施形態では、周波数グリッドは、周波数範囲／周波数間隔の境界周波数を示す遷移周波数のセットによって示され得る。例えば、第１の周波数間隔／範囲が、第１の周波数間隔／範囲の開始周波数および次の周波数間隔／範囲の開始周波数を示すデータによって示されてもよい。

【0138】

多くの実施形態では、周波数範囲は、周波数スケールの対数表現において一定であり得る。

【0139】

周波数バンディング（ｂａｎｄｉｎｇ）および範囲／間隔への分割は、オクターブに基づいて行われてもよい。１オクターブの差は周波数（例えば、１２５、２５０、５００、１０００Ｈｚ）を２倍することを表す。ビットストリームは、例えば、オクターブバンドまたは別の下位区分（例えば、オクターブバンド間にさらに２つの値を配置する１／３オクターブバンド（１２５、１６０、２００、２５０、３１５、４００、５００、６３０、８００、１０００））におけるバンディングがあるか否かを示す。一部の実施形態では、オクターブバンドの分数に位置合わせされたデータによって、少なくとも１つの部分範囲または個別の周波数が示されてもよい。

【0140】

一部の実施形態では、ビットストリームは、個別の周波数、例えば複数の個別の周波数のセッを示すデータを含むことができる。その場合、ビットストリーム内において、他の周波数依存特性は、これらの個別の周波数を特性ごとに明示的に記述する必要なく、これらの個別の周波数のための特性値のセットによって単純に表され得る。

【0141】

多くの実施形態では、その場合、周波数グリッドはビットストリームのデータによって記述／定義され得る。例えば、周波数グリッドの異なるモードが使用されてもよく、データは、周波数グリッドを記述するために使用されるモードを示してもよい。

【0142】

例えば、フィールドｆｇｄＭｅｔｈｏｄは、例えば次のうちのどのモードが使用されるかを示してもよい。
－ デフォルトのグリッド
・例えば、オクターブバンドの分数に位置合わせされる
－ 開始周波数 ＋ 周波数ホップサイズ ＋ バンドの量
・例えば、オクターブバンドの分数に位置合わせされる
－ 個別の周波数
・例えば、オクターブバンドの分数に位置合わせされる

【0143】

周波数グリッドのフォーマット／構文の例は以下の通りである。

【表7】

【0144】

ｂＦｇｄＰｒｅｓｅｎｔ
周波数グリッドが定義されているかを示すフラグ。

【0145】

ｆｇｄＭｅｔｈｏｄ
周波数グリッドがコード化されている方法。

【表8】

【0146】

ｆｇｄＣｅｎｔｅｒＦｒｅｑ
各周波数グリッドの各バンドの中心周波数をＨｚで示す。

【0147】

ｆｒｅｑｕｅｎｃｙＨｏｐＣｏｄｅ
周波数バンディングのホップ係数を示すコード。

【表9】

【0148】

ｆｇｄＤｅｆａｕｌｔＢａｎｄｉｎｇ１ついくつかのデフォルトバンディングスキームを定義する。

【表10】

【0149】

したがって、一部の実施形態では、ビットストリームは、音響環境データの周波数依存特性を記述するために他のデータグループにおいて使用される周波数グリッドを記述するデータグループを含むように生成される。したがって、周波数グリッドがデータストリーム内に提供され、周波数変化を記述するために使用される。さらに、ビットストリームは、ビットストリームが周波数グリッドの記述を含むか否かを示す特定のインジケータを含む。したがって、通信される具体的な特性および周波数依存性のために最適化できる任意選択でカスタマイズ可能な周波数グリッドを使用するようにビットストリーム生成を適合可能な柔軟なアプローチが提供される。単純な例として、周波数分解能または周波数範囲が柔軟に適合できてもよく、実際には、周波数グリッド記述全体が任意選択で、記述が含まれるか否かのインジケータを適切に設定することによって省略できる。

【0150】

また、データグループが、周波数グリッドの記述を含むだけでなく、周波数グリッドの記述に用いられるフォーマットを具体的に示すような構成であってもよい。したがって、受信機が周波数グリッド記述データを解釈することを可能にするインジケーションが提供されてもよく、これにより、ビットストリーム生成器は、具体的な特性およびそれらの特性の具体的な周波数依存性に特に適した周波数グリッドの記述のためのフォーマットを自由に選択できるようになる。

【0151】

周波数グリッドを記述するデータグループは、所定のデフォルトグリッド、周波数グリッドの少なくとも一部の部分範囲の開始周波数および周波数範囲、ならびに／または個別の周波数を示すデータを含み得る。

【0152】

したがって、このアプローチは、このような音響環境データをビットストリーム内に符号化して表現するための具体的な狭いアプローチを使用することにより、ビットストリームに周波数変化特性を含めることを可能にすることができる。このアプローチは、上記のような周波数依存の音響環境特性をビットストリームに含めるための、非常に効率的で、適合性があり、柔軟なアプローチを提供することができる。

【0153】

ＡｃｏｕｓｔｉｃＥｌｅｍｅｎｔＤａｔａ（）
構文のこの部分は、音響要素を記述するデータをカバーする。これらは通常、シーングラフの階層要素として機能する汎用要素である。通常、このような要素の特性は子ノードに引き継がれる。すなわち、音響要素のプリゲイン値は、対応する音響要素の下に編成された音源にも適用される。これらのノードの位置および向きは、親の向きまたはポーズを無視するようにポーズ依存関係が設定されているノードでない限り、子ノードの位置および向きを変換する。

【0154】

一部の実施形態では、音響環境データは、少なくとも１つの音声要素のためのアニメーションインジケーションを含む。アニメーションインジケーションは、ある時間間隔中に音声要素の特性が変化するか否かを示し、したがって、特性が動的特性であるか静的特性であるかを示す。具体的には、あるデータポイント／グループについて、そのデータポイント／グループの時間間隔内で音声要素が静的であるか時間変化するかを示すフラグまたはインジケーションが含まれてもよい。

【0155】

対応する音声が時間変化することをアニメーションインジケーションが示している場合、音響環境データは、変化する特性の変化を記述するデータをさらに含むことができる。このような音声要素の音響環境データは、音声要素の少なくとも１つの特性について、その特性が時間変化する特性であるか否かを示すデータを含むことができる。したがって、（データセット／ポイントの時間間隔内で）どの特性が時間変化し、どの特性が時間変化しないかを示す、特性に関するインジケーションが含まれてもよい。

【0156】

多くの実施形態では、音響環境データは、時間間隔内の異なる時間での特性値を決定する方法を記述するデータを含むことができ、具体的には、音響環境データは、異なる時間での特性値を決定するために適用される補間アプローチを記述するデータを含むことができる。

【0157】

音響環境データは、特定の時間変化する特性について２つ以上の値を含み得、各値は特定の時点のものであり得る。そして、他の時間についての特性値は補間によって決定され得る。符号化された音声データストリーム、特に個別のデータポイントは、時間変化する特性について実行されるべき時間的補間の特性を記述するデータを含み得る。

【0158】

場合によっては、データポイントの時間間隔内で補間に使用される値のうちの１つ以上が、時間間隔／データポイント外で提供されるか、提供される値から決定されてもよい。例えば、１つ以上の値が、例えばビットストリーム内で先に送信されたものであってもよい別のデータポイントのデータから導出され得る。このようなデータ値は、補間が適用される（および補間がそれを対象として定義されている可能性がある）データポイントの時間間隔の前または後の時間であり得る特定の時点（例えば、タイムスタンプによって示される）に関連付けられる可能性がある。

【0159】

一部の実施形態では、データポイントごとに異なる補間が記述され、したがって、時間間隔ごとに異なる補間が適用され得る。また、異なる特性（同じデータポイント／時間間隔の異なる特性を含む）に対して異なる補間が記述されてもよい。

【0160】

補間方法は、例えば、フラグ＊ＩｎｔｅｒｐＭｅｔｈｏｄによって表されるコードによって示され得る。コードは、例えば、以下の表１に示す通りであり得る。

【表11】

【0161】

一部の実施形態では、環境の少なくとも一部の要素の音響環境データは、環境のシーングラフの要素の識別データおよび親識別データを含むことができる。これらの少なくとも一部の要素は、例えば、オブジェクト、音源（音声要素）、および／または環境の音響特性であり得る。

【0162】

例えば、複数の異なるオブジェクトおよび／または音源がシーングラフ内に配置され得、音響環境データは、このシーングラフを示すデータを含み得る。これは、具体的には、個別の要素の識別データおよび親識別情報を提供することによって実現することができる。なぜなら、これによってシーングラフの再構築が可能になり、したがって階層を表すように構成され得る。

【0163】

一部の実施形態では、要素のアニメーションが、音響環境データ内に示されてもよい（場合によっては記述されてもよい）。

【0164】

例えば、音響環境データは、要素／ソースごとに（時間セグメント内で）アニメーション化されているか否かを示すＥｌｅｍｅｎｔＡｎｉｍａｔｅｄ、ＳｏｕｒｃｅＡｎｉｍａｔｅｄ、およびＡｔｔｒｉｂｕｔｅＡｎｉｍａｔｅｄフラグ／インジケーションを含むことができる。その場合、属性／特性がアニメーション化されているか否かを示すために、属性／特性ごとにフラグ／インジケーションを含めることができる。その場合、アニメーション／時間変化を記述するデータがさらに含まれ得る。

【0165】

上記機能の例として、次のフォーマットが使用されてもよい。

【表12】

【0166】

ａｅｄＰｒｅｓｅｎｔ
音響要素が定義されているか否かを示すフラグ。

【0167】

ａｅｄＮｒＥｌｅｍｅｎｔｓ
定義された音響要素の数を通知する。

【0168】

ｅｌｅｍｅｎｔＡｎｉｍａｔｅｄ
そのデータポイントにおいて、対応する要素がアニメーション化されているか否かを示すフラグ。

【0169】

ａｔｔｒｉｂｕｔｅＡｎｉｍａｔｅｄ
そのデータポイントにおいて、対応する属性がアニメーション化されているか否かを示すフラグ。また、より多くのウェイポイントについてのデータが存在するか否かを示すためにも使用される。

【0170】

ａｅｄＩＤ
音響要素のＩＤ。

【0171】

ａｅｄＰａｒｅｎｔＩＤ
シーングラフ内の音響要素の親のＩＤ。

【0172】

ａｅｄＰｏｓｅＤｅｐｅｎｄｅｎｃｙ
音響要素のポーズが何に相対的であるかを示す。

【0173】

ａｅｄＰｏｓｉｔｉｏｎ
音響要素の位置座標（ｘ，ｙ，ｚ）をメートル単位で示す。
同じ要素が複数回出現する場合、これは、データポイントの範囲内に複数のウェイポイントがあることを示す。

【0174】

ａｅｄＰｏｓｉｔｉｏｎＩｎｔｅｒｐＭｅｔｈｏｄ
位置アニメーションに使用する補間方法を示す（表１参照）。

【0175】

ａｅｄＰｏｓｉｔｉｏｎＩｎｔｅｒｐＴａｒｇｅｔＩｄｘ
ＴａｒｇｅｔＯｆｆｓｅｔへのインデックス。先行する位置ターゲット値が有効である、データポイントのタイムスタンプからのオフセットを示す。
データポイントの範囲内のウェイポイントごとに１つのターゲットインデックスが存在するように、複数のターゲットインデックスが提供されてもよい。

【0176】

ａｅｄＰｏｓｉｔｉｏｎＤｅｌｔａ
データポイントのタイムスタンプにおける位置の値を再構築することを可能にする位置デルタ値。
ＰｏｓｉｔｉｏｎＡｔＤＰＳｔａｒｔ ＝ ａｅｄＰｏｓｉｔｉｏｎ － ａｅｄＰｏｓｉｔｉｏｎＤｅｌｔａ
複数のターゲット値が存在する場合、最初のターゲット値を基準とする。

【0177】

ａｅｄＯｒｉｅｎｔａｔｉｏｎ
音響要素の向き（ヨー，ピッチ，ロール）をラジアン単位で示す。
同じ要素が複数回出現する場合、これは、データポイントの範囲内に複数のウェイポイントがあることを示す。

【0178】

ａｅｄＯｒｉｅｎｔａｔｉｏｎＩｎｔｅｒｐＭｅｔｈｏｄ
向きアニメーションに使用する補間方法を示す（表１参照）。

【0179】

ａｅｄＯｒｉｅｎｔａｔｉｏｎＩｎｔｅｒｐＴａｒｇｅｔＩｄｘ
ＴａｒｇｅｔＯｆｆｓｅｔへのインデックス。先行する向きターゲット値が有効である、データポイントのタイムスタンプからのオフセットを示す。
データポイントの範囲内のウェイポイントごとに１つのターゲットインデックスが存在するように、複数のターゲットインデックスが提供されてもよい。

【0180】

ａｅｄＯｒｉｅｎｔａｔｉｏｎＤｅｌｔａ
データポイントのタイムスタンプにおける向きの値を再構築することを可能にする向きデルタ値。
ＯｒｉｅｎｔａｔｉｏｎＡｔＤＰＳｔａｒｔ ＝ ａｅｄＯｒｉｅｎｔａｔｉｏｎ － ａｅｄＯｒｉｅｎｔａｔｉｏｎＤｅｌｔａ
複数のターゲット値が存在する場合、最初のターゲット値を基準とする。

【0181】

ａｅｄＰｒｅｇａｉｎ
対応する音響要素の下に階層的に配置された全てのソースのプリゲイン値（ｄＢ）。
同じ要素が複数回出現する場合、これは、データポイントの範囲内に複数のウェイポイントがあることを示す。

【0182】

ａｅｄＰｒｅｇａｉｎＩｎｔｅｒｐＭｅｔｈｏｄ
プリゲインアニメーションに使用する補間方法を示す（表１参照）。

【0183】

ａｅｄＰｒｅｇａｉｎＩｎｔｅｒｐＴａｒｇｅｔＩｄｘ
ＴａｒｇｅｔＯｆｆｓｅｔへのインデックス。先行するプリゲインターゲット値が有効である、データポイントのタイムスタンプからのオフセットを示す。
データポイントの範囲内のウェイポイントごとに１つのターゲットインデックスが存在するように、複数のターゲットインデックスが提供されてもよい。

【0184】

ａｅｄＰｒｅｇａｉｎＤｅｌｔａ
データポイントのタイムスタンプにおけるプリゲインの値を再構築することを可能にするプリゲインデルタ値。
ＰｒｅｇａｉｎＡｔＤＰＳｔａｒｔ ＝ ａｅｄＰｒｅｇａｉｎ － ａｅｄＰｒｅｇａｉｎＤｅｌｔａ
複数のターゲット値が存在する場合、最初のターゲット値を基準とする。

【0185】

ａｅｄＲｅｎｄｅｒ
レンダリングフラグ。偽の場合、対応する音響要素の下に階層的に配置された全てのソースをレンダリングしないことを示す。

【0186】

ａｅｄＲｅｎｄｅｒＵｐｄａｔｅＴａｒｇｅｔＩｄｘ
ＴａｒｇｅｔＯｆｆｓｅｔへのインデックス。先行するａｅｄＲｅｎｄｅｒ値へとレンダリングフラグが状態を反転する、データポイントのタイムスタンプからのオフセットを示す。
データポイントの範囲内のウェイポイントごとに１つのターゲットインデックスが存在するように、複数のターゲットインデックスが提供されてもよい。各ターゲットインデックスは、フラグの状態のバイナリ反転を示す。

【0187】

ＡｕｄｉｏＳｏｕｒｃｅＤａｔａ（）ＡｕｄｉｏＳｏｕｒｃｅＤａｔａ（）
構文のこの部分は、様々なタイプの音源を集めている。

【表13】

【0188】

ＯｂｊｅｃｔＳｏｕｒｃｅＤａｔａ（）
構文のこの部分は、オブジェクトソースの特性を記述する。

【表14】

【0189】

ｏｓｄＰｒｅｓｅｎｔ
オブジェクトソースの有無を示すフラグ。

【0190】

ｏｓｄＮｒＥｌｅｍｅｎｔｓ
後続するオブジェクトソース要素の数を示す。

【0191】

ｓｏｕｒｃｅＡｎｉｍａｔｅｄ
そのデータポイントにおいて、対応するソースがアニメーション化されているか否かを示すフラグ。

【0192】

ａｅｄＩＤ
音響要素のＩＤ。

【0193】

ａｅｄＰａｒｅｎｔＩＤ
シーングラフ内の音響要素の親のＩＤ。

【0194】

ｏｓｄＳｉｇｎａｌＩｎｄｅｘ
ソースに対応する信号の信号入力バッファ内へのインデックスを示す。

【0195】

ｏｓｄＩｓＣｏｎｔｉｎｕｏｕｓＳｏｕｒｃｅ
連続的な信号に関連付けられているか、またはデコーダ側でトリガされる音響効果に関連付けられているかを示すフラグ。

【0196】

ｏｓｄＲｅｆｅｒｅｎｃｅＤｉｓｔａｎｃｅ
オブジェクトソースの基準距離を示す。

【0197】

ｏｓｄＰｏｓｅＤｅｐｅｎｄｅｎｃｙ
ソースのポーズが何に相対的であるかを示す。

【0198】

ａｔｔｒｉｂｕｔｅＡｎｉｍａｔｅｄ
そのデータポイントにおいて、対応する属性がアニメーション化されているか否かを示すフラグ。また、より多くのウェイポイントについてのデータが存在するか否かを示すためにも使用される。

【0199】

ｏｓｄＰｏｓｉｔｉｏｎ
オブジェクトソースの位置座標（ｘ，ｙ，ｚ）をメートル単位で示す。
同じソースが複数回出現する場合、これは、データポイントの範囲内に複数のウェイポイントがあることを示す。

【0200】

ｏｓｄＰｏｓｉｔｉｏｎＩｎｔｅｒｐＭｅｔｈｏｄ
位置アニメーションに使用する補間方法を示す（表１参照）。

【0201】

ｏｓｄＰｏｓｉｔｉｏｎＩｎｔｅｒｐＴａｒｇｅｔＩｄｘ
ＴａｒｇｅｔＯｆｆｓｅｔへのインデックス。先行する位置ターゲット値が有効である、データポイントのタイムスタンプからのオフセットを示す。
データポイントの範囲内のウェイポイントごとに１つのターゲットインデックスが存在するように、複数のターゲットインデックスが提供されてもよい。

【0202】

ｏｓｄＰｏｓｉｔｉｏｎＤｅｌｔａ
データポイントのタイムスタンプにおけるオブジェクトソース位置の値を再構築することを可能にする位置デルタ値。
ＰｏｓｉｔｉｏｎＡｔＤＰＳｔａｒｔ ＝ ｏｓｄＰｏｓｉｔｉｏｎ － ｏｓｄＰｏｓｉｔｉｏｎＤｅｌｔａ
複数のターゲット値が存在する場合、最初のターゲット値を基準とする。

【0203】

ｏｓｄＯｒｉｅｎｔａｔｉｏｎ
オブジェクトソースの向き（ヨー，ピッチ，ロール）をラジアン単位で示す。
同じソースが複数回出現する場合、これは、データポイントの範囲内に複数のウェイポイントがあることを示す。

【0204】

ｏｓｄＯｒｉｅｎｔａｔｉｏｎＩｎｔｅｒｐＭｅｔｈｏｄ
向きアニメーションに使用する補間方法を示す（表１参照）。

【0205】

ｏｓｄＯｒｉｅｎｔａｔｉｏｎＩｎｔｅｒｐＴａｒｇｅｔＩｄｘ
ＴａｒｇｅｔＯｆｆｓｅｔへのインデックス。先行する向きターゲット値が有効である、データポイントのタイムスタンプからのオフセットを示す。
データポイントの範囲内のウェイポイントごとに１つのターゲットインデックスが存在するように、複数のターゲットインデックスが提供されてもよい。

【0206】

ｏｓｄＯｒｉｅｎｔａｔｉｏｎＤｅｌｔａ
データポイントのタイムスタンプにおけるオブジェクトソースの向きの値を再構築することを可能にする向きデルタ値。
ＯｒｉｅｎｔａｔｉｏｎＡｔＤＰＳｔａｒｔ ＝ ｏｓｄＯｒｉｅｎｔａｔｉｏｎ － ｏｓｄＯｒｉｅｎｔａｔｉｏｎＤｅｌｔａ
複数のターゲット値が存在する場合、最初のターゲット値を基準とする。

【0207】

ｏｓｄＰｒｅｇａｉｎ
オブジェクトソースのプリゲイン値（ｄＢ）。
同じ要素が複数回出現する場合、これは、データポイントの範囲内に複数のウェイポイントがあることを示す。

【0208】

ｏｓｄＰｒｅｇａｉｎＩｎｔｅｒｐＭｅｔｈｏｄ
プリゲインアニメーションに使用する補間方法を示す（表１参照）。

【0209】

ｏｓｄＰｒｅｇａｉｎＩｎｔｅｒｐＴａｒｇｅｔＩｄｘ
ＴａｒｇｅｔＯｆｆｓｅｔへのインデックス。先行するプリゲインターゲット値が有効である、データポイントのタイムスタンプからのオフセットを示す。
データポイントの範囲内のウェイポイントごとに１つのターゲットインデックスが存在するように、複数のターゲットインデックスが提供されてもよい。

【0210】

ｏｓｄＰｒｅｇａｉｎＤｅｌｔａ
データポイントのタイムスタンプにおけるオブジェクトソースのプリゲイン値を再構築することを可能にするプリゲインデルタ値。
ＰｒｅｇａｉｎＡｔＤＰＳｔａｒｔ ＝ ｏｓｄＰｒｅｇａｉｎ － ｏｓｄＰｒｅｇａｉｎＤｅｌｔａ
複数のターゲット値が存在する場合、最初のターゲット値を基準とする。

【0211】

ｏｓｄＲｅｎｄｅｒ
レンダリングフラグ。偽の場合、オブジェクトソースをレンダリングすべきではないことを示す。

【0212】

ｏｓｄＲｅｎｄｅｒＵｐｄａｔｅＴａｒｇｅｔＩｄｘ
ＴａｒｇｅｔＯｆｆｓｅｔへのインデックス。先行するｏｓｄＲｅｎｄｅｒ値へとレンダリングフラグが状態を反転する、データポイントのタイムスタンプからのオフセットを示す。
データポイントの範囲内のウェイポイントごとに１つのターゲットインデックスが存在するように、複数のターゲットインデックスが提供されてもよい。各ターゲットインデックスは、フラグの状態のバイナリ反転を示す。

【0213】

ｏｓｄＩｓＯｍｎｉＤｉｒｅｃｔｉｏｎａｌ
ソースが無指向性であるかを示すフラグ。

【0214】

ｏｓｄＤｉｒｅｃｔｉｖｉｔｙＰａｔｔｅｒｎＩＤ
使用すべき指向性パターンのＩＤ。

【0215】

ＳｏｕｎｄＥｆｆｅｃｔＤａｔａ（）
構文のこの部分は、音響効果の特性を記述する。これらは、連続的にレンダリングされる音声信号ではなく、ユーザインタラクションなどによってトリガされる音声信号の短いセグメントを表す。

【0216】

一部の実施形態では、音響環境データは、音響効果、クリップ、および他の音声要素に関連付けられたメタデータを提供することができ、メタデータは、特に、特定のユーザアクションまたはインタラクションに関連付けられた音響効果音声要素のデータを含むことができる。例えば、きしむ音を出すドアが開かれることに対して音響効果要素が設けてられてもよい。このような音響効果は、環境内でドアが開かれることに対応する入力をユーザが提供した場合に、レンダラーがドアの軋む音響効果を抽出してレンダリングできるように、ユーザアクションに関連付けられてもよい。

【0217】

一部の実施形態では、音声要素は、多数の音響効果要素を含んでもよく、音響環境データは、ユーザによって制御される環境変化を、そのような音響効果要素のうちの１つ（または複数）とリンクさせるデータを含んでもよい。ユーザによって制御される環境変化は、例えば、ユーザ入力もしくはユーザインタラクションであってもよく、またはこれらに基づいて決定されてもよい（またはこれらに由来してもよい）。

【0218】

音響環境データは、例えば、（要素を識別する）ターゲットＩＤ、ターゲット属性、および／または対応するターゲット値を参照することによって、特定のユーザインタラクションのための変更を示すことができる。これらの変化のリストは、トリガＩＤに応じて実行されてもよい。

【0219】

具体例として、音源の属性としてＳｏｕｎｄＥｆｆｅｃｔＩＤを使用することで音響効果のレンダリング開始を示されてもよく、再生されるべき音響効果の音響効果ＩＤがターゲット値として含められてもよい。

【0220】

音響効果データは、例えば、次の構文に従って提供され得る。

【表15】

【0221】

ｓｅｄＰｒｅｓｅｎｔ
音響効果データの有無を示すフラグ。

【0222】

ｓｅｄＮｒＥｌｅｍｅｎｔｓ
次に定義される音響効果要素の数を示す。

【0223】

ｓｅｄＩＤ
音響効果のＩＤ。

【0224】

ａｃｄＰａｒｅｎｔＩＤ
シーングラフ内の音響効果の親のＩＤ。

【0225】

ｓｅｄＤｕｒａｔｉｏｎ
音響効果の継続時間。

【0226】

ｓｅｄＰｒｅｇａｉｎ
音響効果のプリゲイン値。

【0227】

一部の実施形態では、音響環境データは、特定の領域に関連付けられたデータを含むことができる。例えば、特性値が、特性値が適用される特定の領域のインジケーションとともに提供されてもよい。例えば、所与の音源に関して、特性（例えば、周波数依存の減衰）は、リスナーが音源と同じ部屋にいるか、またはユーザが別の部屋にいるかに依存し得る。したがって、特性は、値が有効であるためには、リスニング位置がその中に存在しなければならないリンクされた領域のインジケーションを有し得る。リスニング位置が適用ゾーン外である場合、特性を正当に使用することができない。代わりに、例えば、現在のリスニング位置を含む異なる適用範囲を有する別の特性値が含まれてもよい。

【0228】

多くの実施形態では、メタデータは、１つ以上の特性について、複数のリンクされた領域を含むことができ、具体的には、第１の適用領域および第２の適用領域を含むことができる。第１の領域は音声要素／音源の位置のために提供され、第２の領域はリスニング位置のために提供され得る。したがって、特性値は、一方はリスニング位置に関連し、もう一方は音源位置に関連する２つの領域に関連付けられ得る。その場合、デコーダ／レンダラーは、リスニング位置および音源位置が適切な領域内にあるかを評価する。そうでない場合、別の特性値が使用されてもよく、例えば、デフォルト値、リスニング位置および音源位置を含む他の有効性領域に関連付けられた値、またはオリジナルの値の代替として提供され、有効性領域が満たされない場合に使用するために示される代替特性値が使用されてもよい。

【0229】

具体例として、ビットストリームは、リスニング位置および音源／音声要素位置それぞれの有効性領域をそれぞれが表すａｐｐｌｉｃａｂｌｅＲｅｇｉｏｎおよびｉｎｔｅｒｎａｌＳｏｕｒｃｅＲｅｇｉｏｎで示されるフィールド／データを含むことができる。

【0230】

一例として、ビットストリームは、リスニング位置と、リスニング位置がデータフィールドａｐｐｌｉｃａｂｌｅＲｅｇｉｏｎの値によって示される領域内にあるか否かとに依存する第１の特性値のデータを含むことができる。その場合、この値はさらに、データフィールドｉｎｔｅｒｎａｌＳｏｕｒｃｅＲｅｇｉｏｎ内の値によって示される領域内にある音源に直接適用可能であり、データフィールドｉｎｔｅｒｎａｌＳｏｕｒｃｅＲｅｇｉｏｎによって示される領域外にある場合は別の特性値が適用される。

【0231】

このようなアプローチを使用したビットストリームのデータの例が以下に含まれている。

【0232】

ＡｃｏｕｓｔｉｃＥｎｖｉｒｏｎｍｅｎｔＤａｔａ（）
構文のこの部分は、（一般的な）音響環境／周囲の（全体的な）特性を記述する。具体的には残響特性。

【表16】

【0233】

ａｃｄＰｒｅｓｅｎｔ
音響環境データの有無を示すフラグ。

【0234】

ａｃｄＮｒＥｌｅｍｅｎｔｓ
定義されている音響環境の数を示す。

【0235】

ａｃｄＩＤ
音響環境定義のＩＤ。

【0236】

ａｃｄＰａｒｅｎｔＩＤ
シーングラフ内の音響環境定義の親のＩＤ。

【0237】

ａｐｐｌｉｃａｂｌｅＲｅｇｉｏｎＩＤ
パラメータが適用される領域を記述する幾何学的要素のＩＤ。ポーズ依存性がグローバルでない限り、位置および向きは音響環境の親によってオフセットされる。

【0238】

ｉｎｔｅｒｎａｌＳｏｕｒｃｅＲｅｇｉｏｎＩＤ
全ての包含されているソースの全てのエネルギーが残響に寄与する領域を記述する幾何学的要素のＩＤ。ポーズ依存性がグローバルでない限り、位置および向きは音響環境の親によってオフセットされる。

【0239】

ｆｒｅｑＧｒｉｄＩｄｘ
ＦｒｅｑＧｒｉｄＤａｔａ（）内に定義されている周波数グリッドのリストのインデックス。

【0240】

ｄｓｒＯｆｆｓｅｔ
ＲＩＲにおいてＤＳＲが計算される場所からのオフセット（秒）。オフセット＝０はソースで放たれることに等しい。したがって、オフセットはそれより高いはずである。

【0241】

Ｔ６０
初期減衰後の、ＥＤＣの直線部分の０～－３０ｄＢポイントから計算されるＴ６０時間。

【0242】

ＤＳＲ
拡散エネルギーとソースエネルギーの比率（Ｄｉｆｆｕｓｅ ｔｏ Ｓｏｕｒｃｅ ｅｎｅｒｇｙ Ｒａｔｉｏ）。拡散残響エネルギーは、１人のユーザのサンプルポイントのために、ＲＩＲラグｄｓｒＯｆｆｓｅｔ後に計算される。ソースエネルギーは、その拡散エネルギーを引き起こす放出されたソースエネルギーの合計である。

【0243】

ｄｓｒＣｏｄｅ
ＤＳＲ値を示すコード。

【表17】

【0244】

ＧｅｏｍｅｔｒｉｃＥｌｅｍｅｎｔＤａｔａ（）
構文のこの部分は、幾何学的要素を記述する。

【表18】

【0245】

ｇｅｄＰｒｅｓｅｎｔ
音響環境データの有無を示すフラグ。

【0246】

ｇｅｄＮｒＥｌｅｍｅｎｔｓ
定義された幾何学的要素の数を示す。

【0247】

ｇｅｄＩＤ
幾何学的要素のＩＤ。

【0248】

ｇｅｄＴｙｐｅ
次に伝達される幾何学的要素のタイプを定義する。

【表19】

【0249】

ｃｏｒｎｅｒＰｏｓ１
座表軸に平行なボックスの１つの角を含む。位置はグローバル座標を表す。

【0250】

ｃｏｒｎｅｒＰｏｓ２
ｃｏｒｎｅｒＰｏｓ１の対角である、座標軸に平行なボックスの第２の角を含む。位置はグローバル座標を表す。

【0251】

ｂｏｘＰａｒｅｎｔＩＤ
対応するボックス幾何学的要素の親ノードのＩＤ。

【0252】

ｂｏｘＰｏｓｅＤｅｐｅｎｄｅｎｃｙ
音響要素のポーズが何に相対的であるかを示す。

【0253】

ｂｏｘＰｏｓｉｔｉｏｎ
ボックスジオメトリの位置座標（ｘ，ｙ，ｚ）をメートル単位で示す。

【0254】

ｂｏｘＯｒｉｅｎｔａｔｉｏｎ
ボックスジオメトリの向き（ヨー，ピッチ，ロール）をラジアン単位で示す。

【0255】

ｂｏｘＸＤｉｍ
回転前のｘ軸に沿ったボックスジオメトリの寸法。

【0256】

ｂｏｘＹＤｉｍ
回転前のｙ軸に沿ったボックスジオメトリの寸法。

【0257】

ｂｏｘＺＤｉｍ
回転前のｚ軸に沿ったボックスジオメトリの寸法。

【0258】

ＵｓｅｒＩｎｔｅｒａｃｔｉｏｎＤａｔａ（）
構文のこの部分は、ユーザインタラクションデータを記述する。どの要素について、どの属性をどの値に変更する必要があるか、またはこの値が外部エンティティから提供されるか（例えば、ソースを拾ってシーン内で移動させるなど、完全にユーザによって制御されるインタラクションの場合）を記述することによって、ユーザインタラクションをどのようにしてトリガできるか、およびトリガに応じてどのような変更を加えるべきかを記述する。

【0259】

視覚、音声、触覚などの６ＤｏＦメディアレンダリングの全ての側面をカバーする、ユーザインタラクションのよりセマンティックな定義が、より高いビットストリームレベルで定義され得る。ユーザインタラクションは、これらの側面の全てまたは一部に影響を与える可能性がある。このシステムレイヤー（ＭＰＥＧ－Ｉの場合、ＭＰＥＧ ＳｙｓｔｅｍｓワーキンググループＷＧ０３によってカバーされる）は、ユーザがどのようにして特定のインタラクションをトリガできるかを定義する。これは、シーンの特定の空間的領域内でコントローラのトリガボタンを作動することを定義するという意味であってもよいし、または、他のレイヤーが、抽象的な意味をハードウェア依存制御にリンクさせるというより抽象的な意味であってもよい。例えば、ユーザがドア５を開けた場合、ユーザインタラクションＧを作動する。

【0260】

システムレベルでのそのようなユーザインタラクショントリガは、専用のユーザインタラクショントリガをそれぞれのメディアレンダーに送信する可能性がある。例えば、システムレベルのユーザインタラクションＧは音声ユーザインタラクション１２にリンクされ得、音声レンダラーはその後、ｔｒｉｇｇｅｒＩＤ＝１２を有するユーザインタラクションに関連付けられた変更を実行し得る。

【0261】

多くの実施形態では、そのようなユーザインタラクショントリガは、より没入型のユーザインタラクションのためのさらなるパラメータを伴うことができる。例えば、ユーザによって拾い上げられ、動かされている音源の位置座標が提供されてもよい。

【0262】

音声レンダラーの外部からトリガされるこのようなユーザインタラクションは、外部トリガとも呼ばれる可能性がある。他のユーザインタラクションは、音声レンダラー自体によってトリガされることに依拠してもよい。このようなトリガ間の区別は、ユーザインタラクションの変化を記述するビットストリーム内のｔｒｉｇｇｅｒＴｙｐｅ特性によって示されてもよい。

【表20】

【0263】

ｕｉｄＰｒｅｓｅｎｔ
ユーザインタラクションの有無を示すフラグ。

【0264】

ｔｒｉｇｇｅｒＴｙｐｅ
ユーザインタラクションがどのようにシーン更新をトリガするかを定義する。

【表21】

【0265】

ｔｒｉｇｇｅｒＩｄｘ
この特定のシーンの更新をトリガするために外部ソースからのユーザインタラクションメッセージ内で使用されるインデックス。

【0266】

ｔｒｉｇｇｅｒＩＤ
この特定のシーン更新を記述する状態を記述する状態要素のＩＤ。

【0267】

ｃｏｎｄＴｒａｎｓｉｔｉｏｎ
状態が指定された遷移値に変化すると、更新がトリガされる。

【0268】

ｕｐｄａｔｅＤｅｌａｙ
トリガ後に更新をどれだけ遅らせるべきか。

【0269】

ｎｒＣｈａｎｇｅｓ
このシーン更新の変化の数を示す。

【0270】

ｕｓｅＰｒｅｖｉｏｕｓＩＤ
変化が前の変化と同じＩＤについてのものであるか否かを示すフラグ。

【0271】

ｉｍｍｅｄｉａｔｅＣｈａｎｇｅ
変化が即時であるか、または特定の期間にわたってターゲット値まで補間されるかを示すフラグ。

【0272】

ｄｕｒａｔｉｏｎ
変化の補間期間。

【0273】

ｔａｒｇｅｔＡｔｔｒｉｂｕｔｅ
変更する属性の名称。

【0274】

ａｔｔｒｉｂＣｏｄｅ
変更可能な属性を示すコード。

【表22】

【0275】

ｅｘｔｅｒｎａｌＰａｒａｍｅｔｅｒ
パラメータ値が外部プロセスによって提供されるか否かを示すフラグ。

【0276】

ｐａｒａｍｅｔｅｒＩｄｘ
この属性にマッピングされる外部プロセスからのメッセージ内のパラメータのインデックス。

【0277】

ｐａｒａｍＩｄｘＣｏｄｅ
パラメータインデックスを示すコード。

【表23】

【0278】

ｍｏｒｅＰａｒａｍｅｔｅｒｓ
追加パラメータの有無を示すフラグ。

【0279】

ｔａｒｇｅｔＶａｌｕｅ
変化のターゲット値。ターゲット属性のタイプに応じて、構文内のｓｗｉｔｃｈ文に従い、値のコード化が異なり得る。

【0280】

サポート要素
ビットストリームは、特性値を表すデータの提供をサポートできる様々なサポート要素を含み得る。

【0281】

また、多くの実施形態では、特性の値を示すために使用されるビット数は、ビットストリーム内で可変であってもよい。特に、特性値は、所定の数のビットを含むフィールドによって示され得る。ただし、特性値のための追加ビットを提供する１つ以上の拡張フィールドが含まれていることを示すフラグインジケータが含められてもよい。拡張フィールドは、具体的には、特性値の範囲を拡張するための追加ビットを提供してもよい。特に、拡張フィールドは、（動的）範囲を有する特性値を生成するために、デフォルトフィールドのデータビットと組み合わせられる最上位（／上位）ビットをさらに含み得る（具体的には、より高い値を表現することを可能にする追加ビットを提供し得る）。

【0282】

他のシナリオでは、拡張フィールドは、具体的には、特性値の精度を拡張するための追加ビットを提供し得る。特に、拡張フィールドは、より高精度の特性値を生成するために、デフォルトフィールドのデータビットと組み合わせられる追加の最下位（／下位）ビットをさらに含み得る。

【0283】

一部の実施形態では、音響環境データは、所与の特性の値を表す第１のビットを提供する第１のデータフィールドと、第１のデータフィールド／所与の特性のためのインジケーションを提供し得る第２のデータフィールドとを含み得る。このインジケーションは、第１の特性の値を表すさらなるビットを提供するさらなる拡張データフィールドが含まれるか否かのインジケーションを含み得る。このインジケーションは、例えば、提供されるデータ値の範囲を拡張するためのビットを拡張フィールドが含むことのインジケーション、および／または提供されるデータ値の精度／分解能を高めるためのビットを含むことのインジケーションであり得る。具体的には、このインジケーションは、第１のデフォルトフィールドおよび拡張フィールドの両方からのビットの組み合わせから得られる、より大きなデータワードによって値が表されることを示し得る。

【0284】

一部の実施形態では、さらなるビットは、特性が取り得る値の範囲を拡張する。さらなるビットは、特性の値を表す、データワードの第１のビットよりも上位のビットであってもよい。一部の実施形態では、さらなるビットは、特性が取り得る値の分解能を増加させる。さらなるビットは、第１の特性の値を表す、データワードの第１のビットよりも下位のビットであってもよい。さらなるビットは、第１の特性が取り得る値の精度を拡張し得る。

【0285】

多くの実施形態では、デフォルトビットおよびさらなるビットは、必ずしもビットを連結することによって組み合わせられるわけではなく、他の方法で組み合わせられる値を各々が表してもよい。

【0286】

したがって、一部の実施形態では、音響環境データは、特性の値を決定するためにさらなるビットが使用されることを示すインジケーション／フラグを含むことができる。このアプローチは、例えば、空間的特性、量、ゲイン特性、容量特性、周波数特性、インデックス特性、および識別特性などの多様な特性値について使用できる。

【0287】

例えば、より広い範囲が提供されていることを示すために以下のフィールドが使用されてもよい。
－ 時間の尺度の場合：ａｄｄＳｅｃｏｎｄｓ
－ 空間の尺度の場合：ａｄｄＨｅｃｔｏｍｅｔｅｒｓ
－ 量の尺度の場合：ｉｓＬａｒｇｅｒＮｕｍｂｅｒ
－ （整数）ＩＤ番号の場合：ｌａｒｇｅｒＶａｌｕｅ

【0288】

より正確な（より分解能が高い）値が提供されていることを示すために、以下のフィールドが使用されてもよい。
－ 時間の尺度の場合：ａｄｄＭｉｌｌｉｓｅｃｏｎｄｓ
－ 空間の尺度の場合：ａｄｄＣｅｎｔｉｍｅｔｅｒｓ
－ 周波数の尺度の場合：ｍｏｒｅＡｃｃｕｒａｃｙ
－ 角度の尺度の場合：ａｄｄＦｉｎｅＡｎｇｌｅ
－ ゲインの尺度の場合：ａｄｄＦｉｎｅＧａｉｎ。

【0289】

ビットストリームのための様々なサポート要素を以下に示す。上記したように、サポート要素は可変範囲／分解能値を使用する可能性がある。

【0290】

ＧｅｔＩＤ（）
整数のＩＤを返す。

【表24】

【0291】

ｉｄＶａｌ
ＩＤ値または部分的なＩＤ値。

【0292】

ｌａｒｇｅｒＶａｌｕｅ
ＩＤ値がより大きいかを示すフラグ。

【0293】

ＧｅｔＣｏｕｎｔＯｒＩｎｄｅｘ（）
［０．．１０２３］の範囲内の数値を返す。

【表25】

【0294】

ｃｏｕｎｔＯｒＩｎｄｅｘＬｏＣｏｄｅ
カウントまたはインデックス値の下位ビットを示すコード。

【表26】

【0295】

ｉｓＬａｒｇｅｒＮｕｍｂｅｒ
より大きな数値を示すためにさらに多くのビットが送信されるか否かを示すフラグ。

【0296】

ｃｏｕｎｔＯｒＩｎｄｅｘＨｉＣｏｄｅ
カウントまたはインデックス値の上位ビットを示すコード。

【表27】

【0297】

ＧｅｔＤｕｒａｔｉｏｎ（）
時間的継続時間をサンプルで返す。

【表28】

【0298】

ＬＵＴ（）
値が引数として指定されたフィールドに対応して、ルックアップテーブルへのクエリを実行する。

【0299】

ｄｅｃｉＳｅｃｏｎｄｓＣｏｄｅ
デシ秒継続時間オフセットを示すコード。

【表29】

【0300】

ａｄｄＭｉｌｌｉｓｅｃｏｎｄｓ
次に、ミリ秒継続時間オフセットが送信されるか否かを示すフラグ。

【0301】

ｍｉｌｌｉＳｅｃｏｎｄｓＣｏｄｅ
ミリ秒継続時間オフセットを示すコード。

【表30】

【0302】

ａｄｄＳａｍｐｌｅｓ
次に、サンプルベースの継続時間オフセットが送信されるか否かを示すフラグ。

【0303】

ｓａｍｐｌｅｓＣｏｄｅ
サンプル数継続時間オフセットを示すコード。

【表31】

【0304】

ａｄｄＳｅｃｏｎｄｓ
次に、秒継続時間オフセットが送信されるか否かを示すフラグ。

【0305】

ｓｅｃｏｎｄｓＣｏｄｅ
秒継続時間オフセットを示すコード。

【表32】

【0306】

ＧｅｔＦｒｅｑｕｅｎｃｙ（）
［１６．．．４９７１７］の範囲内の周波数（Ｈｚ）を返す。

【表33】

【0307】

ＬＵＴ（）
値が引数として指定されたフィールドに対応して、ルックアップテーブルへのクエリを実行する。

【0308】

ｆｒｅｑｕｅｎｃｙＣｏｄｅ
１／３オクターブバンドの中心周波数（Ｈｚ）を示すコード。

【表34】

【0309】

ｍｏｒｅＡｃｃｕｒａｃｙ
より正確な周波数のためのデータが送信されるか否かを示すフラグ。

【0310】

ｆｒｅｑｕｅｎｃｙＲｅｆｉｎｅ
周波数値を調整するための値を示すフィールド。

【0311】

ＧｅｔＰｏｓｉｔｉｏｎ（）
位置［ｘ，ｙ，ｚ］をメートル単位で返す。

【表35】

【0312】

ＧｅｔＰｏｓｉｔｉｏｎＤｅｌｔａ（）
位置Δ［ｄｘ，ｄｙ，ｄｚ］をメートル単位で返す。

【表36】

【0313】

ＧｅｔＤｉｓｔａｎｃｅ（）
距離をメートル単位で返す。

【表37】

【0314】

ＬＵＴ（）
値が引数として指定されたフィールドに対応して、ルックアップテーブルへのクエリを実行する。

【0315】

ｍｅｔｅｒｓＣｏｄｅ
メートル座標オフセットを示すコード。

【表38】

【0316】

ａｄｄＨｅｃｔｏｍｅｔｅｒｓ
次に、ヘクトメートル座標オフセットが送信されるか否かを示すフラグ。

【0317】

ｈｅｃｔｏｍｅｔｅｒｓＣｏｄｅ
ヘクトメートル座標オフセットを示すコード。

【表39】

【0318】

ａｄｄＫｉｌｏｍｅｔｅｒｓ
次に、キロメートル座標オフセットが送信されるか否かを示すフラグ。

【0319】

ｋｉｌｏｍｅｔｅｒｓＣｏｄｅ
キロメートル座標オフセットを示すコード。１０ｋｍを超える距離の場合、複数回の出現が提供される可能性がある。

【表40】

【0320】

ａｄｄＣｅｎｔｉｍｅｔｅｒｓ
次に、センチメートル座標オフセットが送信されるか否かを示すフラグ。

【0321】

ｃｅｎｔｉｍｅｔｅｒｓＣｏｄｅ
センチメートル座標オフセットを示すコード。

【表41】

【0322】

ａｄｄＭｉｌｌｉｍｅｔｅｒｓ
次に、ミリメートル座標オフセットが送信されるか否かを示すフラグ。

【0323】

ｍｉｌｌｉｍｅｔｅｒｓＣｏｄｅ
ミリメートル座標オフセットを示すコード。

【表42】

【0324】

向き特性の表現
音響環境データは多くの場合において、実際にはほとんど場合において、１つ以上の向き特性の値を含み得る。

【0325】

一部の実施形態では、これは、向き値の表現を含む音響環境データによって有利に達成され得る。

【0326】

一部の実施形態では、音響環境データは、向き特性を表すための向き表現フォーマットを記述するデータグループ／データフィールドを含む。多くの実施形態では、音響環境データは、複数の異なる向き表現フォーマットを記述するまたは定義するデータを（同じまたは複数の異なるデータセット／ポイント内に）含むことができる。各向き表現フォーマットは、向き値を表現するための（データ／ビット）フォーマットを提供する可能性がある。その場合、複数のデータセット／ポイントは、定義された向き表現フォーマットのうちの１つを使用することによって向き特性を記述するデータを含む可能性がある。

【0327】

一部の実施形態では、音響環境データは、ビットストリームが、向き表現フォーマットを記述するデータグループ／データフィールドを含むか否かを示すインジケータを含むことができる。例えば、向き表現フォーマットを記述するデータフィールドが含まれていることを示すフラグを示すことができる。

【0328】

また、音響環境データ内に定義されている向き表現フォーマットに従って向き値が提供されているか否かを示すフラグ／インジケータが、個別の向き値について提供されてもよい。フラグ／インジケータは、例えば複数の向き表現フォーマットのうちのいずれがその特定の値に使用されるかを示すために、個別の値について含まれてもよい。

【0329】

向き表現フォーマットは、例えば次のうちの１つ以上を含み得る。

【0330】

所定のデフォルト向き表現のインジケーション。デフォルト向き表現の数は事前に決定されていてもよい（例えば、規格の定義によって）。このようなデフォルト向きを参照するデータが含まれていてもよい。例えば、フィールドｏｒｉｅｎｔａｔｉｏｎＣｏｄｅがデフォルト向きを示してもよい。

【0331】

所定の角度のセット。向き表現フォーマットは所定の角度のセットを定義してもよく、向き値は、例えば、そのような所定の角度のうちの１つを単純に参照することによって示され得る。例えば、各所定の角度がインデックスによって表され、適切なインデックスを示すことによって所与の向き値が表されてもよい。例えば、向き値の各角度は、狭い範囲の角度からのデフォルト角度によって示されてもよい。

【0332】

（例えば、量子化グリッド上の）角度のセット。角度の表現は、明示的な角度値によって行われてもよい。角度値は、所与のワード長によって表されてもよく、したがって所与の量子化レベルを有することができる。したがって、各向きの角度は、より大きな範囲の角度のうちの１つによって示される。

【0333】

上記の例に従って向き値を提供するアプローチのいくつかの例を以下に提供する。

【0334】

ＧｅｔＯｒｉｅｎｔａｔｉｏｎ（）
向き［ヨー，ピッチ，ロール］をラジアン単位で返す。

【表43】

【0335】

ＬＵＴ（）
値が引数として指定されたフィールドに対応して、ルックアップテーブルへのクエリを実行する。

【0336】

ｏｒｉｅｎｔａｔｉｏｎＣｏｄｅ
デフォルト向きか、またはさらなるデータによって向きが定義される２つのエスケープ値のいずれかを示す向きのコード。

【表44】

【0337】

ｄｅｆａｕｌｔＹａｗＣｏｄｅ
デフォルトのヨー角のコード。

【表45】

【0338】

ｄｅｆａｕｌｔＰｉｔｃｈＣｏｄｅ
デフォルトのピッチ角のコード。

【表46】

【0339】

ｄｅｆａｕｌｔＲｏｌｌＣｏｄｅ
デフォルトのロール角のコード。

【表47】

【0340】

ｃｏａｒｓｅＡｎｇｌｅＣｏｄｅ
１／３６ｐｉ刻みでの粗い角度インジケーションのコード。

【表48】

【0341】

ａｄｄＦｉｎｅＡｎｇｌｅ
より細かい粒度の角度データが送信されるか否かを示すフラグ。

【0342】

ｆｉｎｅＡｎｇｌｅＣｏｄｅ
１／１８００ｐｉ刻みでの細かい角度インジケーションのコード。

【表49】

【0343】

ＧｅｔＧａｉｎ（）
ゲイン値（ｄＢ）を返す。

【表50】

【0344】

ｃｏａｒｓｅＧａｉｎＣｏｄｅ
粗いゲイン値（ｄＢ）のコード。

【表51】

【0345】

ａｄｄＦｉｎｅＧａｉｎ
より細かい分解能ゲイン値を提供するために、さらなるデータが送信されるか否かを示すフラグ。

【0346】

ｆｉｎｅＧａｉｎＣｏｄｅ
より細かいゲイン分解能（１ｄＢ分解能）のコード。

【表52】

【0347】

ＧｅｔＧａｉｎＤｅｌｔａ（）
ゲインデルタ値（ｄＢ）を返す。

【表53】

【0348】

ＧｅｔＲｅｎｄｅｒｉｎｇＣｏｎｄｉｔｉｏｎｓ（）
ソースをレンダリングする方法に関する情報を含む。

【表54】

【0349】

ｉｓＮｏｒｍａｌＣｏｎｄｉｔｉｏｎｓ
レンダリング条件がノーマルか否かを示すフラグ。これは、いずれの音響特徴が明示的にオフにされず、ソース、またはソースの特定の音響特徴のレンダリングがデコーダによって決定されることを意味する。

【0350】

ｄｏＲｅｖｅｒｂ
対応するソースの残響をレンダリングするか否かを示すフラグ。

【0351】

ｄｏＥａｒｌｙＲｅｆｌｅｃｔｉｏｎｓ
対応するソースの初期反射をレンダリングするか否かを示すフラグ。

【0352】

ｄｏＤｏｐｐｌｅｒ
対応するソースのドップラー硬化をレンダリングするか否かを示すフラグ。

【0353】

ｄｏＤｉｓｔａｎｃｅＡｔｔ
対応するソースの距離減衰をレンダリングするか否かを示すフラグ。

【0354】

ｄｏＤｉｒｅｃｔＰａｔｈ
対応するソースの直接経路をレンダリングするか否かを示すフラグ。

【0355】

ｒｅｇｉｏｎＤｅｐｅｎｄｅｎｔＡｃｔｉｖａｔｉｏｎ
ユーザの位置に応じて、ソースをアクティブにするか否かをさらならデータが指定するか否かを示すフラグ。

【0356】

ａｃｔｉｖａｔｅＧｏｉｎｇＩｎ
真の場合、ユーザが指定された領域内に移動したときにソースがアクティブ化されることを示すフラグ。

【0357】

ｒｅｇｉｏｎＤｅｐｅｎｄｅｎｔＤｅａｃｔｉｖａｔｉｏｎ
ユーザの位置に応じて、ソースを非アクティブにするか否かをさらならデータが指定するか否かを示すフラグ。

【0358】

ｄｅａｃｔｉｖａｔｅＧｏｉｎｇＩｎ
真の場合、ユーザが指定された領域内に移動したときにソースが非アクティブ化されることを示すフラグ。

【0359】

上記では、音声および音源という用語が使用されているが、これは音／サウンドおよびサウンドソースという用語と等価であることが理解されるであろう。「音声」という用語への言及は、「音／サウンド」という用語への言及に置き換えることができる。

【0360】

明瞭さのために、上記の説明は、異なる機能的回路、ユニット、およびプロセッサに関連して本発明の実施形態を説明している。しかしながら、本発明を損なうことなく、異なる機能的回路、ユニット、またはプロセッサ間で、機能が適切に分散され得ることが理解されよう。例えば、複数の別々のプロセッサまたはコントローラによって実行されるように説明された機能が、同じプロセッサまたはコントローラによって実行されてもよい。したがって、特定の機能的ユニットまたは回路への言及は、厳密な論理的または物理的な構造または組織を示すものではなく、説明される機能を提供するための適切な手段への言及であると考えられたい。

【0361】

本発明は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせを含む任意の適切な形態で実施することができる。本発明は、１つ以上のデータプロセッサおよび／またはデジタル信号プロセッサ上で動作するコンピュータソフトウェアとして少なくとも部分的に実装されてもよい。本発明の実施形態の要素および構成要素は、任意の適切な方法で物理的、機能的、および論理的に実装され得る。実際には、機能は、単一のユニット、複数のユニット、または他の機能ユニットの一部として実装されてもよい。したがって、本発明は、単一のユニットとして実装されてもよく、または複数の異なるユニット、回路、およびプロセッサの間で物理的および機能的に分散されてもよい。

【0362】

いくつかの実施形態に関連して本発明を説明したが、本発明は明細書に記載される具体的形態に限定されない。本発明の範囲は添付の特許請求の範囲によってのみ限定される。さらに、ある特徴が特定の実施形態に関連して記載されているように見えたとしても、当業者は、上記実施形態の様々な特徴が本発明に従って組み合わせられ得ることを認識するであろう。請求項において、備える、含む等の用語は他の要素またはステップの存在を排除するものではない。

【0363】

さらに、個別に列挙されていたとしても、複数の手段、要素、回路、または方法ステップは、例えば、単一の回路、ユニット、またはプロセッサによって実施されてもよい。さらに、個々の特徴が異なる請求項に含まれていたとしても、これらは好適に組み合わされ得、異なる請求項に含まれていることは、特徴の組み合わせが実現不可能であるおよび／または有利でないことを意味するものではない。また、１つのクレームカテゴリー内にある特徴が含まれているからといって、その特徴がこのカテゴリーに限定されるとは限らず、特徴は適宜、他のクレームカテゴリーに等しく適用可能である。さらに、請求項における特徴の順序は、特徴が作用すべき特定の順序を指すものではなく、特に、方法クレームにおける個々のステップの順序はステップをその順序で実行しなければならないことを意味しない。ステップは任意の適切な順序で実行され得る。また、単数形の表現は複数形を排除するものではない。したがって、「ａ」、「ａｎ」、「第１の」、「第２の」などの表現は複数を排除するものではない。特許請求の範囲内の参照符号は明瞭さのための例に過ぎず、請求項の範囲を如何ようにも限定するものではない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【国際調査報告】