JP2024540094A - ドップラー効果モデリングを制御するための方法、装置、およびシステム - Google Patents

Abstract

ユーザ側で６自由度（６ＤｏＦ）環境のためのオーディオコンテンツをレンダリングするときにドップラー効果をモデル化する方法が記載される。特に、本方法は、ピッチ係数修正値の許容範囲を示す１つまたは複数の第１のパラメータの第１のパラメータ値を取得することを備え得る。本方法は、モデル化されるべきドップラー効果の所望の強度を示す第２のパラメータの第２のパラメータ値を取得することをさらに含み得る。本方法は、所定のピッチ係数修正関数を用いて、オーディオコンテンツにおけるリスナと音源との間の相対速度と、第１及び第２のパラメータ値とに基づいてピッチ係数修正値を決定することを更に有してもよい。特に、所定のピッチ係数修正関数は、第１及び第２のパラメータを有してもよく、相対速度をピッチ係数修正値にマッピングするための関数であってもよい。最後に、本方法は、ピッチ係数修正値に基づいて音源をレンダリングすることを含んでもよい。
【選択図】図４

Description

関連出願の相互参照
本出願は、２０２１年１０月２９日に出願された米国仮出願第６３／２７３，１８５号（参照番号：Ｄ２１０９２ＵＳＰ１）の優先権を主張する。

本開示は、ドップラー効果モデリングの一般的な分野に関し、より具体的には、例えば、仮想現実または拡張現実環境で使用するための、ドップラー効果モデリングを制御するための方法および装置に関する。

一般的に言えば、ドップラー効果（またはドップラーシフト）という用語は、典型的には、波源（例えば、音源）に対して移動している観測者（例えば、リスナ）に対して波（例えば、音波）の周波数の変化があるときに経験される音声効果を指すために使用される。より具体的には、ドップラー効果は、一般に、波源（例えば、緊急車両のサイレン）が観測者に接近すると、（周波数または知覚される周波数を示す一般に使用される尺度である）ピッチが高くなり、波源が通過してさらに離れると、ピッチが低くなると知覚され得る。

今日、ドップラー効果は、例えば仮想現実（ＶＲ）及び／又は拡張現実（ＡＲ）シナリオ（例えばゲーム）において広く採用されている６自由度（６ＤｏＦ）環境における動的シーンのオーディオレンダリングの重要な態様として考えられ始めている。大まかに言えば、オーディオ処理（例えばレンダリング）のコンテキスト内で、ドップラー効果は一般に、オーディオ・ピッチ係数修正値を使ってモデル化されてもよい。

いくつかの従来の実装形態では、一般に、ドップラー効果の物理的記述または近似に基づいてドップラー効果モデリングを実行することが提案される。しかしながら、そのような手法は、一般に、ピッチ係数修正のための基礎をなす信号処理ユニットの能力（例えば、高い相対速度、特異点などのためのピッチ係数修正値の高い大きさ）を考慮するための手段または能力も、コンテンツ作成者の意図（または言い換えれば、主観的リスニング体験）に従ってピッチ係数修正値（すなわち、ドップラー効果の強度を表す）を制御するための手段または能力も有しない。

より具体的には、仮想現実および／または拡張現実環境などの６ＤｏＦ環境のためのオーディオコンテンツをレンダリングするときに、ドップラー効果モデリングを実行する（制御する）技法が必要とされている。

上記に鑑みて、本開示は、概して、６自由度（６ＤｏＦ）環境のためのオーディオコンテンツをレンダリングするときにドップラー効果をモデル化する方法、６ＤｏＦ環境のためのオーディオコンテンツをレンダリングするときにドップラー効果をモデル化する際に使うパラメータをエンコーディングする方法、ならびに、それぞれの独立請求項の特徴をもつ、対応するオーディオレンダラ、エンコーダ、プログラムおよびコンピュータ可読記憶媒体を提供する。

本発明の第１の態様によれば、６ＤｏＦ環境のためのオーディオコンテンツをレンダリングするときにドップラー効果をモデル化する方法が提供される。本方法は、ユーザ側で、または言い換えれば、ユーザ（デコーディング）側環境において実行され得る。

特に、本方法は、ピッチ係数修正値の許容範囲を示す１つまたは複数の第１のパラメータの第１のパラメータ値を取得することを備え得る。ピッチ係数修正値の許容範囲は、例えば、上限（例えば、境界）および／または下限（例えば、境界）を使用することによって示され得る。本方法は、モデル化されるべきドップラー効果の所望の強度（又は、場合によっては「アグレッシブネス」とも呼ばれる）を示す第２のパラメータの第２のパラメータ値を取得することを更に含み得る。本方法は、所定のピッチ係数修正関数を用いて、オーディオコンテンツにおけるリスナと音源との間の相対速度と、第１及び第２のパラメータ値とに基づいてピッチ係数修正値を決定するステップを更に有してもよい。特に、所定のピッチ係数修正関数は、第１および第２のパラメータを有してもよく（または、言い換えれば、とりわけ、第１および第２のパラメータを入力として取ってもよく）、相対速度をピッチ係数修正値にマッピングするための関数であってもよい。特に、当業者によって理解され認識されるように、ピッチ係数修正値は、ピッチを適切に修正（例えば、シフト）するために一般的に使用される値（おそらくは、任意の適切な形式で表される）とみなされてもよく、それによって、６ＤｏＦ環境におけるドップラー効果の適切かつ適切なモデリング及びオーディオコンテンツのレンダリングを可能にする。最後に、本方法は、（決定された）ピッチ係数修正値に基づいて音源をレンダリングすることを含んでもよい。

言い換えると、広い意味で、本開示は、概して、（例えば、６ＤｏＦ環境においてオーディオコンテンツをレンダリングするときに）ドップラー効果をモデル化するために、相対速度を対応するピッチ係数修正値にマッピングするために、予め定義された（または所定の／予め実装された）ピッチ係数修正関数を利用する方法を提案する。以下でより詳細に説明するように、そのような所定のピッチ係数修正関数は、一般に満たされるべきいくつかの要件（または特性）を前提として、任意の好適な手段で実装され得る。具体的には、所定のピッチ係数修正関数は、複数のパラメータを有してもよく（又は、言い換えれば、複数のパラメータを入力として取得してもよく）、その中には、（少なくとも）ピッチ係数修正値の許容範囲を示す第１のパラメータと、モデル化されるべきドップラー効果の所望の強度（アグレッシブネス）を示す第２のパラメータとがある。次いで、実際には、提案される方法が、例えば、あらかじめ定義されたピッチファクタ修正関数が展開されているオーディオレンダリングデバイス（または単にオーディオレンダラと呼ばれる）によって実行されているとき、オーディオレンダリングデバイスは、それぞれ第１および第２のパラメータに対応する第１および第２のパラメータ値を取得するように構成され得る。第１および第２のパラメータ値を取得することは、様々な要件および／または実装形態に応じて、任意の適切な手段で実行され得る。例えば、いくつかの可能な場合には、第１および第２のパラメータ値は、エンコーディングデバイスから受信されたビットストリームから導出（または単に抽出）され得、または、いくつかの他の可能な場合には、ファイルまたはルックアップテーブル（ＬＵＴ）から取得（または単に読み出し）され得る。このように、特にピッチ係数修正関数を適用することによって、ドップラー効果をモデル化するためのピッチ係数修正値は、リスナと音源との間の相対速度に基づいて、また第１および第２のパラメータ値に基づいて決定され得る。

上述のように構成されて、提案される方法は、６ＤｏＦ環境のためのオーディオコンテンツをレンダリングするときにドップラー効果モデリングを実行する（例えば、制御する）ための効率的で柔軟なメカニズムを提供することができ、同時に、ピッチ係数修正（例えば、高い相対速度、特異点などのためのピッチ係数修正値の高い大きさ）のための（例えば、オーディオレンダラの）基礎をなす信号処理ユニットの（許容可能なまたは許容可能な）能力と、コンテンツ作成者の意図（言い換えれば、主観的なリスニング体験）に従って（例えば、モデル化されるべきドップラー効果の所望の強度／アグレッシブネスを表す）（所望の）ピッチ係数修正値を制御する可能性との両方を考慮に入れ、それによって、（リスナ側、例えば、ＶＲ環境でゲームをプレイするユーザにおいて）知覚されるリスニング体験を改善する。

さらに、ピッチ係数修正関数は、とりわけ、第１および第２のパラメータの両方の値を入力として取るあらかじめ定義された関数としてすでにあらかじめ実装されているので、レンダリング条件が変化する（例えば、異なる処理能力をもつ異なるレンダラが展開される、異なる著者によっておよび／または異なるシーンのために作成された異なるオーディオコンテンツなど）たびに新しいピッチ係数修正関数を再設計（または再実装）する必要は概してない。むしろ、一般に、ピッチ係数修正値の対応する許容可能な範囲（例えば、限度）およびモデル化されるべきドップラー効果の対応する所望の強度をそれぞれ表す異なる第１および第２のパラメータ値を（例えば、エンコーディング側でエンコーディングされたビットストリームを使用して）通信することのみが必要とされる。したがって、いくつかの可能なシナリオでは、事前定義されたピッチ係数修正関数は、様々な要件および／または実装形態に応じて、様々なソフトウェアおよび／またはプラットフォームにおいて展開され得、必要な場合にさらにカスタマイズされ得る、（第１のパラメータおよび第２のパラメータを所望のドップラー効果をモデル化するための入力とみなす）プラグインまたはライブラリと同じくらい単純に実装され得る。それによって、ピッチ係数変更関数の不必要な再設計／再実装が回避され、オーディオレンダリングプロセス全体における効率がさらに改善される。

いくつかの例示的な実装形態では、相対速度は、リスナと音源との位置（例えば、相対位置）に基づいて計算され得る。例えば、いくつかの可能な場合において、相対速度は、音源とリスナとの間の相対距離の変化率から（例えば、１次導関数をとることによって）、それらのそれぞれの位置に基づいて決定され得る。当然ながら、当業者によって理解され認識されるように、相対速度を取得または計算するために、任意の他の適切な手段が採用されてもよい。

いくつかの例示的な実装形態では、１つまたは複数の第１のパラメータは、ピッチ係数修正値の許容範囲の上限および／または下限を示すパラメータを備え得る。

いくつかの例示的な実装では、ピッチ係数修正値の許容範囲は、オーディオコンテンツをレンダリングするオーディオレンダラの処理能力を反映していてもよい。すなわち、大まかに言えば、ピッチ係数修正値の許容範囲（例えば、上限および／または下限）を示す第１のパラメータは、レンダリングデバイス（例えば、オーディオレンダラ）、またはより正確には、ドップラー効果をモデル化するためのそのレンダリングデバイスの基礎をなす処理ユニットによってサポートされる処理能力の範囲を表すものとして、ある観点で見ることができる。

いくつかの例示的実装では、そのようにして得られたピッチ係数修正値の許容範囲がオーディオレンダラ（の基礎をなす処理ユニット）によってサポートされることができない場合、ピッチ係数修正値のデフォルト範囲がそのオーディオレンダラによって使われてもよい。そのようなシナリオの例示的な例は、（比較的）より強力なレンダリングデバイス（例えば、ゲームコンソールまたは専門的なワークステーション）を当初はターゲットにするように設定された（例えば、エンコーディングデバイスによって）ピッチ係数修正値の範囲を取得する（例えば、受信する）、（比較的）制限された処理（レンダリング）能力をもつモバイルデバイス（例えば、モバイルフォン）のシナリオであり得る。そのようなシナリオでは、レンダリングプロセスに予期せずまたは悪影響を及ぼすことを回避するために、モバイルデバイスが、取得されたサポートされていないパラメータ値を使用する代わりに、例えば、そのモバイルデバイスの実際の処理（レンダリング）能力をより正確に反映するように（モバイルデバイスの）製造業者によって設定され得る（例えば、最初に取得されたより広い範囲に入る）デフォルト範囲パラメータ設定を適用することがより実用的であると見なされ得る。

いくつかの例示的な実装形態では、第２のパラメータは、モデル化されるべきドップラー効果のアグレッシブさを反映すると見なされ得るピッチ係数修正関数の勾配（または、いくつかの可能な場合には、「強度」とも呼ばれる）を制御し得る。

