JP6710675B2 - オーディオ処理システムおよび方法 - Google Patents

Description

関連出願への相互参照
本願は2014年7月31日に出願された米国仮特許出願第62/031,723号の優先権を主張するものである。同出願の内容はここに参照によってその全体において組み込まれる。

発明の分野
一つまたは複数の実装は概括的にはオーディオ信号処理に、より詳細には、適応オーディオ処理システムにおいて使うためのチャネル・ベースとオブジェクト・ベースのオーディオの間でなめらかに切り換えるための方法および関連するオブジェクト・オーディオ・レンダラー・インターフェースに関する。

デジタル映画館の導入および真の三次元（「3D」）または仮想3Dコンテンツの発達は、サウンドについての新たなスタンダードを作り出した。たとえば、コンテンツ・クリエーターにとってのより大きな創造性を許容する複数チャネル・オーディオの組み込みや、聴衆にとってより包み込むような、リアルな聴覚経験などである。空間的オーディオを配送する手段として伝統的なスピーカー・フィードおよびチャネル・ベースのオーディオを超えて拡張することは枢要であり、聴取者が選んだ構成のために特にレンダリングされたオーディオを用いることで聴取者が所望される再生構成を選択することを許容するモデル・ベースのオーディオ記述には多大な関心が寄せられてきた。音の空間的呈示はオーディオ・オブジェクトを利用する。オーディオ・オブジェクトは、見かけの源位置（たとえば3D座標）、見かけの源幅および他のパラメータの、関連付けられたパラメトリックな源記述をもつオーディオ信号である。さらなる進歩として、オーディオ・オブジェクトと伝統的なチャネル・ベースのスピーカー・フィードとの混合をオーディオ・オブジェクトのための位置メタデータとともに含む次世代空間的オーディオ（「適応オーディオ」とも称される）フォーマットが開発されている。空間的オーディオ・デコーダでは、チャネルは関連付けられたスピーカーに直接送られるか、あるいは既存のスピーカー集合にダウンミックス〔下方混合〕され、オーディオ・オブジェクトはデコーダによって、柔軟な（適応的な）仕方でレンダリングされる。各オブジェクトに関連付けられたパラメトリックな源記述、たとえば3D空間における位置軌跡は、デコーダに接続されたスピーカーの数および位置とともに入力として取られる。次いで、レンダラーはパン則のようなある種のアルゴリズムを使って、取り付けられたスピーカーの集合にまたがって各オブジェクトに関連付けられたオーディオ（「オブジェクト・ベースのオーディオ」）を配送する。このようにして、各オブジェクトのオーサリングされた空間的意図が、聴取室に存在する特定のスピーカー構成を通じて、最適に呈示される。

伝統的なチャネル・ベースのオーディオ・システムでは、オーディオ後処理はビットストリーム内容の変化に起因して時間的に変化することはない。システムを通じて搬送されるオーディオは常に静的なチャネル識別子（たとえば左、右、中央など）を使って識別されるので、個々のオーディオ後処理技術は常にアクティブなままであることがある。しかしながら、オブジェクト・ベースのオーディオ・システムは、オブジェクト・ベースのオーディオをチャネル・ベースのスピーカー・レイアウトにレンダリングするために特化したメタデータを使う新たなオーディオ後処理機構を使う。実際上、オブジェクト・ベースのオーディオ・システムは、部分的にはレガシー・オーディオ・コンテンツをサポートするために、チャネル・ベースのオーディオをもサポートし、扱う必要がある。チャネル・ベースのオーディオは、オーディオ・レンダリングを可能にする上記の特化したメタデータを欠いているので、ある種のオーディオ後処理技術は、符号化されたオーディオ源がオブジェクト・ベースのまたはチャネル・ベースのオーディオを含むときに異なることがありうる。たとえば、はいってくるチャネル・ベースのオーディオに存在しないスピーカーのためのコンテンツを生成するためにアップミキサー〔上方混合器〕が使われることがあり、そのようなアップミキサーはオブジェクト・ベースのオーディオには適用されないであろう。

たいていの現在のシステムでは、オーディオ・プログラムは一般に、オブジェクト・ベースかチャネル・ベースのどちらか一つの型のオーディオのみを含む。よって、処理チェーン（レンダリングまたはアップミックス）は初期化時に選ぶことができる。しかしながら、新たなオーディオ・フォーマットの到来により、プログラム中のオーディオ型（チャネルまたはオブジェクト）は、伝送媒体、創造上の選択、ユーザー対話または他の同様の要因のため、時間とともに変わることがある。ハイブリッド・オーディオ・システムでは、コーデックを変えることなく、オーディオがオブジェクト・ベースとチャネル・ベースのオーディオの間で切り換わることが可能である。この場合、システムは、最適には、ミュートやオーディオ遅延を示さず、むしろレンダリングされたオブジェクト出力とアップミックスされたチャネル出力との間で切り換えることによってそのスピーカー出力全部に連続的なオーディオ・ストリームを提供する。現在のオーディオ・システムにおける一つの問題は、ビットストリームにおけるそのような変化に際してミュートまたはグリッチを生じうるからである。

オブジェクトおよびチャネルの両方をもつ適応オーディオ・コンテンツについて、ドルビー（登録商標）アトモス（登録商標）技術または他の適応オーディオ規格を利用しうるもののような現代のオーディオ／ビデオ受領器（AVR: Audio/Video Receiver）システムは、一般に、一つまたは複数のデジタル信号プロセッサ（DSP）チップと、単一のチップの一つまたは複数のマイクロコントローラ・チップもしくはコア（たとえばSoC（System on Chip［システム・オン・チップ］）からなる。マイクロコントローラは、DSP上での処理を管理し、ユーザーと対話することを受け持ち、一方、DSPはオーディオ処理を実行するよう特に最適化される。オブジェクト・ベースとチャネル・ベースのオーディオの間で切り換えるとき、DSPがその変化をマイクロコントローラに信号伝達することが可能であることがある。するとマイクロコントローラは論理を使って新たなオーディオ型を扱うようDSPを構成し直す。この型の信号伝達はDSPとマイクロコントローラの間で起こるので「帯域外〔アウトオブバンド〕」信号伝達と称される。そのような帯域外信号伝達は、処理オーバーヘッド、伝送レイテンシー、データ切り換えオーバーヘッドといった要因のために必然的にある程度の時間がかかり、DSPがオーディオ・データを誤って処理する場合、これはしばしばオーディオの不必要なミュートまたは可能なグリッチにつながる。

したがって、必要とされているのは、オブジェクト・ベースとチャネル・ベースのコンテンツの間で切り換えるための、ギャップ、ミュートあるいはグリッチなしに連続的またはなめらかなオーディオ・ストリームを提供する手法である。さらに必要とされているのは、オーディオ処理DSPが、他のプロセッサやマイクロプロセッサと外部通信する必要なしに、はいってくるオーディオのために正しい処理チェーンを選択することを許容する機構である。

オブジェクト・オーディオ・レンダラーを有するオブジェクト・オーディオ・レンダリング・システムに関し、オブジェクト・ベースのオーディオはデジタル・オーディオ・データの諸部分（たとえばPCMオーディオのサンプル）を、関連するサンプルがどのようにレンダリングされるべきかを定義するメタデータとともに、含む。したがって、オーディオ・データの対応するサンプルと一緒のメタデータ更新の適正なタイミングが、オーディオ・オブジェクトの正確なレンダリングのために重要である。多くのオブジェクトをもつおよび／またはサウンド空間のあたりを高速で動きうるオブジェクトをもつダイナミックなオーディオ・プログラムでは、メタデータ更新は、オーディオ・フレーム・レートに対して非常に高速で生起しうる。現在のオブジェクト・ベースのオーディオ処理システムは一般に、定期的に起こるメタデータ更新を、デコーダおよびレンダリング・プロセッサの処理機能の範囲内のレートで、扱うことができる。そのようなシステムはしばしば、設定されたサイズであるオーディオ・フレームおよび一様に周期的な（uniformly periodic）レートで適用されるメタデータ更新に依拠する。しかしながら、更新がより高速でまたは非一様に周期的な（non-uniformly periodic）仕方で起こると、更新の処理はずっと困難になる。しばしば、更新は、それが適用されるオーディオ・サンプルと適正に整列されていないことがありうる。更新の生起が速すぎるためまたはメタデータ更新と対応するオーディオ・サンプルとの間の同期ずれ〔スリップ〕のためである。この場合、オーディオ・サンプルは適正でないメタデータ定義に従ってレンダリングされることがありうる。

さらに必要とされているのは、可能な最も効率的な仕方で適応オーディオ・システムのためのメタデータを適正にバッファリングし、シリアル化解除〔デシリアライズ〕するよう、コーデック・デコードされた出力を適応する機構である。さらに必要とされているのは、オブジェクト・オーディオが最小量の処理パワーおよび高い精度をもってレンダリングされることを保証するよう構成されており、かつ、チップ・アーキテクチャーに依存して、顧客のニーズに合わせて調整可能でもあるオブジェクト・オーディオ・レンダラー・インターフェースである。

背景セクションで論じられている主題は、単に背景セクションで言及されていることの結果として従来技術であると想定されるべきではない。同様に、背景セクションにおいて言及されているまたは背景セクションの主題に関連する問題は、従来技術において以前から認識されていたと見なされるべきではない。背景セクションにおける主題は単に、種々のアプローチを表わすものであり、それらのアプローチ自身も発明であることがありうる。ドルビー、ドルビー・デジタル・プラス、ドルビー・トゥルーHDおよびアトモスはドルビー・ラボラトリーズ・ライセンシング・コーポレイションの登録商標である。

実施形態は、適応オーディオ・コンテンツを処理する方法に向けられる。該処理は、適応オーディオ・ビットストリームの各オーディオ・セグメントについてチャネル・ベースまたはオブジェクト・ベースのどちらかとしてオーディオ型を判別し、対応するオーディオ・セグメントのオーディオ型を示すメタデータ定義をもって各オーディオ・セグメントにタグ付けし、チャネル・ベースのオーディオとしてタグ付けされたオーディオ・セグメントをチャネル・オーディオ・レンダラー・コンポーネントにおいて処理し、オブジェクト・ベースのオーディオとしてタグ付けされたオーディオ・セグメントを前記チャネル・オーディオ・レンダラー・コンポーネントとは異なるオブジェクト・オーディオ・レンダラー・コンポーネントにおいて処理することによる。本方法はさらに、前記メタデータ定義を、各オーディオ・セグメントに関連付けられたメタデータ・ペイロードの一部としてエンコードされたオーディオ型メタデータ要素としてエンコードすることを含む。前記メタデータ定義は、デコーダによって設定され、前記チャネル・オーディオ・レンダラー・コンポーネントおよびオブジェクト・オーディオ・レンダラー・コンポーネントに伝送される二値のフラグ値を含んでいてもよい。この実施形態について、二値のフラグ値は、前記チャネル・オーディオ・レンダラー・コンポーネントおよびオブジェクト・オーディオ・レンダラー・コンポーネントによって、受領された各オーディオ・セグメントについてデコードされ、該オーディオ・セグメント内のオーディオ・データは、デコードされた二値のフラグ値に基づいて、前記チャネル・オーディオ・レンダラー・コンポーネントおよびオブジェクト・オーディオ・レンダラー・コンポーネントの一方によってレンダリングされる。チャネル・ベースのオーディオは、ステレオまたはレガシーのサラウンドサウンドのオーディオを含んでいてもよく、前記チャネル・オーディオ・レンダラー・コンポーネントはアップミキサーまたは単なる素通しノードを含んでいてもよい。前記オブジェクト・オーディオ・レンダラー・コンポーネントはオブジェクト・オーディオ・レンダラー・インターフェースを有していてもよい。本方法はさらに、任意の二つの相続くオーディオ・セグメントの間の伝送および処理レイテンシーについて、初期化フェーズの間に既知のレイテンシー差について事前補償することによって調整することを含んでいてもよい。

実施形態はさらに、適応オーディオをレンダリングする方法に向けられる。これは、ビットストリームにおいてエンコードされたチャネル・ベースのオーディオおよびオブジェクト・ベースのオーディオ・セグメントを含む入力オーディオをデコーダにおいて受領し、該デコーダにおいてチャネル・ベースのオーディオとオブジェクト・ベースのオーディオ・セグメントとの間の型の変化を検出し、型の変化の検出に際してオーディオ・セグメントの各型について、メタデータ定義を生成し、該メタデータ定義を適切なオーディオ・セグメントと関連付け、各オーディオ・セグメントを、関連付けられたメタデータ定義に依存して、適切なポストデコーダ処理コンポーネントにおいて処理することによる。チャネル・ベースのオーディオは、適応オーディオ・レンダリング・システムのアップミキサーを通じてレンダリングされるべきレガシーのサラウンドサウンド・オーディオを含んでいてもよく、オブジェクト・ベースのオーディオはシステムのオブジェクト・オーディオ・レンダラー・インターフェースを通じてレンダリングされてもよい。ある実施形態では、本方法はさらに、任意の二つの相続くオーディオ・セグメントの間の処理レイテンシーについて、初期化フェーズの間に既知のレイテンシー差について事前補償することによって調整することを含む。本方法についてのメタデータ定義は、デコーダによって、オーディオ・ビットストリームに関連付けられたメタデータ・ペイロードの一部としてエンコードされるオーディオ型フラグを含んでいてもよい。この実施形態について、フラグの第一の状態は関連付けられたオーディオ・セグメントがチャネル・ベースのオーディオであることを示し、フラグの第二の状態は関連付けられたオーディオ・セグメントがオブジェクト・ベースのオーディオであることを示す。

