(57)【要約】本稿は、ビットストリーム（101）を生成する方法（500）であって、前記ビットストリーム（101）は、没入的オーディオ信号（111）のフレームのシーケンスについてのスーパーフレーム（400）のシーケンスを含む。当該方法（500）は、スーパーフレーム（400）の前記シーケンスについて、繰り返し、前記没入的オーディオ信号（111）から導出された一つまたは複数のダウンミックス・チャネル信号（203）の一つまたは複数のフレームについての符号化されたオーディオ・データ（206）を、スーパーフレーム（400）のデータ・フィールド（411、421、412、422）に挿入する段階（501）と；前記符号化されたオーディオ・データ（206）から前記没入的オーディオ信号（111）の一つまたは複数のフレームを再構成するためのメタデータ（202,205）を、前記スーパーフレーム（400）のメタデータ・フィールド（403）に挿入する段階（502）とを実行することを含む。
2021530723.tif 000002
【特許請求の範囲】
【請求項１】
ビットストリーム（101）を生成する方法（500）であって、前記ビットストリーム（101）は、没入的オーディオ信号（111）のフレームのシーケンスについてのスーパーフレーム（400）のシーケンスを含み、当該方法（500）は、スーパーフレーム（400）の前記シーケンスについて、繰り返し：
前記没入的オーディオ信号（111）から導出された一つまたは複数のダウンミックス・チャネル信号（203）の一つまたは複数のフレームについての符号化されたオーディオ・データ（206）を、スーパーフレーム（400）のデータ・フィールド（411、421、412、422）に挿入する段階（501）と；
前記符号化されたオーディオ・データ（206）から前記没入的オーディオ信号（111）の一つまたは複数のフレームを再構成するためのメタデータ（202,205）を、前記スーパーフレーム（400）のメタデータ・フィールド（403）に挿入する段階（502）とを実行することを含む、
方法。
【請求項２】
・当該方法（500）が、前記スーパーフレーム（400）にヘッダ・フィールド（401）を挿入することを含み；
・前記ヘッダ・フィールド（401）は、前記スーパーフレーム（400）の前記メタデータ・フィールド（403）のサイズを示す、
請求項１に記載の方法。
【請求項３】
・前記メタデータ・フィールド（403）は可能な最大サイズを示し；
・前記ヘッダ・フィールド（401）は調整値を示し；
・前記スーパーフレーム（400）の前記メタデータ・フィールド（403）のサイズは、前記可能な最大サイズから前記調整値を引いたものに対応する、
請求項２に記載の方法。
【請求項４】
前記ヘッダ・フィールド（401）は、前記メタデータ・フィールド（403）についてのサイズ・インジケータを含み；
前記サイズ・インジケータは、前記メタデータ・フィールド（403）のサイズの異なるサイズ範囲について異なる分解能を示す、
請求項２または３に記載の方法。
【請求項５】
・前記没入的オーディオ信号（111）の前記一つまたは複数のフレームを再構成するための前記メタデータ（202,205）は、該メタデータ（202,205）のサイズの統計的サイズ分布を示し；
・前記サイズ・インジケータの分解能は、前記メタデータ（202,205）のサイズ分布に依存する、
請求項４に記載の方法。
【請求項６】
・当該方法（500）が、前記スーパーフレーム（400）にヘッダ・フィールド（401）を挿入することを含み；
・前記ヘッダ・フィールド（401）は、前記スーパーフレーム（400）が構成情報フィールド（402）を含むか否かを示し；
・前記ヘッダ・フィールド（401）は、構成情報フィールド（402）の存在を示す、
請求項１ないし５のうちいずれか一項に記載の方法。
【請求項７】
・当該方法（500）は、構成情報フィールド（402）を前記スーパーフレーム（400）に挿入することを含み；
・前記構成情報フィールド（402）は、前記スーパーフレーム（400）のデータ・フィールド（411、421、412、422）によって表わされるダウンミックス・チャネル信号（203）の数を示す、
請求項１ないし６のうちいずれか一項に記載の方法。
【請求項８】
・当該方法（500）は、構成情報フィールド（402）を前記スーパーフレーム（400）に挿入することを含み；
・前記構成情報フィールド（402）は、前記メタデータ・フィールド（403）の可能な最大サイズを示す、
請求項１ないし７のうちいずれか一項に記載の方法。
【請求項９】
・当該方法（500）は、構成情報フィールド（402）を前記スーパーフレーム（400）に挿入することを含み；
・前記構成情報フィールド（402）は、前記没入的オーディオ信号（111）内に含まれる音場表現信号の次数を示す、
請求項１ないし８のうちいずれか一項に記載の方法。
【請求項１０】
・当該方法（500）は、構成情報フィールド（402）を前記スーパーフレーム（400）に挿入することを含み；
・前記構成情報フィールド（402）は、前記一つまたは複数のダウンミックス・チャネル信号（203）のそれぞれを符号化するために使用されるフレーム・タイプおよび／または符号化モードを示す、
請求項１ないし９のうちいずれか一項に記載の方法。
【請求項１１】
・当該方法（500）は、ヘッダ・フィールド（401）を前記スーパーフレーム（400）に挿入することを含み；
・ヘッダ・フィールド（401）は、前記スーパーフレーム（400）が前記没入的オーディオ信号（111）に関する追加的情報のための拡張フィールド（404）を含むか否かを示す、
請求項１ないし１０のうちいずれか一項に記載の方法。
【請求項１２】
スーパーフレーム（400）が、前記一つまたは複数のダウンミックス・チャネル信号（203）の2つ以上のフレームを含む、請求項１ないし３のうちいずれか一項に記載の方法。
【請求項１３】
・ダウンミックス・チャネル信号（203）のフレームの前記符号化されたオーディオ・データ（206）は、マルチモードおよび／またはマルチレート発話またはオーディオ・コーデックを使用して生成される；および／または
・前記メタデータ（202,205）は、マルチモードおよび／またはマルチレートの没入的メタデータ符号化方式を使用して生成される、
請求項１ないし１２のうちいずれか一項に記載の方法。
【請求項１４】
ダウンミックス・チャネル信号（203）のフレームの前記符号化されたオーディオ・データ（206）が、向上音声サービス・エンコーダを使用してエンコードされる、請求項１ないし１３のうちいずれか一項に記載の方法。
【請求項１５】
前記スーパーフレーム（400）が、伝送プロトコル、特にDASH、RTSPまたはRTPを用いて伝送される、または記憶フォーマット、特にISOBMFFに従ってファイルに格納される、データ要素の少なくとも一部を構成する、請求項１ないし１４のうちいずれか一項に記載の方法。
【請求項１６】
・前記ヘッダ・フィールド（401）は、構成情報フィールド（402）が存在しないことを示し；
・当該方法（500）は、前記スーパーフレーム（400）のシーケンスの以前のスーパーフレーム（400）において、またはアウトオブバンド信号伝達方式を使って、構成情報を伝達することを含む、
請求項１ないし１５のうちいずれか一項に記載の方法。
【請求項１７】
当該方法が、
・前記没入的オーディオ信号（111）から導出された第1のダウンミックス・チャネル信号（203）および第2のダウンミックス・チャネル信号（203）の一つまたは複数のフレームについての符号化されたオーディオ・データ（206）を、前記スーパーフレーム（400）の一つまたは複数の第1データ・フィールド（411、421）および一つまたは複数の第2データ・フィールド（412、422）に、それぞれ挿入する段階であって、前記第1のダウンミックス・チャネル信号（203）は第1のエンコーダを用いてエンコードされ、前記第2のダウンミックス・チャネル信号（203）は第2のエンコーダを用いてエンコードされる、段階と；
・前記第1のエンコーダおよび前記第2のエンコーダに関する構成情報を、前記スーパーフレーム（400）内で、前記スーパーフレーム（400）のシーケンスのうち以前のスーパーフレーム（400）内で、またはアウトオブバンド信号伝達方式を使って、提供する段階とを含む、
請求項１ないし１６のうちいずれか一項に記載の方法。
【請求項１８】
当該方法が、
・IA信号と呼ばれる、前記没入的オーディオ信号（111）から一つまたは複数のオーディオ・オブジェクトを抽出する段階であって、オーディオ・オブジェクトは、オブジェクト信号と、前記オーディオ・オブジェクトの位置を示すオブジェクト・メタデータ（202）とを含む、段階と；
・前記IA信号（111）に基づき、かつ前記一つまたは複数のオーディオ・オブジェクトに基づいて、残留信号（201）を決定する、段階と；
・前記IA信号（111）に基づいてダウンミックス信号を提供し、特に、前記ダウンミックス信号のダウンミックス・チャネル信号（203）の数が前記IA信号（111）のチャネル信号の数よりも少ないようにする、段階と；
・前記ダウンミックス信号を、前記一つまたは複数のオーディオ・オブジェクトに対応する一つまたは複数の再構成されたオーディオ・オブジェクト信号および／または前記残留信号（201）に対応する再構成された残留信号（311）にアップミックスすることを可能にするための合同符号化メタデータ（205）を決定する段階と；
・前記ダウンミックス信号の波形符号化を実行して、前記一つまたは複数のダウンミックス・チャネル信号（203）のフレームのシーケンスについて、符号化されたオーディオ・データ（206）を提供する段階と；
・前記合同符号化メタデータ（205）および前記一つまたは複数のオーディオ・オブジェクトの前記オブジェクト・メタデータ（202）のエントロピー符号化を実行して、前記スーパーフレーム（400）のシーケンスの前記メタデータ・フィールド（403）に挿入される前記メタデータ（202,205）を提供する段階とを含む、
請求項１ないし１７のうちいずれか一項に記載の方法。
【請求項１９】
ビットストリーム（101）のスーパーフレーム（400）であって、当該ビットストリーム（101）は、没入的オーディオ信号（111）のフレームのシーケンスについてのスーパーフレーム（400）のシーケンスを含み、前記スーパーフレーム（400）は、
・前記没入的オーディオ信号（111）から導出された一つまたは複数のダウンミックス・チャネル信号（203）の一つまたは複数のフレームについての符号化されたオーディオ・データ（206）のデータ・フィールド（411、421、412、422）と；
・前記符号化されたオーディオ・データ（206）から前記没入的オーディオ信号（111）の一つまたは複数のフレームを再構成するように適応されたメタデータ（202,205）のための単一のメタデータ・フィールド（403）とを含む、
スーパーフレーム。
【請求項２０】
ビットストリーム（101）から没入的オーディオ信号（111）に関するデータを導出するための方法（600）であって、前記ビットストリーム（101）は、前記没入的オーディオ信号（111）のフレームのシーケンスについてのスーパーフレーム（400）のシーケンスを含み、当該方法（600）は、スーパーフレーム（400）の前記シーケンスについて繰り返し、
・スーパーフレーム（400）のデータ・フィールド（411、421、412、422）から、前記没入的オーディオ信号（111）から導出された一つまたは複数のダウンミックス・チャネル信号（203）の一つまたは複数のフレームについての符号化されたオーディオ・データ（206）を抽出する段階（601）と；
・前記スーパーフレーム（400）のメタデータ・フィールド（403）から、前記符号化されたオーディオ・データ（206）から前記没入的オーディオ信号（111）の一つまたは複数のフレームを再構成するためのメタデータ（202,205）を抽出する段階（602）とを実行することを含む、
方法。
【請求項２１】
・前記符号化されたオーディオ・データ（206）および前記メタデータ（202,205）から一つまたは複数の再構成されたオーディオ・オブジェクトを導出する段階であって、オーディオ・オブジェクトは、オブジェクト信号および該オーディオ・オブジェクトの位置を示すオブジェクト・メタデータ（202）を含む、段階と；
・前記符号化されたオーディオ・データ（206）および前記メタデータ（202,205）から、再構成された残留信号（311）を導出する段階であって、前記一つまたは複数の再構成されたオーディオ・オブジェクトおよび前記再構成された残留信号（311）は、前記没入的オーディオ信号（111）を記述する、
請求項２０に記載の方法。
【請求項２２】
当該方法は、
・前記スーパーフレーム（400）からヘッダ・フィールド（401）を抽出する段階と；
・前記ヘッダ・フィールド（401）から前記スーパーフレーム（400）の前記メタデータ・フィールド（403）のサイズを導出する段階とを含む、
請求項２０または２１に記載の方法。
【請求項２３】
・前記メタデータ・フィールド（403）が可能な最大サイズを示し；
・前記ヘッダ・フィールド（401）が調整値を示し；
・前記スーパーフレーム（400）の前記メタデータ・フィールド（403）のサイズは、前記可能な最大サイズから前記調整値を引いたものに対応する、
請求項２２に記載の方法。
【請求項２４】
・前記ヘッダ・フィールド（401）は、前記メタデータ・フィールド（403）のサイズについてのサイズ・インジケータを含み；
・前記サイズ・インジケータは、前記メタデータ・フィールド（403）のサイズの異なるサイズ範囲について異なる分解能を示す、
請求項２２または２３に記載の方法。
【請求項２５】
当該方法が、
・前記スーパーフレーム（400）からヘッダ・フィールド（401）を抽出する段階と；
・前記ヘッダ・フィールド（401）に基づき、前記スーパーフレーム（400）が構成情報フィールド（402）を含むか否かを判定する段階と；
・前記ヘッダ・フィールド（401）に基づいて、構成情報フィールド（402）が前記スーパーフレーム（400）内に存在するかどうかを判定する段階とを含む、
請求項２０ないし２４のうちいずれか一項に記載の方法。
【請求項２６】
当該方法が、
・前記スーパーフレーム（400）から構成情報フィールド（402）を抽出する段階と；
・前記構成情報フィールド（402）に基づいて、前記スーパーフレーム（400）の前記データ・フィールド（411、421、412、422）によって表わされるダウンミックス・チャネル信号（203）の数を決定する段階とを含む、
請求項２０ないし２５のうちいずれか一項に記載の方法。
【請求項２７】
当該方法が、
・前記スーパーフレーム（400）から構成情報フィールド（402）を抽出する段階と；
・前記構成情報フィールド（402）に基づいて、前記メタデータ・フィールド（403）の可能な最大サイズを決定する段階とを含む、
請求項２０ないし２６のうちいずれか一項に記載の方法。
【請求項２８】
当該方法が、
・前記スーパーフレーム（400）から構成情報フィールド（402）を抽出する段階と；
・前記構成情報フィールド（402）に基づいて、前記没入的オーディオ信号（111）内に含まれる音場表現信号の次数を決定する段階とを含む、
請求項２０ないし２７のうちいずれか一項に記載の方法。
【請求項２９】
当該方法が、
・前記スーパーフレーム（400）から構成情報フィールド（402）を抽出する段階と；
・前記構成情報フィールド（402）に基づいて、前記一つまたは複数のダウンミックス・チャネル信号（203）のそれぞれを符号化するために使用されるフレーム・タイプおよび／または符号化モードを決定する段階とを含む、
請求項２０ないし２８のうちいずれか一項に記載の方法。
【請求項３０】
当該方法が、
・前記スーパーフレーム（400）からヘッダ・フィールド（401）を抽出する段階と；
・前記ヘッダ・フィールド（401）に基づいて、前記スーパーフレーム（400）が、前記没入的オーディオ信号（111）に関する追加的情報のための拡張フィールド（404）を含むか否かを判定する段階とを含む、
請求項２０ないし２９のうちいずれか一項に記載の方法。
【請求項３１】
ビットストリーム（101）を生成するよう構成されたエンコード装置（110）であって、前記ビットストリーム（101）は、没入的オーディオ信号（111）のフレームのシーケンスについてのスーパーフレーム（400）のシーケンスを含み、当該エンコード装置（110）は、スーパーフレーム（400）の前記シーケンスについて、繰り返し：
前記没入的オーディオ信号（111）から導出された一つまたは複数のダウンミックス・チャネル信号（203）の一つまたは複数のフレームについての符号化されたオーディオ・データ（206）を、スーパーフレーム（400）のデータ・フィールド（411、421、412、422）に挿入する段階と；
前記符号化されたオーディオ・データ（206）から前記没入的オーディオ信号（111）の一つまたは複数のフレームを再構成するためのメタデータ（202,205）を、前記スーパーフレーム（400）のメタデータ・フィールド（403）に挿入する段階とを実行するように構成されている、
エンコード装置。
【請求項３２】
ビットストリーム（101）から没入的オーディオ信号（111）に関するデータを導出するよう構成されたデコード装置（120）であって、前記ビットストリーム（101）は、前記没入的オーディオ信号（111）のフレームのシーケンスについてのスーパーフレーム（400）のシーケンスを含み、当該デコード装置（120）は、スーパーフレーム（400）の前記シーケンスについて繰り返し、
・スーパーフレーム（400）のデータ・フィールド（411、421、412、422）から、前記没入的オーディオ信号から導出された一つまたは複数のダウンミックス・チャネル信号（203）の一つまたは複数のフレームについての符号化されたオーディオ・データ（206）を抽出する段階と；
・前記スーパーフレーム（400）のメタデータ・フィールド（403）から、前記符号化されたオーディオ・データ（206）から前記没入的オーディオ信号（111）の一つまたは複数のフレームを再構成するためのメタデータ（202,205）を抽出する段階とを実行するよう構成されている、
デコード装置。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願への相互参照
本願は、2018年7月2日に出願された米国仮特許出願第62/693,246号への優先権の利益を主張する。同出願の内容はここに参照によって組み込まれる。
【０００２】
技術分野
本稿は、音場表現信号、特にアンビソニックス信号を含みうる没入的オーディオ信号に関する。特に、本稿は、没入的オーディオ信号を含むビットストリームを生成およびデコードすることに関する。
【背景技術】
【０００３】
聴取位置に置かれた聴取者の聴取環境内の音または音場は、アンビソニックス信号を使用して記述されうる。アンビソニックス信号は、マルチチャネル・オーディオ信号として見ることができる。ここで、各チャネルが聴取者の聴取位置における音場の特定の指向性パターンに対応する。アンビソニックス信号は、3次元（3D）デカルト座標系を用いて記述されてもよく、座標系の原点が聴取位置に対応し、x軸は前方を指し、y軸は左を指し、z軸は、上方を指す。
【０００４】
オーディオ信号またはチャネルの数を増やし、対応する指向性パターン（および対応するパン関数）の数を増やすことによって、音場の記述精度を高めることができる。例として、一次アンビソニックス信号は、4つのチャネルまたは波形、すなわち、音場の全方向成分を示すWチャネル、x軸に対応する双極子指向性パターンをもつ音場を記述するXチャネル、y軸に対応する双極子指向性パターンをもつ音場を記述するYチャネル、およびz軸に対応する双極子指向性パターンをもつ音場を記述するZチャネルを含む。二次アンビソニックス信号は、一次アンビソニックス信号の4チャネル（Bフォーマットとも呼ばれる）と、異なる指向性パターンのための5つの追加チャネルを含む9チャネルを有する。一般に、L次アンビソニックス信号は、(L−1)次アンビソニックス信号のL2個のチャネルと、追加の指向性パターンのための[(L＋1)2−L2]個の追加チャネルとを含む(L＋1)2個のチャネルを有する（3Dアンビソニック・フォーマットを使用する場合）。L＞1についてのL次アンビソニックス信号は、高次アンビソニック（HOA）信号と呼ばれることがある。
【０００５】
HOA信号は、HOA信号をレンダリングするために使用されるスピーカーの配置から独立して3D音場を記述するために使用されうる。スピーカーの配置例は、ヘッドフォン、またはラウドスピーカーの一つまたは複数の配置、または仮想現実レンダリング環境を含む。よって、オーディオ・レンダリングがスピーカーの異なる配置に柔軟に適応できるようにするために、オーディオ・レンダラーにHOA信号を提供することが有益でありうる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
アンビソニックス信号のような音場表現（soundfield  representation、SR）信号は、没入的オーディオ（immersive  audio、IA）信号を提供するために、オーディオ・オブジェクトおよび／またはマルチチャネル信号で補完されてもよい。本稿は、帯域幅効率のよい仕方で、高い知覚的品質をもってIA信号を送信および／または記憶する技術的問題に対処する。特に、本稿は、IA信号を示す効率的なビットストリームを提供するという技術的問題に対処する。かかる技術的問題は、独立請求項によって解決される。好ましい例は、従属請求項に記載されている。
【課題を解決するための手段】
【０００７】
ある側面によれば、ビットストリームを生成する方法が記載される。ビットストリームは、没入的オーディオ信号のフレームのシーケンスについてのスーパーフレームのシーケンスを含む。本方法は、スーパーフレームの前記シーケンスについて繰り返し、没入的オーディオ信号から導出された一つまたは複数のダウンミックス・チャネル信号の一つまたは複数のフレームについての符号化されたオーディオ・データを、スーパーフレームのデータ・フィールドに挿入することを含む。さらに、本方法は、符号化されたオーディオ・データから没入的オーディオ信号の一つまたは複数のフレームを再構成するためのメタデータ、特に符号化されたメタデータをスーパーフレームのメタデータ・フィールドに挿入することを含む。
【０００８】
もう一つの側面によれば、ビットストリームから没入的オーディオ信号に関するデータを導出する方法が記載される。ビットストリームは、没入的オーディオ信号のフレームのシーケンスについてのスーパーフレームシーケンスを含む。本方法は、スーパーフレームの前記シーケンスについて繰り返し、スーパーフレームのデータ・フィールドから、没入的オーディオ信号から導出された一つまたは複数のダウンミックス・チャネル信号の一つまたは複数のフレームについての符号化されたオーディオ・データを抽出することを含む。さらに、本方法は、スーパーフレームのメタデータ・フィールドから、符号化されたオーディオ・データから没入的オーディオ信号の一つまたは複数のフレームを再構成するためのメタデータを抽出することを含む。
【０００９】
さらなる側面によれば、ソフトウェア・プログラムが記載される。ソフトウェア・プログラムは、プロセッサ上での実行のために、また、プロセッサ上で実行されたときに、本稿で概説される方法段階を実行するように適応されてもよい。
【００１０】
別の側面によれば、記憶媒体が記載される。記憶媒体は、プロセッサ上での実行のために、また、プロセッサ上で実行されたときに、本稿で概説される方法段階を実行するように適応されたソフトウェア・プログラムを含んでいてもよい。
【００１１】
さらなる側面によれば、コンピュータ・プログラム製品が記載される。コンピュータ・プログラムは、コンピュータ上で実行されるときに、本稿に概説されている方法段階を実行するための実行可能命令を含んでいてもよい。
【００１２】
さらなる側面によれば、ビットストリームのスーパーフレームが記載される。ビットストリームは、没入的オーディオ信号のフレームのシーケンスについてのスーパーフレームのシーケンスを含む。スーパーフレームは、没入的オーディオ信号から導出された、一つまたは複数のダウンミックス・チャネル信号の一つまたは複数の（特に複数の）フレームについての符号化されたオーディオ・データのためのデータ・フィールドを含む。さらに、スーパーフレームは、符号化されたオーディオ・データから没入的オーディオ信号の一つまたは複数の（特に複数の）フレームを再構成するために適応されたメタデータのための（単一の）メタデータ・フィールドを含む。
【００１３】
別の側面によれば、ビットストリームを生成するように構成されたエンコード装置が記載される。ビットストリームは、没入的オーディオ信号のフレームのシーケンスについてのスーパーフレームのシーケンスを含む。エンコード装置は、スーパーフレームの前記シーケンスについて繰り返し、没入的オーディオ信号から導出された一つまたは複数のダウンミックス・チャネル信号の一つまたは複数の（特に複数の）フレームについての符号化されたオーディオ・データを、スーパーフレームのデータ・フィールドに挿入し；符号化されたオーディオ・データから没入的オーディオ信号の一つまたは複数の（特に複数の）フレームを再構成するためのメタデータをスーパーフレームのメタデータ・フィールドに挿入するように構成される。
【００１４】
さらなる側面によれば、ビットストリームから没入的オーディオ信号に関するデータを導出するように構成されたデコード装置であって、前記ビットストリームは、没入的オーディオ信号のフレームのシーケンスについてのスーパーフレームのシーケンスを含む、デコード装置。デコード装置は、スーパーフレームのシーケンスについて繰り返し、没入的オーディオ信号から導出された一つまたは複数のダウンミックス・チャネル信号の一つまたは複数の（特に複数の）フレームについての符号化されたオーディオ・データを、スーパーフレームのデータ・フィールドから抽出し；符号化されたオーディオ・データから没入的オーディオ信号の一つまたは複数の（特に複数の）フレームを再構成するためのメタデータを、スーパーフレームのメタデータ・フィールドから抽出するように構成される。
【００１５】
本特許出願で概説される、その好ましい実施形態を含む方法、装置およびシステムは、独立して、または本稿に開示されている他の方法、装置およびシステムと組み合わせて使用されうることに注意しておくべきである。さらに、本特許出願で概説される方法、装置およびシステムのすべての側面は、任意に組み合わされうる。特に、請求項の特徴は、任意の仕方で互いに組み合わされてもよい。
【図面の簡単な説明】
【００１６】
本発明は、添付の図面を参照して、例示的な仕方で下記に説明される。
【図１】符号化システムの例を示す。
【図２】没入的オーディオ信号をエンコードするための例示的なエンコード・ユニットを示す。
【図３】没入的オーディオ信号をデコードするための別の例示的なデコード・ユニットを示す;
【図４】没入的オーディオ信号についての、特に没入的オーディオ信号を示す符号化されたデータについての例示的なスーパーフレーム構造を示す。
【図５】没入的オーディオ信号を示すスーパーフレームのシーケンスを含むビットストリームを生成するための例示的な方法のフローチャートを示す。
【図６】没入的信号を示すスーパーフレームのシーケンスを含むビットストリームから情報を抽出するための例示的な方法のフローチャートを示す。
【発明を実施するための形態】
【００１７】
上に概説したように、本稿は、HOA信号、マルチチャネルおよび／またはオブジェクト・オーディオ信号のような没入的オーディオ信号の効率的な符号化に関する。ここで、特にHOA信号は、本明細書では、より一般的に、音場表現（soundfield  representation、SR）信号と呼ばれる。さらに、本稿は、ビットストリーム内での伝送ネットワークを通じた没入的オーディオ（immersive  audio、IA）信号の記憶または伝送に関する。
【００１８】
導入部で概説したように、SR信号は、比較的多数のチャネルまたは波形を含むことがあり、異なるチャネルは、異なるパン関数および／または異なる指向性パターンに関係する。例として、L次の3D一次アンビソニクス（FOA）またはHOA信号は、(L＋1)2個のチャネルを有する。一次アンビソニックス（FOA）信号は、4チャネルを含む次数L＝1のアンビソニックス信号である。SR信号は、さまざまな異なるフォーマットで表現されうる。
【００１９】
音場は、聴取位置のまわりの任意の方向から発せられる一つまたは複数の音事象で構成されていると見なすことができる。結果として、前記一つまたは複数の音事象の位置は球の表面上で定義されてもよい（聴取位置または基準位置が球の中心にある）。
【００２０】
FOAまたは高次アンビソニックス（HOA）のような音場フォーマットは、任意のスピーカー配置（すなわち任意のレンダリング・システム）で音場をレンダリングできるようにする仕方で定義される。しかしながら、レンダリング・システム（ドルビー・アトモス・システムなど）は、典型的には、スピーカーの可能な高さが、定義された数の平面（たとえば、耳の高さの（水平）平面、天井もしくは上平面および／または床もしくは下平面）に固定されるという意味で、制約される。よって、理想的な球面音場の概念は、球面の表面上のさまざまな高さにある異なるリング（蜂の巣を構成する積み重ねられたリングと同様）内に位置する音オブジェクトで構成される音場に修正されうる。
【００２１】
図1に示されるように、オーディオ符号化システム100は、エンコード・ユニット110とデコード・ユニット120とを備える。エンコード・ユニット110は、入力信号111に基づいて、デコード・ユニット120への伝送のためのビットストリーム101を生成するように構成されてもよく、入力信号111は、没入的オーディオ信号（たとえば、仮想現実（VR）アプリケーションのために使用される）を含んでいてもよく、または、没入的オーディオ信号であってもよい。没入的オーディオ信号111は、SR信号、マルチチャネル信号および／または複数のオブジェクト（各オブジェクトは、オブジェクト信号およびオブジェクト・メタデータを含む）を含んでいてもよい。デコード・ユニット120は、ビットストリーム101に基づいて出力信号121を提供するように構成されてもよく、出力信号121は、再構成された没入的オーディオ信号を含んでいてもよく、または、再構成された没入的オーディオ信号であってもよい。
【００２２】
図2は、エンコード・ユニット110、200の例を示す。エンコード・ユニット200は、入力信号111をエンコードするように構成されてもよく、入力信号111は、没入的オーディオ（IA）信号111であってもよい。IA信号111は、マルチチャネル入力信号201を含んでいてもよい。マルチチャネル入力信号201は、SR信号および一つまたは複数のオブジェクト信号を含んでいてもよい。さらに、前記複数のオブジェクト信号についてのオブジェクト・メタデータ202が、IA信号111の一部として提供されてもよい。IA信号111は、コンテンツ摂取エンジンによって提供されてもよく、コンテンツ摂取エンジンは、SR信号、一つまたは複数のマルチチャネル信号、および／または一つまたは複数のオブジェクトを含んでいてもよいVRコンテンツのような（複合）IAコンテンツからオブジェクトおよび／またはSR信号を導出するように構成されてもよい。
【００２３】
エンコード・ユニット200は、マルチチャネル入力信号201を複数のダウンミックス・チャネル信号203にダウンミックスするように構成されたダウンミックス・モジュール210を有する。前記複数のダウンミックス・チャネル信号203は、SR信号、特に一次アンビソニックス（FOA）信号に対応してもよい。
ダウンミックスは、サブバンド領域またはQMF領域（たとえば、10以上のサブバンドを使用）で実行されてもよい。エンコード・ユニット200は、複数のダウンミックス・チャネル信号203からマルチチャネル入力信号201を再構成するように構成された合同符号化メタデータ205（特に、SPAR（Spatial  Audio  Resolution  Reconstruction［空間オーディオ分解能再構成］）メタデータ）を決定するように構成された合同符号化モジュール230（特に、SPARモジュール）をさらに有する。合同符号化モジュール230は、サブバンド領域において合同符号化メタデータ205を決定するように構成されてもよい。一例では、空間オーディオ再構成（spatial  audio  reconstruction）（SPAR）ツールは、比較的多数のオーディオ・チャネルおよびオブジェクトの改善された符号化のための符号化ツールである。符号化効率を稼ぐために、このツールは、より少数の合同入力オーディオ・チャネルと低オーバーヘッドのサイド情報からのオーディオ・チャネルおよびオブジェクトを再構成することをサポートする。
【００２４】
合同符号化またはSPARメタデータ205を決定するために、複数のダウンミックス・チャネル信号203は、サブバンド領域に変換されてもよく、および／またはサブバンド領域内で処理されてもよい。さらに、マルチチャネル入力信号201がサブバンド領域に変換されてもよい。その後、合同符号化またはSPARメタデータ205は、サブバンド毎に決定されてもよく、特に、合同符号化またはSPARメタデータ205を使用して複数のダウンミックス・チャネル信号203のサブバンド信号203をアップミックスすることによって、マルチチャネル入力信号201のサブバンド信号の近似が得られる。種々のサブバンドについての合同符号化またはSPARメタデータ205は、対応するデコード・ユニット120への送信のために、ビットストリーム101に挿入されてもよい。
【００２５】
さらに、エンコード・ユニット200は、複数のダウンミックス・チャネル信号203の波形符号化を実行し、それにより符号化されたオーディオ・データ206を提供するように構成された符号化モジュール240を有していてもよい。ダウンミックス・チャネル信号203のそれぞれは、モノ波形エンコーダ（たとえば、3GPP  EVSエンコード）を用いてエンコードされてもよく、それにより、効率的なエンコードが可能になる。複数のダウンミックス・チャネル信号203をエンコードすることのさらなる例は、MPEG  AAC、MPEG  HE-AACおよび他のMPEGオーディオ・コーデック、3GPPコーデック、ドルビー・デジタル／ドルビー・デジタル・プラス（AC-3、eAC-3）、Opus、LC-3および他の同様のコーデックである。さらなる例として、AC-4コーデックに含まれる符号化ツールは、エンコード・ユニット200の動作を実行するように構成されてもよい。
【００２６】
さらに、符号化モジュール240は、合同符号化メタデータ（すなわち、SPARメタデータ）205およびオブジェクト・メタデータ202のエントロピー符号化を実行し、それにより、符号化されたメタデータ207を提供するように構成されてもよい。符号化されたオーディオ・データ206および符号化されたメタデータ207はビットストリーム101に挿入されてもよい。ビットストリーム101は、本稿に記載されているスーパーフレーム構造を示してもよい。本稿に記載されている方法500は、符号化モジュール240によって実行されてもよい。
【００２７】
図3は、デコード・ユニット120、350の例を示す。デコード・ユニット120、350は、符号化されたオーディオ・データ206および符号化されたメタデータ207を含んでいてもよいビットストリーム101を受領する受領器を含んでいてもよい。デコード・ユニット120、350は、ビットストリーム101から符号化されたオーディオ・データ206および符号化されたメタデータ207を多重分離するプロセッサおよび／またはデマルチプレクサを含んでいてもよい。デコード・ユニット350は、符号化されたオーディオ・データ206から複数の再構成されたチャネル信号314を導出するように構成されたデコード・モジュール360を有する。デコード・モジュール360は、さらに、符号化されたメタデータ207から合同符号化またはSPARメタデータ205および／またはオブジェクト・メタデータ202を導出するように構成されてもよい。本稿に記載される方法600は、デコード・モジュール360によって実行されてもよい。
さらに、デコード・ユニット350は、合同符号化またはSPARメタデータ205から、および複数の再構成されたチャネル信号314から、再構成されたマルチチャネル信号311を導出するように構成された再構成モジュール370を有する。合同符号化またはSPARメタデータ205は、複数の再構成されたチャネル信号314からマルチチャネル信号311を再構成することを可能にするアップミックス行列の時間および／または周波数変化する要素を伝達してもよい。アップミックス・プロセスは、QMF（直交ミラー・フィルタ）サブバンド領域で実行されてもよい。あるいはまた、アップミックス・プロセスを実行するために、別の時間／周波数変換、特にFFT（高速フーリエ変換）に基づく変換が使用されてもよい。一般に、周波数選択的な解析および（アップミックス）処理を可能にする変換が適用されうる。アップミックス・プロセスはまた、再構成されたマルチチャネル信号311の共分散の改善された再構成を可能にする脱相関器を含んでいてもよく、脱相関器は、追加の合同符号化またはSPARメタデータ205によって制御されてもよい。
【００２８】
再構成されたマルチチャネル信号311は、再構成されたSR信号と、一つまたは複数の再構成されたオブジェクト信号とを含んでいてもよい。再構成されたマルチチャネル信号311およびオブジェクト・メタデータは、出力信号121（再構成されたIA信号121としても知られる）を形成してもよい。再構成されたIA信号121は、スピーカー・レンダリング331、ヘッドフォン・レンダリング332、および／または、たとえば、SR表現に依拠するVRコンテンツのレンダリング333のために使用されうる。
【００２９】
よって、IA入力信号111を
・複数のダウンミックス・チャネル信号203を含むダウンミックス信号；ここで、ダウンミックス信号203は、音場表現（SR）信号であってもよい；および
・SPARまたは合同符号化メタデータ205および／または一つまたは複数のオブジェクトについてのオブジェクト・メタデータ202を含むメタデータ202、205
にエンコードするように構成されたエンコード・ユニット110、200が記述される。
【００３０】
メタデータ202、205、特にSPARメタデータ205は、ダウンミックス信号とは異なる時間分解能を示してもよい。特に、メタデータ202、205は、ダウンミックス信号の複数のフレーム（たとえば、2フレーム）のために使用されてもよい。これに鑑み、ビットストリーム101についてスーパーフレームが定義されてもよい。スーパーフレームは、前記ダウンミックス信号の複数のフレームと、前記SRダウンミックス信号の前記複数のフレームについてのメタデータ202、205とを含む。
【００３１】
図4は、例示的なスーパーフレーム400を示す。スーパーフレーム400は、ベース・ヘッダ（base  header、BH）フィールド401、および／またはスーパーフレーム400全体について有効なデータを含みうる構成情報（configuration  information、CI）フィールド402を含みうる。さらに、スーパーフレーム400は、ダウンミックス信号の一つまたは複数の（特に複数の）フレームについての符号化されたオーディオ・データ206のための信号データ・フィールド411、412、421、422を含む。特に、各ダウンミックス・チャネル信号203について、一つまたは複数の（特に複数の）信号データ・フィールド411、412、421、422が設けられてもよく、たとえば、第1のダウンミックス・チャネル信号203の2つのフレームのための信号データ・フィールド411、421と、N番目のダウンミックス・チャネル信号203の2つのフレームのための信号データ・フィールド412、422である。信号データ・フィールド411、412、421、422は、本明細書ではEVSビット・フィールドとも呼ばれる（たとえば、EVS符号化器がダウンミックス・チャネル信号203をエンコードするために使用される）。
【００３２】
さらに、スーパーフレーム400は、メタデータ・フィールド（MDF）403を含む。メタデータ・フィールド403は、SPARまたは合同符号化メタデータ205および／または予測係数（PC）を提供するように構成されてもよい。よって、メタデータ・フィールド403は、SPARビット・フィールドまたはPCビット・フィールドでありうる（使用されている符号化モードに依存する）。加えて、スーパーフレーム400は、フレーム・エクステンダー（frame  extender、FE）・フィールド404を含んでいてもよい。
【００３３】
よって、スーパーフレーム400は、次のように構成された信号伝達要素を含んでいてもよい：
・N個のダウンミックス・チャネル信号の（EVS）符号化のため使用された前記一つまたは複数の（EVS）コーデック・モードを示す；デフォルトはN＝4チャネルであってもよく、つまり、4個の（EVS）コーデック・ダウンミックス・チャネル信号W、X'、Y'、Z'が存在する；
・メタデータ支援（metadata-assisted）（EVS）コーデックの選択された動作モードを示す；
・メタデータ・ビットレートを示す；
・潜在的な将来の拡張を信号伝達する可能性を提供する。
【００３４】
一つまたは複数の信号伝達要素（たとえばCIフィールド402）は、スーパーフレーム400内においてインバンドで条件付きで提供されるだけであってもよい。任意的なまたは条件付きの信号伝達要素が提供される場合、この信号伝達要素は、動的に適応される、および／またはスーパーフレーム400内に含まれうる。一つまたは複数の信号伝達要素は、静的に保持されてもよく、および／または、たとえばアウトオブバンド・メッセージとして、1回だけ提供されてもよい。一つまたは複数の信号伝達要素は半動的であってもよく、その場合、前記一つまたは複数の信号伝達要素は、選択されたスーパーフレーム400においてのみインバンドで提供される。
【００３５】
スーパーフレーム400は、以下の特徴の一つまたは複数を可能にするように設計されうる：
・メタデータ支援EVS符号化スーパーフレームの完全なデコードおよびレンダリング。
・メタデータ支援EVS符号化スーパーフレームの部分的なモノ・デコード。
・連結されたスーパーフレームのシーケンスからのスーパーフレーム・サイズ情報の、スーパーフレームをデコードする必要のない、低計算量の抽出。たとえば、スーパーフレーム・サイズ情報を、このスーパーフレーム・サイズ情報を提供するまたは必要とする二次フォーマット（たとえば、ISOBMFF、ISOベース媒体ファイル・フォーマット）に入れるためである。
・スーパーフレーム・データをデコードする必要のない、低計算量のビットレート決定。
・スーパーフレーム・データをデコードする必要のない、スーパーフレームの低計算量のフィードフォワードとスキップ。
・（特に、一定ビットレート動作の場合の）スーパーフレーム・データをデコードする必要のない、低計算量のフィードバック。
・算術符号化および／またはエントロピー符号化されたEVSおよび／またはメタデータ・ビットストリーム部分におけるビット誤りの場合の、単純な再同期およびスーパーフレーム・スキップ。
・編集可能なスーパーフレーム。これは、メタデータまたはEVSデータ・フレームを置き換えることを許容する。
【００３６】
メタデータ支援EVSコーデックの符号化されたビット・スーパーフレーム400は、40msの符号化ストライドに対応しうる（たとえば、20msの2つのフレームを含む）。それは次の基本ビット・フィールドで構成される：
・ベース・ヘッダ・フィールド（BH）401：このフィールドは、構成フィールド存在インジケータ（Configuration  field  Presence  Indicator、CPI）、メタデータ・フィールド・サイズ調整インジケータ（MetaData  field  size  Adjustment  indicator、MDA）、および拡張インジケータ（Extension  Indicator、EI）を含む。CPIは、構成情報（CI）フィールドが現在のスーパーフレーム400において供給されているか否かを示してもよい。MDAは、信号伝達された最大メタデータ・フレーム・サイズと実際のメタデータ・フレーム・サイズとの間の差を信号伝達してもよい。EIは、スーパーフレーム400がフレーム・エクステンダー（Frame  Extender、FE）404によって拡張されるか否かを信号伝達してもよい。
・構成情報フィールド（CI）402：このフィールドは、使用されたEVS、SPAR、および予測係数（Predictive  Coefficient）符号化ツールの構成に関する信号伝達情報を担持してもよく、たとえば本稿内で記述されているフレーム・タイプ（符号化モード）、ビットレート、および他の構成パラメータなどである。
・EVSビット・フィールド411、421、412、422：各フィールドは、3GPP  TS26.445:  "Codec  for  Enhanced  Voice  Services（EVS）;  Detailed  algorithmic  description"、セクション7に規定されているような、単一のEVSフレームのビットを担持してもよい（特に、EVSペイロード・ヘッダなし）。この文献は参照により本稿に組み込まれる。
・SPARビット・フィールド（SPAR）403：このフィールドは、単一のSPARメタデータ・フレームのビットを担持してもよく、可能性としては、バイト整列させるために、末尾にゼロ・パディングされる。
・予測係数（Predictive  Coefficient）ビット・フィールド（PC）403：このフィールドは、単一の予測係数メタデータ・フレームのビットを担持してもよく、可能性としては、バイト整列させるために、末尾にゼロ・パディングされる。
・フレーム・エクステンダー（Frame  Extender、FE）404：このフィールドは将来の使用のために定義されてもよく、拡張データを担持してもよい。FEに含まれるサイズ要素を除き、FEによって担持される他のデータは将来の使用のためにリザーブされてもよい（reserved  for  future  use、RFU）。
【００３７】
すべての基本ビット・フィールドは、バイト整列され、必要であれば、最終的にそれらの定義されたサイズまで末尾にゼロ・パディングされてもよい。
【００３８】
上記の基本フィールドは、以下のシーケンス順で（単一の）スーパーフレーム400内に含まれてもよい。スーパーフレームは、
・一つのベース・ヘッダ（BH）401であって、
−構成フィールド存在インジケータ（CPI）、
−メタデータ・フィールド・サイズ調整インジケータ（MDA）および
−拡張インジケータ（EI）
を含むBH。
・一つの任意的な構成情報フィールド（CI）402。CIフィールド402の存在は、CPIによって信号伝達されてもよい。
・N個のEVSエンコードされたダウンミックス・チャネル信号S1,…,SNのデータ。各ダウンミックス・チャネル信号について2つの相続くフレームがある。これは、2×N個の基本EVSビット・フィールド411、421、412、422（本明細書では、EVS(.)と称される）によって担持されうる。4つのダウンミックス・チャネル信号をもつデフォルト動作では、8つの相続くEVSビット・フィールド411、421、412、422があり、ダウンミックス・チャネル信号W、X'、Y'、Z'の2つのフレームを表わす。
・SPARまたは予測係数のための一つのメタデータ・フレーム（MDF）フィールド403。よってこれは、
−一つの基本SPARビット・フィールド、または
−一つの基本PCビット・フィールドである。
・一つの任意的なフレーム・エクステンダー（FE）404。FEフィールドの存在は、EIによって示されてもよい。
【００３９】
表1は、スーパーフレーム400の例示的な構造を示す。
【表１】
2021530723.tif 000003
【００４０】
デフォルトの状況では、4つのEVS符号化されたダウンミックス・チャネル信号がある。デフォルトの状況についてのスーパーフレーム構造は表2に示される。
【表２】
2021530723.tif 000004
【００４１】
種々の基本ビット・フィールドに関するさらなる詳細が、下記で提供される。
【００４２】
ベース・ヘッダ（Base  Header、BH）・フィールド401は、構成フィールド存在インジケータ（Configuration  field  Presence  Indicator、CPI）、メタデータ・フィールド・サイズ調整インジケータ（MetaData  field  size  Adjustment  indicator、MDA）、および拡張インジケータ（Extension  Indicator、EI）を担持することができる。このバイト・フィールドは常にスーパーフレーム400の最初の要素であってもよい。
【００４３】
BHフィールド401の構造が表3に示される。
【表３】
2021530723.tif 000005
【００４４】
構成フィールド存在インジケータ（CPI）は、現在のスーパーフレーム400内の構成情報（Configuration  Information、CI）フィールドの存在を信号伝達するために使用される単一ビットであってもよい。CPIは以下の意味をもちうる。
・CPI＝'0'：これは、現在のスーパーフレーム400において構成情報フィールドが提供されていないことを示す。その代わり、構成情報は、静的なアウトオブバンドの情報として、または、構成情報フィールド402を担持する、以前に受信されたスーパーフレーム400のうち最も最近のものから提供されてもよいことを注意しておくべきである。
・CPI＝'1'：現在のスーパーフレーム400で構成情報フィールドが提供されていることを示す。CIフィールド402内で提供される構成情報は、構成情報フィールド402を担持する次のスーパーフレーム400が提供されるまで、このスーパーフレーム400および将来のスーパーフレーム400について有効である。
【００４５】
メタデータ・フィールド・サイズ調整インジケータ（MDA）は、CPIビットの直後に提供されてもよい。この6ビット・インジケータは、MDR要素（下記で定義）によって信号伝達されるMDF  403の長さとMDF  403の実際のサイズとの間の差を信号伝達してもよい。示される差は、MDAをインデックスとして用いて、表4に示されるルックアップから導出されうる。表4の一連の調整値は、Matlabスタイル：start-value:step-size:end-value〔開始値：ステップ・サイズ：終了値〕で指定される。表4に示される一定でない調整パラメータ・ステップ・サイズは、メタデータの全エントロピー符号長の分布の近似モデルに従って設計されうる。これは、MDF  403内の未使用ビットの数を最小化し、よって、伝送オーバーヘッドを最小化することを許容する。
【表４】
2021530723.tif 000006
【００４６】
最大MDFサイズに依存して、調整値は1バイトまたは2バイトの単位を表わす。275バイトまでの最大MDFサイズについては、調整値は1バイト単位を表わし、それ以外については2バイト単位を表わす。
【００４７】
MDAインジケータには、単一の拡張インジケータ・ビット（Extension  Indicator  bit、EI）が続いてもよい。このビットが1に設定されている場合、現在のスーパーフレーム400の後には、フレーム・エクステンダー（Frame  Extender、FE）要素が追加される。
【００４８】
任意的に提供される構成情報（CI）フィールド402は、表5に示されるように、以下の信号伝達要素を担持してもよい。CIフィールド402は、8バイトのデータから構成されてもよく、または、8バイトのデータを含んでいてもよい（ダウンミックス・チャネル信号一つ当たり2つのEVSフレームかつN＝4個のダウンミックス・チャネルの場合）。
【表５】
2021530723.tif 000007
【００４９】
表6は、4つのEVS符号化されたダウンミックス・チャネル信号を有するデフォルトの場合についての任意的な構成情報フィールド402を示している。この場合、CIフィールドは9バイトのデータで構成される。
【表６】
2021530723.tif 000008
【００５０】
EVS符号化されたダウンミックス・チャネル信号の数Nについてのインジケータ（N-I）は、EVS符号化されたダウンミックス・チャネル信号の数Nをエンコードする3ビットの要素であってもよい。Nは、3ビットの要素で表わされる数を1だけ増分することにより、インジケータN-Iから得られる。4つのEVSダウンミックス・チャネル信号でデフォルト動作を達成するためには、N-I要素は3（'011'）に設定されてもよい。
【００５１】
メタデータ・タイプ指示（Metadata  Type  indication、MDT）ビットは、次の意味をもちうる：
・MDT＝'0'：MDFがPCビット・フィールドを担持することを示す。
・MDT＝'1'：MDFがSPARビット・フィールドを担持することを示す。
【００５２】
メタデータ符号化構成フィールド（MetaData  Coding  configuration  field、MDC）は、MDTビットの指示に依存して、使用された予測係数ツールまたはSPAR符号化ツールのいずれかの構成情報を含みうる。MDCフィールドは、CIフィールド402の11ビット要素であってもよい。そのビットの意味は、CIフィールド402のMDTビットに依存しうる。MDTビットの値に依存して、MDCビットは次の意味をもちうる：
・MDT＝'0'：MDTビットが0の場合、MDCの3つのMSBは、予測係数符号化方式の構成パラメータをエンコードする。MDCの残りの8ビットは使用されず、ゼロ・パディングされる。この場合のMDCフィールドの構造と内容が表7  aに示される。
・MDT＝'1'：MDTビットが1の場合、11個のMDCビットは、表７  ｂに示されるSPARコーデック構成をエンコードする。HOA次数は、hoa_order_idxを1だけインクリメントすることによって計算されうる。
【表７】
2021530723.tif 000009
【００５３】
メタデータ・ビットレート信号伝達フィールド（MetaData  Bit  rate  signaling  field、MDR）は、5ビットを含んでいてもよく、MDFの最大サイズをエンコードするために使用されうる。最大MDFサイズは、表8を用いたテーブル・ルックアップによって得られてもよく、ここで、MDR値が表8のインデックスである。さらに、表8は、（最大）メタデータ・ビットレートをkbps単位で示す。表8では、実際のMDFサイズは、最大MDFサイズから、MDA（BHフィールド401から）によって示される調整数／値を引いたものとして信号伝達される。これにより、細かい分解能（典型的にはバイト分解能）で実際のMDFサイズの信号伝達ができる。また、MDF中の未使用ビットはゼロ・パッディングされてもよく、そのようなことは、実際のMDFサイズが符号化されたメタデータのために必要とされるよりも多くのスペースを提供する場合に起こりうることも注意しておくべきである。
【表８】
2021530723.tif 000010
【００５４】
帯域数フィールド（Band  Number  field、BND）は3ビットの数であってもよく、メタデータ符号化において使用されるサブバンドの数を示してもよい。帯域数は、表9内のルックアップによってBND値から導出される。デフォルト動作では、BNDフィールドは5（'101'）に設定されてもよく、これは12個のサブバンドを示す。
【表９】
2021530723.tif 000011
【００５５】
予約ビット（Reserved  bit、RES）の使用は、将来の使用のためにリザーブされてもよい。デフォルト動作では、このビットは'0'に設定され、受信者によって無視されうる。
【００５６】
EVS  FTフィールド（FT-x,y）は、x番目のダウンミックス・チャネル信号のy番目のフレームの符号化のために適用されるEVSフレーム・タイプ（FT）を表わしてもよい。ここでx=1…Nであり、y＝1,2である。EVSフレーム・タイプは、3GPP  TS  26.445、セクションA2.2.1.2に定義されていてもよく、これはここに参照により組み込まれる。CIフィールド402内の最後のEVS  FTフィールドには、オクテット整列を確実にする最大7つのゼロ・パディング・ビットが続いてもよいことを注意しておくべきである。最後のEVS  FTフィールドがオクテット整列して終わる場合、後にゼロ・パディング・ビットは追加されない。ゼロ・パディング・ビットは受信器によって無視される。
【００５７】
基本EVSビット・フィールド411、421、412、422は、それぞれ使用されるEVS符号化モードについて、3GPP  TS  26.445、セクション7（これはここに参照により組み込まれる）に規定されるように定義されてもよい。引用した文献で規定されているように、ビットレートまたはEVS動作モードを示すために、基本EVSフレーム・フィールドの一部として、追加の信号伝達ビットは定義されていない。この情報は、現在または以前のスーパーフレーム400の任意的なCIフィールド402の一部であってもよく、またはアウトオブバンドで提供されてもよい。
【００５８】
SPARメタデータのための係数の詳細な割り当ては表10に示される。表10は、フレーム内に挿入されるビットの順序を示す。各パラメータの最上位ビット（MSB）が常に最初に挿入されることに注意されたい。各フィールドは動的に量子化されるので、ビット割り当ては可変である。
【表１０】
2021530723.tif 000012
【００５９】
PCメタデータの係数の詳細な割り当てが表11に示される。表11は、スーパーフレーム400内に挿入されるビットの順序を示す。各パラメータの最上位ビット（MSB）が常に最初に挿入されることに注意されたい。各フィールドは動的に量子化されるので、ビット割り当ては可変である。
【表１１】
2021530723.tif 000013
【００６０】
フレーム・エクステンダー（FE）404は、典型的には、最初の2バイトに、FEフィールド404のサイズをバイト単位で示す16ビットの符号なし整数を担持する。この要素はFEサイズと称される。よって、FEサイズ数は2以上である。FEフィールド404の残りのFEデータ部分の内容および意味は、将来の使用のためにリザーブされてもよい。デフォルト動作では、FEサイズ要素は構文解析されてもよく、FEデータ要素はスキップされ、無視されてもよい。FEフィールド404の構造および内容は、表12に示される。
【表１２】
2021530723.tif 000014
【００６１】
よって、メタデータ支援EVSコーデックの構成情報の信号伝達を可能にするスーパーフレーム構造が記述される。スーパーフレーム構造は、受信器がメタデータ支援EVSコーデック・データをデコードできるようにする。
【００６２】
一般的なレベルでは、メタデータ支援EVSコーデックは、マルチモードおよび／またはマルチレート符号化システムである。根底にあるEVSコーデックは、多数の異なる符号化モードおよび／またはビットレートで動作するように構成されてもよい。さらに、空間的メタデータ・コーデックは、さまざまな異なる符号化モードおよび／またはビットレートを提供しうる。空間的メタデータ・コーデックは、典型的には一定でないビットレートに帰着するエントロピー符号化を使用する。これは、実際に使用されるビットレートが、典型的には、与えられた目標ビットレートよりも低いことを意味する。ある種のフレームについては、このビットレート・アンダーシュートはより小さいことがあり、他のいくつかのフレームについては、より大きいことがある。
【００６３】
デコーダ120が伝送されたビットストリーム101を適正にデコードできるように、エンコーダ110によって使用された正確な符号化モードおよびビットレートが提供されてもよい。メタデータのエントロピー符号化された部分について、使用されたハフマン符号がコンマレス（commaless）であり、一意的に復号可能であるので、正確に使用されたビットレートは要求されないことがありうる。それにもかかわらず、ビットストリーム101の受信器は、フレーム（またはスーパーフレーム400）の符号化のために使用されるビット数を提供されてもよい。これは、たとえば、デコーダ120が、これらのフレームをデコードする必要なく、いくつかの受信フレームをスキップする必要がある場合に、望ましい。本稿では、スーパーフレーム構造であって、以下の特徴をサポートするものを記述した：
・フル・フレームのデコード。
・モノ再生のために必要な部分のみのデコード。
・フレーム400から長さ情報を抽出して、この情報を提供するおよび／または必要とする二次フォーマット（ISOBMFF）にする。
・フレーム400の連結において、途中でのみデコードし、最初の数フレームを効率的にスキップする。
・ビット誤りがある場合に、次のフレーム開始をみつける（再同期）。
・フレームをデコードする必要なく、迅速かつ効率的にビットレートを決定する。
・フレームの編集（メタデータまたはEVSフレームの一部を置き換える）。
・フレームをデコードしない高速フィードフォワード動作。
・一定長および可変長のコーデック・データ・ペイロードの効率的な搬送のサポート。
【００６４】
さらに、スーパーフレーム構造は、次のことのための必要なすべての信号伝達要素を含むように記述されている：
・N個のダウンミックス・チャネル信号のEVS符号化のために使用されるEVSコーデック・モード（ビットレートを含む）を示す。
・デフォルトはN＝4であってもよく、これは、4つのEVSコーデック・ダウンミックス・チャネルW、X'、Y'、Z'があることを意味する。
・支援メタデータ・コーデックの選択された動作モードを示す。
・有意な信号伝達オーバーヘッドなしで、メタデータのビットレートを高分解能で示す。
・潜在的な将来の拡張を信号伝達する可能性を提供する。
【００６５】
スーパーフレーム400の信号伝達要素のあるものは、符号化セッション中に頻繁に変化しないことがあり、または静的でさえある。メタデータ・ビットレートのような他のいくつかの信号伝達要素は、スーパーフレームからスーパーフレームへと変化することがある。その理由で、ある種の信号伝達要素は、スーパーフレーム400（CIフィールド402など）内でインバンドで条件付きで提供されるだけである。それらが提供される場合、これらの信号伝達要素は、スーパーフレームごとに動的に適応させることができる。また、これらの信号伝達要素を静的に保ち、たとえばアウトオブバンド・メッセージとして一度だけ提供するという可能性もある。信号伝達要素は半動的であってもよく、その場合、それらはある種のスーパーフレームにおいてインバンドで提供されるだけである。
【００６６】
メタデータ・ビットレートの信号伝達に関して、主な課題は、スーパーフレーム400当たりに必要とされるビット数（またはバイト数）が比較的大きな範囲内で変化する可能性があることである。フレーム当たりの最大の可能なビット数のみを信号伝達すると、エントロピー符号が最大長よりもかなり短い場合、未使用のままとなるビット数が比較的多くなる可能性がある。他方、スーパーフレーム400内で実際に使用されたビット数（またはバイト数）を示すための直接的な信号伝達要素を提供するには、比較的多数の信号伝達ビットを必要とすることになる。本稿では、可能なメタデータ・ビットレートの比較的大きな範囲をカバーしつつ、スーパーフレーム400内で実際に使用されたビット数（またはバイト数）についての信号伝達ビット数を最小限に保つ方式が記述される。
【００６７】
システムの観点からは、メタデータ支援EVSコーデックのスーパーフレーム400は、エンコード・ヘッドエンドで生成される。これは、符号化されていない没入的またはVR（Virtual  Reality［仮想現実］）オーディオ・データへのアクセスを有するネットワーク内のサーバーであってもよい。それはまた、没入的オーディオ信号を捕捉する携帯電話であってもよい。エンコードされたフレーム400は、受信端末にダウンロードされるか、またはDASH（Dynamic  Adaptive  Streaming  over  HTTP［を通じた動的な適応的ストリーミング］）またはRTSP/RTP（Real-Time  Streaming  Protocol/Real-time  Transport  Protocol［リアルタイム・ストリーミング・プロトコル／リアルタイム・トランスポート・プロトコル］）のようなストリーミング・プロトコルに従って伝送されるファイルに挿入されうる。エンコードされたスーパーフレーム400がファイルに格納される場合、スーパーフレーム400は、ISOBMFFに従ってフォーマットされたファイルに挿入されてもよい。ある種の構成情報が静的であり、スーパーフレーム400の一部として伝送されない場合、それは代わりに、セッション記述プロトコル（session  description  protocol、SDP）のようなアウトオブバンド手段によってエンコード端からデコード端に提供されてもよい。
【００６８】
本稿で概説されている方式は、基礎となるコーデックとしてEVSコーデックを使用してもよく、スーパーフレーム400においてインバンドで、またはたとえばSDPを使ってアウトオブバンドで、マルチモード／マルチレート・メッセージ（フレーム・タイプ）を提供してもよい。これはマルチモードの没入的メタデータ符号化フレームワークと組み合わされてもよい。該フレームワークは、やはりインバンドまたはアウトオブバンドで伝送できる一組の構成パラメータを用いて効率的に構成できる。さらに、マルチモードの没入的メタデータ符号化を、関連する最大ビットレート（またはフレーム／スーパーフレーム内のビット数）をインバンドまたはアウトオブバンドで許容する方式と組み合わせる可能性がある。
【００６９】
本稿に記載されたスーパーフレーム構造は、実際に使用されたメタデータ・フィールド・サイズを、最大数（これは任意的に、アウトオブバンドで信号伝達される）から調整パラメータを引いたものとして信号伝達する。調整パラメータについては、各スーパーフレーム400の一部として、指示が伝送される。調整パラメータの符号化は、好ましくは、一定でないステップ・サイズで実行され、それが、調整パラメータのための信号伝達ビットの低減された数を使って、可能な調整の増大した範囲をカバーすることを許容する。さらに、一定でない調整パラメータ・ステップ・サイズは、メタデータの全エントロピー符号長の分布の近似モデルを使用して設計されてもよい。これにより、メタデータ・フィールド内の未使用ビット数を最小にし、こうして伝送オーバーヘッドを最小限にすることができる。さらに、メタデータ・ビットレート（サイズ）のためのオーバーヘッドは、メタデータ・フィールド内の未使用ビット数を最小限に抑えながら、信号伝達されうる。よって、全体的な伝送ビットレートは低減される。
【００７０】
CIフィールド402内の構成情報（CI）は、4つのダウンミックス・チャネル信号W、X'、Y'、Z'のEVS符号化のための選択されたEVSフレーム・タイプに関係してもよい。構成情報は、さらに、（i）メタデータ支援EVSコード、FOAまたはHIQの選択された動作モード、（ii）HIQ動作の場合のSPARメタデータのビットレート、（iii）FOA動作の場合の予測係数メタデータのビットレート、に関係してもよい。構成情報の指示は、（1）動的であり、ペイロードと一緒にインバンドで提供される；（2）半動的であり、以前のペイロードと一緒にインバンドで提供される；あるいは（3）静的であり、アウトオブバンドで、DASH適応セットのコーデック属性と一緒に16進ストリングとして提供されることがありうる。
【００７１】
FOA（First  Order  Ambisonics［一次アンビソニックス］）モードは、予測係数メタデータに依拠する低ビットレート動作モードである（たとえば約128kbpsで動作）。FOAは、比較的低い空間分解能のため、典型的には比較的限定された品質を示す。HIQ（High  Immersive  Quality［高没入品質］）モードは、中ないし高レートの動作モードである（たとえば、128〜512kbpsで動作）。これはSPARメタデータに依拠し、もとのSR信号を再構成することを目的として、非常に高い没入品質を提供することができる。
【００７２】
図5は、ビットストリーム101を生成するための方法500を示し、ビットストリーム101は、没入的オーディオ信号111の（基本）フレームのシーケンスについてのスーパーフレーム400のシーケンスを含む。没入的オーディオ（immersive  audio、IA）信号111は、基準位置での音場を記述しうる音場表現（soundfield  representation、SR）信号を含んでいてもよい。基準位置は、聴取者の聴取位置および／またはマイクロフォンの捕捉位置であってもよい。SR信号は、基準位置における音場の複数の異なる到達方向のための複数のチャネル（または波形）を含んでいてもよい。代替的または追加的に、IA信号111は、一つまたは複数のオーディオ・オブジェクトおよび／またはマルチチャネル信号を含んでいてもよい。
【００７３】
IA信号111、特に、IA信号内に含まれるSR信号は、L次アンビソニックス信号を含んでいてもよく、L次アンビソニックス信号であってもよく、Lは1以上である。代替的または追加的に、SR信号は、基準位置のまわり球上の複数の異なるリングに配置された複数の到達方向を有する、ビーハイブ（beehive、BH）フォーマットを示してもよい。複数のリングは、中央リング、上リング、下リング、および／または天頂を含んでいてもよい。代替的または追加的に、SR信号は、ISFと呼ばれる中間的な空間フォーマット、特に、ドルビー・アトモス技術内で定義されるISFフォーマットを示してもよい。
【００７４】
よって、IA信号111は、複数の異なるチャネルを含んでいてもよい。IA信号111内に含まれる各チャネルは、典型的には、時点のシーケンスについての、またはフレームのシーケンスについての、オーディオ・サンプルのシーケンスを含む。換言すれば、本稿に記載される「信号」は、典型的には、対応する時点またはフレーム（たとえば、20ms以下の時間的距離）のシーケンスについてのオーディオ・サンプルのシーケンスを含む。
【００７５】
方法500は、IA信号111から一つまたは複数のオーディオ・オブジェクトを抽出することを含んでいてもよい。オーディオ・オブジェクトは、典型的には、オブジェクト信号（対応する時点またはフレームのシーケンスについてのオーディオ・サンプルのシーケンスをもつ）を含む。さらに、オーディオ・オブジェクトは、典型的には、オーディオ・オブジェクトの位置を示すオブジェクト・メタデータ202を含む。オーディオ・オブジェクトの位置は、時間とともに変化してもよく、そのため、オーディオ・オブジェクトのオブジェクト・メタデータ202が、時点またはフレームのシーケンスについての位置のシーケンスを示してもよい。
【００７６】
さらに、方法500は、前記IA信号111に基づき、かつ、前記一つまたは複数のオーディオ・オブジェクトに基づいて、残留信号を決定することを含んでいてもよい。残留信号は、前記一つまたは複数のオーディオ・オブジェクト103、303が抽出および／または除去されたもとのIA信号を記述してもよい。残留信号は、IA信号111内に含まれるSR信号であってもよい。代替的または追加的に、残留信号は、マルチチャネル・オーディオ信号および／またはオーディオ信号のベッドを含んでいてもよく、またはそれらであってもよい。代替的または追加的に、残留信号は、固定したオブジェクト・ロケーションおよび／または位置にある複数のオーディオ・オブジェクト（たとえば、定義されたスピーカー配置の特定のスピーカーに割り当てられたオーディオ・オブジェクト）を含んでいてもよい。
【００７７】
さらに、方法500は、IA信号111に基づいて（たとえば、ダウンミックス・モジュール210を使用して）ダウンミックス信号を生成および／または提供することを含んでいてもよい。ダウンミックス信号のチャネル数は、典型的には、IA信号111のチャネル数よりも小さい。さらに、方法500は、ダウンミックス信号（すなわち、一つまたは複数のダウンミックス・チャネル信号203）を、対応する一つまたは複数のオーディオ・オブジェクトのための一つまたは複数の再構成されたオーディオ・オブジェクトのための信号にアップミックスすることを可能にする合同符号化またはSPARメタデータ205を決定することを含んでいてもよい。さらに、合同符号化またはSPARメタデータ205は、ダウンミックス信号を、対応する残留信号のための再構成された残留信号にアップミックスすることを可能にしうる。
【００７８】
一つまたは複数のダウンミックス・チャネル信号203と、SPARメタデータ205と、オブジェクト・メタデータ202とを含むダウンミックス信号は、ビットストリーム101に挿入されてもよい。特に、方法500は、ダウンミックス信号の波形符号化を実行して、一つまたは複数のダウンミックス・チャネル信号203のフレームのシーケンスについての符号化されたオーディオ・データ206を提供することを含んでいてもよい。波形符号化は、たとえば向上音声サービス（Enhanced  Voice  Services、EVS）符号化を使って実行されてもよい。さらに、方法500は、SPARメタデータ205および／または一つまたは複数のオーディオ・オブジェクトのオブジェクト・メタデータ202のエントロピー符号化を実行して、ビットストリーム101に挿入されるべき（符号化された）メタデータ207を提供することを含んでいてもよい。
【００７９】
方法500は、スーパーフレーム400のシーケンスについて繰り返して、没入的オーディオ信号111から導出された一つまたは複数のダウンミックス・チャネル信号203の一つまたは複数の（特に複数の）フレーム（たとえば、2つ以上のフレーム）についての符号化されたオーディオ・データ206を、スーパーフレーム400のデータ・フィールド411、421、412、422に挿入すること（501）を含んでいてもよい。ダウンミックス・チャネル信号203の（基本）フレームは、ダウンミックス・チャネル信号203の20msにまたがることができる。スーパーフレーム400は、（基本）フレームの長さの倍数、たとえば、40msにまたがることができる。
【００８０】
さらに、方法500は、符号化されたオーディオ・データ206からの没入的オーディオ信号111の一つまたは複数の（特に複数の）フレームを再構成するためのメタデータ202、205（特に符号化されたメタデータ207）を、スーパーフレーム400の（単一の）メタデータ・フィールド403に挿入すること（502）を含んでいてもよい。よって、スーパーフレーム400は、一つまたは複数のダウンミックス・チャネル信号203の一つまたは複数の（特に複数の）フレームについてのメタデータ202、205を提供することができ、それにより、IA信号111の効率的な伝送を可能にする。
【００８１】
特に、ダウンミックス・チャネル信号203のフレームは、マルチモードおよび／またはマルチレート発話またはオーディオ・コーデックを使用して生成されてもよい。さらに、メタデータ202、205は、マルチモードおよび／またはマルチレートの没入的メタデータ符号化方式を使用して生成されてもよい。マルチモードおよび／またはマルチレート発話またはオーディオ・コーデック（ダウンミックス・チャネル信号203のために使用されたもの）の動作および／またはマルチモードおよび／またはマルチレートの没入的メタデータ符号化方式の動作を示す構成情報は、（現在の）スーパーフレーム400の構成情報フィールド402に含まれてもよく、スーパーフレーム400のシーケンスのうち、前のスーパーフレーム400の構成情報フィールド402に含まれてもよく、またはアウトオブバンド信号伝達方式を使用して伝えられてもよい。この結果として、没入的オーディオ信号111をエンコードするための効率的かつ柔軟な方式が提供されてもよい。
【００８２】
スーパーフレーム400は、複数のダウンミックス・チャネル信号203に関連する符号化されたオーディオ・データ206を含んでいてもよい。第1のダウンミックス・チャネル信号203のフレームの符号化されたオーディオ・データ206は、マルチモードおよび／またはマルチレート発話またはオーディオ・コーデックの第1のインスタンスを使用して生成されてもよい。さらに、第2のダウンミックス・チャネル信号203のフレームの符号化されたオーディオ・データ206は、マルチモードおよび／またはマルチレート発話またはオーディオ・コーデックの第2のインスタンスを使用して生成されてもよく、マルチモードおよび／またはマルチレート発話またはオーディオ・コーデックの第1および第2のインスタンスは異なっていてもよい。構成情報（現在のスーパーフレーム400内、前のスーパーフレーム400内に含まれる、またはアウトオブバンドで伝えられる）は、マルチモードおよび／またはマルチレート発話またはオーディオ・コーデックの第1および第2のインスタンス（特に、各インスタンス）の動作を示してもよい。こうすることにより、没入的オーディオ信号111をエンコードするための柔軟性および効率がさらに向上されうる。
【００８３】
換言すれば、方法500は、没入的オーディオ信号111から導出された第1のダウンミックス・チャネル信号203および第2のダウンミックス・チャネル信号203の一つまたは複数のフレームについて、符号化されたオーディオ・データ206を、それぞれスーパーフレーム400の一つまたは複数の第1データ・フィールド411、421および一つまたは複数の第2データ・フィールド412、422に挿入することを含んでいてもよい。第1のダウンミックス・チャネル信号203は、第1の（オーディオまたは発話）エンコーダを使用してエンコードされてもよく、第2のダウンミックス・チャネル信号は、第2の（オーディオまたは発話）エンコーダを使用してエンコードされてもよい。第1および第2のエンコーダは異なっていてもよく、または異なる構成を使用して動作させられてもよい。さらに、方法500は、第1のエンコーダおよび第2のエンコーダに関する構成情報を、スーパーフレーム400内で、スーパーフレーム400のシーケンスのうち、前のスーパーフレーム400内で、またはアウトオブバンド信号伝達方式を使って、提供することを含んでいてもよい。こうすることにより、没入的オーディオ信号111をエンコードするための柔軟性および効率がさらに向上されうる。
【００８４】
方法500は、スーパーフレーム400にヘッダ・フィールド401を挿入することを含んでいてもよい。ヘッダ・フィールド401は、スーパーフレーム400のメタデータ・フィールド403のサイズを示してもよく、それにより、スーパーフレーム400のサイズが、（エントロピー符号化および／または無損失符号化された）メタデータ207のさまざまな長さに柔軟に適合させられることができる。
【００８５】
メタデータ・フィールド403は、可能な最大サイズ（これはたとえば、スーパーフレーム400の任意的な構成情報フィールド402内に示されてもよい）を示してもよい。ヘッダ・フィールド401は、調整値を示してもよく、スーパーフレーム400のメタデータ・フィールド403のサイズは、最大可能サイズから調整値を引いたものに対応してもよく、それにより、メタデータ・フィールド403のサイズが、正確かつ効率的な仕方で信号伝達されることを可能にする。ヘッダ・フィールド401は、メタデータ・フィールド403のサイズについてのサイズ・インジケータ（たとえば前記調整値）を含んでいてもよい。サイズ・インジケータは、メタデータ・フィールド403のサイズの異なるサイズ範囲について、（サイズ間隔に関して）異なる分解能またはステップ・サイズを示してもよい。サイズ・インジケータの分解能および／またはステップ・サイズは、（エントロピー符号化された）メタデータの統計的なサイズ分布に依存しうる。可変分解能をもつサイズ・インジケータを提供することによって、メタデータ・フィールド403のサイズを信号伝達するためのビットレート効率が改善されうる。
【００８６】
ヘッダ・フィールド401は、スーパーフレーム400が構成情報フィールド402を含むか否かを示してもよい。換言すれば、ヘッダ・フィールド401は、構成情報フィールド402の存在を示してもよい。構成情報フィールド402は、必要な場合（たとえば、IA信号111のエンコーダの構成が変更された場合）にのみ、スーパーフレーム400に挿入されてもよい。この結果として、スーパーフレーム400のシーケンスのビットレート効率が改善されうる。
【００８７】
ヘッダ・フィールド401は、構成情報フィールド402が現在のスーパーフレーム400内に存在しないことを示してもよい。方法500は、スーパーフレーム400のシーケンスのうち、前のスーパーフレーム400内で、またはアウトオブバンド信号伝達方式を使って、構成情報を伝達することを含んでいてもよい。この結果として、（少なくとも一時的に静的である）構成情報は、効率的な仕方で伝送されうる。
【００８８】
代替的または追加的に、ヘッダ・フィールド401は、スーパーフレーム400が、没入的オーディオ信号111に関する追加的な情報のための拡張フィールド404を含むか否かを示してもよい。この結果として、スーパーフレーム構造は、将来の拡張に柔軟な仕方で適応させられうる。
【００８９】
方法500は、（必要な場合）構成情報フィールド402をスーパーフレーム400に挿入することを含んでいてもよい。構成情報フィールド402は、スーパーフレーム400のデータ・フィールド411、421、412、422内に含まれるダウンミックス・チャネル信号203の数を示してもよい。代替的または追加的に、構成情報フィールド402は、IA信号111内に含まれる音場表現信号の次数を示してもよい。この結果として、さまざまな異なるタイプのIA信号111（さまざまな異なるタイプのSR信号を有する）がエンコードされ、送信されうる。
【００９０】
構成情報フィールド402は、メタデータ・フィールド403の可能な最大サイズを示してもよい。代替的または追加的に、構成情報フィールド402は、一つまたは複数のダウンミックス・チャネル信号203のそれぞれを符号化するために使用されたフレーム・タイプおよび／または符号化モードを示してもよい。この情報の提供は、IA信号111をエンコードするための異なる符号化方式の使用を可能にする。
【００９１】
ダウンミックス・チャネル信号203のフレームの符号化されたオーディオ・データ206は、マルチモードおよび／またはマルチレート発話またはオーディオ・コーデックを用いて生成されてもよい。代替的または追加的に、（符号化された）メタデータ207は、マルチモードおよび／またはマルチレートの没入的メタデータ符号化方式を使用して生成されてもよい。この結果として、IA信号111は、比較的高い品質で、比較的低いデータレートでエンコードされうる。
【００９２】
スーパーフレーム400のシーケンスのスーパーフレーム400は、伝送プロトコル、特にDASH、RTSPまたはRTPを用いて伝送されるか、または記憶フォーマット、特にISOBMFFに従ってファイルに格納されるデータ要素の少なくとも一部を構成しうる。換言すれば、スーパーフレーム400のシーケンスを含むビットストリーム101は、伝送プロトコルまたは記憶フォーマットの一つまたは複数のデータ要素を使用してもよい。それにより、ビットストリーム101は、効率的で信頼性のある仕方で伝送または記憶されることが可能になる。
【００９３】
図6は、ビットストリーム101から没入的オーディオ信号111に関するデータを導出するための例示的な方法600のフローチャートを示す。ビットストリーム101は、没入的オーディオ信号111のフレームのシーケンスについてのスーパーフレーム400のシーケンスを含む。ある好ましい例では、IA信号111の複数の（基本）フレームは、単一のスーパーフレーム400内に含まれる。ビットストリーム101を生成するための方法500のコンテキストで記述されたすべての特徴は、ビットストリーム101からデータを導出するための方法600について、類似の仕方で適用可能であることを注意しておくべきである。
【００９４】
IA信号111は、SR信号、マルチチャネル信号および／または一つまたは複数のオーディオ・オブジェクトを含んでいてもよい。方法500の文脈において、および／またはエンコード装置110の文脈において記述された側面および／または特徴は、方法600および／またはデコード装置120についても、類似した、および／または相補的な仕方で適用可能である（逆も成り立つ）。
【００９５】
方法600は、スーパーフレーム400のシーケンスについて繰り返し、スーパーフレーム400のデータ・フィールド411、421、412、422から没入的オーディオ信号111から導出された一つまたは複数のダウンミックス・チャネル信号203の一つまたは複数の（特に複数の）フレームについての符号化されたオーディオ・データ206を抽出すること（601）を含んでいてもよい。さらに、方法600は、スーパーフレーム400のメタデータ・フィールド403から、符号化されたオーディオ・データ206から没入的オーディオ信号111の一つまたは複数の（特に複数の）のフレームを再構成するための（符号化された）メタデータ207を抽出すること（602）を含む。
【００９６】
方法600は、符号化されたオーディオ・データ206およびメタデータ207（特に、オブジェクト・メタデータ202）から、一つまたは複数の再構成されたオーディオ・オブジェクトを導出することを含んでいてもよい。上述のように、オーディオ・オブジェクトは、典型的には、オブジェクト信号と、オーディオ・オブジェクトの（時間変化する）位置を示すオブジェクト・メタデータ202を含む。さらに、方法600は、符号化されたオーディオ・データ206およびメタデータ202、205から、再構成された残留信号を導出することを含んでいてもよい。前記一つまたは複数の再構成されたオーディオ・オブジェクトおよび再構成された残留信号は、IA信号111を記述してもよく、および／またはそれを示してもよい。特に、データ（たとえば、IA信号111内に含まれるSR信号のオーダー（order））が、ビットストリーム101から抽出されてもよく、これは、再構成されたIA信号121の決定を可能にし、ここで、再構成されたIA信号121は、もとのIA信号111の近似である。
【００９７】
上述のように、ビットストリーム101から没入的オーディオ信号111に関するデータを導出するための方法600は、ビットストリーム101を生成するための方法500に対する対応する特徴を含んでいてもよい。特に、方法600は、与えられたスーパーフレーム400からヘッダ・フィールド401を抽出することを含んでいてもよい。与えられたスーパーフレーム400のメタデータ・フィールド403のサイズは、ヘッダ・フィールド401から導出されてもよい。
【００９８】
メタデータ・フィールド403のサイズは、方法500のコンテキストで概説されたように示されてもよい。メタデータ・フィールド403は、可能な最大サイズを示してもよく、ヘッダ・フィールド401は、調整値を示してもよく、スーパーフレーム400のメタデータ・フィールド403のサイズは、可能な最大サイズから調整値を引いたものに対応してもよい。特に、ヘッダ・フィールド401は、メタデータ・フィールド403のサイズについてのサイズ・インジケータを含んでいてもよく、サイズ・インジケータは、メタデータ・フィールド403のサイズの異なるサイズ範囲について異なる分解能を示してもよい。この結果として、メタデータ・フィールド403のサイズは、ビットレート効率のよい仕方で信号伝達されうる。
【００９９】
方法600は、ヘッダ・フィールド401に基づいて、スーパーフレーム400が構成情報フィールド402を含むか否か、および／または構成情報フィールド402がスーパーフレーム400内に存在するか否かを判定することを含んでいてもよい。構成情報フィールド402が存在しない場合、以前のスーパーフレーム400内で提供された、および／またはアウトオブバンドで提供された構成情報が、スーパーフレーム400内に含まれる一つまたは複数のダウンミックス・チャネル信号203の一つまたは複数のフレームを処理するために使用されてもよい。構成情報フィールド402が存在する場合、スーパーフレーム400内に含まれる構成情報は、スーパーフレーム400内に含まれる一つまたは複数のダウンミックス・チャネル信号203の一つまたは複数のフレームを処理するために使用されてもよい。
【０１００】
さらに、方法600は、ヘッダ・フィールド401に基づいて、スーパーフレーム400が、没入的オーディオ信号111に関する追加的な情報のための拡張フィールド404を含むか否かを判定することを含んでいてもよく、それにより、ビットストリーム101内で情報を伝送するための効率的で柔軟な手段を提供する。
【０１０１】
方法600は、スーパーフレーム400から構成情報フィールド402を抽出することを含んでいてもよい。さらに、方法600は、構成情報フィールド402に基づいて、スーパーフレーム400のデータ・フィールド411、421、412、422によって表わされるダウンミックス・チャネル信号203の数を決定することを含んでいてもよく、それにより、スーパーフレーム400内に含まれる一つまたは複数のダウンミックス・チャネル信号203の一つまたは複数のフレームの正確な処理を可能にする。
【０１０２】
さらに、方法600は、構成情報フィールド402に基づいて、メタデータ・フィールド403の可能な最大サイズを決定することを含んでいてもよい。
【０１０３】
さらに、方法600は、構成情報フィールド402に基づいて、IA信号111の正確な再構成を可能にするために、没入的オーディオ信号111のオーダーを決定することを含んでいてもよい。
【０１０４】
方法600はまた、構成情報フィールド402に基づいて、一つまたは複数のダウンミックス・チャネル信号のそれぞれを符号化するために使用されるフレーム・タイプおよび／または符号化モードを決定することを含んでいてもよく、それにより、スーパーフレーム400内に含まれる一つまたは複数のダウンミックス・チャネル信号203の一つまたは複数のフレームの正確な処理を可能にする。
【０１０５】
本発明のさまざまな例示的な実施形態は、ハードウェアまたは特殊目的回路、ソフトウェア、論理、またはそれらの任意の組み合わせで実装されうる。いくつかの側面はハードウェアで実装されてもよく、他の側面はコントローラ、マイクロプロセッサ、または他のコンピューティング装置によって実行されうるファームウェアまたはソフトウェアで実装されてもよい。一般に、本開示は、上述の方法を実行するのに好適な装置、たとえば、メモリおよび該メモリに結合されたプロセッサを有する装置（空間レンダラー）であって、プロセッサは、命令を実行し、本開示の実施形態に従って方法を実行するように構成される、装置を包含することが理解される。
【０１０６】
本発明の例示的な実施形態のさまざまな側面が、ブロック図、フローチャートとして、または他のいくつかの絵的な表現を用いて図示され記述されているが、本明細書に記載されるブロック、装置、システム、技法、または方法は、限定しない例として、ハードウェア、ソフトウェア、ファームウェア、特殊目的回路もしくは論理、汎用ハードウェアもしくはコントローラ、または他のコンピューティング装置、またはそれらのいくつかの組み合わせにおいて実装されてもよいことが理解されるであろう。
【０１０７】
さらに、フローチャートに示されたさまざまなブロックは、方法ステップとして、および／またはコンピュータ・プログラム・コードの動作から帰結する動作として、および／または関連する機能を実行するように構築された複数の結合された論理回路素子として見なすことができる。たとえば、本発明の実施形態は、機械可読媒体上に有体に具現されたコンピュータ・プログラムを含むコンピュータ・プログラム製品を含み、このコンピュータ・プログラムは、上述の方法を実行するように構成されたプログラム・コードを含む。
【０１０８】
本開示の文脈において、機械可読媒体は、命令実行システム、装置、またはデバイスによって、またはそれと関連して使用するためのプログラムを含む、または記憶することができる任意の有体な媒体でありうる。機械可読媒体は、機械可読信号媒体または機械可読記憶媒体でありうる。機械可読媒体は、電子、磁気、光学、電磁、赤外線、もしくは半導体システム、装置、もしくはデバイス、または上記の任意の好適な組み合わせを含み得るが、それらに限定されない。機械可読記憶媒体の、より具体的な例は、一つまたは複数のワイヤ、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（RAM）、読み出し専用メモリ（ROM）、消去可能なプログラマブル読み出し専用メモリ（EPROMまたはフラッシュメモリ）、光ファイバー、ポータブルなコンパクトディスク読み出し専用メモリ（CD-ROM）、光記憶デバイス、磁気記憶デバイス、または上記の任意の好適な組み合わせを有する電気接続を含む。
【０１０９】
本発明の方法を実行するためのコンピュータ・プログラム・コードは、一つまたは複数のプログラミング言語の任意の組み合わせで書かれてもよい。これらのコンピュータ・プログラム・コードは、汎用コンピュータ、専用コンピュータ、または他のプログラマブル・データ処理装置のプロセッサに提供されてもよく、プログラム・コードは、コンピュータのプロセッサまたは他のプログラマブル・データ処理装置によって実行されると、フローチャートおよび／またはブロック図において指定された機能／動作を実施させる。プログラム・コードは、コンピュータ上で、部分的にコンピュータ上で、スタンドアローンのソフトウェア・パッケージとして、部分的にはコンピュータ上、部分的には遠隔コンピュータ上で、または全部が遠隔コンピュータまたはサーバー上で実行されてもよい。
【０１１０】
さらに、動作が特定の順序で描かれているが、これは、そのような動作が、図示された特定の順序でまたは逐次順に実行されること、または、望ましい結果を達成するために、図示されたすべての動作が実行されることを要求するものとして理解されるべきではない。ある種の状況では、マルチタスクおよび並列処理が有利でありうる。同様に、いくつかの具体的な実装詳細が上記の議論に含まれているが、これらは、いずれかの発明、または特許請求されうるものの範囲に対する限定として解釈されるべきではなく、むしろ、具体的な発明の具体的な実施形態に固有でありうる特徴の説明として解釈されるべきである。本明細書において別々の実施形態の文脈において記載されるある種の特徴が、単一の実施形態において組み合わせて実施されてもよい。逆に、単一の実施形態の文脈において記述されるさまざまな特徴が、複数の実施形態において別々に、または任意の好適なサブコンビネーションにおいて実装されてもよい。
【０１１１】
明細書および図面は、提案される方法および装置の原理を説明するに過ぎないことを注意しておくべきである。よって、当業者は、本明細書に明示的に記載または図示されていないが、本発明の原理を具現し、その精神および範囲内に含まれるさまざまな構成を考案することができることが理解されるであろう。さらに、本明細書に記載されたすべての例は、主として、提案される方法および装置の原理、ならびに当該技術を促進するために発明者によって寄与された概念を理解する際に読者を助けるという教育目的のみをはっきりと目的とするものであり、そのように具体的に記載された例および条件に限定することなく、解釈される。さらに、本発明の原理、側面、および実施形態、ならびにそれらの特定の例を記載する本明細書のすべての陳述は、それらの均等物を包含することが意図されている。
【図１】
2021530723.tif 000015
【図２】
2021530723.tif 000016
【図３】
2021530723.tif 000017
【図４】
2021530723.tif 000018
【図５】
2021530723.tif 000019
【図６】
2021530723.tif 000020
【国際調査報告】
2021530723.tif 000021
2021530723.tif 000022
2021530723.tif 000023