いくつかの例示的実装では、受領されたビットストリームからオーディオコンテンツが抽出されてもよい。ビットストリームは、例えば、任意の適切な手段を使用することによって、任意の適切なフォーマットで、エンコーディングデバイスによってエンコーディングされていることがある。したがって、様々な実装形態に応じて、第１および第２のパラメータ値は、ビットストリーム中に含まれる指示から導出（例えば、抽出、デコーディングなど）され得る。いくつかの可能な場合において、第一および第二のパラメータ値の指示は、当業者によって理解および認識されるように、ビットストリームにおいてラベル（またはフィールド）としてエンコーディングされてもよい。

もちろん、いくつかの他の可能な実装形態では、オーディオコンテンツと第１および第２のパラメータとが（例えば、２つの別個のビットストリームから）別個に取得され得ることも可能である。

いくつかの例示的な実装では、第二のパラメータ値はオーディオコンテンツのコンテンツ作成者によって設定されてもよい。特に、第２のパラメータ値は、オーディオコンテンツのコンテンツ作成者によって、そのコンテンツ作成者の意図に従って設定されてもよい。したがって、広い意味では、第２のパラメータ値は、コンテンツ作成者によって目標とされる（およびコンテンツ作成者によって制御される）主観的なリスニング体験を反映すると見なされてもよい。

いくつかの例示的な実装形態では、第２のパラメータ値は、所望のドップラー効果強度についての現実世界の基準および／または芸術的予想をモデル化することによって設定され得る。当然ながら、当業者によって理解され認識されるように、第２のパラメータ値を決定し設定するための任意の他の適切な実装も可能であり得る。
いくつかの例示的な実装形態では、ピッチ係数修正値に基づいてオーディオコンテンツをレンダリングすることは、ピッチ係数修正値に基づいてオーディオコンテンツ中の音源のピッチを調整することを備え得る。

いくつかの例示的な実装形態では、正のピッチ係数修正値は、概して、音源のピッチを増加させることを示し得る。同様に、負のピッチ係数修正値は、一般に、音源のピッチを減少させることを示し得る。

いくつかの例示的な実装形態では、音源のピッチ調整は、半音の単位で実行され得る。例えば、ピッチ係数修正値２は、単に、音源のピッチを２半音だけ増加させることを意味してもよく、対応して、ピッチ係数修正値－２は、単に、音源のピッチを２半音だけ減少させることを意味してもよい。

いくつかの例示的な実装形態では、ピッチ係数修正関数は、一般化されたロジスティック関数に基づいて実装され得る。すなわち、ピッチ係数修正関数を実装することは、例えば、ロジスティック関数、または具体的には一般化ロジスティック関数を適宜修正することを含むことができる場合がある。しかしながら、以下の説明を考慮してより明らかになるように、そのように実装されたピッチ係数修正関数がいくつかの特性を満たすという条件で、任意の他の好適な手段（例えば、公式または式）がそのようなピッチ係数修正関数を実装するために使用され得ることに留意することは価値があり得る。

いくつかの例示的な実装形態では、ピッチ係数修正関数は、相対速度に対して連続的かつ単調であること、１つまたは複数の第１のパラメータによって制御される漸近的限界を有すること、ゼロ相対速度においてゼロピッチ係数修正値をもたらすこと、および／または第２のパラメータによって制御されるゼロ速度の近傍において勾配を有することのうちの１つまたは複数の特性を有し得る。当業者によって理解され認識されるように、いくつかの可能な実装形態では、任意の他の適切な特性も必要であり得る。

いくつかの例示的な実装形態では、ピッチ係数修正関数Ｆは、

として実装され得る。
ここで、νは、相対速度を表し、ｌ＝｛ｌ_ｌ，ｌ_ｈ｝は、第１のパラメータを表し、ｌ_ｌは、範囲の下限を示し、ｌ_ｈは、範囲の上限を示し、ｓは、第２のパラメータを表す。しかしながら、そのような機能は、単に例として提供され、いかなる種類の限定としても提供されない。既に上述したように、当業者は、ピッチ係数変更関数Ｆは、任意の他の適切な方法でも実装され得る。

いくつかの例示的な実装では、本方法はさらに、さまざまな実装またはユーザー側環境（例えばコンピュータ、ゲーム・コンソール、モバイルなど）に依存して、レンダリングされた音源を（例えばオーディオコンテンツの一部として）スピーカーまたはヘッドフォン（または他の任意の好適な再生デバイス）に、ユーザーへの再生のために出力することを含んでいてもよい。

本発明の第２の態様によれば、６自由度（６ＤｏＦ）環境のためのオーディオコンテンツをレンダリングするときにドップラー効果をモデル化する際に使用するためのパラメータをエンコーディングする方法が提供される。この方法によって（例えばエンコーダ側でまたはエンコーディング側環境において）そのようにエンコーディングされたパラメータは、（例えばユーザー側でまたはユーザー／デコーディング側環境において）６ＤｏＦ環境についてオーディオコンテンツをレンダリングするときにドップラー効果をモデル化するために、前述の第１の態様およびその例示的実装形態において記述された方法のいずれによっても使われてもよい。

特に、本方法は、ピッチ係数修正値の許容範囲を示す１つまたは複数の第１のパラメータの第１のパラメータ値を決定する（例えば、計算する、設定するなど）ことを備え得る。本方法は、モデル化されるべきドップラー効果の所望の強度（または、場合によっては、「アグレッシブネス」とも呼ばれる）を示す第２のパラメータの第２のパラメータ値を決定する（例えば、計算する、設定するなど）ことをさらに備え得る。最後に、本方法は、第１及び第２のパラメータ値の指示をエンコーディングするステップを更に有してもよい。具体的には、上記で示したように、第１および第２のパラメータ値は、オーディオコンテンツのリスナと音源との間の相対速度を、所定のピッチ係数修正関数に基づいてピッチ係数修正値にマッピングするために使用されてもよく、ピッチ係数修正値は、音源をレンダリングするために使用されてもよく、所定のピッチ係数修正関数は、第１および第２のパラメータを有してもよく、相対速度をピッチ係数修正値にマッピングするための関数であってもよい。

上述のように構成されて、提案される方法は、６ＤｏＦ環境のためのオーディオコンテンツをレンダリングするときにドップラー効果モデリングのために使用されるパラメータをエンコーディングするための効率的で柔軟な機構を提供することができ、同時に、ピッチ係数修正のための（オーディオレンダラ側の）基礎となる信号処理ユニットの（許容可能な又は許容可能な）能力（例えば、高い相対速度、特異点などに対するピッチ係数修正値の高い大きさ）と、コンテンツ作成者の意図（言い換えれば、目的とする主観的なリスニング体験）に従って（所望の）ピッチ係数修正値（すなわち、ドップラー効果の所望の強度を表す）を制御する可能性との両方を考慮に入れ、それによって、（リスナ側で）知覚されるリスニング体験を改善する。

さらに、上述したように、ピッチ係数修正関数は、第１および第２のパラメータを入力として取る（レンダラ側での）所定の関数としてすでに実装され、展開されているので、一般に、レンダリング条件が変化する（例えば、異なる処理能力をもつ異なるレンダラが展開される、異なる人によっておよび／または異なるシーンのために作成された異なるオーディオコンテンツなど）たびに新しいピッチ係数修正関数を再設計（または再実装）する必要はない。代わりに、エンコーディング側は、ピッチ係数修正値の対応する許容範囲（限度）とモデル化されるべきドップラー効果の対応する所望の強度とをそれぞれ表す（例えば、ビットストリーム中でエンコーディングされた）異なる第１および第２のパラメータ値を通信するだけであり得る。したがって、いくつかの可能なシナリオでは、あらかじめ定義されたピッチ係数修正関数は、様々な要件および／または実装形態に応じて、様々なソフトウェアおよび／またはプラットフォームにおいて展開され得、必要な場合にさらにカスタマイズされ得る（レンダラ側の）プラグインと同じくらい単純に実装され得る。それによって、ピッチ係数変更関数の不必要な再設計／再実装が回避され、オーディオレンダリングプロセス全体における効率がさらに改善される。

いくつかの例示的実装では、第一および第二のパラメータ値の指示は、ビットストリームにおいてラベル（またはフィールド）としてエンコーディングされてもよい。当業者によって理解され認識されるように、そのような指示は、（所定のピッチ係数修正関数が展開されている）対応するレンダリング側デバイスが必要に応じて第１および第２のパラメータ値を導出することを可能にされ得る限り、任意の他の適切な手段においても実装され得る。いかなる種類の限定ではなく例として、エンコーディング方法が、例えばＡＲ／ＶＲゲーム環境において（ゲーム／制御）エンジン（または、時にはゲーム制御論理エンジンとも呼ばれる）によって実行され得るいくつかの可能な場合において、第１および第２のパラメータ値（またはそのそれぞれの指示）は、必ずしも常にビットストリームにエンコーディングされる必要はなく（例えば、場合によっては、ゲームエンジンが、典型的には、レンダリングおよび／またはリスニングコンポーネントと同じ環境に、例えばＰＣの形態で配置され得るという理由により）、オーディオコンテンツと一緒にまたはオーディオコンテンツとは別に、任意の他の適切なフォーマットで（または、いくつかの可能な場合にはプレーンまたはクリアパラメータ値としてさえ）エンコーディング（またはカプセル化）され得ることが理解できる。

いくつかの例示的実装では、第一および第二のパラメータ値の指示は、オーディオコンテンツと一緒に単一のビットストリームにおいてまたは別個のビットストリームとしてエンコーディングされてもよい。

いくつかの例示的な実装形態では、第１および第２のパラメータ値は、上記で示したように、コンテンツ作成者またはゲームエンジンによって決定され得る。

本発明の第３の態様によれば、プロセッサと、プロセッサに結合されたメモリとを含むオーディオレンダラ（レンダリング装置）が提供される。プロセッサは、オーディオレンダラに、第１の態様において説明された例示的な方法のいずれかに従ってすべてのステップを実行させるように適合され得る。

本発明の第４の態様によれば、プロセッサと、プロセッサに結合されたメモリとを含むエンコーダ（エンコーダ装置）が提供される。プロセッサは、第２の態様で説明された例示的な方法のいずれかに従って、エンコーダにすべてのステップを実行させるように適合され得る。

本発明の第５の態様によれば、コンピュータプログラムが提供される。コンピュータプログラムは、プロセッサによって実行されると、プロセッサに、本開示全体を通して説明される方法の全てのステップを実施させる命令を含み得る。

本発明の第６の態様によれば、コンピュータ可読記憶媒体が提供される。コンピュータ可読記憶媒体は、上述のコンピュータプログラムを記憶してもよい。

装置の特徴および方法のステップは、多くの方法で交換され得ることが理解されるであろう。特に、開示された方法の詳細は、当業者が理解するように、対応する装置（又はシステム）によって実現されることができ、その逆も同様である。さらに、方法（複数可）に関してなされた上記の記述のいずれも、対応する装置（またはシステム）に同様に適用され、その逆も同様であることが理解される。

本発明の例示的な実施形態は、添付の図面を参照して以下に説明される。

相対速度とピッチ修正値との間の例示的な関数マッピングを示す概略図である。 本発明の実施形態によるドップラー効果モデリング範囲の異なる設定に対する相対速度とピッチ修正値との間の例示的な関数マッピングを示す概略図である。 本発明の実施形態による、ドップラー効果モデリング強度の異なる設定に対する相対速度とピッチ修正値との間の例示的な関数マッピングを示す概略図である。 本発明の実施形態による方法の一例を示す概略フローチャートである。 本発明の実施形態による方法の別の例を示す概略フローチャートである。 従来のドップラー効果モデリングアプローチによって処理されたオーディオ信号と、本発明の実施形態に従って処理されたオーディオ信号との間の例示的な比較を概略的に示す。 従来のドップラー効果モデリングアプローチによって処理されたオーディオ信号と、本発明の実施形態に従って処理されたオーディオ信号との間の例示的な比較を概略的に示す。 従来のドップラー効果モデリングアプローチによって処理されたオーディオ信号と、本発明の実施形態に従って処理されたオーディオ信号との間の別の例示的な比較を概略的に示す。 従来のドップラー効果モデリングアプローチによって処理されたオーディオ信号と、本発明の実施形態に従って処理されたオーディオ信号との間の別の例示的な比較を概略的に示す。 本発明の実施形態による方法を実行するための例示的な装置のブロック図である。 本発明の実施形態による方法を実行するための例示的な装置のブロック図である。