実施形態はさらに、適応オーディオ・レンダリング・システムに向けられる。本システムは、オーディオ・コンテンツおよび関連するメタデータを有する入力オーディオ・ビットストリームを受領するデコーダであって、前記オーディオ・コンテンツは、任意の一つの時点においては、チャネル・ベースのオーディオまたはオブジェクト・ベースの型のオーディオのうちの一方を有するオーディオ型をもつ、デコーダと、前記チャネル・ベースのオーディオを処理するための前記デコーダに結合されたアップミキサーと、オブジェクト・オーディオ・レンダラーを通じて前記オブジェクト・ベースのオーディオをレンダリングするための、前記アップミキサーと並列に前記デコーダに結合されたオブジェクト・オーディオ・レンダラー・インターフェースと、チャネル・ベースのオーディオを第一のメタデータ定義でタグ付けし、オブジェクト・ベースのオーディオを第二のメタデータ定義でタグ付けするよう構成された、前記デコーダ内のメタデータ要素生成器とを有する。このシステムにおいて、前記アップミキサーはタグ付けされたチャネル・ベースのオーディオおよびタグ付けされたオブジェクト・ベースのオーディオの両方を前記デコーダから受領し、前記チャネル・ベースのオーディオのみを処理する；前記オブジェクト・オーディオ・レンダラー・インターフェースはタグ付けされたチャネル・ベースのオーディオおよびタグ付けされたオブジェクト・ベースのオーディオの両方を前記デコーダから受領し、前記オブジェクト・ベースのオーディオのみを処理する。メタデータ要素生成器は、前記デコーダから前記アップミキサーおよび前記オブジェクト・オーディオ・レンダラー・インターフェースに伝送されるオーディオ・セグメントの型を示す二値フラグを設定するよう構成されていてもよい。ここで、二値フラグは、前記デコーダによって、前記ビットストリームに関連付けられたメタデータ・ペイロードの一部としてエンコードされる。前記チャネル・ベースのオーディオはサラウンドサウンド・オーディオ・ベッドを含んでいてもよく、前記オーディオ・オブジェクトはオブジェクト・オーディオ・メタデータ（OAMD: object audio metadata）フォーマットに整合するオブジェクトを含んでいてもよい。ある実施形態では、システムはさらに、任意の二つの相続くオーディオ・セグメントの間のレイテンシーについて、初期化フェーズの間に既知のレイテンシー差について事前補償して、前記相続くオーディオ・セグメントについて前記アップミキサーおよびオブジェクト・オーディオ・レンダラー・インターフェースを通る異なる信号経路の時間整列された出力を提供することによって、調整するよう構成されたレイテンシー・マネージャを有する。いくつかの実施形態では、前記アップミキサーは、入力オーディオ・チャネルを出力スピーカーにマッピングする単純な素通しノードで置き換えられてもよい。

実施形態は、オブジェクト・ベースのオーディオを処理する方法にも向けられる。該処理は、オーディオ・サンプルのブロックおよび一つまたは複数の関連するオブジェクト・オーディオ・メタデータ・ペイロードをオブジェクト・オーディオ・レンダラー・インターフェース（OARI）において受領し、各オブジェクト・オーディオ・メタデータ・ペイロードからの一つまたは複数のオーディオ・ブロック更新をシリアル化解除し、オーディオ・サンプルおよびオーディオ・ブロック更新をそれぞれのオーディオ・サンプルおよびオーディオ・ブロック更新メモリ・キャッシュに記憶し、前記オーディオ・サンプルの処理ブロック・サイズを、処理ブロック境界に対するオーディオ・ブロック更新のタイミングおよび整列ならびに最大／最小処理ブロック・サイズ・パラメータを含む一つまたは複数の他のパラメータに基づいて動的に選択することによる。本方法はさらに、オブジェクト・ベースのオーディオを、前記動的な選択によって決定されたサイズの処理ブロックで、OARIからOARに伝送することを含んでいてもよい。各メタデータ要素はメタデータ・フレームにおいて渡され、サンプル・オフセットが、オーディオ・ブロック中のどのサンプルにおいて当該フレームが適用されるかを示す。本方法はさらに、オブジェクト優先順位付け、幅除去、無効化されたオブジェクトの扱い、過度に頻繁な更新のフィルタリング、所望される範囲への空間位置クリッピングおよび更新データの所望されるフォーマットへの変換を含む一つまたは複数のプロセスを通じて前記メタデータ要素を含む前記メタデータを準備することを含んでいてもよい。OARは、長さ32,64,128,256,480,512,1024,1536または2048サンプルといった限られた数の処理ブロック・サイズをサポートしてもよいが、そのように限定されるものではない。ある実施形態では、処理ブロック・サイズの選択は、オーディオ・ブロック更新が、処理ブロック・サイズ選択パラメータによって許容される限り処理ブロックの最初のサンプルの近くに位置されるようになされる。処理ブロック・サイズは、オーディオ・ブロック更新位置、OAR処理ブロック・サイズおよびOARI最大および最小ブロック・サイズ・パラメータ値によって制約されて可能な限り大きく選択されてもよい。メタデータ・フレームはオーディオ・サンプルのブロックにおいて一つまたは複数のオブジェクトのレンダリングに関する属性を定義するメタデータを含んでいてもよい。それらの属性は、ダイアログ、音楽、効果、効果音（Foley）、背景音および周囲音定義を含むコンテンツ型属性；3D位置、オブジェクト・サイズおよびオブジェクト速度を含む空間的属性；およびスピーカー位置にスナップ、チャネル重み、利得、傾斜〔ランプ〕およびベース〔低音〕管理情報を含むスピーカー・レンダリング属性からなる群から選択される。

実施形態はさらに、オーディオ・オブジェクトを処理する方法に向けられる。該処理は、オーディオ・サンプルのブロックおよび該オーディオ・サンプルがオブジェクト・オーディオ・レンダラー（OAR）においてどのようにレンダリングされるかを定義する関連するメタデータを、オブジェクト・オーディオ・レンダラー・インターフェース（OARI）において受領する段階であって、前記メタデータは、前記オーディオ・オブジェクトの異なるレンダリング属性を定義するよう時間とともに更新される、段階と、前記オーディオ・サンプルおよびメタデータ更新を、前記OARによって処理されるよう、諸処理ブロックの配置においてバッファリングする段階と、処理ブロック・サイズを、ブロック境界に対するメタデータ更新のタイミングおよび整列ならびに最大／最小処理ブロック・サイズ・パラメータを含む一つまたは複数の他のパラメータに基づいて動的に選択する段階と、前記オブジェクト・ベースのオーディオを、前記動的な選択の段階によって決定されたサイズのブロックで、前記OARIから前記OARに伝送する段階とを実行することによる。本方法はさらに、各ブロックについての前記オーディオ・データおよびブロック更新をそれぞれのオーディオおよび更新メモリ・キャッシュに記憶することを含み、前記ブロック更新は、オブジェクト・オーディオ・メタデータ・ペイロードに格納されるメタデータ要素においてエンコードされる。各メタデータ要素はメタデータ・フレームにおいて渡され、サンプル・オフセットが、処理ブロック中のどのサンプルにおいて当該フレームが適用されるかを示してもよい。ブロック・サイズの選択は、ブロック更新が、前記最小出力ブロック・サイズ選択によって許容される限り当該ブロックの最初のサンプルの近くに位置されるようになされてもよい。ある実施形態では、ブロック・サイズは、ブロック更新位置、OARブロック・サイズおよびOARI最大ブロック・サイズ・パラメータ値によって制約されて可能な限り大きく選択される。本方法はさらに、オブジェクト優先順位付け、幅除去、無効化されたオブジェクトの扱い、過度に頻繁な更新のフィルタリング、所望される範囲への空間位置クリッピングおよび更新データの所望されるフォーマットへの変換を含む一つまたは複数のプロセスを通じて前記メタデータ要素を含む前記メタデータを準備することを含んでいてもよい。

実施形態はさらに、処理されるべきオーディオがチャネル・ベースのオーディオかオブジェクト・ベースのオーディオかを、定義されたメタデータ定義を通じて判定し、チャネル・ベースであれば前記オーディオをチャネル・ベース・オーディオ・レンダラー（CAR）を通じて処理し、オブジェクト・ベースであれば前記オーディオをオブジェクト・ベース・オーディオ・レンダラー（OAR）を通じて処理することによって適応オーディオ・データを処理する方法に向けられる。ここで、前記OARは、前記オーディオの処理ブロック・サイズを、メタデータ更新のタイミングおよび整列ならびに最大および最小ブロック・サイズを含む一つまたは複数の他のパラメータに基づいて動的に調整するOARインターフェース（OARI）を利用する。

実施形態は、チャネル・ベースまたはオブジェクト・ベースのオーディオ・レンダリングの間で切り換える方法にも向けられる。これは、オーディオ・ブロックをもつメタデータ要素をチャネル・ベースのオーディオ・コンテンツを示す第一の状態またはオブジェクト・ベースのオーディオ・コンテンツを示す第二の状態をもつようエンコードし、前記メタデータ要素をオーディオ・ビットストリームの一部としてデコーダに伝送し、前記メタデータ要素を前記デコーダにおいてデコードして、前記メタデータ要素が前記第一の状態であればチャネル・ベースのオーディオ・コンテンツをチャネル・オーディオ・レンダラー（CAR）に、前記メタデータ要素が前記第二の状態であればオブジェクト・ベースのオーディオ・コンテンツをオブジェクト・オーディオ・レンダラー（OAR）にルーティングすることによる。この方法において、前記メタデータ要素は、前記デコーダに伝送されるパルス符号変調された（PCM）オーディオ・ビットストリームを用いて帯域内〔インバンド〕で伝送されるメタデータ・フラグを有する。CARは、アップミキサーまたはチャネル・ベースのオーディオの入力チャネルを出力スピーカーにマッピングする素通しノードの一方を含んでいてもよい。OARは、前記オーディオの処理ブロック・サイズを、メタデータ更新のタイミングおよび整列ならびに最大および最小ブロック・サイズを含む一つまたは複数の他のパラメータに基づいて動的に調整するOARインターフェース（OARI）を利用するレンダラーを含む。

実施形態はさらに、上述した方法の少なくとも一部を実装する回路を組み込んでいる上述した方法および／またはスピーカー・システムを実装するデジタル信号処理システムに向けられる。

〈参照による組み込み〉
本明細書において言及される各刊行物、特許および／または特許出願はここに参照によって、個々の各刊行物および／または特許出願が具体的かつ個別的に参照によって組み込まれることが示されている場合と同じ程度にその全体において組み込まれる。

以下の図面では、同様の参照符号が同様の要素を指すために使われる。以下の図はさまざまな例を描いているが、前記一つまたは複数の実装は図面に描かれる例に限定されるものではない。
高さチャネルの再生のための高さスピーカーを提供するサラウンド・システム（たとえば9.1サラウンド）における例示的なスピーカー配置を示す図である。 ある実施形態のもとでの、適応的なオーディオ混合を生成するためのチャネルおよびオブジェクト・ベースのデータの組み合わせを示す図である。 ある実施形態のもとでの、チャネル・ベースおよびオブジェクト・ベースのオーディオを処理する適応的なオーディオ・システムのブロック図である。 Ａは、ある実施形態のもとでの、適応的なオーディオAVRシステムにおけるチャネル・ベースのデコードおよびアップミックスのための処理経路を示し、Ｂは、ある実施形態のもとでの、Ａの適応的なオーディオAVRシステムにおけるオブジェクト・ベースのデコードおよびレンダリングのための処理経路を示す図である。 ある実施形態のもとでの、オブジェクト・ベースとチャネル・ベースのオーディオ・データの間で切り換えるための帯域内信号伝達メタデータを提供する方法を示すフローチャートである。 ある実施形態のもとでの、オブジェクト・オーディオ・レンダラーによって処理される階層構造へのメタデータの編成を示す図である。 ある実施形態のもとでの、第一の型のコーデック内でのメタデータ更新の適用およびメタデータ更新のフレーム構成（framing）を示す図である。 ある実施形態のもとでの、第二の型のコーデック内でのメタデータ更新の適用およびメタデータ更新のフレーム構成（framing）を示す図である。 ある実施形態のもとでの、オブジェクト・オーディオ・レンダラー・インターフェースによって実行されるプロセス段階を示す流れ図である。 ある実施形態のもとでの、オブジェクト・オーディオ・レンダラー・インターフェースのキャッシングおよびシリアル化解除処理サイクルを示す図である。 ある実施形態のもとでの、オブジェクト・オーディオ・レンダラー・インターフェースによるメタデータ更新の適用を示す流れ図である。 ある実施形態のもとでの、オブジェクト・オーディオ・レンダラー・インターフェースによって実行される初期の処理サイクルの例を示す図である。 図１２の例示的な処理サイクルに続くその後の処理サイクルを示す図である。 ある実施形態のもとでの、内部データ構造におけるオフセット・フィールドの計算において使われる諸フィールドを列挙する表である。

適応オーディオ・システムにおいてオブジェクト・ベースとチャネル・ベースのオーディオの間で切り換えるための、ギャップ、ミュートあるいはグリッチなしに連続的なオーディオ・ストリームの再生を許容するシステムおよび方法が記述される。適応オーディオ処理システムのオブジェクト・オーディオ・レンダラーにおいてオブジェクト・オーディオ・メタデータの、オブジェクト・オーディオPCMデータとの適正な整列を維持しつつ、プロセッサ効率およびメモリ使用を最適化するよう動的に選択された処理ブロック・サイズを生じる関連するオブジェクト・オーディオ・レンダラー・インターフェースのための実施形態も記述される。本稿に記載される一つまたは複数の実施形態の諸側面は、ソフトウェア命令を実行する一つまたは複数のコンピュータまたは処理装置を含む混合、レンダリングおよび再生システムにおいて源オーディオ情報を処理するオーディオまたはオーディオビジュアル・システムにおいて実装されうる。記載される実施形態はいずれも、単独でまたは任意の組み合わせにおいて互いと一緒に使用されうる。さまざまな実施形態が、本明細書の一つまたは複数の場所で論じられるまたは暗示されることがありうる従来技術でのさまざまな欠点によって動機付けられていることがありうるが、それらの実施形態は必ずしもこれらの欠点のいずれかに取り組むものではない。つまり、種々の実施形態は本明細書において論じられることがある種々の欠点に取り組むことがある。いくつかの実施形態は、本明細書において論じられることがあるいくつかの欠点または一つだけの欠点に部分的に取り組むだけであることがあり、いくつかの実施形態はこれらの欠点のどれにも取り組まないこともある。