図面及び以下の説明は、例示のみを目的とした好ましい実施形態に関する。以下の説明から、本明細書に開示される構造および方法の代替実施形態が、特許請求されるものの原理から逸脱することなく採用され得る実行可能な代替形態として容易に認識されることに留意されたい。

ここで、いくつかの実施形態を詳細に参照し、その例を添付の図面に示す。実行可能な場合はいつでも、類似または同様の参照番号が図中で使用され得、類似または同様の機能を示し得ることに留意されたい。図面は、開示されたシステム（または方法）の実施形態を、例示のみを目的として示す。当業者は、本明細書に記載された原理から逸脱することなく、本明細書に示された構造および方法の代替の実施形態を使用することができることを、以下の説明から容易に認識するであろう。

さらに、図において、実線または破線または矢印などの接続要素が、２つ以上の他の概略要素間の接続、関係、または関連を示すために使用される場合、任意のそのような接続要素の不在は、接続、関係、または関連が存在し得ないことを暗示することを意味しない。言い換えれば、要素間のいくつかの接続、関係、または関連付けは、本発明を不明瞭にしないように、図面に示されていない。加えて、説明を容易にするために、単一の接続要素が、要素間の複数の接続、関係、または関連付けを表すために使用される。例えば、接続要素が信号、データ、または命令の通信を表す場合、そのような要素は、必要に応じて、通信に影響を及ぼすための１つまたは複数の信号経路を表すことを当業者は理解されたい。

上記のように、「ドップラー効果」または「ドップラーシフト」という用語は、一般に、波源（例えば、音源）に対して移動している観測者（例えば、リスナ）に対して波（例えば、音波）の周波数の変化があるときに経験されるオーディオ効果を指すために使用される。概して、ドップラ効果は、波源が観測者に対して移動しているときはいつでも観測され得る。ドップラー効果は、移動する波源によって生じる効果として説明することができ、波源が近づいてくる観測者には周波数の明らかな上方シフトがあり、波源が遠ざかっていく観測者には周波数の明らかな下方シフトがある。それにもかかわらず、この効果は、ソースの周波数の実際の変化のために生じないことに留意することが重要である。

ドップラー効果は、当業者によって理解され認識され得るように、任意のタイプの波、水波、音波、光波などについて観察され得る。ドップラー効果が一般に知覚され得る例示的なシナリオは、警察車両または緊急車両が高速道路上の聞き手に向かって移動している事例であり得る。自動車がサイレンに近づくにつれて、サイレン音のピッチ（周波数を示すために一般的に使用される尺度）は高く（高く）なり、次いで、自動車が通過して遠くに移動した後、サイレン音のピッチは低く（低く）なる。

また、上述したように、ドップラー効果は、最近、例えば、仮想現実（ＶＲ）及び／又は拡張現実（ＡＲ）シナリオ（例えば、ゲーム、没入型コンテンツ等）において広く採用されている６自由度（６ＤｏＦ）環境における動的シーンのオーディオレンダリングにおける重要な態様として考えられ始めている。

大まかに言えば、ハーフステップまたはハーフトーンとも呼ばれる半音は、一般に、ほとんどの音調音楽で一般に使用される最小の音程であり、ハーモニーで鳴らされるときに最も不協和音であると考えられる。一般的に、半音は、１２音スケール上の２つの隣接する音符間の間隔として定義される。すなわち、オクターブを１２等分したテンパー調の音階に基づいて設計された楽器の多くは、任意の２つの半音（ハーフステップ）の周波数比が、概ね２の１２乗根となる。

オーディオ処理（例えば、オーディオレンダリング）のコンテキスト内で、ドップラー効果は、一般に、オーディオピッチ係数（シフト）修正値（本開示全体を通して、単にｐとして示されることもある）を使用してモデル化され得る。したがって、半音の一般的な概念に従って、本発明のいくつかの可能な実装形態では、以下でより詳細に説明するように、正のピッチ係数（シフト）修正値は、一般に、特に半音の単位での、音源のピッチの増加を意味し得る。例えば、ピッチ係数修正値２は、単に、音源の２半音の増加に変換され得る。これに対応して、負のピッチ係数（シフト）修正値は、一般に、音源のピッチ（半音単位）の減少を意味することができる。しかしながら、当業者が理解するように、ピッチ係数修正値のための代替的なフレームワーク及びユニットも、本発明の文脈において実現可能であり得る。

ドップラー効果をモデル化するためのいくつかのアプローチは、ドップラー効果の物理的記述および／または近似に基づくモデル化を含み得る。したがって、それらの手法は、一般に、ピッチ係数修正のための基礎をなす信号処理ユニットの能力（例えば、高い相対速度、特異点についてのピッチ係数修正値の高い大きさ）を考慮するための手段も、コンテンツ作成者の意図（言い換えれば、主観的リスニング体験）に従ってピッチ係数修正値（すなわち、ドップラー効果の強度を表す）を制御するための手段も有しない。

その観点から、本発明は、一般に、１）相対速度（本開示を通してνとしても示される、リスナおよび音源位置に基づいて計算される）、２）信号処理ユニットによってサポートされるピッチ係数修正値の範囲（本開示を通してｌとしても示される）、および３）コンテンツ作成者設定（例えば、本開示を通してｓとしても示される、（従来の）モデリング方程式、現実世界の基準、ドップラー効果強度に対する芸術的期待などに基づいて、１）～３）の入力データに知覚的に対応し得る適切なピッチ修正値ｐを見つける）を仮定して、問題に対処しようとするものであり得る。特に、いくつかの可能な実装形態では、ピッチ係数修正値ｌの範囲は、それ自体が下限ｌ_ｌおよび上限ｌ_ｈを含んでもよく、したがって、範囲ｌは、ｌ＝｛ｌ_ｌ，ｌ_ｈ｝として示されてもよい。

上記の問題に対処するために、広い意味で、本発明は、一般に、信号処理ユニットの制限ｌおよびユーザ調整可能な設定ｓを考慮して、ピッチ係数修正関数Ｆを実施して相対速度ｖをピッチ係数修正値ｐにマッピングすることを検討することを提案する。いくつかの可能な実装形態では、ピッチ係数修正関数Ｆは、修正された一般化されたロジスティック関数として実装され得る。

このようなピッチ係数変更関数Ｆを実施するための可能な例（いかなる種類の限定も意図しない）は、以下の通りであってもよい。

ここで、上に示したように、νは、リスナと音源との間の相対速度を示し、ｌ＝｛ｌ_ｌ，ｌ_ｈ｝は、モデリングを実行するための基礎となる信号処理ユニット（例えば、オーディオレンダラに配置される）によってサポートされるピッチ係数修正値の範囲を示し、ｌ_ｌは、下限を表し、ｌ_ｈは、上限を表し、ｓは、コンテンツ作成者設定（例えば、（従来の）モデリング方程式、現実世界の基準、ドップラー効果強度に対する芸術的な期待などに基づく）を示し、ｅは数学的定数（オイラー数）である。

式（１）の任意の等価な表現は、本発明によって包含されるものとする。例えば、当業者には理解されるように、ピッチ係数修正値のサポートされる範囲は、本発明によって包含されると考えられる２つのパラメータの任意の適切な組み合わせによって表現されてもよい。例えば、下限ｌ_ｈ及び上限ｌ_ｈを使用する代わりに、いずれかの限界の指示と共に許容範囲の大きさの指示Δｌ＝ｌ_ｈ－ｌ_ｌなどを使用することもできる。この場合、例えば、ｌ_ｈ＝Δｌ＋ｌ_ｌまたはｌ_ｌ＝ｌ_ｈ－Δｌが成立し、上記の式（１）を修正するために使用され得る。

さらに、式（１）のオイラー数も、１より大きい代替定数によって、またはベキ指数の符号を交換して、１より小さい代替定数によって置き換えることができる。

加えて、当業者によって理解され認識されるように、ピッチ係数修正関数Ｆは、様々な要件および／または実装形態に応じて、上記で識別された要件（すなわち、範囲／制限パラメータｌおよびユーザ／コンテンツ作成者設定ｓ）が考慮されるという条件の下で、任意の他の好適な形態／式で定義されてもよい。ピッチ係数修正関数Ｆの特性は、図面に付随する以下の説明を考慮するとより明らかになるであろう。

特に、広い意味では、本発明において提案されるアプローチを適用することによって、信号処理ユニット制限ｌおよびユーザー設定ｓのパラメータの値を、エンコーダ側で調整する（および、場合によっては、例えばカプセル化して、ビットストリームに入れる）ことが可能にされてもよい。したがって、コンテンツ作成者は、ドップラー効果モデリングをオーディオレンダラの能力に適合させるためにドップラー効果モデリングの制御を確立し、同時に、コンテンツ作成者自身の好みに従ってドップラー効果モデリングを調整することも可能にされ得る。

ここで図面に関して、図１は、ドップラー効果をモデル化するための異なるアプローチに基づく、相対速度とピッチ修正値との間の例示的な関数マッピングを示す概略図である。

特に、ｘ軸は、音源と観測者（例えば、６ＤｏＦ環境におけるリスナ）との間の（入力される）相対速度を概略的に示す。音源と観測者／リスナとの間の相対速度は、例えば、リスナおよび音源の位置に基づいて、任意の好適な手段で判定されてもよい。例えば、いくつかの可能な実装形態では、相対速度は、リスナおよび音源の位置（例えば、音源と観測者／リスナとの間の距離）の変化のレート（例えば、１次導関数）に基づいて決定されてもよい。ここで、当業者によって理解され認識されるように、相対速度の負の値は、一般に、音源と観測者／リスナとが互いに接近している（互いに近づいている）ことを意味し、相対速度の正の値は、一般に、音源と観測者／リスナとが互いに（さらに遠く）離れていっていることを意味する。

一方、ｙ軸は、（出力される）ピッチシフト修正値（例えば、半音単位）を模式的に示す。上記に示されたように、いくつかの可能な実装形態では、ピッチシフト修正値の正の値は、一般に、音源のピッチの増加を意味し得、ピッチシフト修正値の負の値は、一般に、音源のピッチの減少を意味し得、例えば、両方とも半音の単位である。

より具体的には、図１のダイアグラム１０１は、例えば（理論的な）数式に基づく、ドップラー効果モデルの（理論的な）基準の例を一般的に示す。ダイアグラム１０１は、概して、ドップラー効果をモデル化するための（理論的な）基準を表すので、このダイアグラムは、例えば、実際のソフトウェア実装には適合しない（又は、換言すれば、６ＤｏＦ環境においてオーディオコンテンツをレンダリングする際の実装には適合しない）ことがあるが、ドップラー効果の「性質」をモデル化するための純粋な数学的例示を表すものとして主に機能するものと見なされ得る。したがって、当業者によって理解され認識されるように、ダイアグラム１０１に示されるような「カットオフ」（おおよそ－３４３ ｍ／ｓ）は、一般に、音速の制限によるものと考えられ得る。同様に、相対速度が（０から）－３４３ ｍ／ｓに近づくときのほぼ無限のピッチ係数修正値により、ダイアグラム１０１が何らかの形で「セグメント化」されているように見える。

一方、ダイアグラム１０２は、可能なアプローチによるドップラー効果のモデル化の例を一般的に表す。そのようなモデル化は、例えば、（理論的）数学的公式の推定（近似）に基づいて実行されてもよい。