本記述の目的のためには、以下の用語は関連付けられた意味をもつ：用語「チャネル」は、オーディオ信号にメタデータを加えたものを意味する。メタデータにおいて、位置はチャネル識別子、たとえば左前方または右上方サラウンドとして符号化される。「チャネル・ベースのオーディオ」は、関連付けられた公称位置をもつスピーカー・ゾーンのあらかじめ定義されたセット、たとえば5.1、7.1などを通じた再生のためにフォーマットされたオーディオである。用語「オブジェクト」または「オブジェクト・ベースのオーディオ」は、見かけの源位置（たとえば3D座標）、見かけの源幅などといったパラメトリックな源記述をもつ一つまたは複数のオーディオ・チャネルを意味する。「適応オーディオ」は、チャネル・ベースのおよび／またはオブジェクト・ベースのオーディオ信号に、オーディオ・ストリームに位置が空間内の3D位置として符号化されているメタデータを加えたものを使って、再生環境に基づいてオーディオ信号をレンダリングするメタデータを加えたものを意味する。「適応ストリーミング」は、適応的に変化しうる（たとえばチャネル・ベースからオブジェクト・ベースに、あるいは再び逆に）オーディオ型を指し、これはオンライン・ストリーミング・アプリケーションについて一般的であり、その場合、オーディオのフォーマットは変動する帯域幅制約条件に合わせてスケーリングする必要がある（たとえば、オブジェクト・オーディオがより高いデータ・レートになる傾向があると、より低い帯域幅の条件下での予備策はしばしばチャネル・ベースのオーディオである）。「聴取環境」は、任意の開けた、部分的に囲まれたまたは完全に囲まれた領域、たとえば部屋であって、オーディオ・コンテンツを単独でまたはビデオまたは他のコンテンツと一緒に再生するために使用できる領域を意味し、自宅、映画館、シアター、講堂、スタジオ、ゲーム・コンソールなどにおいて具現されることができる。

〈適応的なオーディオ・フォーマットおよびシステム〉
ある実施形態では、相互接続システムは、「空間的オーディオ・システム」「ハイブリッド・オーディオ・システム」または「適応オーディオ・システム」と称されうる音フォーマットおよび処理システムとともに機能するよう構成されているオーディオ・システムの一部として実装される。そのようなシステムは、向上した聴衆没入感、より大きな芸術的制御ならびにシステム柔軟性およびスケーラビリティーを許容するためのオーディオ・フォーマットおよびレンダリング技術に基づく。全体的な適応オーディオ・システムは一般に、通常のチャネル・ベースのオーディオ要素およびオーディオ・オブジェクト符号化要素の両方を含む一つまたは複数のビットストリーム（オブジェクト・ベース・オーディオ）を生成するよう構成されたオーディオ・エンコード、配送およびデコード・システムを含む。そのような組み合わされたアプローチは、別個に実施されるチャネル・ベースまたはオブジェクト・ベースのアプローチのいずれと比べても、より大きな符号化効率およびレンダリング柔軟性を提供する。

適応オーディオ・システムおよび関連するオーディオ・フォーマットの例は、ドルビー（登録商標）・アトモス（登録商標）・プラットフォームである。そのようなシステムは、9.1サラウンド・システムまたは同様のサラウンドサウンド構成として実装されてもよい高さ（上下）次元を組み込む。そのような高さベースのシステムは、x.y.z指定を通じて高さスピーカーが床スピーカーから区別される異なる命名法によって指定されうる。xが床スピーカーの数であり、yがサブウーファーの数であり、zが高さスピーカーの数である。よって、9.1システムは、5.1システムと4つの高さスピーカーを含む5.1.4システムと呼ばれてもよい。

図１は、高さチャネルの再生のための高さスピーカーを提供する現在のサラウンド・システム（たとえば5.1.4サラウンド）におけるスピーカー配置を示している。システム１００のスピーカー構成は、床面における五つのスピーカー１０２および高さ面における四つのスピーカー１０４から構成される。一般に、これらのスピーカーは、室内で多少なりとも正確に任意の位置から発するよう設計された音を生じるために使用されうる。図１に示されるようなあらかじめ定義されたスピーカー構成は、当然ながら、所与の音源の位置を正確に表現する能力を制限することがある。たとえば、音源は左スピーカー自身よりさらに左にパンされることはできない。これはすべてのスピーカーにあてはまり、よってダウンミックスがその中に制約される一次元（たとえば左右）、二次元（たとえば前後）または三次元（たとえば左右、前後、上下）の幾何形状をなす。そのようなスピーカー構成において、さまざまな異なるスピーカー構成および型が使用されうる。たとえば、ある種の向上されたオーディオ・システムは、9.1、11.1、13.1、19.4または他の構成、たとえばx.y.z構成によって指定される構成にあるスピーカーを使ってもよい。スピーカー型はフルレンジ直接スピーカー、スピーカー・アレイ、サラウンド・スピーカー、サブウーファー、ツイーターおよび他の型のスピーカーを含みうる。

オーディオ・オブジェクトは、聴取環境における特定の物理的位置（単数または複数）から発するように知覚されうる音要素の群と考えることができる。そのようなオブジェクトは静的（すなわち定常）または動的（すなわち動いている）であることができる。オーディオ・オブジェクトは、他の機能とともに所与の時点における音の位置を定義するメタデータによって制御される。オブジェクトが再生されるとき、オブジェクトは、必ずしもあらかじめ定義された物理チャネルに出力されるのではなく、位置メタデータに従って、存在している諸スピーカーを使ってレンダリングされる。セッションにおけるトラックはオーディオ・オブジェクトであることができ、標準的なパン・データは位置メタデータに似ている。このように、スクリーン上に配置されたコンテンツはチャネル・ベースのコンテンツと同じ仕方で効果的にパンしうるが、サラウンドに配置されたコンテンツは望むなら個別のスピーカーにレンダリングされることができる。オーディオ・オブジェクトの使用が離散的な諸効果についての所望される制御を提供する一方、サウンドトラックの他の側面がチャネル・ベースの環境において効果的に機能しうる。たとえば、多くの周囲効果または残響は、スピーカーのアレイに供給されることから実際に裨益する。これらはアレイを満たすために十分な幅をもつオブジェクトとして扱われることができるが、いくつかのチャネル・ベースの機能を保持することが有益である。

適応オーディオ・システムは、オーディオ・オブジェクトに加えてオーディオ・ベッドをサポートするよう構成されている。ここで、ベッドとは、事実上、チャネル・ベースのサブミックスまたはステムである。これらは、コンテンツ・クリエーターの意図に依存して、個々に、あるいは単一のベッドに組み合わされて、最終的な再生（レンダリング）のために送達されることができる。これらのベッドは、5.1、7.1および9.1ならびに図１に示したような頭上スピーカーを含むアレイのような、異なるチャネル・ベースの構成で生成されることができる。図２は、ある実施形態のもとでの、適応的なオーディオ混合を生成するための、チャネルおよびオブジェクト・ベースのデータの組み合わせを示している。プロセス２００において示されるように、たとえばパルス符号変調された（PCM）データの形で提供された5.1または7.1サラウンドサウンド・データでありうるチャネル・ベースのデータ２０２が、オーディオ・オブジェクト・データ２０４と組み合わされて、適応オーディオ混合２０８を生成する。オーディオ・オブジェクト・データ２０４は、もとのチャネル・ベースのデータを、オーディオ・オブジェクトの位置に関するある種のパラメータを指定する関連するメタデータと組み合わせることによって生成される。図２に概念的に示されるように、オーサリング・ツールは、スピーカー・チャネル・グループおよびオブジェクト・チャネルの組み合わせを同時に含むオーディオ・プログラムを生成する能力を提供する。たとえば、オーディオ・プログラムは、任意的にグループ（またはトラック、たとえばステレオまたは5.1トラック）に編成されている一つまたは複数のスピーカー・チャネルと、一つまたは複数のスピーカー・チャネルについての記述メタデータと、一つまたは複数のオブジェクト・チャネルと、一つまたは複数のオブジェクト・チャネルにつじての記述メタデータとを含むことができる。

適応オーディオ混合２０８のために、再生システムは、入力オーディオをデジタル・ビットストリームとしてエンコードする一つまたは複数の捕捉、前処理、オーサリングおよび符号化コンポーネントを通じて生成されるオーディオ・コンテンツをレンダリングし、再生するよう構成されることができる。源離間（source separation）およびコンテンツ型といった因子を調べることによる入力オーディオの解析を通じて適切なメタデータを自動的に生成するために、適応オーディオ・コンポーネントが使用されてもよい。たとえば、チャネル対間の相関した入力の相対レベルの解析を通じて、位置メタデータがマルチチャネル・レコーディングから導出されてもよい。発話または音楽といったコンテンツ型の検出は、たとえば、特徴抽出および分類によって達成されてもよい。ある種のオーサリング・ツールは、サウンドエンジニアの創造的な意図の入力および符号化を最適化することによってオーディオ・プログラムのオーサリングを許容し、サウンドエンジニアが最終的なオーディオ混合を一度だけ生成することを許容し、それが実際上任意の再生環境における再生のために最適化される。これは、オーディオ・オブジェクトと、もとのオーディオ・コンテンツに関連付けられ、一緒にエンコードされている位置データとを使うことを通じて達成できる。ひとたび適応的なオーディオ・コンテンツがオーサリングされ、適切なコーデック装置において符号化されたら、図１に示されるようなスピーカーを通じた再生のためにデコードされ、レンダリングされる。

図３は、ある実施形態のもとでの、チャネル・ベースおよびオブジェクト・ベースのオーディオを処理する適応オーディオ・システムのブロック図である。システム３００に示されるように、オブジェクト・メタデータを含むオブジェクト・ベースのオーディオならびにチャネル・ベースのオーディオを含む入力オーディオが入力オーディオ・ビットストリーム（オーディオ入力）としてデコード／レンダリング（デコーダ）サブシステム３０２内の一つまたは複数のデコーダ回路に入力される。ビットストリーム中のオーディオはさまざまなオーディオ成分、たとえば関連付けられたスピーカーもしくはチャネル識別子をもつチャネル（オーディオ・ベッド）および関連付けられたオブジェクト・メタデータをもつさまざまなオーディオ・オブジェクト（たとえば静的または動的なオブジェクト）をエンコードしている。ある実施形態では、任意の特定の時点においてはオブジェクトまたはチャネルの一つの型のオーディオのみが入力されるが、オーディオ入力ストリームは、プログラムの経過の間、これら二つの型のオーディオ・コンテンツの間で周期的にまたはある程度頻繁に切り替わってもよい。オブジェクト・ベースのストリームは、チャネルおよびオブジェクトの両方を含んでいてもよく、オブジェクトは異なる型：ベッド・オブジェクト（すなわちチャネル）、動的なオブジェクトおよびISF（Intermediate Spatial Format［中間空間フォーマット］）オブジェクトでありうる。ISFは、パン動作を時間変化する部分および静的な部分という二つの部分に分割することによってオーディオ・オブジェクト・パンナーの動作を最適化するフォーマットである。他の同様のオブジェクトも本システムによって処理されうる。OARはこれらすべての型を同時に扱う。一方、CARは、レガシーのチャネル・ベースのコンテンツのブラインド・アップミックスを行なうまたは素通しノードとして機能するために使われる。

デコーダ３０２後のオーディオの処理は、一般に、チャネル・ベースのオーディオとオブジェクト・ベースのオーディオとで異なる。よって、図３の実施形態について、チャネル・ベースのオーディオはアップミキサー３０４または他のチャネル・ベースのオーディオ・プロセッサを通じて処理されるものとして示されており、一方、オブジェクト・ベースのオーディオはオブジェクト・オーディオ・レンダラー・インターフェース（OARI）３０６を通じて処理されるものとして示されている。CARコンポーネントは、図のようなアップミキサーを有していてもよく、あるいは入力オーディオ・チャネルを出力スピーカーにマッピングする単純な素通しノードを含んでいてもよく、あるいは他の任意の適切なチャネル・ベースの処理コンポーネントであってもよい。次いで、処理されたオーディオは、結合器（joiner）コンポーネント３０８または同様の組み合わせ回路において多重化されるまたは結び合わされ、結果として得られるオーディオ出力が次いで、図１のアレイ１００のようなスピーカー・アレイ内の適切なスピーカー（単数または複数）３１０に送られる。

図３の実施形態について、オーディオ入力は、チャネルおよびオブジェクトをそれぞれの関連するメタデータまたは識別子データとともに含みうる。このように、エンコードされたオーディオ・ビットストリームは、デコーダ３０２に入力される際には、両方の型のオーディオ・データを含んでいる。ある実施形態では、デコーダ３０２は、それぞれの特定の型のオーディオ・コンテンツが適切なプロセッサ３０４または３０６にルーティングされるよう、オブジェクトおよびチャネル・ベースのオーディオ・データの間で切り換えるために帯域内信号伝達メタデータを利用する切り換え機構３０１を含んでいる。そのような信号伝達メタデータを使うことによって、符号化されたオーディオ源はオブジェクトとチャネル・ベースのオーディオ３０１の間の切り換えを信号伝達しうる。ある実施形態では、信号伝達メタデータ信号はオーディオ入力ビットストリームと一緒に「帯域内で」伝送され、オーディオ・レンダリング３０６またはアップミックス３０４のような下流のプロセスをアクティブ化するはたらきをする。これは、ギャップ、ミュート、グリッチまたはオーディオ／ビジュアル同期シフトのない連続的なオーディオ・ストリームを許容する。初期化時には、デコーダ３０２は、オブジェクト・ベースおよびチャネル・ベースのオーディオ両方を処理する用意ができている。オーディオ型の間で変化が起こると、デコーダDSPの内部でメタデータが生成されて、オーディオ処理ブロックの間で伝送される。このメタデータを利用することによって、他のDSPまたはマイクロコントローラに外部通信する必要なしに、DSPがはいってくるオーディオのための正しい処理チェーンを選択できるようにすることが可能になる。これは、符号化されたオーディオ源が、オーディオ・コンテンツと一緒に伝送されるメタデータ信号を通じてオブジェクト・ベースとチャネル・ベースのオーディオの間の切り換えを信号伝達することを許容する。