さらに、ダイアグラム１０３（実線）は、本発明の実施形態によるドップラー効果の可能なモデル化の例を一般的に示す。上述したように、（所定の）ピッチ係数修正関数Ｆを通じて達成されるドップラー効果のこのモデル化は、複数のパラメータを含み（又は換言すれば、複数のパラメータを入力として取り入れ）、その中には、例えば（従来の）モデル化方程式、現実世界の基準、ドップラー効果強度の芸術的期待などに基づく、信号処理ユニットによってサポートされるピッチ係数修正値の範囲（すなわち、ｌ）及びコンテンツ作成者設定（すなわち、ｓ）がある。

図１に示されるような特定の例では、（例示的なダイアグラム１０３及びダイアグラム１０２からも分かるように）範囲／制限パラメータｌは、例示的に｛－８，８｝に設定され、すなわち、ｌ＝｛ｌ_ｌ，ｌ_ｈ｝＝｛－８，８｝であることに留意されたい。そして、強度／アグレッシブネスパラメータｓは、例示的に０．０１５に設定される。しかしながら、当業者によって理解され認識されるように、パラメータのこれらの値は、（いかなる種類の限定としてではなく）単に可能な例として設定され、様々な要件および／または実装に応じて、任意の他の適切な値が当然ながら使用され得る。

図１の例に明確に示されるように、ダイアグラム１０２（すなわち、ドップラー効果の可能なモデル化を表す）は、一般に、より低い速度範囲（おおよそ０～±１７０ ｍ／ｓ）からより高い速度範囲（おおよそ±１７０ ｍ／ｓより高い）への「粗い」／「激しい」変化（またはトランザクション）を示す。対照的に、ダイアグラム１０３（本開示の実施形態による可能な実装を表す）のそれらの領域におけるトランザクションは、「よりソフト」であるように見える。したがって、（例えば、６ＤｏＦ環境における）リスナによって知覚される（ダイアグラム１０３のドップラー効果モデルに従ってレンダリングされているオーディオコンテンツの）オーディオ品質が改善され得る。

上記のように、少なくとも範囲／制限パラメータｌおよびユーザ／コンテンツ作成者設定ｓが考慮されるならば、ピッチ係数修正関数Ｆを実装するために、（式（１）に例示されたもの以外の）任意の好適な形式／公式が使用され得る。それにもかかわらず、上記の例示された式（１）の性能に匹敵する（例えば、知覚されるオーディオ品質に関して）多かれ少なかれ同様の性能を達成するために、ピッチ係数修正関数Ｆが満たす必要があり得るいくつかの特性に留意することは価値があり得る。

より具体的には、本発明の実施形態によれば、ピッチ係数修正関数Ｆは、以下の１つ以上の特性を有してもよい：
・相対速度に関して連続的で単調であること、
・前記１つ以上の範囲／限界パラメータ（すなわち、ｌ）によって制御される漸近的限界を有すること、
・ゼロ相対速度でゼロピッチ係数修正値をもたらすこと、および／または、
・ゼロ速度の近傍で、アグレッシブネス／強度パラメータ（すなわち、ｓ）によって制御される勾配を有すること。

いくつかの実装形態では、ピッチ係数修正関数Ｆは、上記の特性のすべてを有し得る。

上記の特性は、本発明の実施形態によるピッチ係数修正関数Ｆを実装するダイアグラム１０３にも明確に反映されている。

ここで、異なるパラメータ設定がドップラー効果のモデル化にどのように影響を及ぼすかをより詳細に概略的に示す図２及び図３を参照する。上記に示されるように、広い意味では、信号処理ユニット設定（例えば、ｌ）は、一般に、（例えば、図２に例示されるように）高い相対速度領域においてより関数の漸近的限界に影響を及ぼし、一方、コンテンツ作成者基準設定（例えば、ｓ）は、一般に、（例えば、図３に例示されるように）低い相対速度領域の周りでより関数Ｆの傾きに影響を及ぼすことが理解され得る。

特に、図２は、本発明の実施形態による、ドップラー効果モデリング範囲パラメータｌの異なる設定に対する相対速度とピッチ修正値との間の例示的な関数マッピングを示す概略図である。特に、ドップラー効果の（理論的な）数学的表現である図２のダイアグラム２０１は、図１のダイアグラム１０１と同じであり、そのため、その繰り返しの説明は、簡潔さのために省略され得る。

具体的には、図２に示される例では、ダイアグラム２０２、２０３、および２０４についての範囲／制限パラメータｌ＝｛ｌ_ｌ，ｌ_ｈ｝は、例示的に、それぞれ、ｌ＝｛－８，８｝、ｌ＝｛－４，８｝、およびｌ＝｛－８、４｝に設定される。一方、全てのダイアグラム２０２、２０３、および２０４における勾配パラメータｓは、同じである（任意の好適な値、例えば、０．０１５に設定され得る）。したがって、図２から理解されるように、ダイアグラム２０２、２０３及び２０４は、（特に低速領域において）多かれ少なかれ類似した傾きを示すように見えるが、（出力）ピッチ係数修正値のそれぞれの上限及び／又は限界のみが、範囲／限界パラメータｌ＝｛ｌ_ｌ，ｌ_ｈ｝に依存して異なる。

上述のように、範囲／制限パラメータｌは、一般に、ドップラーモデリングを実行するための（例えば、レンダラ側の）（基礎となる）信号処理ユニットによってサポートされるピッチ係数修正値の範囲を示すように設定される。言い換えると、そのようなパラメータｌは、信号処理ユニット（または、大まかに言えば、レンダラ）の（処理）能力（例えば、ハードウェアおよび／またはソフトウェア能力の観点から）を一般的に表すものと見なされてもよい。さらに、上述したように、ピッチ係数修正関数Ｆは、典型的には、他の入力（例えば、相対速度、コンテンツ作成者設定ｓなど）とともに範囲パラメータｌを（例えば、エンコーディング側から）単に受信するプラグインとして実装され得る（または何らかの種類のライブラリとしてカプセル化され得る）。したがって、いくつかの実装形態では、そのように受信された範囲パラメータｌが、残念ながらレンダラ（の処理ユニット）によって（完全にまたは部分的に）サポートされないことがあることが可能であり得る。そのようなシナリオの例は、（比較的）制限された処理（レンダリング）能力を有するモバイルデバイス（例えば、モバイルフォン）が、レンダリングのためのオーディオコンテンツとともに、（比較的）より強力なレンダリングデバイス（例えば、ゲームコンソール又は専門的なワークステーション）をターゲットとするように（例えば、エンコーダによって）元々設定されている範囲パラメータｌ（例えば、｛－８，８｝）を受信することであり得る。そのような場合、モバイルデバイスが、受信されたサポートされていないパラメータｌ（例えば、｛－８，８｝）を使用するのではなく、デフォルトの範囲パラメータ設定（例えば、｛－４，８｝または｛－８，４｝を適用することがより実用的であり得る。ここで、デフォルト範囲パラメータ設定は、例えば、レンダリングプロセスに予期せず悪影響を及ぼすことを回避するために、そのモバイルデバイスの実際の処理（レンダリング）能力をより正確に反映するように、（モバイルデバイスの）製造業者によって設定され得る。

一方、図３は、本発明の実施形態による、ドップラー効果モデリング強度パラメータｓの異なる設定に対する相対速度とピッチ修正値との間の例示的な関数マッピングを示す概略図である。上記と同様に、ドップラー効果の（理論的な）数学的表現である図３のダイアグラム３０１は、図１のダイアグラム１０１と同じ（及び図２のダイアグラム２０１と同じ）であり、そのため、その繰り返しの説明は、簡潔さのために省略され得る。

図３に示される例において、ダイアグラム３０２、３０３、３０４及び３０５における（例えば、主観的なリスニング体験に対するコンテンツ作成者の意図を表すために主に使用される）傾き／アグレッシブネスパラメータｓは、例示的に、それぞれ、ｓ＝０．０１５、ｓ＝０．０１０、ｓ＝０．００５及びｓ＝０．００２５に設定される。一方、全てのダイアグラム３０２、３０３、３０４、及び３０５における範囲パラメータｌは同じである（これは、任意の適切な値、例えば、｛－８，８｝に設定され得る）。したがって、図３から理解され得るように、ダイアグラム３０２、３０３、３０４および３０５は、（特に低速領域において）変化する傾きを示すように見えるが、（出力）ピッチ係数修正値の（理論的な）上限および／または限界は、多かれ少なかれ類似している。それによって、レンダリングされているオーディオコンテンツにおけるドップラー効果の異なる「強さ」が、例えばコンテンツ作成者の意図に依存して、（例えば６ＤｏＦ環境において）リスナによって知覚されうる。

要約すると、傾き／アグレッシブネスパラメータｓを適切に設定することによって（場合によっては、その後に、パラメータ値を、例えば、ビットストリームまたは他の好適なフォーマットにエンコーディング／カプセル化し、それをユーザ／デコーダ側デバイス、または一般にレンダラに送信または通信することによって）、コンテンツ作成者（またはいくつかの可能な実装形態では「ゲームエンジン」）は、概して、例えば、ドップラー効果モデリングがまったくない状態と（ほぼ）「現実の」（理論的）ドップラー効果モデリング、又は更には過度に強調されたドップラー効果モデリングとの間で、所望されるようにドップラー効果のモデリング挙動を制御する自由を有する。。

したがって、本発明は、コンテンツ作成者に、ユーザ側でのドップラー効果のモデル化に関する追加の自由度を提供すると言える。このように、本発明は、コンテンツ作成者が、オブジェクト特有の方法で、デコーダ／レンダラによるドップラー効果モデリングを選択的に制御またはオーバーライドすることを可能にする。これは、パラメータ値のセットを適切な形式でユーザ／デコーダ側デバイス（最終的には実際のレンダラを含む）に提供することによって達成される。これらのパラメータ値は、ビットストリームにおいてエンコーディングされてもよく、またはレンダラのデータインターフェースに適した、またはそれと互換性のある任意の形態でレンダラに提供されてもよい。

例示的で非限定的な例として、超音速の飛行ジェットを有するＶＲシーンの使用事例が考えられ得る。ドップラー効果モデリング（例えば、図３のダイアグラム３０１に対応する）のための物理学の実際の法則が適用される場合、ユーザ／リスナ（例えば、ゲーム競技者またはＶＲシーンコンテンツの他の受信者）は、おそらく、ジェットからの音をまったく知覚しないはずであり、それは、不快な（ただし、物理的に現実的な）ＶＲ体験（例えば、ゲーム体験）をもたらすことになる。その場合、特に本開示で提案される方法を適用することによって、コンテンツ作成者（又は適切に構成されたゲームエンジン）は、所望のようにドップラー効果のモデル化を制御する自由を有する。言い換えれば、例えば、勾配／アグレッシブネスパラメータｓの値を適切に設定することによって、コンテンツ作成者（またはゲームエンジン）は、必要または所望と考えられるときに、ＶＲ環境においてユーザにとっておそらくあまり正確ではないかまたはあまり現実的ではないが、より快適なリスニング体験をもたらすであろう他のモデリング設定（例えば、ダイアグラム３０２、３０３、３０４または３０５などに対応する）を使用することによって、物理法則に従ってレンダラのドップラーモデリング（例えば、図３のダイアグラム３０１に対応する）をオーバーライドする自由を与えられる。この例は、ＶＲシーンをレンダリングするために使用されるレンダラが、物理法則に従って、または物理法則に基づいて「デフォルト」ドップラー効果モデリングを適用することが可能であると仮定する。いくつかの例示的な実装形態では、このデフォルトのドップラー効果モデリングは、前述の式のためのパラメータ値の特定のセットによって実現され得る。

別の例示的で非限定的な例として、比較的低速度のオブジェクトまたはスピーチを有するオブジェクト（例えば、漫画映画のキャラクタ）には、より弱いドップラー効果モデリングが適用され得るか、または場合によってはドップラー効果モデリングがまったく適用されないことさえあり、他のオブジェクトには、中程度のまたは物理的に正確なドップラー効果モデリングが考慮され得る。例えば、スピーチが付随した非常に高速のオーディオオブジェクト（例えば、飛んでいるスーパーヒーローなど）を有するシーンを考えると、スピーチにはドップラー効果モデリングをほとんど適用しないか、または全く適用しないが、残りの音には少なくともある程度のドップラー効果モデリングを適用することが望ましい場合がある。

図４は、本発明の実施形態による、６ＤｏＦ環境のためのオーディオコンテンツをレンダリングするときのドップラー効果をモデル化する方法４００の例を示す概略的なフローチャートである。実施態様に応じて、方法は、デコーダまたはユーザ側環境（例えば、ＶＲ／ＡＲ環境）において実行されてもよい。

特に、方法４００は、ピッチ係数修正値の許容範囲を示す１つまたは複数の第１のパラメータの第１のパラメータ値を取得する（例えば、受信する）ことによって、ステップＳ４０１において開始し得る。続いて、ステップＳ４０２において、方法４００は、モデル化されるべきドップラー効果の所望の強度を示す第２のパラメータの第２のパラメータ値を取得することを含むことができる。方法４００は、次いで、所定のピッチ係数修正関数を使用して、オーディオコンテンツ内のリスナと音源との間の相対速度、ならびに第１および第２のパラメータ値に基づいてピッチ係数修正値を決定することによって、ステップＳ４０３に進むことができる。ピッチ係数変更関数は、図１～図３に関する上記の説明に従って、任意の適切な形態で、予め定義されてもよく、例えば、プラグインまたはライブラリとして予め実装されてもよい。より具体的には、所定のピッチ係数修正関数は、とりわけ、第１および第２のパラメータを有してもよく（または、言い換えれば、第１および第２のパラメータを（追加の）入力として取ってもよく）、相対速度をピッチ係数修正値にマッピングするための関数であってもよい。最後に、方法４００は、ステップＳ４０４において、ピッチ係数修正値に基づいて音源をレンダリングすることを含んでもよい。実装に依存して、方法は、任意的に、レンダリングされた音源を例えば出力（再生）装置（例えば一つまたは複数のスピーカー、ヘッドフォンなどに対応するまたは含む）に出力する段階をさらに含んでいてもよく、モデル化されたドップラー効果をもつレンダリングされたオーディオ出力（信号）は再生され、ユーザーによって知覚されてもよい。

上述したように、提案される方法４００は、一般に、（例えば、６ＤｏＦ環境においてオーディオコンテンツをレンダリングするときに）ドップラー効果をモデル化するために、相対速度を対応するピッチ係数修正値にマッピングするために、予め定義された（又は所定の／予め実装された）ピッチ係数修正関数を利用してもよい。動作中、実際には、提案される方法４００が、例えば、あらかじめ定義されたピッチ係数修正関数が展開されているオーディオレンダリングデバイス（例えば、ユーザ側環境におけるＡＲ／ＶＲデバイスのオーディオレンダリングデバイス）によって実行されるとき、オーディオレンダリングデバイスは、それぞれ第１および第２のパラメータに対応する第１および第２のパラメータ値を取得するように構成され得る。例えば、オーディオレンダリングデバイスは、フレームごとに、例えば、各フレームについて、または各キーフレームについて、音源のための第１および第２のパラメータ値を取得し得る。したがって、本開示は、ドップラー効果モデリングの時間依存および／またはオブジェクト固有の制御を提供する。

第１および第２のパラメータ値を実際に取得することは、要件および／または実装形態に応じて、任意の適切な方法で実行され得る。例えば、いくつかの可能な実装では、第一および第二のパラメータ値は、（例えば図５に関連して以下の方法５００において記述されるように）エンコーディング装置によってエンコーディングされ送られたビットストリームから導出（例えばデコーディングまたは抽出）されてもよい。いくつかの他の可能な実装形態では、第１および第２のパラメータ値は、ビットストリーム中の指示に基づいて、例えばユーザデバイスのメモリに記憶されたファイルまたはルックアップテーブル（ＬＵＴ）から取得され得る（例えば、単に読み出され得る）。その場合、エンコーディング側環境／装置は、例えば、ビットストリーム内で、プレーン／クリアで、または任意の他の適切な形式でエンコーディングされた、例えば、適切なポインタ、参照またはインデックスを送信してもよい。

実際のオーディオコンテンツ自体がどのようにエンコーディング及び／又は送信されるかに依存して、ユーザ側でのオーディオコンテンツ（例えば、オーディオ信号）のデコーディングは、当業者により理解及び認識されるように、最終的なレンダリング（ステップＳ４０４）が行われる前に、任意の適切な方法で、任意の適切なタイミングで実行されてもよいことにも留意されたい。したがって、実際のオーディオコンテンツ（例えば、オーディオ信号）のデコーディングは、ピッチ係数修正値の決定とは無関係である。

上述のように構成されて、提案される方法は、６ＤｏＦ環境のためのオーディオコンテンツをレンダリングするときにドップラー効果モデリングを実行する（例えば、制御する）ための効率的で柔軟なメカニズムを提供することができ、同時に、ピッチ係数修正（例えば、高い相対速度、特異点などのためのピッチ係数修正値の高い大きさ）のための（オーディオレンダラの）基礎をなす信号処理ユニットの（許容可能なまたは許容可能な）能力を考慮に入れ、コンテンツ作成者の意図（言い換えれば、主観的なリスニング体験）に従って（所望の）ピッチ係数修正値（すなわち、モデル化されるべきドップラー効果の所望の強度／アグレッシブネスを表す）を制御する可能性を与え、それによって、（リスナ側、例えば、ＶＲ環境におけるゲーマーにおいて）知覚されるリスニング体験を改善する。

さらに、ピッチ係数修正関数は、とりわけ、第１および第２のパラメータの両方の値を入力として取る所定の関数としてすでに事前実装されているので、レンダリング条件が変化する（例えば、異なる処理能力をもつ異なるレンダラが展開される、異なるオーディオコンテンツが異なる著者によっておよび／または異なるシーンのために作成されたなど）たびに新しいピッチ係数修正関数を再設計（または再実装）する必要は概してない。むしろ、一般に、ピッチ係数修正値の対応する許容可能な範囲（例えば、限度）およびモデル化されるべきドップラー効果の対応する所望の強度をそれぞれ表す異なる第１および第２のパラメータ値を（例えば、エンコーディング側でエンコーディングされたビットストリームを使用して）通信することのみが必要である。したがって、いくつかの可能なシナリオでは、事前定義されたピッチ係数修正関数は、様々な要件および／または実装形態に応じて、様々なソフトウェアおよび／またはプラットフォームにおいて展開され得るか、あるいは必要な場合にはさらにカスタマイズされ得る、（第１および第２のパラメータを所望のドップラー効果をモデル化するための入力と見なす）プラグインまたはライブラリと同じくらい単純に実装され得る。それによって、ピッチ係数修正関数の不必要な再設計／再実装が回避され、オーディオレンダリングプロセス全体における効率をさらに改善する。

図５は、本発明の実施形態に係る、６ＤｏＦ環境のためのオーディオコンテンツをレンダリングするときにドップラー効果をモデル化する際に使うためのパラメータをエンコーディングする方法５００の別の例を示す概略的なフローチャートである。換言すれば、この方法５００によってそのようにエンコーディングされたパラメータは、図４を参照して記述されたような先行する方法４００によって、６ＤｏＦ環境についてオーディオコンテンツをレンダリングするときにドップラー効果をモデル化するために使われてもよい。すなわち、いくつかの可能な実装では、図５の方法５００によってエンコーディングされたパラメータ値は、例えばユーザー側装置（例えばユーザー側またはデコーディング／レンダリング環境における）に（任意の好適な仕方で）送信または通信されてもよい。ユーザ側デバイスは、パラメータ値を適切に取得し（例えば、ビットストリームからデコーディングし）、図４に関して上記で説明したようにドップラー効果をモデル化する方法４００を実行するように構成され得る。特に、実装に依存して、エンコーディング方法５００は、例えば、コンテンツ作成者からのユーザ入力を利用するエンコーディングデバイス（又は略してエンコーダ）によって、ゲームエンジンによって、等で実行されても良い。

特に、方法５００は、ピッチ係数修正値の許容範囲を示す１つまたは複数の第１のパラメータの第１のパラメータ値を決定することによって、ステップＳ５０１から開始することができる。続いて、ステップＳ５０２において、方法５００は、モデル化されるべきドップラー効果の所望の強度を示す第２のパラメータの第２のパラメータ値を決定することを含むことができる。最後に、方法５００は、ステップＳ５０３において、第１及び第２のパラメータ値の指示をエンコーディングすることを含むことができる。より具体的には、第１および第２のパラメータ値は、オーディオコンテンツのリスナと音源との間の相対速度を、所定のピッチ係数修正関数に基づいてピッチ係数修正値にマッピングするために使用され得る。上記で示したように、ピッチ係数修正値は、音源をレンダリングするために使用されてもよく、所定のピッチ係数修正関数は、第１および第２のパラメータを有してもよく、相対速度をピッチ係数修正値にマッピングするための関数であってもよい。

当業者によって理解され認識されるように、第１及び第２のパラメータ値は、任意の適切な方法でエンコーディングされてもよい。例えば、いくつかの実装形態では、第１および第２のパラメータは、オーディオコンテンツ（例えば、オーディオ信号）とともに単一のビットストリームに、または別個のビットストリームにエンコーディングされ得る。また、実装および／または要件に依存して、第一および第二のパラメータ値は（おそらくはオーディオコンテンツ／信号とともに）、圧縮を伴ってまたは伴わずに、任意の好適なフォーマット、例えばＭＰＥＧオーディオ規格（例えば来たるべきＭＰＥＧ－Ｉオーディオ規格など）のようなオーディオ規格と互換性のあるビットストリームまたはデータ・フォーマットにエンコーディングされてもよい。その場合、第１及び第２のパラメータ値は、当業者によって理解され認識されるように、例えば、ヘッダフィールド、メタデータ等の一部として、適宜エンコーディングされてもよい。いくつかの他の可能な場合において、第１および第２のパラメータ値は、任意の適切なデータフォーマットにプレーン変数（例えば、浮動小数点数）として挿入（カプセル化）され得る。エンコーディングされたビットストリームは、任意の適切な手段を使用することによって、例えば有線または無線の方法で、（例えば、デコーディングまたはレンダリングデバイスを備える）ユーザ環境に送信または通信されてもよい。

さらに、上述のように、本開示で提案されるエンコーディング方法５００は、例えばコンテンツ作成者によるユーザ入力に基づいて実行されてもよい。その場合、ステップＳ５０１における第１のパラメータ値の決定および／またはステップＳ５０２における第２のパラメータ値の決定は、ユーザ入力に基づき得る。同様に、エンコーディング方法５００は、シナリオおよび／または実装に応じて、（ソフトウェアベースの）ゲームエンジン（ゲーム制御論理エンジン）によって実行され得る。この場合、Ｓ５０１および／またはＳ５０２における決定は、例えば、音源のタイプおよび／または速度に基づいて、ゲームエンジンの決定ルーチンに従って実行される。

より具体的には、コンテンツ作成者からのユーザ入力の場合、いくつかの可能な実装では、コンテンツ作成者は、ピッチ係数修正値の許容範囲を示す第一のパラメータについての値を適切に決定し、設定するために、任意の好適な手段を使って、ターゲットデコーディング／レンダリング装置の処理能力またはプロファイルを示す情報を取得してもよい。いくつかの可能な実装形態では、コンテンツ作成者が、それぞれの複数のターゲットデバイスのためのエンコーディングのための（すなわち、それぞれの第１および第２のパラメータ値をもつ）複数のパラメータセットを入力し得、パラメータセットの各々が、それぞれのデコーディング／レンダリングデバイスをターゲットとする第１および第２のパラメータ値を備えることも可能である。その場合、デコーディング／レンダリングデバイスは、デコーディング／レンダリングデバイスに最も適合する（例えば、デコーディング／レンダリングデバイスのプロファイルまたは能力に最も適合する）それぞれの第１および第２のパラメータ値を取得するために、受信されたパラメータセットから単に選ぶかまたは選定し得る。加えて、コンテンツ作成者はまた、様々なシナリオおよび／または実装形態に応じて、ドップラー効果モデリングを適用するかどうかを決定し、適用する場合、（例えば、図３に関して上記で示したように）どの程度まで適用するかを決定する必要があり得る。例えば、いくつかの可能な実装では、コンテンツ作成者は、（グローバル）フラグ（例えば、ビットストリーム内の特定のビットフィールド）を利用および設定して、ドップラー効果のモデル化を（グローバルに）アクティブ化または非アクティブ化してもよい。このフラグは、その後、同様にエンコーディングされる。いくつかの他の可能な実装形態では、コンテンツ作成者は、（グローバル）フラグを使用する代わりに、モデル化されるべきドップラー効果の勾配（アグレッシブネス）を（例えば、所望の強度を示す第２のパラメータの値を制御することによって）単に０に設定し得る。したがって、グローバルなアクティブ化または非アクティブ化と比較して、コンテンツ作成者は、より連続的な方法で（例えば、ドップラー効果モデリングのフレームごとの制御を使用して）ドップラー効果モデリングを制御するためのさらなる自由を有し得る。