図４のＡおよびＢは、ある実施形態のもとでの、適応オーディオAVRシステムにおける、オブジェクト・ベースのデコードおよびレンダリングとチャネル・ベースのデコードおよびアップミックスとについてたどられる異なる処理経路を示している。図４のＡは、適応オーディオAVRシステムにおける、チャネル・ベースのデコードおよびアップミックスについての処理経路および信号フローを示しており、図４のＢは、同じAVRシステムにおける、オブジェクト・ベースのデコードおよびレンダリングについての処理経路および信号フローを示している。ドルビー・デジタル・プラスまたは同様のビットストリームであってもよい入力ビットストリームは、時間とともに、オブジェクト・ベースとチャネル・ベースのコンテンツの間で変化しうる。コンテンツが変化すると、デコーダ４０２（たとえばドルビー・デジタル・プラス・デコーダ）は、オーディオ構成（オブジェクトかチャネルか）をエンコードするまたは示す帯域内メタデータを出力するよう構成されている。図４のＡに示されるように、入力ビットストリーム内のチャネル・ベースのオーディオは、スピーカー構成情報をも受け取るアップミキサー４０４を通じて処理され；図４のＢに示されるように、入力ビットストリーム内のオブジェクト・ベースのオーディオは、適切なスピーカー構成情報をも受け取るオブジェクト・オーディオ・レンダラー（OAR）４０６を通じて処理される。OARは、図３に示されるオブジェクト・オーディオ・レンダラー・インターフェース（OARI）３０６を通じてAVRシステム４１１とインターフェースをもつ。オーディオ・コンテンツと一緒にエンコードされてオーディオ型をエンコードする帯域内メタデータの使用は、アップミキサー４０４およびレンダラー４０６が処理すべき適切なオーディオを選ぶことを許容する。こうして、図４のＡおよびＢに示されるように、アップミキサー４０４はインライン・メタデータを通じてチャネル・ベースのオーディオの存在を検出し、該チャネル・ベースのオーディオのみを処理し、他方ではオブジェクト・ベースのオーディオを無視する。同様に、レンダラー４０６は、インライン・メタデータを通じてオブジェクト・ベースのオーディオの存在を検出し、該オブジェクト・ベースのオーディオのみを処理し、他方ではチャネル・ベースのオーディオを無視する。このインライン・メタデータは事実上、システムが、適切なポストデコーダ処理コンポーネント（たとえばアップミキサー、OAR）の間で、これらのコンポーネントによって検出されるオーディオ・コンテンツの型に直接基づいて、切り替わることを許容する。このことは仮想的なスイッチ４０３によって示されている。

レンダリングされたオーディオ（オブジェクト・ベース）とアップミックスされたオーディオ（チャネル・ベース）の間で切り換えるとき、レイテンシーを管理することも重要である。アップミキサー４０４およびレンダラー４０６はいずれも異なる0でないレイテンシーをもちうる。レイテンシーが考慮に入れられないと、オーディオ／ビデオ同期が影響されることがあり、オーディオ・グリッチが知覚されることがありうる。レイテンシー管理は別個に扱われてもよく、あるいはレンダラーまたはアップミキサーによって扱われてもよい。レンダラーまたはアップミキサーが最初に初期化されるとき、各コンポーネントは、各コンポーネント内のレイテンシー決定アルゴリズムなどを通じて、サンプル単位でのそのレイテンシーについて問い合わせされる。レンダラーまたはアップミキサーがアクティブになるとき、そのレイテンシーに等しい、コンポーネント・アルゴリズムによって生成される初期の諸サンプルが、破棄される。レンダラーまたはアップミキサーが非アクティブになるとき、そのレイテンシーに等しい余計な数の0のサンプルが処理される。こうして、出力されるサンプル数は、入力されたサンプル数に厳密に等しくなる。先行する0は出力されず、古くなったデータがコンポーネント・アルゴリズムに残されることもない。そのような管理および同期は、システム４００および４１１におけるレイテンシー管理コンポーネント４０８によって提供される。レイテンシー・マネージャ４０８は、アップミキサー４０４とレンダラー４０６の出力を一つの連続的オーディオ・ストリームに結合することをも受け持つ。ある実施形態では、実際のレイテンシー管理機能は、レイテンシー処理規則に従ってそれぞれの受領されたオーディオ・セグメントについて先行する0を破棄して余計なデータを処理することによって、アップミキサーおよびレンダラー両方の内部で扱われてもよい。このように、レイテンシー・マネージャは、異なる信号経路の時間整列された出力を保証する。このことは、システムが、複数の再生条件およびビットストリームにおける変化の可能性のために普通なら生じうる可聴で不快なアーチファクトを生じることなく、ビットストリーム変化を扱うことを許容する。

ある実施形態では、レイテンシー整列は、初期化フェーズの間に既知のレイテンシー差について事前補償することによって行なわれる。連続するオーディオ・セグメントの途中でサンプルが脱落させられてもよい。（たとえばチャネル・オーディオ・レンダラーにおいて）オーディオが最小フレーム境界サイズに整列しない、あるいはシステムが過渡成分を最小にするよう「フェード」を適用しているからである。図４のＡおよびＢに示されるように、レイテンシー同期されたオーディオは次いで一つまたは複数の追加的な後工程４１０を通じて処理される。後工程４１０は、音ステアリング、オブジェクト軌跡、高さ効果などに関するパラメータを提供する適応オーディオ対応スピーカー情報を利用しうる。

ある実施形態では、ビットストリーム・パラメータに関する切り換えを可能にするために、アップミキサー４０４はメモリにおいて初期化されたままである必要がある。このようにして、適応オーディオ・コンテンツの喪失が検出されるとき、アップミキサーはすぐに、チャネル・ベースのオーディオのアップミックスを開始することができる。

図５は、ある実施形態のもとでの、オブジェクト・ベースとチャネル・ベースのオーディオ・データの間で切り換えるために帯域内信号伝達メタデータを提供する方法を示すフローチャートである。図５のプロセス５００に示されるように、異なる時点においてチャネル・ベースとオブジェクト・ベースのオーディオをもつ入力ビットストリームがデコーダにおいて受領される（５０２）。デコーダは、ビットストリームを受領する際にオーディオ型の変化を検出する（５０４）。デコーダは内部的に、オーディオの各受領されたセグメントについてオーディオ型を示すメタデータを生成し、この生成されたメタデータを、下流のプロセッサまたは処理ブロックへの伝送のために各オーディオ・セグメントと一緒にエンコードする（５０６）。こうして、チャネル・ベースのオーディオ・セグメントはそれぞれチャネル識別メタデータ定義と一緒にエンコードされ（チャネル・ベースであるとタグ付けされる）、オブジェクト・ベースのオーディオ・セグメントはそれぞれオブジェクト識別メタデータ定義と一緒にエンコードされる（オブジェクト・ベースであるとタグ付けされる）。デコーダ後の各処理ブロックは、このインライン信号伝達メタデータに基づいてはいってくるオーディオ信号セグメントの型を検出し、しかるべくそれを処理または無視する（５０８）。こうして、アップミキサーまたは他の同様のプロセスは、チャネル・ベースであると信号伝達されるオーディオ・セグメントを処理することになり、OARまたは他の同様のプロセスは、オブジェクト・ベースであると信号伝達されるオーディオ・セグメントを処理することになる。相続くオーディオ・セグメントの間のレイテンシー差があればそれはシステム内のまたは各下流の処理ブロック内のレイテンシー管理プロセスを通じて調整され、それらのオーディオ・ストリームは結合されて出力オーディオ・ストリームを形成する（５１０）。次いで、出力ストリームはサラウンドサウンド・スピーカー・アレイに伝送される（５１２）。

帯域内メタデータ信号伝達を利用し、レイテンシーを管理することにより、図３のオーディオ・システムは、時間とともにオブジェクトとチャネルの間で変化するオーディオを受領し、処理することができ、グリッチ、ミュートやオーディオ／ビデオ同期ドリフトなしにすべての要求されたスピーカー・フィードのために一定のオーディオ出力を維持する。これは、同じビットストリーム内に新しい（たとえばドルビー・アトモスのオーディオ／ビデオ）コンテンツおよびレガシー（たとえばサラウンドサウンド・オーディオ）コンテンツの両方を含むオーディオ・コンテンツの配送および処理を許容する。適切なアップミキサー３０４を使うことによって、AVRまたは他の装置が、最小の空間的歪みを引き起こしつつコンテンツ型の間で切り換えをすることができる。これは、新たに開発されたAVR製品が、ビットレートおよびチャネル構成などビットストリームにおける変化を、結果として生じるいかなるオーディオ脱落も望ましくないオーディオ・アーチファクトもなしに、受領できることを許容する。業界は新たなコンテンツ送達形態および適応的なストリーミング・シナリオに向けて動いているので、このことは特に重要である。記述されたサラウンド・アップミックス技術は、デコーダがこれらのビットストリーム変化を扱うのを助けることにおいて重要な役割を演じる。

図４のＡおよびＢにさらに詳述された図３のシステムが適応オーディオのための再生システムの例を表わしており、他の構成、コンポーネントおよび相互接続も可能であることを注意しておくべきである。たとえば、デコーダ３０２は、アップミックスおよびオブジェクト・レンダリングのための二つの別個のプロセッサ（DSP）に結合されたマイクロコントローラとして実装されてもよく、これらのコンポーネントは物理的な伝送インターフェースまたはネットワークによって一緒に結合された別個の装置として実装されてもよい。デコーダ・マイクロコントローラと処理DSPはそれぞれ別個のコンポーネントまたはサブシステム内に含まれていてもよく、あるいは統合されたデコーダ／レンダラー・コンポーネントのような同じサブシステム内に含まれる別個のコンポーネントであってもよい。あるいはまた、デコーダおよびポストデコーダ・プロセスは、モノリシックな集積回路デバイス内の別個の処理コンポーネントとして実装されてもよい。

〈メタデータ定義〉
ある実施形態では、適応オーディオ・システムは、もとの空間的オーディオ・フォーマットからメタデータを生成するコンポーネントを含む。記載されるシステムの方法およびコンポーネントは、通常のチャネル・ベースのオーディオ要素およびオーディオ・オブジェクト符号化要素の両方を含む一つまたは複数のビットストリームを処理するよう構成されたオーディオ・レンダリング・システムを有する。空間的オーディオ・プロセッサからの空間的オーディオ・コンテンツはオーディオ・オブジェクト、チャネルおよび位置メタデータを含む。メタデータは、エンジニアの混合入力に応答してオーディオ・ワークステーションにおいて生成され、空間的パラメータ（たとえば位置、速度、強度、音色など）を制御し、展示中に聴取環境におけるどのドライバ（単数または複数）またはスピーカー（単数または複数）がそれぞれの音を再生するかを指定するレンダリング・キューを提供する。メタデータは、オーディオ・プロセッサによるパッケージングおよび転送のために、前記ワークステーションにおいてそれぞれのオーディオ・データに関連付けられる。

ある実施形態では、オーディオ型（すなわちチャネルまたはオブジェクト・ベースのオーディオ）メタデータ定義が、適応オーディオ処理システムによって処理されるオーディオ・ビットストリームの一部として伝送されるメタデータ・ペイロードに加えられ、あるいは該ペイロード内でエンコードされ、あるいは該ペイロードと他の仕方で関連付けられる。一般に、適応オーディオのためのオーサリングおよび配送システムは、固定したスピーカー位置（左チャネル、右チャネルなど）を介した再生を許容するオーディオと、位置、サイズおよび速度を含む一般化された3D空間情報をもつオブジェクト・ベースのオーディオ要素とを生成し、送達する。システムは、コンテンツ制作／オーサリングの時点でコンテンツ・クリエーターによってオーディオ・エッセンスと対にされるメタデータを通じて、オーディオ・コンテンツについての有用な情報を提供する。このように、メタデータは、レンダリングの間に使用されることのできる、オーディオの属性についての詳細な情報をエンコードする。そのような属性は、コンテンツ型（たとえばダイアログ、音楽、効果、効果音、背景音／周囲音など）ならびにオーディオ・オブジェクト情報、たとえば空間的属性（たとえば3D位置、オブジェクト・サイズ、速度など）および有用なレンダリング情報（たとえばスピーカー位置にスナップ、チャネル重み、利得、傾斜〔ランプ〕、ベース〔低音〕管理情報など）を含みうる。オーディオ・コンテンツおよび再生意図メタデータは、コンテンツ・クリエーターによって手動で作成されてもよく、あるいはオーサリング・プロセスの間にバックグラウンドで実行できる自動的なメディア知能アルゴリズムを使って生成されて、望むなら最終的な品質コントロール・フェーズの間にコンテンツ・クリエーターによって確認されてもよい。

ある実施形態では、データを記述するために協働するいくつかの異なるメタデータ型がある。第一に、デコーダとアップミキサーもしくはレンダラーの間など、各処理ノードの間の接続がある。この接続は、データ・バッファおよびメタデータ・バッファを含む。OARIに関して下記でより詳細に述べるように、メタデータ・バッファはリストとして実装され、データ・バッファのある種のバイト・オフセットへのポインタをもつ。ノードにとって前記接続へのインターフェースは「ピン」を通じてである。ノードは、0個以上の入力ピンおよび0個以上の出力ピンを有しうる。あるノードの入力ピンと別のノードの出力ピンの間で接続がなされる。ピンの一つの特徴は、そのデータ型である。すなわち、前記接続中のデータ・バッファはさまざまな異なる型のデータ――PCMオーディオ、エンコードされたオーディオ、ビデオなど――を表わしうる。出力ピンを通じてどんな型のデータが出力されるのかを示すことはノードの責任である。処理ノードは、どんな型のデータが入力されるのかを知るために、その入力ピンにも問い合わせするべきである。

ひとたびノードがその入力ピンに問い合わせしたら、ノードは次いではいってくるデータをどのように処理するべきかを決定することができる。はいってくるデータがPCMオーディオであれば、ノードはそのPCMオーディオのフォーマットが正確にはどんなものかを知る必要がある。オーディオのフォーマットは「pcm_config」メタデータ・ペイロード構造によって記述される。この構造はたとえば、PCMオーディオのチャネル・カウント、ストライドおよびチャネル割り当てを記述する。この構造はフラグ「object_audio」をも含む。これは1に設定されていたらPCMオーディオがオブジェクト・ベースであることを示し、あるいはPCMオーディオがチャネル・ベースであれば0に設定される。ただし、他のフラグ設定値も可能である。ある実施形態では、このpcm_config構造はデコーダ・ノードによって設定され、OARIおよびCARノードの両方によって受領される。レンダリング・ノードは、pcm_configメタデータ更新を受領するとき、object_audioフラグを検査し、しかるべく反応して、必要に応じて新たなストリームを生成するか現在のストリームを終了する。