一方、エンコーディングタスクを実行する（ソフトウェアベースの）ゲームエンジン（例えば、ＶＲ／ＡＲ環境用）の場合、コンテンツ作成者の役割がゲームエンジンによって置き換えられることを除いて、プロセスは、（人間の）コンテンツ作成者からのユーザ入力に関して上で説明したものとほぼ同じである。より具体的には、ここでは、レンダリング／デコーディングプラットフォームの対応する能力／プロファイルの知識を取得し、加えて、実装および／または要件に応じて、適宜、ドップラー効果のモデル化の勾配／アグレッシブネスを（例えば、任意の好適な論理／アルゴリズム、機械学習、ハードコード等を使用することによって）判定および制御する必要があり得るのは、ゲームエンジン（またはその開発者）である。いくつかの可能な場合において、主に、ＶＲ／ＡＲ環境における（リアルタイム）レンダリングにおいて、（エンコーディングタスクを実行する）ゲームエンジンが、典型的には、デコーディング／レンダリングデバイス／コンポーネントとともに（例えば、同じコンピュータデバイスまたはゲームコンソール内に）配置されるという理由で、第１および第２のパラメータの値は、ビットストリームにエンコーディングされる必要さえなくてもよく、他の適切なフォーマットで（例えば、プレーン変数などとして）デコーディング／レンダリングデバイス／コンポーネントに通信／送信されてもよい。また、シナリオおよび／または実装形態に応じて、パラメータ値は、周期的に（例えば、フレームベースで）またはオンデマンドで、あるいは任意の他の好適な形態で通信され得る。

上述のように構成されて、提案される方法は、６ＤｏＦ環境のためのオーディオコンテンツをレンダリングするときにドップラー効果モデリングのために使用されるパラメータをエンコーディングするための効率的で柔軟な機構を提供することができ、同時に、ピッチ係数修正（例えば、高い相対速度、特異点などのためのピッチ係数修正値の高い大きさ）のための（オーディオレンダラ側の）基礎となる信号処理ユニットの（許容可能なまたは許容可能な）能力を考慮に入れ、コンテンツ作成者の意図（言い換えれば、主観的なリスニング体験）に従って（所望の）ピッチ係数修正値（すなわち、ドップラー効果の所望の強度を表す）を制御する可能性も与え、それによって、（リスナ／ユーザ側での）知覚されるリスニング体験を改善する。

さらに、上述したように、ピッチ係数修正関数は、第１および第２のパラメータを入力として取る（レンダラ側での）所定の関数としてすでに実装され、展開されているので、一般に、レンダリング条件が変化する（例えば、異なる処理能力をもつ異なるレンダラが展開される、異なるオーディオコンテンツが異なる人によっておよび／または異なるシーンのために作成されたなど）たびに新しいピッチ係数修正関数を再設計（または再実装）する必要はない。代わりに、エンコーディング側は、ピッチ係数修正値の対応する許容範囲（限度）とモデル化されるべきドップラー効果の対応する所望の強度とをそれぞれ表す（例えば、ビットストリーム中でエンコーディングされた）異なる第１および第２のパラメータ値を通信するだけであり得る。したがって、いくつかの可能なシナリオでは、あらかじめ定義されたピッチ係数修正関数は、様々な要件および／または実装形態に応じて、様々なソフトウェアおよび／またはプラットフォームにおいて展開され得る（レンダラ側の）プラグインと同じくらい単純に実装され得るか、または必要な場合にはさらにカスタマイズされることさえあり得る。それによって、ピッチ係数変更関数の不必要な再設計／再実装が回避され、オーディオレンダリングプロセス全体における効率がさらに改善される。

最後に、上述のピッチ係数修正関数Ｆに対する最小要件（複数可）は、この関数の計算的に単純な実装を可能にし、一方で、ドップラー効果の現実的なモデル化を依然として達成することに留意されたい。これは、式（１）およびその等価物で与えられるピッチ係数修正関数Ｆの明示的な例に特に当てはまり得る。

ここで、図６Ａ～６Ｂおよび図７Ａ～７Ｂにおいて、可能なドップラー効果モデリングアプローチによって処理されたオーディオ信号（例えば、ユーザ側環境において）と、本発明の実施形態に従って処理されたオーディオ信号（例えば、ユーザ側環境において）との間の比較が概略的に示される。換言すれば、図６Ａ～図６Ｂ及び図７Ａ～図７Ｂは、概して、ドップラー効果に対して異なるモデリングアプローチを適用することによって得られた（スペクトログラムの形式の）それぞれのレンダリング結果を示し、比較する。特に、当業者によって理解され、認識され得るように、図６Ａ～図６Ｂおよび図７Ａ～図７Ｂにおいて、ｘ軸は、概して時間を表し、ｙ軸は、概して周波数を表す。

より具体的には、同じ例示的なオーディオ信号「ｊｅｔ」がそれぞれのモデリングアプローチによって処理される図６Ｂ（本発明の可能な実装による）と比較して図６Ａ（可能な従来のモデリングアプローチによる）に反映されるように、本発明において提案されるような（すなわち、図６Ｂに例示的に示されるような）ピッチ係数修正関数Ｆは、一般に、より高い次数の連続性（ソフト／滑らかな屈曲対ハード／鋭い屈曲）を示し、これは、より良好な知覚性能をもたらす。同様の発見は、図７Ａ及び図７Ｂに示されるような比較においても観察され、同じ例示的なオーディオ信号「サイレン」がそれぞれのモデリングアプローチによって処理される。図６Ａ～図６Ｂおよび図７Ａ～図７Ｂの両方の場合において、説明の目的で、－５００から＋５００ ｍ／ｓまでの音源の一定の加速が仮定される。特に、当業者によって理解されるように、図の左端から右に延びる図６Ａ～図６Ｂおよび図７Ａ～図７Ｂに示される線または線構造は、これらの線または線構造が実質的に等しいまたは同等のエネルギー密度を有する時間／周波数スロットを接続するという意味で、「等エネルギー」時間／周波数スロットを表すものと見なされ得る。したがって、これらの線または線構造は、時間が進行するにつれてエネルギー密度が周波数にわたってどのように移動したかを示す。

本発明は、同様に、本発明全体にわたって説明される方法および技法を実行するための装置に関する。図８Ａおよび８Ｂは、それぞれ、そのような装置８００および８０１の例を一般的に示す。特に、装置８００（又は８０１）は、プロセッサ８１０（又は８１１）と、プロセッサ８１０（又は８１１）に結合されたメモリ８２０（又は８２１）とを備える。メモリ８２０（または８２１）は、プロセッサ８１０（または８１１）のための命令を記憶し得る。プロセッサ８１０（または８１１）は、とりわけ、入力データ（例えば、ビットストリームまたは任意の他の適切なフォーマットの形態で）８３０（または８３１）を受信し得る。プロセッサ８１０（または８１１）は、本発明全体にわたって説明される方法／技法を実行し、それに応じて出力データ８４０（または８４１）を生成するように適合され得る。例えば、装置８００は、状況に依存して、図４に関して上で示されたような６ＤｏＦ環境のためのオーディオコンテンツをレンダリングするときにドップラー効果をモデル化する方法４００を実行するよう構成されたオーディオレンダラを実装してもよく、装置８０１は、状況に依存して、本発明の実施形態に従って、図５に関して上で示されたような６ＤｏＦ環境のためのオーディオコンテンツをレンダリングするときにドップラー効果をモデル化する際に使うためのパラメータをエンコーディングする方法５００を実行するよう構成されたエンコーダを実装してもよい。

解釈
上記の技術を実装するコンピューティングデバイスは、以下の例示的なアーキテクチャを有することができる。より多くの又はより少ない構成要素を有するアーキテクチャを含む他のアーキテクチャも可能である。いくつかの実装形態では、例示的なアーキテクチャは、１つまたは複数のプロセッサ（例えば、デュアルコアＩｎｔｅｌ（登録商標）Ｘｅｏｎ（登録商標）プロセッサ）、１つまたは複数の出力デバイス（例えば、ＬＣＤ）、１つまたは複数のネットワークインターフェース、１つまたは複数の入力デバイス（例えば、マウス、キーボード、タッチセンシティブディスプレイ）、および１つまたは複数のコンピュータ可読媒体（例えば、ＲＡＭ、ＲＯＭ、ＳＤＲＡＭ、ハードディスク、光ディスク、フラッシュメモリなど）を含む。これらの構成要素は、１つ以上の通信チャネル（例えば、バス）を介して通信及びデータを交換することができ、通信チャネルは、構成要素間のデータ及び制御信号の転送を容易にするための様々なハードウェア及びソフトウェアを利用することができる。

「コンピュータ可読媒体」という用語は、実行のためにプロセッサに命令を提供することに関与する媒体を指し、限定はしないが、不揮発性媒体（例えば、光学または磁気ディスク）、揮発性媒体（例えば、メモリ）および伝送媒体を含む。伝送媒体は、同軸ケーブル、銅線、および光ファイバを含むが、これらに限定されない。

コンピュータ可読媒体は、オペレーティングシステム（例えば、Ｌｉｎｕｘ（登録商標）オペレーティングシステム）、ネットワーク通信モジュール、オーディオインタフェースマネージャ、オーディオ処理マネージャ、及びライブコンテンツディストリビュータを更に含むことができる。オペレーティングシステムは、ネットワークインターフェースおよび／またはデバイスからの入力を認識し、それらに出力を提供すること、コンピュータ可読媒体（例えば、メモリまたは記憶デバイス）上のファイルおよびディレクトリを追跡し、管理すること、周辺デバイスを制御すること、ならびに１つまたはそれを上回る通信チャネル上のトラフィックを管理することを含むが、それらに限定されない、基本タスクを行う。ネットワーク通信モジュールは、ネットワーク接続を確立し、維持するための様々な構成要素（例えば、ＴＣＰ／ＩＰ、ＨＴＴＰなどの通信プロトコルを実施するためのソフトウェア）を含む。

アーキテクチャは、並列処理またはピアツーピアインフラストラクチャにおいて、または１つまたは複数のプロセッサを有する単一のデバイス上で実施され得る。ソフトウェアは、複数のソフトウェアコンポーネントを含むことができ、又は単一のコード本体とすることができる。

記載された特徴は、データ記憶システム、少なくとも１つの入力装置、および少なくとも１つの出力装置からデータおよび命令を受信し、それらにデータおよび命令を送信するように結合された少なくとも１つのプログラマブルプロセッサを含むプログラマブルシステム上で実行可能な１つまたは複数のコンピュータプログラムで有利に実施することができる。コンピュータプログラムは、特定の活動を実行するか、または特定の結果をもたらすために、コンピュータにおいて直接的または間接的に使用され得る命令のセットである。コンピュータプログラムは、コンパイル型言語またはインタープリタ型言語を含む任意の形態のプログラミング言語（例えば、Ｏｂｊｅｃｔｉｖｅ－Ｃ、Ｊａｖａ（登録商標））で書くことができ、スタンドアロンプログラムとして、またはモジュール、コンポーネント、サブルーチン、ブラウザベースのウェブアプリケーション、もしくはコンピューティング環境での使用に適した他のユニットとして含む任意の形態で展開することができる。