他の多くのメタデータ型がオーディオ処理フレームワークによって定義されうる。一般に、メタデータ項目は、識別子、ペイロード・サイズ、データ・バッファ中へのオフセットおよび任意的なペイロードからなる。多くのメタデータ型は実際のペイロードを全くもたず、純粋に情報提供用である。たとえば、「シーケンス開始」および「シーケンス終了」信号伝達メタデータは、単に合図でありさらなる情報はないので、ペイロードをもたない。実際のオブジェクト・オーディオ・メタデータは「発展（Evolution）」フレームにおいて担持され、発展のためのメタデータ型は発展フレームのサイズに等しいペイロード・サイズをもつ。発展フレームのサイズは固定ではなく、フレームからフレームへと変わることができる。用語「発展」フレームは一般に、安全な拡張可能なメタデータ・パッケージングおよび送達フレームワークであって、フレームが一つまたは複数のメタデータ・ペイロードおよび関連するタイミングおよびセキュリティ情報を含むことができるものを指す。実施形態は発展フレームに関して記述されているが、同様の機能を提供するいかなる適切なフレーム構成が使用されてもよいことは注意しておくべきである。

〈オブジェクト・オーディオ・レンダラー・インターフェース〉
図３に示されるように、オブジェクト・ベースのオーディオは、オブジェクト・ベースのオーディオのレンダリングのためのオブジェクト・オーディオ・レンダラー（OAR）を含むまたはそのまわりにラップするオブジェクト・オーディオ・レンダラー・インターフェース３０６を通じて処理される。ある実施形態では、OARI ３０６はオーディオ・データをデコーダ３０２から受領し、適切なインライン・メタデータによってオブジェクト・ベースのオーディオとして信号伝達されたオーディオ・データを処理する。OARIは一般に、ある種のAVR製品および再生コンポーネント、たとえば適応オーディオ対応スピーカーおよびサウンドバーのためのメタデータ更新をフィルタリングするはたらきをする。OARIは、メタデータの、はいってくるバッファリングされたサンプルとの適正な整列；プロセッサ・ニーズを満たすようさまざまな複雑さにプロセッサを適合させること；ブロック境界に整列しないメタデータ更新の知的なフィルタリング；およびサウンドバーまたは他の特化したスピーカー製品のようなアプリケーションのためのメタデータ更新のフィルタリングといった技法を実装する。

オブジェクト・オーディオ・レンダラー・インターフェースは本質的には、オブジェクト・オーディオ・レンダラーのためのラッパーであり、二つの動作を実行する：第一に、発展フレームワークおよびオブジェクト・オーディオ・メタデータ・ビットストリームをシリアル化解除し、第二に、適切な時点において適切なブロック・サイズを用いてOARによって処理されるべき入力サンプルおよびメタデータ更新をバッファリングする。ある実施形態では、OARIは非同期入出力API（アプリケーション・プログラム・インターフェース）を実装し、ここで、サンプルおよびメタデータ更新が入力オーディオ・ビットストリームにプッシュされる。この入力コールがなされたのち、利用可能なサンプル数が呼び出し側に返され、次いでそれらのサンプルが処理される。

オブジェクト・オーディオ・メタデータは、デコーダ（たとえば、ドルビー・デジタル・プラス、ドルビー・トゥルーHD、ドルビーMATデコーダまたは他のデコーダ）からのオブジェクト・ベースのPCMオーディオ出力の関連する集合とともに、適応オーディオ・プログラムをレンダリングするために必要とされるすべての関連する情報を含む。図６は、オブジェクト・オーディオ・レンダラーによって処理される階層構造へのメタデータの編成を示す。描画６００に示されるように、オブジェクト・オーディオ・メタデータ・ペイロードはプログラム割り当ておよび関連付けられたオブジェクト・オーディオ要素に分割される。オブジェクト・オーディオ要素は、複数のオブジェクトのためのデータを含み、各オブジェクト・データ要素は、オブジェクト基本情報およびオブジェクト・レンダー情報を含む関連付けられたオブジェクト情報ブロックをもつ。オブジェクト・オーディオ要素は、各オブジェクト・オーディオ要素について、メタデータ更新情報およびブロック更新情報をももつ。

入力オーディオ・ビットストリームのPCMサンプルはある種のメタデータに関連付けられており、該メタデータはそれらのサンプルがどのようにレンダリングされるかを定義する。オブジェクトおよびレンダリング・パラメータが変化すると、新たなまたは相続くPCMサンプルについてメタデータが更新される。メタデータ・フレーム構成（framing）に関し、メタデータ更新は、コーデックの型に依存して異なる仕方で格納されることができる。しかしながら、一般には、コーデック固有のフレーム構成が除去されると、メタデータ更新は、そのトランスポートには関わりなく、等価なタイミングおよびレンダー情報をもつ。図７は、ある実施形態のもとでの、第一の型のコーデック内での、メタデータ更新の適用およびメタデータ更新のフレーム構成を示している。使用されるデータ・コーデックに依存して、すべてのフレームが単一のフレーム中に複数のブロックを含みうるメタデータ更新を含むか、あるいはアクセス単位が更新を含み、一般にフレーム当たりブロックは一つだけである。描画７００に示されるように、PCMサンプル７０２は周期的なメタデータ更新７０４に関連付けられている。この描画では、五つのそのような更新が示されている。ドルビー・デジタル・プラス・フォーマットのようなある種のコーデックでは、一つまたは複数のメタデータ更新が発展フレーム７０６に記憶されていてもよく、発展フレーム７０６は、それぞれの関連するメタデータ更新についてオブジェクト・オーディオ・メタデータおよびブロック更新を含む。そこで、図７の例は、最初の二つのメタデータ更新が二つのブロック更新をもつ第一の発展フレームに格納され、次の三つのメタデータ更新が三つのブロック更新をもつ第二の発展フレームに格納されていることを示している。これらの発展フレームは一様フレーム７０８および７１０に対応し、それぞれ定義された数のサンプル（たとえばドルビー・デジタル・プラスのフレームについては1536サンプルの長さ）をもつ。

図７の実施形態は、ドルビー・デジタル・プラス・コーデックのような一つの型のコーデックについてメタデータ更新の格納を示している。しかしながら、他のコーデックおよびフレーム構成方式が使われてもよい。図８は、ドルビー・トゥルーHDコーデックのような異なるコーデックと一緒に使うための代替的なフレーム構成方式に従ったメタデータの格納を示している。描画８００に示されるように、メタデータ更新８０２はそれぞれ、オブジェクト・オーディオ・メタデータ要素（OAMD）および関連付けられたブロック更新をもつ対応する発展フレーム８０４にパッケージングされる。これらはある数のサンプル（たとえばドルビー・トゥルーHDコーデックについては40サンプル）をもつアクセス単位８０６にフレーム化される。実施形態はドルビー・デジタル・プラスおよびドルビー・トゥルーHDといったある種の例示的なコーデックについて記述してきたが、オブジェクト・ベースのオーディオのための任意の適切なコーデックが使用されてもよく、メタデータ・フレーム構成方式がしかるべく構成されてもよいことは注意しておくべきである。

〈OARI動作〉
オーディオ・オブジェクト・レンダラー・インターフェースは、オーディオ・データおよび発展メタデータの、オブジェクト・オーディオ・レンダラーへの接続を受け持つ。これを達成するために、オブジェクト・オーディオ・レンダラー・インターフェース（OARI）はオーディオ・サンプルおよび付随するメタデータをオブジェクト・オーディオ・レンダラー（OAR）に、扱いやすいデータ部分またはフレームにおいて提供する。図７および図８は、OARIにはいってくるオーディオにおいてメタデータ更新がどのように格納されるかを示しており、OARのためのオーディオ・サンプルおよび付随するメタデータは図１１、図１２および図１３に示される。

オブジェクト・オーディオ・レンダラー・インターフェース動作はいくつかの離散的な段階または処理動作からなる。これは図９の流れ図９００に示されている。図９の方法は概括的には、オブジェクト・ベースのオーディオを処理するプロセスを示している。該処理は、オーディオ・サンプルのブロックおよび一つまたは複数の関連するオブジェクト・オーディオ・メタデータ・ペイロードをオブジェクト・オーディオ・レンダラー・インターフェース（OARI）において受領し、各オブジェクト・オーディオ・メタデータ・ペイロードからの一つまたは複数のオーディオ・ブロック更新をシリアル化解除し、オーディオ・サンプルおよびオーディオ・ブロック更新をそれぞれのオーディオ・サンプルおよびオーディオ・ブロック更新メモリ・キャッシュに記憶し、前記オーディオ・サンプルの処理ブロック・サイズを、処理ブロック境界に対するオーディオ・ブロック更新のタイミングおよび整列ならびに最大／最小処理ブロック・サイズ・パラメータを含む一つまたは複数の他のパラメータに基づいて動的に選択することによる。この方法では、オブジェクト・ベースのオーディオは、前記動的な選択プロセスによって決定されたサイズの処理ブロックで、OARIからOARに伝送される。

図９を参照するに、オブジェクト・オーディオ・レンダラー・インターフェースはまず、オーディオ・サンプルのブロックおよびシリアル化解除された発展メタデータ・フレームを受領する（９０２）。オーディオ・サンプル・ブロックは任意のサイズであることができ、たとえばオブジェクト・オーディオ・レンダラー・インターフェース初期化の間に渡されたmax_input_block_size〔最大入力ブロック・サイズ〕パラメータまでのサイズであることができる。OARは長さ32,64,128,256,480,512,1024,1536および2048サンプルのブロック・サイズといった限られた数のブロック・サイズをサポートするよう構成されていてもよいが、そのように限定されるものではなく、いかなる実際的なブロック・サイズが使われてもよい。

メタデータは、二進ペイロード（たとえばデータ型evo_payload_t）およびサンプル・オフセットをもつシリアル化解除された発展フレームワーク・フレームとして渡される。サンプル・オフセットは、オーディオ・ブロック中のどのサンプルにおいて当該発展フレームワーク・フレームが適用されるかを示す。オブジェクト・オーディオ・メタデータを含んでいる発展フレームワーク・ペイロードのみがオブジェクト・オーディオ・レンダラー・インターフェースに渡される。次に、オーディオ・ブロック更新データがオブジェクト・オーディオ・メタデータ・ペイロードからシリアル化解除される（９０４）。ブロック更新は、サンプルのブロックについて、空間位置および他のメタデータ（オブジェクト型、利得および傾斜〔ランプ〕データなど）を担持する。システム構成に依存して、たとえば8個までのブロック更新がオブジェクト・オーディオ・メタデータ構造に格納される。オフセット計算は、個々のブロック更新に加えて、発展フレームワーク・オフセット、オブジェクト・オーディオ・レンダラー・インターフェース・サンプル・キャッシュの進行およびオブジェクト・オーディオ・メタデータのオフセット値を組み込む。次いで、オーディオ・データおよびブロック更新がキャッシュされる（９０６）。キャッシュ動作はメタデータとキャッシュにおけるサンプル位置との間の関係を保持する。ブロック９０８に示されるように、オブジェクト・オーディオ・レンダラー・インターフェースは、オーディオ・サンプルの処理ブロックのためのサイズを選択する。次いでメタデータが当該処理ブロックのために準備される（９１０）。この段階は、オブジェクト優先順位付け、幅除去、無効にされたオブジェクトの扱い、選択されたブロック・サイズについて頻繁すぎる更新のフィルタリング、オブジェクト・オーディオ・レンダラーによってサポートされる範囲への空間位置クリッピング（負のZ値がないことを保証するため）、オブジェクト・オーディオ・レンダラーが使うための特別なフォーマットへの更新データの変換といったある種の手順を含む。オブジェクト・オーディオ・レンダラーは次いで、選択された処理ブロックを用いて呼び出される（９１２）。

ある実施形態では、オブジェクト・オーディオ・レンダラー・インターフェースの諸段階はAPI関数によって実行される。ある関数（たとえばoari_addsamples_evo）がオブジェクト・オーディオ・メタデータ・ペイロードをブロック更新にデコードし、サンプルおよびブロック更新をキャッシュし、第一の処理ブロック・サイズを選択する。第二の関数（たとえば第一のoari_process〔OARIプロセス〕）が一つのブロックを処理し、次の処理ブロック・サイズを選択する。一つの処理サイクルの例示的な呼び出しシーケンスは次のようになる：第一に、oari_addsamples_evoへの一つの呼び出し、第二に、処理ブロックが利用可能であればoari_processへの0回以上の呼び出し、そしてこれらのステップが各サイクルについて繰り返される。

図９のステップ９０６に示されるように、OARIはキャッシングおよびシリアル化解除動作を実行する。図１０は、ある実施形態のもとでの、オブジェクト・オーディオ・レンダラー・インターフェースのキャッシングおよびシリアル化解除処理サイクルをより詳細に示している。描画１０００に示されるように、PCMサンプルの形のオブジェクト・オーディオ・データがPCMオーディオ・キャッシュ１００４に入力され、対応するメタデータ・ペイロードがオブジェクト・オーディオ・メタデータ・パーサー１００７を通じて更新キャッシュ１００８に入力される。ブロック更新は、番号付きの円によって表わされており、それぞれは、矢印によって示されるように、PCMオーディオ・キャッシュ１００４におけるサンプル位置への固定した関係をもつ。図１０に示される例示的な更新シナリオについて、最後の二つの更新は、将来のサイクルのオーディオに関連付けられている、現在のキャッシュの末尾を過ぎたサンプルに関係している。キャッシング・プロセスは、前の処理サイクルからのオーディオの任意の未使用部分および付随するメタデータを保持することに関わる。ブロック更新のためのこの繰り越しキャッシュは更新キャッシュ１００８から離される。オブジェクト・オーディオ・メタデータ・パーサーは常に定数いっぱいの更新をメイン・キャッシュ１００４にシリアル化解除しているからである。オーディオ・キャッシュのサイズは初期化時に与えられる入力パラメータ、たとえばmax_input_block_size、max_output_block_size〔最大出力ブロック・サイズ〕およびmax_objsパラメータによって影響される。メタデータ・キャッシュ・サイズは固定されているが、必要であれば、オブジェクト・オーディオ・レンダラー・インターフェース実装の内部でOARI_MAX_EVO_MDパラメータを変えることは可能である。

OARI_MAX_EVO_MD定義のための新たな値を選択するために、選ばれているmax_input_block_sizeパラメータが考慮される必要がある。OARI_MAX_EVO_MDパラメータは、oari_addsamples_evo関数への一回の呼び出しでオブジェクト・オーディオ・レンダラー・インターフェースに送られることのできるオブジェクト・オーディオ・メタデータ・ペイロードの数を表わす。サンプルの入力ブロックがより多くのオブジェクト・オーディオ・メタデータによってカバーされる場合、入力サイズは、オブジェクト・オーディオ・メタデータの許容される量に到達するよう、呼び出しコードによって減らされる必要がある。過剰なオーディオおよびオブジェクト・オーディオ・メタデータは将来の処理サイクルにおけるoari_addsamples_evoへの追加的な呼び出しによって処理される。繰り越された更新はオーディオ・キャッシュ１００４の繰り越されたPCM部分１００３に送られる。ある種の実装では、オブジェクト・オーディオ・メタデータの数についての理論的な最悪ケースはmax_input_block_size/40であり、より現実的な最悪ケースはmax_input_block_size/128である。oari_addsamples_evo関数を呼び出すときに変動するブロック・サイズを扱える呼び出しコードは、現実的な最悪ケースを選ぶべきである。一方、固定した入力ブロック・サイズに依拠するコードは理論的な最悪ケースを選ぶ必要がある。そのような実装では、OARI_MAX_ED_MDについてのデフォルト値は16である。

幅（時に「サイズ」と称される）のあるオブジェクトのレンダリングは一般に、そうでない場合よりも多くの処理パワーを必要とする。ある実施形態では、オブジェクト・オーディオ・レンダラー・インターフェースは、いくつかのまたはすべてのオブジェクトから幅を除去することができる。この機能は、max_width_objects〔最大幅オブジェクト〕パラメータのようなパラメータによって制御される。幅は、このカウントを超過しているオブジェクトから除去される。幅除去のために選択されるオブジェクトは、オブジェクト・オーディオ・メタデータにおいて優先度情報が指定されている場合には優先度の劣るものであり、あるいはより大きなオブジェクト・インデックスによる。

さらに、オブジェクト・オーディオ・レンダラー・インターフェースは、オブジェクト・オーディオ・レンダラーにおけるリミッターによって導入される処理レイテンシーを補償する。これは、b_compensate_latencyパラメータのようなパラメータ設定によって有効化または無効化されることができる。オブジェクト・オーディオ・レンダラー・インターフェースは、初期の無音を脱落させることによって、および末尾の0のフラッシュ（zero-flushing）によって補償する。

図９のステップ９０８に示されるように、OARIは処理ブロック・サイズ選択動作を実行する。処理ブロックは、0個以上の更新をもつサンプルのブロックである。更新なしでは、オブジェクト・オーディオ・レンダラーは、新しいオーディオ・データについて、前の更新のメタデータを使い続ける。上述したように、オブジェクト・オーディオ・レンダラーは、32,64,128,256,480,512,1024,1536および2048サンプルという限られた数のブロック・サイズをサポートするよう構成されていてもよいが、他のサイズも可能である。一般に、大きな処理ブロック・サイズほどCPU効率がよい。オブジェクト・オーディオ・レンダラーは、処理ブロックの先頭とメタデータの間のオフセットをサポートしないよう構成されてもよい。この場合、ブロック更新は処理ブロックの先頭または先頭付近でなければならない。一般に、ブロック更新は、最小出力ブロック・サイズ選択によって許容されるブロックの最初のサンプルに近く位置される。処理ブロック・サイズ選択の目的は、できるだけ大きな処理ブロック・サイズを選択し、ブロック更新が処理ブロックの最初のサンプルに位置されるようにすることである。この選択は、利用可能なオブジェクト・オーディオ・レンダラー・ブロック・サイズおよびブロック更新位置によって制約される。追加的な制約条件は、オブジェクト・オーディオ・レンダラー・インターフェース・パラメータ、たとえばmin_output_block_size〔最小出力ブロック・サイズ〕およびmax_output_block_sizeパラメータに由来する。キャッシュ・サイズおよび入力ブロック・サイズは、処理ブロック・サイズの選択における要因ではない。min_output_block_size個のサンプル内で二つ以上の更新が発生する場合には、最初の更新のみが保持され、追加的な更新があれば破棄される。ブロック更新が処理ブロックの最初のサンプルに位置していない場合には、メタデータの適用が早すぎるので、不正確な更新になる。最大可能な不正確さは、min_output_block_size−1のようなパラメータ値によって与えられる。いかなるブロック更新データもない初期のサンプルは無音出力を与える。ある数のサンプルにわたって更新データが受領されなければ、出力はやはりミュートされる。エラー・ケースが検出されるまでのサンプル数は初期化時にパラメータmax_lag_samples〔最大遅延サンプル〕によって与えられる。

図１１は、ある実施形態のもとでの、オブジェクト・オーディオ・レンダラー・インターフェースによるメタデータ更新の適用を示している。この例において、min_output_block_sizeは128サンプルに設定され、max_output_block_sizeは512サンプルに設定されている。したがって、128,256,480,512という四つの可能なブロック・サイズが処理のために利用可能である。図１１はオブジェクト・オーディオ・レンダラーに送るためのサンプルの正しいサイズを選択するプロセスを示している。一般に、適正なブロック・サイズを決定することは、ある条件を与えられて可能な最大ブロック・サイズをコールすることによって全体的な計算効率を最適化することに基づくある基準に基づく。第一の条件について、最小ブロック・サイズより近接している二つの更新があれば、第二の更新はブロック・サイズ決定の計算に先立って除去されるべきである。ブロック・サイズは：処理されるべきサンプルのブロックに単一の更新が適用され、該更新は処理されるべきブロックの最初のサンプルに可能な限り近い；ブロック・サイズは初期化の間に渡されたmin_output_block_sizeパラメータ値より小さくない必要がある；ブロック・サイズは初期化の間に渡されたmax_output_block_sizeパラメータ値より大きくない必要がある。

図１２は、ある実施形態のもとでの、オブジェクト・オーディオ・レンダラー・インターフェースによって実行される初期の処理サイクルの例を示している。描画１２００に示されるように、メタデータ更新は1ないし5の番号を付された円によって表わされている。処理サイクルは、オーディオ・キャッシュおよびメタデータ・キャッシュを埋めるoari_addsamples_evo関数１２０４へのコールをもって始まり、一連のoari_processレンダリング関数１２０６がそれに続く。こうして、関数１２０４へのコールの後、第一のoari_process関数にコールがなされ、この関数がオーディオの第一のブロックを更新0と一緒にオブジェクト・オーディオ・レンダラーに送る。ブロックおよび更新領域は図１２において斜線の領域として示されている。その後、サンプル・キャッシュを通じた進行が各関数コール１２０６で示される。最大出力ブロック・サイズがどのように実施されているかに注意されたい。すなわち、それぞれの斜線の領域のサイズはmax_output_block_size １２０２を超えない。図示した例では、更新２および３には、max_output_block_sizeパラメータによって許容されるより多くのオーディオ・データが関連付けられており、よって複数の処理ブロックとして送られる。第一の処理ブロックのみが更新メタデータをもつ。最後のチャンクは、max_output_block_sizeより小さいので、まだ処理されていない。処理ブロック選択は、処理ブロックを最大化するために次のラウンドにおける追加的なサンプルを待っているのである。oari_addsamples_evo関数へのその後のコールがなされ、新たな処理サイクルを開始する。図で見て取れるように、更新５はまだ追加されていないオーディオに適用される。

その後の処理サイクルでは、oari_addsamples_evo関数はまずすべての残っているオーディオをキャッシュの先頭に移し、残りの更新のオフセットを調整する。図１３は、図１２の例示的な処理サイクルに続く第二の処理サイクルを示している。次いで、oari_addsamples_evo関数は、キャッシュ内の繰り越しコンテンツ後に新たなオーディオおよびメタデータを加える。更新１の処理はmix_output_block_sizeパラメータの実施を示している。更新０の第二の処理ブロックはこのパラメータより小さく、よってこの最小サイズに一致するよう拡大される。結果として、処理ブロックは今や、このブロックのオーディオに沿って処理されなければならない更新１を含んでいる。更新１は処理ブロックの最初のサンプルに位置しているのではなく、オブジェクト・オーディオ・レンダラーがそれをそこで適用するので、メタデータは早く適用される。この結果、オーディオ・レンダリングの精度が低下する。

メタデータ・タイミングに関し、実施形態は、オブジェクト・オーディオ・レンダラー・インターフェースにおいてオブジェクト・オーディオ・レンダラーにメタデータを適用するときに正確なタイミングを維持するための機構を含む。一つのそのような機構は、内部データ構造におけるサンプル・オフセット・フィールドの使用を含む。図１４は、ある実施形態のもとでの、内部oari_md_update〔OARIメタデータ更新〕データ構造におけるオフセット・フィールドの計算において使われるフィールドを列挙する表（表１）を示している。

高めのサンプル・レートについては、示されているサンプル・オフセットのいくつかはスケーリングされる必要がある。後続のビット・フィールドの時間スケールはオーディオ・サンプル・レートに基づく：
Timestamp〔タイムスタンプ〕
oa_sample_offset〔OAサンプル・オフセット〕
block_offset_factor〔ブロック・オフセット因子〕
oa_sample_offsetビット・フィールドは、oa_sample_offset_type〔OAサンプル・オフセット型〕、oa_sample_offset_code〔OAサンプル・オフセット・コード〕およびoa_sample_offset〔OAサンプル・オフセット〕フィールドの組み合わせによって与えられる。これらのビット・フィールドの値は、次の表２に列挙されるようにオーディオ・サンプリング周波数に依存するスケール因子によってスケーリングされる必要がある。

たとえば、96kHzビットストリームの発展フレームワーク・ペイロードが2000個のサンプルのペイロード・オフセットをもつ場合、この値はスケール因子2によってスケーリングされる必要があり、発展フレームワーク・ペイロードにおけるタイムスタンプは1000個のサンプルを示さなければならない。オブジェクト・オーディオ・メタデータ・ペイロードはオーディオ・サンプリング・レートの知識をもたないので、48kHzの時間スケール・ベースを想定する。これはスケール因子1をもつ。オブジェクト・オーディオ・メタデータ内で傾斜〔ランプ〕継続時間値（ramp_duration_code〔傾斜継続時間コード〕、use_ramp_table〔傾斜テーブル使用〕、ramp_duration_table〔傾斜継続時間テーブル〕およびramp_duration〔傾斜継続時間〕フィールドの組み合わせによって与えられる）も48kHzの時間スケール・ベースを使うことを注意しておくことが重要である。ramp_duration値は関連するオーディオのサンプリング周波数に従ってスケーリングされる必要がある。

ひとたびスケーリング動作が実行されたら、最終的なサンプル・オフセット計算がなされてもよい。ある実施形態では、オフセット値の全体的な計算のための式が次のプログラム・ルーチンによって与えられる。
/* Nはオブジェクト・オーディオ・メタデータ・ペイロードにおけるメタデータ・ブロックの数を表わし、[1,8]の範囲内になければならない。 */
for (i=0; i<N; i++) {
metadata_update_buffer[i].offset＝sample_offset＋(timestamp*fs_scale_factor)＋
(oa_sample_offset*fs_scale_factor)＋(32*block_offset_factor[i]*fs_scale_factor);
}
。

オブジェクト・オーディオ・レンダラー・インターフェースは、オーディオの処理ブロック・サイズを、メタデータ更新のタイミングおよび整列ならびに最大／最小処理ブロック・サイズ定義および他の可能な要因に基づいて動的に調整する。これは、メタデータ更新が、メタデータが適用されることが意図されているオーディオ・ブロックに関して最適に適用されることを許容する。こうして、メタデータは、複数のオブジェクトのレンダリングと、データ・ブロック境界に関して非一様に更新するオブジェクトを折り合わせる仕方で、かつシステム・プロセッサがプロセッサ・サイクルに関して効率的に機能できるようにする仕方で、オーディオ・エッセンスと対にされることができる。

実施形態はドルビー・デジタル・プラス、MAT2.0およびトゥルーHDのような一つまたは複数の特定のコーデックにおける実装に関して記述され、図示されているが、任意のコーデックまたはデコーダ・フォーマットが使用されうることは注意しておくべきである。

本稿に記述されるオーディオ環境の諸側面は、適切なスピーカーおよび再生装置を通じたオーディオまたはオーディオ／ビジュアル・コンテンツの再生を表わし、聴取者が捕捉されたコンテンツの再生を経験している任意の環境、たとえば映画館、コンサートホール、屋外シアター、家庭または部屋、聴取ブース、自動車、ゲーム・コンソール、ヘッドフォンまたはヘッドセット・システム、公衆アナウンス（PA: public address）システムまたは他の任意の再生環境を表わしうる。実施形態は主として、空間的オーディオ・コンテンツがテレビジョン・コンテンツに関連付けられているホームシアター環境における例および実装に関して記述されてきたが、実施形態は、ゲーム、スクリーニング・システムおよび他の任意のモニター・ベースのA/Vシステムといった他の消費者ベースのシステムにおいて実装されてもよいことを注意しておくべきである。オブジェクト・ベースのオーディオおよびチャネル・ベースのオーディオを含む空間的オーディオ・コンテンツは、いかなる関係するコンテンツ（関連付けられたオーディオ、ビデオ、グラフィックなど）との関連で使われてもよく、単独のオーディオ・コンテンツをなしていてもよい。再生環境は、ヘッドフォンまたはニア・フィールド・モニターから大小の部屋、自動車、屋外アリーナ、コンサートホールなどまでのいかなる適切な聴取環境であってもよい。

本稿に記載されるシステムの諸側面は、デジタルまたはデジタイズされたオーディオ・ファイルを処理するための適切なコンピュータ・ベースの音処理ネットワーク環境において実装されてもよい。適応オーディオ・システムの諸部分は、コンピュータ間で伝送されるデータをバッファリングおよびルーティングするはたらきをする一つまたは複数のルーター（図示せず）を含め、任意の所望される数の個々の機械を含む一つまたは複数のネットワークを含んでいてもよい。そのようなネットワークは、さまざまな異なるネットワーク・プロトコル上で構築されてもよく、インターネット、広域ネットワーク（WAN）、ローカル・エリア・ネットワーク（LAN）またはその任意の組み合わせであってもよい。ネットワークがインターネットを含む実施形態では、一つまたは複数の機会がウェブ・ブラウザー・プログラムを通じてインターネットにアクセスするよう構成されてもよい。