命令のプログラムの実行に適したプロセッサは、例として、汎用マイクロプロセッサと専用マイクロプロセッサの両方、および任意の種類のコンピュータの単一のプロセッサまたは複数のプロセッサもしくはコアのうちの１つを含む。一般に、プロセッサは、リードオンリーメモリまたはランダムアクセスメモリまたはその両方から命令およびデータを受信する。コンピュータの必須要素は、命令を実行するためのプロセッサと、命令およびデータを記憶するための１つまたは複数のメモリである。一般に、コンピュータは、データファイルを記憶するための１つまたは複数の大容量記憶装置も含むか、またはそれと通信するように動作可能に結合され、そのような装置は、内部ハードディスクおよび取外し可能ディスクなどの磁気ディスク、光磁気ディスク、および光ディスクを含む。コンピュータプログラム命令およびデータを有形に実施するのに適した記憶装置は、例として、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイスなどの半導体メモリデバイス、内部ハードディスクおよびリムーバブルディスクなどの磁気ディスク、光磁気ディスク、ならびにＣＤ－ＲＯＭおよびＤＶＤ－ＲＯＭディスクを含む、すべての形態の不揮発性メモリを含む。プロセッサおよびメモリは、ＡＳ ＩＣ（特定用途向け集積回路）によって補完されてもよく、またはＡＳ ＩＣに組み込まれてもよい。

ユーザとの対話を提供するために、特徴は、ユーザに情報を表示するためのＣＲＴ（陰極線管）またはＬＣＤ（液晶ディスプレイ）モニタまたは網膜ディスプレイデバイスなどのディスプレイデバイスを有するコンピュータ上で実施され得る。コンピュータは、タッチ表面入力デバイス（例えば、タッチスクリーン）またはキーボード、およびマウスまたはトラックボールなどのポインティングデバイスを有することができ、それによってユーザはコンピュータに入力を提供することができる。コンピュータは、ユーザから音声コマンドを受信するための音声入力装置を有することができる。

特徴は、データサーバなどのバックエンドコンポーネントを含む、またはアプリケーションサーバもしくはインターネットサーバなどのミドルウェアコンポーネントを含む、またはグラフィカルユーザインターフェースもしくはインターネットブラウザを有するクライアントコンピュータなどのフロントエンドコンポーネントを含む、またはそれらの任意の組合せを含むコンピュータシステムにおいて実装され得る。システムの構成要素は、通信ネットワークなどのデジタルデータ通信の任意の形態または媒体によって接続され得る。通信ネットワークの例は、例えば、ＬＡＮ、ＷＡＮ、及びインターネットを形成するコンピュータ及びネットワークを含む。

コンピューティングシステムは、クライアントおよびサーバを含み得る。クライアントおよびサーバは、一般に、互いに遠隔にあり、通常、通信ネットワークを介して対話する。クライアントとサーバの関係は、それぞれのコンピュータ上で実行され、互いにクライアント－サーバ関係を有するコンピュータプログラムによって生じる。いくつかの実施形態では、サーバは、（例えば、クライアントデバイスと対話するユーザにデータを表示し、ユーザからユーザ入力を受信する目的で）クライアントデバイスにデータ（例えば、ＨＴＭＬページ）を送信する。クライアントデバイスで生成されたデータ（例えば、ユーザ対話の結果）は、サーバでクライアントデバイスから受信され得る。

１つまたは複数のコンピュータのシステムは、動作中にシステムにアクションを実行させる、システムにインストールされたソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せを有することによって、特定のアクションを実行するように構成され得る。１つまたは複数のコンピュータプログラムは、データ処理装置によって実行されると、装置にアクションを実行させる命令を含むことによって、特定のアクションを実行するように構成され得る。

本明細書は、多くの特定の実装の詳細を含むが、これらは、任意の発明の範囲または特許請求され得るものの範囲に対する限定として解釈されるべきではなく、むしろ、特定の発明の特定の実施形態に特有の特徴の説明として解釈されるべきである。別々の実施形態の文脈において本明細書に記載されている特定の特徴は、単一の実施形態において組み合わせて実施することもできる。逆に、単一の実施形態の文脈で説明される様々な特徴は、複数の実施形態で別々に、または任意の適切な部分的組合せで実施することもできる。さらに、特徴は、ある組み合わせで作用するものとして上述され、最初にそのように請求され得るが、請求される組み合わせからの１つ以上の特徴は、いくつかの場合において、組み合わせから削除されることができ、請求される組み合わせは、部分的組み合わせまたは部分的組み合わせの変形例を対象とし得る。

同様に、動作は、特定の順序で図面に示されているが、これは、望ましい結果を達成するために、そのような動作が示された特定の順序で、または連続した順序で実行されること、あるいはすべての示された動作が実行されることを必要とすると理解されるべきではない。ある状況では、マルチタスキングおよび並列処理が有利である場合がある。さらに、上述の実施形態における様々なシステムコンポーネントの分離は、すべての実施形態においてそのような分離を必要とするものとして理解されるべきではなく、説明されたプログラムコンポーネントおよびシステムは、一般に、単一のソフトウェア製品に一緒に統合されるか、または複数のソフトウェア製品にパッケージ化され得ることを理解されたい。

特に明記しない限り、以下の説明から明らかなように、本発明の説明全体を通して、「処理」、「計算」、「算出」、「決定」、「分析」などの用語を利用する説明は、電子的な量などの物理的な量として表されるデータを、同様に物理的な量として表される他のデータに操作および／または変換するコンピュータもしくはコンピューティングシステム、または同様の電子コンピューティングデバイスの動作および／またはプロセスを指すことが理解される。

本発明を通して、「一実施形態例」、「いくつかの実施形態例」、または「実施形態例」への言及は、実施形態例に関連して説明される特定の特徴、構造、または特性が、本発明の少なくとも１つの実施形態例に含まれることを意味する。したがって、本発明全体を通して様々な箇所に「一実施形態例において」、「いくつかの実施形態例において」、または「実施形態例において」という語句が現れることは、必ずしもすべてが同じ実施形態例を指しているわけではない。さらに、特定の特徴、構造、または特性は、１つまたは複数の例示的な実施形態において、本発明から当業者に明らかであるように、任意の適切な方法で組み合わされてもよい。

本明細書で使用される場合、特に指定のない限り、共通の対象を説明するための順序を示す形容詞「第１の」、「第２の」、「第３の」などの使用は、単に、同様の対象の異なる例が言及されていることを示し、そのように説明される対象が、時間的に、空間的に、ランキングで、または任意の他の方法で、所与の順序でなければならないことを暗示することを意図しない。

また、本明細書で使用される表現および用語は、説明のためのものであり、限定と見なされるべきではないことを理解されたい。「含む（ｉｎｃｌｕｄｉｎｇ）」、「備える（ｃｏｍｐｒｉｓｉｎｇ）」、または「有する（ｈａｖｉｎｇ）」、およびそれらの変形の使用は、その後に列挙される項目およびそれらの等価物、ならびに追加の項目を包含することを意味する。特に指定又は限定されない限り、「取り付けられた」、「接続された」、「支持された」、及び「結合された」という用語、並びにこれらの変形は、広義に使用され、直接的及び間接的な取り付け、接続、支持、及び結合の両方を包含する。

以下の特許請求の範囲および本明細書の説明において、含む（ｃｏｍｐｒｉｓｉｎｇ）、からなる（ｃｏｍｐｒｉｓｅｄ ｏｆ）、または、それを含む（ｗｈｉｃｈ ｃｏｍｐｒｉｓｅｓ）という用語のいずれか１つは、少なくともそれに続く要素／特徴を含むが、他のものを除外しないことを意味するオープンタームである。したがって、特許請求の範囲で使用される場合、含むという用語は、その後に列挙される手段または要素またはステップに限定されるものとして解釈されるべきではない。例えば、Ａ及びＢを含むデバイスという表現の範囲は、要素Ａ及びＢのみからなるデバイスに限定されるべきではない。本明細書で使用される「含む（ｉｎｃｌｕｄｉｎｇ）」又は「含む（ｗｈｉｃｈ ｉｎｃｌｕｄｅｓ）」又は「含む（ｔｈａｔ ｉｎｃｌｕｄｅｓ）」という用語のいずれか１つは、少なくともその用語に続く要素／特徴を含むが、他のものを除外しないことも意味するオープンタームでもある。したがって、含む（ｉｎｃｌｕｄｉｎｇ）は、備える（ｃｏｍｐｒｉｓｉｎｇ）と同義であり、備える（ｃｏｍｐｒｉｓｉｎｇ）を意味する。

本発明の例示的な実施形態の上記の説明において、本発明の様々な特徴は、本発明を合理化し、様々な発明の態様のうちの１つまたは複数の理解を助ける目的で、単一の例示的な実施形態、図、またはその説明にまとめられることがあることを理解されたい。しかしながら、本発明のこの方法は、請求項が各請求項に明示的に記載されているよりも多くの特徴を必要とするという意図を反映するものとして解釈されるべきではない。むしろ、以下の特許請求の範囲が反映するように、発明の態様は、単一の上記の開示された例示的な実施形態のすべての特徴よりも少ない特徴にある。したがって、本明細書に続く特許請求の範囲は、本明細書に明示的に組み込まれ、各請求項は、本発明の別個の例示的実施形態として独立している。

さらに、本明細書に記載されたいくつかの例示的な実施形態は、他の例示的な実施形態に含まれるいくつかの特徴を含むが、他の特徴は含まず、異なる例示的な実施形態の特徴の組み合わせは、本発明の範囲内にあることを意味し、当業者によって理解されるように、異なる例示的な実施形態を形成する。例えば、以下の特許請求の範囲において、請求される例示的な実施形態のいずれも、任意の組み合わせで使用され得る。

本明細書に提供される説明では、多数の具体的な詳細が記載される。しかしながら、本発明の例示的な実施形態は、これらの具体的な詳細なしに実施されてもよいことが理解される。他の例では、この説明の理解を曖昧にしないために、周知の方法、構造、および技術は詳細に示されていない。

したがって、本発明の最良の形態であると考えられるものを説明したが、当業者は、本発明の精神から逸脱することなく、他のさらなる修正をそれに対して行うことができ、本発明の範囲内にあるようなすべての変更および修正を請求することが意図されることを認識するであろう。例えば、上記の任意の式は、使用され得る手順の単なる代表例である。機能は、ブロック図に追加されてもよく、またはブロック図から削除されてもよく、動作は、機能ブロック間で交換されてもよい。本開示の範囲内で、記載された方法にステップを追加または削除してもよい。

本発明の様々な態様は、以下の列挙された例示的な実施形態（ＥＥＥ）から理解され得る。

ＥＥＥ１．ユーザ側で６自由度（６ＤｏＦ）環境のためのオーディオコンテンツをレンダリングするときにドップラー効果をモデル化する方法であって、
ピッチ係数修正値の許容範囲を示す１つまたは複数の第１のパラメータの第１のパラメータ値を取得することと、
前記モデル化されるべきドップラー効果の所望の強度を示す第２のパラメータの第２のパラメータ値を取得することと、
所定のピッチ係数修正関数を使用して、前記オーディオコンテンツ内のリスナと音源との間の相対速度と、前記第１および第２のパラメータ値とに基づいてピッチ係数修正値を決定することと、
前記ピッチ係数修正値に基づいて前記音源をレンダリングすることと、を含み、
前記所定のピッチ係数修正関数は、前記第１及び第２のパラメータを有し、相対速度をピッチ係数修正値にマッピングするための関数である、方法。

ＥＥＥ２．前記相対速度は、前記リスナおよび前記音源の位置に基づいて計算される、ＥＥＥ１に記載の方法。

ＥＥＥ３．前記一つまたは複数の第一のパラメータは、ピッチ因子修正値の許容範囲の上限および／または下限を示すパラメータを含む、ＥＥＥ１または２に記載の方法。

ＥＥＥ４．ピッチ係数修正値の許容可能な範囲は、オーディオコンテンツをレンダリングするオーディオレンダラの処理能力を反映する、先行するＥＥＥのうちのいずれか１つに記載の方法。

ＥＥＥ５．ピッチ係数修正値の前記許容範囲が前記オーディオレンダラによってサポートされない場合、ピッチ係数修正値のデフォルト範囲が前記オーディオレンダラによって使用される、ＥＥＥ４に記載の方法。