上記のコンポーネント、ブロック、プロセスまたは他の機能構成要素の一つまたは複数は、システムのプロセッサ・ベースのコンピューティング装置の実行を制御するコンピュータ・プログラムを通じて実装されてもよい。本稿に開示されるさまざまな機能は、ハードウェア、ファームウェアのいくつもある組み合わせを使っておよび／またはさまざまな機械可読もしくはコンピュータ可読媒体において具現されたデータおよび／または命令として、挙動上の、レジスタ転送、論理コンポーネントおよび／または他の特性を用いて記載されることがあることを注意しておくべきである。そのようなフォーマットされたデータおよび／または命令が具現されうるコンピュータ可読媒体は、光学式、磁気式もしくは半導体記憶媒体のようなさまざまな形の物理的（非一時的）、不揮発性記憶媒体を含むがそれに限定されない。

文脈がそうでないことを明確に要求するのでないかぎり、本記述および請求項を通じて、単語「有する」「含む」などは、排他的もしくは網羅的な意味ではなく包含的な意味に解釈されるものとする。すなわち、「……を含むがそれに限定されない」の意味である。単数または複数を使った単語は、それぞれ複数または単数をも含む。さらに、「本稿で」「以下で」「上記で」「下記で」および類似の意味の単語は、全体としての本願を指すのであって、本願のいかなる特定の部分を指すものでもない。単語「または」が二つ以上の項目のリストを参照して使われるとき、その単語は該単語の以下の解釈のすべてをカバーする：リスト中の項目の任意のもの、リスト中の項目のすべておよびリスト中の項目の任意の組み合わせ。

本明細書を通じて「一つの実施形態」「いくつかの実施形態」または「ある実施形態」への言及は、その実施形態との関連で記述されている特定の特徴、構造または特性が開示されるシステムおよび方法の少なくとも一つの実施形態に含まれることを意味する。よって、本稿を通じた随所に「一つの実施形態では」「いくつかの実施形態では」または「ある実施形態では」という句が現われるのは、同じ実施形態を指すこともあれば、必ずしもそうでないこともある。さらに、具体的な特徴、構造または特性は、当業者には明白であろう任意の好適な仕方で組み合わされてもよい。

一つまたは複数の実装が、例として、個別的な実施形態を用いて記載されているが、一つまたは複数の実装は開示される実施形態に限定されないことは理解されるものとする。逆に、当業者に明白であろうさまざまな修正および類似の構成をカバーすることが意図されている。したがって、付属の請求項の範囲は、そのようなすべての修正および類似の構成を包含するような最も広い解釈を与えられるべきである。
いくつかの態様を記載しておく。
〔態様１〕
適応オーディオ・コンテンツを処理する方法であって：
複数のオーディオ・セグメントを含む適応オーディオ・ビットストリームの各オーディオ・セグメントについてチャネル・ベースのオーディオおよびオブジェクト・ベースのオーディオのうちの一方としてオーディオ型を判別する段階と；
対応するオーディオ・セグメントのオーディオ型を示すメタデータ定義をもって前記各オーディオ・セグメントにタグ付けする段階と；
チャネル・ベースのオーディオとしてタグ付けされたオーディオ・セグメントをチャネル・オーディオ・レンダラー・コンポーネントにおいて処理する段階と；
オブジェクト・ベースのオーディオとしてタグ付けされたオーディオ・セグメントを前記チャネル・オーディオ・レンダラー・コンポーネントとは異なるオブジェクト・オーディオ・レンダラー・コンポーネントにおいて処理する段階とを含む、
方法。
〔態様２〕
前記メタデータ定義を、各オーディオ・セグメントに関連付けられたメタデータ・ペイロードの一部としてエンコードされたオーディオ型メタデータ要素としてエンコードすることをさらに含む、態様１記載の方法。
〔態様３〕
前記メタデータ定義は、デコーダ・コンポーネントによって設定され、前記チャネル・オーディオ・レンダラー・コンポーネントおよびオブジェクト・オーディオ・レンダラー・コンポーネントに伝送される二値のフラグ値を含む、態様１または２記載の方法。
〔態様４〕
二値のフラグ値は、前記チャネル・オーディオ・レンダラー・コンポーネントおよびオブジェクト・オーディオ・レンダラー・コンポーネントによって、受領された各オーディオ・セグメントについてデコードされ、該オーディオ・セグメント内のオーディオ・データは、デコードされた二値のフラグ値に基づいて、前記チャネル・オーディオ・レンダラー・コンポーネントおよびオブジェクト・オーディオ・レンダラー・コンポーネントの一方によってレンダリングされる、態様３記載の方法。
〔態様５〕
前記チャネル・ベースのオーディオは、レガシーのサラウンドサウンドのオーディオを含み、前記チャネル・オーディオ・レンダラー・コンポーネントはアップミキサーを含み、前記オブジェクト・オーディオ・レンダラー・コンポーネントはオブジェクト・オーディオ・レンダラー・インターフェースを有する、態様１ないし４のうちいずれか一項記載の方法。
〔態様６〕
任意の二つの相続くオーディオ・セグメントの間の伝送および処理レイテンシーについて、初期化フェーズの間に既知のレイテンシー差について事前補償することによって調整することを含む、態様１ないし５のうちいずれか一項記載の方法。
〔態様７〕
適応オーディオをレンダリングする方法であって：
オーディオ・ビットストリームにおいてエンコードされたチャネル・ベースのオーディオおよびオブジェクト・ベースのオーディオのセグメントを含む入力オーディオをデコーダにおいて受領する段階と；
該デコーダにおいてチャネル・ベースのオーディオとオブジェクト・ベースのオーディオのセグメントとの間の型の変化を検出する段階と；
型の変化の検出に際してオーディオ・セグメントの各型についてメタデータ定義を生成し；
該メタデータ定義を適切なオーディオ・セグメントと関連付ける段階と；
各オーディオ・セグメントを、関連付けられたメタデータ定義に依存して、適切なポストデコーダ処理コンポーネントにおいて処理する段階とを含む、
方法。
〔態様８〕
前記チャネル・ベースのオーディオは、適応オーディオ・レンダリング・システムのアップミキサーを通じてレンダリングされるべきレガシーのサラウンドサウンド・オーディオを含み、さらに、前記オブジェクト・ベースのオーディオは前記適応オーディオ・レンダリング・システムのオブジェクト・オーディオ・レンダラー・インターフェースを通じてレンダリングされる、態様７記載の方法。
〔態様９〕
任意の二つの相続くオーディオ・セグメントの間の伝送および処理レイテンシーについて、初期化フェーズの間に既知のレイテンシー差について事前補償することによって調整することを含む、態様７または８記載の方法。
〔態様１０〕
前記メタデータ定義は、前記デコーダによって、前記オーディオ・ビットストリームに関連付けられたメタデータ・ペイロードの一部としてエンコードされるオーディオ型フラグを含む、態様７ないし９のうちいずれか一項記載の方法。
〔態様１１〕
前記フラグの第一の状態は関連付けられたオーディオ・セグメントがチャネル・ベースのオーディオであることを示し、前記フラグの第二の状態は関連付けられたオーディオ・セグメントがオブジェクト・ベースのオーディオであることを示す、態様１０記載の方法。
〔態様１２〕
適応オーディオをレンダリングするシステムであって：
オーディオ・コンテンツおよび関連するメタデータを有するビットストリームにおいて入力オーディオを受領するデコーダであって、前記オーディオ・コンテンツは、任意の一つの時点においては、チャネル・ベースのオーディオまたはオブジェクト・ベースの型のオーディオのうちの一方を有するオーディオ型をもつ、デコーダと；
前記チャネル・ベースのオーディオを処理するための前記デコーダに結合されたアップミキサーと；
オブジェクト・オーディオ・レンダラーを通じて前記オブジェクト・ベースのオーディオをレンダリングするための、前記アップミキサーと並列に前記デコーダに結合されたオブジェクト・オーディオ・レンダラー・インターフェースと；
チャネル・ベースのオーディオを第一のメタデータ定義でタグ付けし、オブジェクト・ベースのオーディオを第二のメタデータ定義でタグ付けするよう構成された、前記デコーダ内のメタデータ要素生成器とを有する、
システム。
〔態様１３〕
前記アップミキサーはタグ付けされたチャネル・ベースのオーディオおよびタグ付けされたオブジェクト・ベースのオーディオの両方を前記デコーダから受領し、前記チャネル・ベースのオーディオのみを処理する、態様１２記載のシステム。
〔態様１４〕
前記オブジェクト・オーディオ・レンダラー・インターフェースはタグ付けされたチャネル・ベースのオーディオおよびタグ付けされたオブジェクト・ベースのオーディオの両方を前記デコーダから受領し、前記オブジェクト・ベースのオーディオのみを処理する、態様１２または１３記載のシステム。
〔態様１５〕
前記メタデータ要素生成器は、前記デコーダから前記アップミキサーおよび前記オブジェクト・オーディオ・レンダラー・インターフェースに伝送されるオーディオ・セグメントの型を示す二値フラグを設定し、前記二値フラグは、前記デコーダによって、前記ビットストリームに関連付けられたメタデータ・ペイロードの一部としてエンコードされる、態様１２ないし１４のうちいずれか一項記載のシステム。
〔態様１６〕
前記チャネル・ベースのオーディオはサラウンドサウンド・オーディオ・ベッドを含み、前記オーディオ・オブジェクトはオブジェクト・オーディオ・メタデータ（OAMD）フォーマットに整合するオブジェクトを含む、態様１２ないし１５のうちいずれか一項記載のシステム。
〔態様１７〕
任意の二つの相続くオーディオ・セグメントの間の伝送および処理レイテンシーについて、初期化フェーズの間に既知のレイテンシー差について事前補償して、前記相続くオーディオ・セグメントについて前記アップミキサーおよびオブジェクト・オーディオ・レンダラー・インターフェースを通る異なる信号経路の時間整列された出力を提供することによって、調整するよう構成されたレイテンシー・マネージャをさらに有する、態様１２ないし１６のうちいずれか一項記載のシステム。
〔態様１８〕
オブジェクト・ベースのオーディオを処理する方法であって：
オーディオ・サンプルのブロックおよび一つまたは複数の関連するオブジェクト・オーディオ・メタデータ・ペイロードを、オブジェクト・オーディオ・レンダラー・インターフェース（OARI）において受領し；
各オブジェクト・オーディオ・メタデータ・ペイロードからの一つまたは複数のオーディオ・ブロック更新をシリアル化解除し；
前記オーディオ・サンプルおよび前記オーディオ・ブロック更新をそれぞれのオーディオ・サンプルおよびオーディオ・ブロック更新メモリ・キャッシュに記憶し；
前記オーディオ・サンプルの処理ブロック・サイズを、処理ブロック境界に対するオーディオ・ブロック更新のタイミングおよび整列ならびに最大／最小処理ブロック・サイズ・パラメータを含む一つまたは複数の他のパラメータに基づいて動的に選択することを含む、
方法。
〔態様１９〕
前記オブジェクト・ベースのオーディオを、前記動的な選択段階によって決定されたサイズの処理ブロックで、前記OARIから前記OARに伝送することをさらに含む、態様１８記載の方法。
〔態様２０〕
各メタデータ要素はメタデータ・フレームにおいて渡され、サンプル・オフセットが、オーディオ・ブロック中のどのサンプルにおいて当該フレームが適用されるかを示す、態様１８または１９記載の方法。
〔態様２１〕
オブジェクト優先順位付け、幅除去、無効化されたオブジェクトの扱い、過度に頻繁な更新のフィルタリング、所望される範囲への空間位置クリッピングおよび更新データの所望されるフォーマットへの変換を含む一つまたは複数のプロセスを通じて前記メタデータ要素を含む前記メタデータを準備することをさらに含む、態様１８ないし２０のうちいずれか一項記載の方法。
〔態様２２〕
前記OARは限られた数の処理ブロック・サイズをサポートする、態様１９記載の方法。
〔態様２３〕
前記処理ブロック・サイズが、長さ32,64,128,256,480,512,1024,1536および2048サンプルからなる群から選択される、態様２２記載の方法。
〔態様２４〕
処理ブロック・サイズの選択は、前記オーディオ・ブロック更新が、処理ブロック・サイズ選択パラメータによって許容される限り当該処理ブロックの最初のサンプルの近くに位置されるようになされる、態様１９記載の方法。
〔態様２５〕
前記処理ブロック・サイズは、オーディオ・ブロック更新位置、OAR処理ブロック・サイズおよびOARI最大および最小ブロック・サイズ・パラメータ値によって制約されて可能な限り大きいように選択される、態様２４記載の方法。
〔態様２６〕
前記メタデータ・フレームがオーディオ・サンプルのブロックにおいて一つまたは複数のオブジェクトのレンダリングに関する属性を定義するメタデータを含み、それらの属性は、ダイアログ、音楽、効果、効果音、背景音および周囲音定義を含むコンテンツ型属性；3D位置、オブジェクト・サイズおよびオブジェクト速度を含む空間的属性；およびスピーカー位置にスナップ、チャネル重み、利得、傾斜およびベース管理情報を含むスピーカー・レンダリング属性からなる群から選択される、態様１８ないし２５のうちいずれか一項記載の方法。
〔態様２７〕
オーディオ・オブジェクトを処理する方法であって：
オーディオ・サンプルのブロックおよび該オーディオ・サンプルがオブジェクト・オーディオ・レンダラー（OAR）においてどのようにレンダリングされるかを定義する関連するメタデータを、オブジェクト・オーディオ・レンダラー・インターフェース（OARI）において受領する段階であって、前記メタデータは、前記オーディオ・オブジェクトの異なるレンダリング属性を定義するよう時間とともに更新される、段階と；
前記オーディオ・サンプルおよびメタデータ更新を、前記OARによって処理されるよう、諸処理ブロックの配置においてバッファリングする段階と；
処理ブロック・サイズを、ブロック境界に対するメタデータ更新のタイミングおよび整列ならびに最大／最小処理ブロック・サイズ・パラメータを含む一つまたは複数の他のパラメータに基づいて動的に選択する段階と；
前記オブジェクト・ベースのオーディオを、前記動的な選択の段階によって決定されたサイズのブロックで、前記OARIから前記OARに伝送する段階とを含む、
方法。
〔態様２８〕
各ブロックについての前記オーディオ・データおよびブロック更新をそれぞれのオーディオ・キャッシュおよび更新メモリ・キャッシュに記憶することを含み、前記ブロック更新は、オブジェクト・オーディオ・メタデータ・ペイロードに格納されるメタデータ要素においてエンコードされる、態様２７記載の方法。
〔態様２９〕
各メタデータ要素はメタデータ・フレームにおいて渡され、サンプル・オフセットが、処理ブロック中のどのサンプルにおいて当該フレームが適用されるかを示す、態様２８記載の方法。
〔態様３０〕
ブロック・サイズの選択は、前記ブロック更新が、ブロック・サイズ選択パラメータによって許容される限り当該ブロックの最初のサンプルの近くに位置されるようになされる、態様２７ないし２９のうちいずれか一項記載の方法。
〔態様３１〕
前記ブロック・サイズは、ブロック更新位置、OARブロック・サイズおよびOARI最大および最小ブロック・サイズ・パラメータ値によって制約されて可能な限り大きいように選択される、態様３０記載の方法。
〔態様３２〕
オブジェクト優先順位付け、幅除去、無効化されたオブジェクトの扱い、過度に頻繁な更新のフィルタリング、所望される範囲への空間位置クリッピングおよび更新データの所望されるフォーマットへの変換を含む一つまたは複数のプロセスを通じて前記メタデータ要素を含む前記メタデータを準備することを含む、態様２７ないし３１のうちいずれか一項記載の方法。
〔態様３３〕
適応オーディオ・データを処理する方法であって：
処理されるべきオーディオがチャネル・ベースのオーディオかオブジェクト・ベースのオーディオかを、定義されたメタデータ定義を通じて判定し；
チャネル・ベースであれば前記オーディオをチャネル・ベース・オーディオ・レンダラー（CAR）を通じて処理し；
オブジェクト・ベースであれば前記オーディオをオブジェクト・ベース・オーディオ・レンダラー（OAR）を通じて処理することを含み、
前記OARは、前記オーディオの処理ブロック・サイズを、メタデータ更新のタイミングおよび整列ならびに最大および最小ブロック・サイズを含む一つまたは複数の他のパラメータに基づいて動的に調整するOARインターフェース（OARI）を利用する、
方法。
〔態様３４〕
チャネル・ベースまたはオブジェクト・ベースのオーディオ・レンダリングの間で切り換える方法であって：
メタデータ要素を、関連付けられたオーディオ・ブロックについて、チャネル・ベースのオーディオ・コンテンツを示す第一の状態またはオブジェクト・ベースのオーディオ・コンテンツを示す第二の状態をもつようエンコードし；
前記メタデータ要素を複数のオーディオ・ブロックを含むオーディオ・ビットストリームの一部としてデコーダに伝送し；
各オーディオ・ブロックについて前記メタデータ要素を前記デコーダにおいてデコードして、前記メタデータ要素が前記第一の状態であればチャネル・ベースのオーディオ・コンテンツをチャネル・オーディオ・レンダラー（CAR）に、前記メタデータ要素が前記第二の状態であればオブジェクト・ベースのオーディオ・コンテンツをオブジェクト・オーディオ・レンダラー（OAR）にルーティングすることを含む、
方法。
〔態様３５〕
前記メタデータ要素は、前記デコーダに伝送されるパルス符号変調された（PCM）オーディオ・ビットストリームを用いて帯域内で伝送されるメタデータ・フラグを有する、態様３４記載の方法。
〔態様３６〕
前記CARは、アップミキサーまたはチャネル・ベースのオーディオの入力チャネルを出力スピーカーにマッピングする素通しノードの一方を含む、態様３４または３５記載の方法。
〔態様３７〕
前記OARは、前記オーディオの処理ブロック・サイズを、メタデータ更新のタイミングおよび整列ならびに最大および最小ブロック・サイズを含む一つまたは複数の他のパラメータに基づいて動的に調整するOARインターフェース（OARI）を利用するレンダラーを含む、態様３４ないし３６のうちいずれか一項記載の方法。

Claims (18)

1. 適応オーディオ・コンテンツを処理する方法であって：
   複数のオーディオ・セグメントを含む適応オーディオ・ビットストリームの各オーディオ・セグメントについてチャネル・ベースのオーディオおよびオブジェクト・ベースのオーディオのうちの一方としてオーディオ型を判別する段階と；
   対応するオーディオ・セグメントのオーディオ型を示すメタデータ定義をもって前記各オーディオ・セグメントにタグ付けする段階と；
   チャネル・ベースのオーディオとしてタグ付けされたオーディオ・セグメントをチャネル・オーディオ・レンダラー・コンポーネントにおいて処理する段階と；
   オブジェクト・ベースのオーディオとしてタグ付けされたオーディオ・セグメントを前記チャネル・オーディオ・レンダラー・コンポーネントとは異なるオブジェクト・オーディオ・レンダラー・コンポーネントにおいて処理する段階とを含み、
   前記チャネル・オーディオ・レンダラー・コンポーネントおよび前記オブジェクト・オーディオ・レンダラー・コンポーネントは0でない異なるレイテンシーをもち、それらのレンダラー・コンポーネントの両方は、それらの最初の初期化に際して、サンプル単位でのそれぞれのレイテンシーについて問い合わせされ、
   前記チャネル・オーディオ・レンダラー・コンポーネントおよび前記オブジェクト・オーディオ・レンダラー・コンポーネントの前記サンプル単位でのそれぞれのレイテンシーは、オブジェクト・ベースのオーディオ・セグメントおよびチャネル・ベースのオーディオ・セグメントの処理の間で切り換えるときにレイテンシーを管理するために使用されるためのものである、
   方法。
2. 前記メタデータ定義を、各オーディオ・セグメントに関連付けられたメタデータ・ペイロードの一部としてエンコードされたオーディオ型メタデータ要素としてエンコードすることをさらに含む、請求項１記載の方法。
3. 前記メタデータ定義は、デコーダ・コンポーネントによって設定され、前記チャネル・オーディオ・レンダラー・コンポーネントおよびオブジェクト・オーディオ・レンダラー・コンポーネントに伝送される二値のフラグ値を含む、請求項１または２記載の方法。
4. 前記二値のフラグ値は、前記チャネル・オーディオ・レンダラー・コンポーネントおよびオブジェクト・オーディオ・レンダラー・コンポーネントによって、受領された各オーディオ・セグメントについてデコードされ、該オーディオ・セグメント内のオーディオ・データは、デコードされた二値のフラグ値に基づいて、前記チャネル・オーディオ・レンダラー・コンポーネントおよびオブジェクト・オーディオ・レンダラー・コンポーネントの一方によってレンダリングされる、請求項３記載の方法。
5. 前記チャネル・ベースのオーディオは、サラウンドサウンドのオーディオを含み、前記チャネル・オーディオ・レンダラー・コンポーネントはアップミキサーを含み、前記オブジェクト・オーディオ・レンダラー・コンポーネントはオブジェクト・オーディオ・レンダラー・インターフェースを有する、請求項１ないし４のうちいずれか一項記載の方法。
6. 適応オーディオをレンダリングする方法であって：
   オーディオ・ビットストリームにおいてエンコードされたチャネル・ベースのオーディオおよびオブジェクト・ベースのオーディオのセグメントを含む入力オーディオをデコーダにおいて受領する段階と；
   該デコーダにおいてチャネル・ベースのオーディオとオブジェクト・ベースのオーディオのセグメントとの間の型の変化を検出する段階と；
   型の変化の検出に際してオーディオ・セグメントの各型についてメタデータ定義を生成し；
   該メタデータ定義を適切なオーディオ・セグメントと関連付ける段階と；
   各オーディオ・セグメントを、関連付けられたメタデータ定義に依存して、適切なポストデコーダ処理コンポーネントにおいて処理する段階とを含み、
   各ポストデコーダ処理コンポーネントはそれぞれの他のポストデコーダ処理コンポーネントのレイテンシーとは異なる0でないレイテンシーをもち、それらのポストデコーダ処理コンポーネントは、それらの最初の初期化に際して、サンプル単位でのそれぞれのレイテンシーについて問い合わせされ、
   前記ポストデコーダ処理コンポーネントの前記サンプル単位でのそれぞれのレイテンシーは、オブジェクト・ベースのオーディオ・セグメントおよびチャネル・ベースのオーディオ・セグメントの処理の間で切り換えるときにレイテンシーを管理するために使用されるためのものである、
   方法。
7. 前記チャネル・ベースのオーディオは、適応オーディオ・レンダリング・システムのアップミキサーを通じてレンダリングされるべきレガシーのサラウンドサウンド・オーディオを含み、さらに、前記オブジェクト・ベースのオーディオは前記適応オーディオ・レンダリング・システムのオブジェクト・オーディオ・レンダラー・インターフェースを通じてレンダリングされる、請求項６記載の方法。
8. 前記メタデータ定義は、前記デコーダによって、前記オーディオ・ビットストリームに関連付けられたメタデータ・ペイロードの一部としてエンコードされるオーディオ型フラグを含む、請求項６または７記載の方法。
9. 前記フラグの第一の状態は関連付けられたオーディオ・セグメントがチャネル・ベースのオーディオであることを示し、前記フラグの第二の状態は関連付けられたオーディオ・セグメントがオブジェクト・ベースのオーディオであることを示す、請求項８記載の方法。
10. 適応オーディオをレンダリングするシステムであって：
    オーディオ・コンテンツおよび関連するメタデータを有するビットストリームにおいて入力オーディオを受領するデコーダであって、前記オーディオ・コンテンツは、任意の一つの時点においては、チャネル・ベースのオーディオまたはオブジェクト・ベースの型のオーディオのうちの一方を有するオーディオ型をもつ、デコーダと；
    前記チャネル・ベースのオーディオを処理するための前記デコーダに結合されたアップミキサーと；
    オブジェクト・オーディオ・レンダラーを通じて前記オブジェクト・ベースのオーディオをレンダリングするための、前記アップミキサーと並列に前記デコーダに結合されたオブジェクト・オーディオ・レンダラー・インターフェースと；
    チャネル・ベースのオーディオを第一のメタデータ定義でタグ付けし、オブジェクト・ベースのオーディオを第二のメタデータ定義でタグ付けするよう構成された、前記デコーダ内のメタデータ要素生成器と；
    任意の二つの相続くオーディオ・セグメントの間の伝送および処理レイテンシーについて、初期化フェーズの間に既知のレイテンシー差について事前補償して、前記相続くオーディオ・セグメントについて前記アップミキサーおよびオブジェクト・オーディオ・レンダラー・インターフェースを通る異なる信号経路の時間整列された出力を提供することによって、調整するよう構成されたレイテンシー・マネージャとを有し、
    前記アップミキサーおよび前記オブジェクト・オーディオ・レンダラーの両者は0でない異なるレイテンシーをもち、前記アップミキサーおよび前記オブジェクト・オーディオ・レンダラーはそれらの最初の初期化に際して、サンプル単位でのそれらのレイテンシーについて問い合わせされる、システム。
11. 前記アップミキサーはタグ付けされたチャネル・ベースのオーディオおよびタグ付けされたオブジェクト・ベースのオーディオの両方を前記デコーダから受領し、前記チャネル・ベースのオーディオのみを処理する、請求項１０記載のシステム。
12. 前記オブジェクト・オーディオ・レンダラー・インターフェースはタグ付けされたチャネル・ベースのオーディオおよびタグ付けされたオブジェクト・ベースのオーディオの両方を前記デコーダから受領し、前記オブジェクト・ベースのオーディオのみを処理する、請求項１０または１１記載のシステム。
13. 前記メタデータ要素生成器は、前記デコーダから前記アップミキサーおよび前記オブジェクト・オーディオ・レンダラー・インターフェースに伝送されるオーディオ・セグメントの型を示す二値フラグを設定し、前記二値フラグは、前記デコーダによって、前記ビットストリームに関連付けられたメタデータ・ペイロードの一部としてエンコードされる、請求項１０ないし１２のうちいずれか一項記載のシステム。
14. 前記チャネル・ベースのオーディオはサラウンドサウンド・オーディオ・ベッドを含み、前記オブジェクト・ベースのオーディオはオブジェクト・オーディオ・メタデータ（OAMD）フォーマットに整合するオブジェクトを含む、請求項１０ないし１３のうちいずれか一項記載のシステム。
15. チャネル・ベースまたはオブジェクト・ベースのオーディオ・レンダリングの間で切り換える方法であって：
    メタデータ要素を、関連付けられたオーディオ・ブロックについて、チャネル・ベースのオーディオ・コンテンツを示す第一の状態またはオブジェクト・ベースのオーディオ・コンテンツを示す第二の状態をもつようエンコードし；
    前記メタデータ要素を複数のオーディオ・ブロックを含むオーディオ・ビットストリームの一部としてデコーダに伝送し；
    各オーディオ・ブロックについて前記メタデータ要素を前記デコーダにおいてデコードして、前記メタデータ要素が前記第一の状態であればチャネル・ベースのオーディオ・コンテンツをチャネル・オーディオ・レンダラー（CAR）に、前記メタデータ要素が前記第二の状態であればオブジェクト・ベースのオーディオ・コンテンツをオブジェクト・オーディオ・レンダラー（OAR）にルーティングすることを含み、
    前記チャネル・オーディオ・レンダラーおよび前記オブジェクト・オーディオ・レンダラーの両者は0でない異なるレイテンシーをもち、前記チャネル・オーディオ・レンダラーおよび前記オブジェクト・オーディオ・レンダラーは、それらの最初の初期化に際して、サンプル単位でのそれぞれのレイテンシーについて問い合わせされ、
    前記チャネル・オーディオ・レンダラー・コンポーネントおよび前記オブジェクト・オーディオ・レンダラー・コンポーネントの前記サンプル単位でのそれぞれのレイテンシーは、オブジェクト・ベースのオーディオ・セグメントおよびチャネル・ベースのオーディオ・セグメントの処理の間で切り換えるときにレイテンシーを管理するために使用されるためのものである、
    方法。
16. 前記メタデータ要素は、前記デコーダに伝送されるパルス符号変調された（PCM）オーディオ・ビットストリームを用いて帯域内で伝送されるメタデータ・フラグを有する、請求項１５記載の方法。
17. 前記CARは、アップミキサーまたはチャネル・ベースのオーディオの入力チャネルを出力スピーカーにマッピングする素通しノードの一方を含む、請求項１５または１６記載の方法。
18. 前記OARは、前記オーディオの処理ブロック・サイズを、メタデータ更新のタイミングおよび整列ならびに最大および最小ブロック・サイズを含む一つまたは複数の他のパラメータに基づいて動的に調整するOARインターフェース（OARI）を利用するレンダラーを含む、請求項１５ないし１７のうちいずれか一項記載の方法。

Images