ＥＥＥ６．第２のパラメータは、モデル化されるべきドップラー効果のアグレッシブネスを反映するピッチ係数修正関数の傾きを制御する、先行するＥＥＥのうちのいずれか１つに記載の方法。

ＥＥＥ７．オーディオコンテンツが受領されたビットストリームから抽出され、第一および第二のパラメータ値が前記ビットストリームに含まれる指示から導出される、先行するＥＥＥのうちのいずれか１つに記載の方法。

ＥＥＥ８．前記オーディオコンテンツならびに前記第一および第二のパラメータ値は別個のビットストリームから得られる、ＥＥＥ１ないし６のうちのいずれか一つに記載の方法。

ＥＥＥ９．第２のパラメータ値は、オーディオコンテンツのコンテンツ作成者によって設定される、先行するＥＥＥのうちのいずれか１つに記載の方法。

ＥＥＥ１０．第２のパラメータ値は、所望のドップラー効果強度についての現実世界の基準及び／又は芸術的な期待値をモデル化することによって設定される、先行するＥＥＥのうちのいずれか１つに記載の方法。

ＥＥＥ１１．前記ピッチ因子修正値に基づいて前記オーディオコンテンツをレンダリングすることは、
前記ピッチ係数修正値に基づいて前記オーディオコンテンツ内の前記音源のピッチを調整することを含む、先行するＥＥＥのうちのいずれか１つに記載の方法。

ＥＥＥ１２．正のピッチ係数修正値は、前記音源のピッチを増大させることを示す、ＥＥＥ１１に記載の方法。

ＥＥＥ１３．前記音源のピッチ調整が半音単位で実行される、ＥＥＥ１１または１２に記載の方法。

ＥＥＥ１４．ピッチ係数修正関数は、一般化ロジスティック関数に基づく、先行するＥＥＥのうちのいずれか１つに記載の方法。

ＥＥＥ１５．前記ピッチ係数修正関数は、
－相対速度に関して連続的で単調であること、
－前記１つ以上の第１のパラメータによって制御される漸近的限界を有すること、
－ゼロ相対速度でゼロピッチ係数修正値をもたらすこと、および／または
－ゼロ速度の近傍で、前記第２のパラメータによって制御される勾配を有すること
のうちの１つ以上の特性を有する、先行するＥＥＥのうちのいずれか１つに記載の方法。

ＥＥＥ１６．前記ピッチ係数修正関数Ｆは、

として実装され、ここで、νは、相対速度を表し、ｌ＝｛ｌ_ｌ，ｌ_ｈ｝は、第１のパラメータを表し、ｌ_ｌは、範囲の下限を示し、ｌ_ｈは、範囲の上限を示し、ｓは、第２のパラメータを表す、先行するＥＥＥのうちのいずれか１つに記載の方法。

ＥＥＥ１７．前記ユーザに対する再生のために前記レンダリングされた音源をスピーカまたはヘッドフォンに出力すること、をさらに含む、先行するＥＥＥのうちのいずれか１つに記載の方法。

ＥＥＥ１８．６自由度（６ＤｏＦ）環境のためのオーディオコンテンツをレンダリングするときにドップラー効果をモデル化することにおいて使用するためのパラメータをエンコーディングする方法であって
ピッチ係数修正値の許容範囲を示す１つまたは複数の第１のパラメータの第１のパラメータ値を決定することと、
前記モデル化されるべきドップラー効果の所望の強度を示す第２のパラメータの第２のパラメータ値を決定することと、
前記第１及び第２のパラメータ値の指示をエンコーディングすることと、を含み、
前記第１及び第２のパラメータ値は、前記オーディオコンテンツのリスナと音源との間の相対速度を、所定のピッチ係数修正関数に基づいてピッチ係数修正値にマッピングするために使用されることができ、前記ピッチ係数修正値は、前記音源をレンダリングするために使用され、前記所定のピッチ係数修正関数は、前記第１及び第２のパラメータを有し、相対速度をピッチ係数修正値にマッピングするための関数である、方法。

ＥＥＥ１９．前記第１及び第２のパラメータ値の指示は、ビットストリームにおいてラベルとしてエンコーディングされる、ＥＥＥ１８に記載の方法。

ＥＥＥ２０．第１および第２のパラメータ値の指示は、オーディオコンテンツと一緒に単一のビットストリームにおいて、または、別個のビットストリームとしてエンコーディングされる、ＥＥＥ１８または１９に記載の方法。

ＥＥＥ２１．第１及び第２のパラメータ値は、コンテンツ作成者またはゲームエンジンによって決定される、ＥＥＥ１８ないし２０のうちのいずれか１つに記載の方法。

ＥＥＥ２２．プロセッサと、前記プロセッサに結合されたメモリとを備えるオーディオレンダラであって、前記プロセッサは、前記オーディオレンダラに、ＥＥＥ１ないし１７のうちのいずれか１つに記載の方法を実行させるように適合されている、オーディオレンダラ。

ＥＥＥ２３．プロセッサと、前記プロセッサに結合されたメモリとを備えるエンコーダであって、前記プロセッサは、前記エンコーダに、ＥＥＥ１８ないし２１のうちのいずれか１つに記載の方法を実行させるように適合されている、エンコーダ。

ＥＥＥ２４．プロセッサによって実行されると、前記プロセッサに、ＥＥＥ１ないし２１のうちのいずれか１つに記載の方法を実行させる命令を含む、プログラム。

ＥＥＥ２５．ＥＥＥ２４に記載のプログラムを格納した、コンピュータ読み取り可能な記憶媒体。

Claims (22)

1. ６自由度（６ＤｏＦ）環境のためのオーディオコンテンツをユーザ側でレンダリングするときにドップラー効果をモデル化する方法であって
   ピッチ係数修正値の許容範囲を示す１つまたは複数の第１のパラメータの第１のパラメータ値を取得することと、
   モデル化されるべきドップラー効果の所望の強度を示す第２のパラメータの第２のパラメータ値を取得することと、
   所定のピッチ係数修正関数を使用して、前記オーディオコンテンツ内のリスナと音源との間の相対速度と、前記第１及び第２のパラメータ値とに基づいてピッチ係数修正値を決定することと、
   前記ピッチ係数修正値に基づいて前記音源をレンダリングすることと、を含み、
   前記所定のピッチ係数修正関数は、前記第１及び第２のパラメータを有し、相対速度をピッチ係数修正値にマッピングするための関数であり、
   ピッチ係数修正値の前記許容範囲は、前記オーディオコンテンツをレンダリングするオーディオレンダラの処理能力を反映し、
   前記第２のパラメータは、前記モデル化されるべきドップラー効果のアグレッシブネスを反映するピッチ係数修正関数の傾きを制御する、方法。
2. 前記相対速度は、前記リスナと前記音源の位置に基づいて計算される、請求項１に記載の方法。
3. 前記１つまたは複数の第１のパラメータは、ピッチ係数修正値の前記許容範囲の上限および／または下限を示すパラメータを含む、請求項１または２に記載の方法。
4. ピッチ係数修正値の前記許容範囲が前記オーディオレンダラによってサポートされない場合、ピッチ係数修正値のデフォルト範囲が前記オーディオレンダラによって使用される、請求項１から３のいずれか１項に記載の方法。
5. 前記オーディオコンテンツは受領されたビットストリームから抽出され、前記第１及び第２のパラメータ値は前記ビットストリームに含まれる指示から導出される、請求項１から４のいずれか１項に記載の方法。
6. 前記オーディオコンテンツならびに前記第１及び第２のパラメータ値は、別個のビットストリームから得られる、請求項１から５のいずれか１項に記載の方法。
7. 前記第２のパラメータ値は、前記オーディオコンテンツのコンテンツ作成者によって設定される、請求項１から６のいずれか１項に記載の方法。
8. 前記第２のパラメータ値は、所望のドップラー効果強度に対する現実世界の基準及び／又は芸術的な期待をモデル化することによって設定される、請求項１－７のいずれか１項に記載の方法。
9. 前記ピッチ係数修正値に基づいて前記オーディオコンテンツをレンダリングすることは、
   前記ピッチ係数修正値に基づいて前記オーディオコンテンツ内の前記音源のピッチを調整することを含む、請求項１から８のいずれか１項に記載の方法。
10. 正のピッチ係数修正値は、前記音源のピッチを増加させることを示す、請求項９に記載の方法。
11. 前記音源のピッチ調整は、半音単位で行われる、請求項９または１０に記載の方法。
12. 前記ピッチ係数修正関数は、一般化ロジスティック関数に基づき、
    前記ピッチ係数修正関数は、
    －相対速度に関して連続的で単調であること、
    －前記１つまたは複数の第１のパラメータによって制御される漸近的限界を有すること、
    －ゼロ相対速度でゼロピッチ係数修正値をもたらすこと、および／または
    －ゼロ速度の近傍で、前記第２のパラメータによって制御される勾配を有すること
    のうちの１つ以上の特性を有する、請求項１から１１のいずれか１項に記載の方法。
13. 前記ピッチ係数修正関数Ｆは、
    

    

    として実装され、ここで、νは、前記相対速度を表し、ｌ＝｛ｌ_ｌ，ｌ_ｈ｝は、前記第１のパラメータを表し、ｌ_ｌは、範囲の下限を示し、ｌ_ｈは、範囲の上限を示し、ｓは、前記第２のパラメータを表す、請求項１から１２のいずれか１項に記載の方法。
14. 前記ユーザへの再生のために、前記レンダリングされた音源をスピーカまたはヘッドフォンに出力すること、をさらに含む、請求項１から１３のいずれか１項に記載の方法。
15. ６自由度（６ＤｏＦ）環境のためのオーディオコンテンツをレンダリングするときにドップラー効果をモデル化する際に使うためのパラメータをエンコーディングする方法であって、
    ピッチ係数修正値の許容範囲を示す１つまたは複数の第１のパラメータの第１のパラメータ値を決定することと、
    モデル化されるべきドップラー効果の所望の強度を示す第２のパラメータの第２のパラメータ値を決定することと、
    前記第１及び第２のパラメータ値の指示をエンコーディングすることと、を含み、
    前記第１及び第２のパラメータ値は、所定のピッチ係数修正関数に基づいて、前記オーディオコンテンツのリスナと音源との間の相対速度をピッチ係数修正値にマッピングするために使用されることができ、前記ピッチ係数修正値は、前記音源をレンダリングするために使用され、前記所定のピッチ係数修正関数は、前記第１及び第２のパラメータを有し、相対速度をピッチ係数修正値にマッピングするための関数であり、
    ピッチ係数修正値の前記許容範囲は、前記オーディオコンテンツをレンダリングするオーディオレンダラの処理能力を反映し、
    前記第２のパラメータは、前記モデル化されるべきドップラー効果のアグレッシブネスを反映する前記ピッチ係数修正関数の傾きを制御する、方法。
16. 前記第１及び第２のパラメータ値の前記指示は、ビットストリームにおいてラベルとしてエンコーディングされる、請求項１５に記載の方法。
17. 前記第１及び第２のパラメータ値の前記指示は、単一のビットストリームにおいて、または別個のビットストリームとして、前記オーディオコンテンツと一緒にエンコーディングされる、請求項１５または１６に記載の方法。
18. 前記第１及び第２のパラメータ値は、コンテンツ作成者又はゲームエンジンによって決定される、請求項１５から１７のいずれか１項に記載の方法。
19. プロセッサと、前記プロセッサに結合されたメモリとを備えるオーディオレンダラであって、前記プロセッサは、前記オーディオレンダラに、請求項１から１４のいずれか１項に記載の方法を実行させるように適合される、オーディオレンダラ。
20. プロセッサと、前記プロセッサに結合されたメモリとを備えるエンコーダであって、前記プロセッサは、前記エンコーダに、請求項１５から１８のいずれか１項に記載の方法を実行させるように適合される、エンコーダ。
21. プロセッサによって実行されると、前記プロセッサに、請求項１から１８のいずれか１項に記載の方法を実行させる命令を含む、プログラム。
22. 請求項２１に記載のプログラムを格納した、コンピュータ読み取り可能な記憶媒体。

Images