波形エディターは通るのに QC で落ちる、イマーシブ・マスターの話

イマーシブの納品物は、波形エディターで開いて 12 本や 16 本の健全そうなトラックが並び、まともに再生できても、なお却下されることがあります。理由は構造的なものです。BW64 ファイルではオーディオとメタデータは別々の存在であり、両者は厳密に一致していなければならないのに、フォーマット自体はそれを強制しません。レンダラーは参照を解決します。エディターはサンプルを描画します。仕事が違うのです。だからこそ ADM の QC は、耳で聴く作業ではなく、参照の整合性を検査する作業になります。以下では、二つの規格が何を定めているのか、参照はどこで壊れるのか、そしてどの検査がどの不具合を捕まえるのかを見ていきます。

三種類のオーディオと、その区別がすべてを決める理由

イマーシブ納品のトラブルは、ほぼすべて、あるトラックが三つのうちどれなのかという混同から始まります。

チャンネルベース・オーディオ は、各トラックを固定されたスピーカー位置に割り当てます。ステレオはチャンネルベースであり、5.1 もそうですし、7.1.4 のベッドもそうです。位置はチャンネルの同一性そのものに焼き込まれています。トラック 3 はセンタースピーカーであり、それを再生するどのシステムでもセンタースピーカーです。ITU-R BS.2051 はこれを先進音響システム向けに定式化し、レイアウトを Upper + Middle + Bottom の各レイヤーのチャンネル数として記述します。System A は 0+2+0（ステレオ）、System B は 0+5+0（5.1）、System D は 4+5+0、System J は 4+7+0、System H は 9+10+3、すなわち 22.2 構成です。ADM ではこれが DirectSpeakers の typeDefinition、typeLabel 0001 にあたります。

オブジェクトベース・オーディオ は、モノ（またはマルチチャンネルのパック）信号に、時間とともに変化する位置メタデータを添えて運びます。実際にどのスピーカーで再生するかは、その部屋に存在するレイアウトをもとにレンダラーが決めます。トラックの側はスピーカーを何も前提しません。これが typeDefinition Objects、typeLabel 0003 です。

シーンベース・オーディオ、実務上は高次アンビソニックスは、音場全体を球面調和成分として符号化します。どの成分も単独では方向に対応せず、方向は線形結合から立ち上がります。これが HOA、typeLabel 0004 です。ADM はさらに、ミッドサイドや Lt/Rt のようなマトリクス信号のための Matrix（0002）と、Binaural（0005）も定義しています。

この区別は分類学の話ではありません。チャンネルベースの納品物は、裸の WAV になっても生き延びられる程度には自己記述的です。チャンネル順さえ合っていれば鳴ります。オブジェクトベースやシーンベースの納品物は、メタデータなしでは無意味です。オーディオは区別のつかないモノ信号の山にすぎず、そうではないと言えるのは ADM だけだからです。この非対称性こそ、BW64 と ADM が存在する理由です。

BW64 は 32 ビットの数のせいで存在する

従来の WAV は RIFF ファイルです。1991 年に生まれた RIFF は、すべてのチャンクの先頭に 32 ビットのサイズフィールドを置きます。32 ビットで表せるのは 4,294,967,296 バイト — 4 GB — であり、これがファイル全体にも内部の data チャンクにも掛かる絶対的な上限です。

48 kHz / 24 ビットのステレオならデータレートは毎秒 288,000 バイトなので、4 GB はおよそ 4 時間 8 分です。無関係と言っていいでしょう。96 kHz / 24 ビットで 128 トラックのオブジェクトベース・マスターなら毎秒 36,864,000 バイトになり、4 GB は 2 分未満 — 116.5 秒です。

イマーシブのマスターは日常的にこの上限を越えます。そして上限に達した WAV ライターが吐き出すのは、切り詰められたファイルか、宣言されたサイズが黙って一周してしまったファイルのどちらかです。EBU はまず RF64（EBU Tech 3306）でこれに対処し、ITU がそれを勧告 ITU-R BS.2088 — BW64 — として引き継ぎました。

番人の仕掛け: 0xFFFFFFFF と ds64 チャンク

BS.2088 はこの仕組みを明示しています。"The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file"（ファイル先頭 4 バイトでは 'RIFF' の代わりに ID 'BW64' を用いる）とあり、元の 32 ビットのサイズフィールドはエスケープフラグになります。"If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."（フィールドの 32 ビット値が 0xFFFFFFFF なら、代わりに 'ds64' チャンク内の 64 ビット値を用いる。）

仕掛けはこれだけであり、はっきり言っておく価値があります。BW64 は RIFF のサイズフィールドを広げてはいません。 そこを番人として 0xFFFFFFFF で埋め、本当の 64 ビットのサイズを、ファイル内で必ず先頭に来なければならない ds64 チャンクに置くだけです。したがって 4 GB 未満の BW64 ファイルは、4 文字のシグネチャを除けばあらゆる点で WAV リーダーとバイト互換です。多くのツールはこれを受け入れますが、頑として受け入れないものもあります。

チャンク群と、1 エントリーがちょうど 40 バイトのもの

BS.2088 によれば、BW64 ファイルには少なくとも ds64、fmt 、chna、axml（メタデータの代替キャリアとして bxml と sxml）、そして波形データが含まれることが期待されます。

ds64 はシグネチャの直後、最初のチャンクでなければなりません。リーダーは他の何かをたどる前に本当のサイズを知る必要があるからです。ファイル全体のサイズと data のサイズについて 32 ビットの下位/上位半分を持ち、加えて 他の 巨大なチャンクのための ChunkSize64 エントリーの表を持ちます。サンプル精度のオートメーションつきで数千のオブジェクトを記述する axml チャンクは、それ自体が 4 GB に迫る、あるいは超えることがあるからです。

fmt は標準的な WAVE フォーマットチャンクです。サンプル形式、サンプリング周波数、チャンネル数、ビット深度、ブロックアラインを持ちます。data にインターリーブされたチャンネルが何本あるのかについて、権威ある記述はこれだけです。以降のものはすべて、それらのチャンネル について語る メタデータであり、メタデータは嘘をつきえます。

chna は物理トラックと ADM をつなぐ橋です。ckID、ckSize、2 バイトの numTracks、2 バイトの numUIDs に続いて、それぞれちょうど 40 バイトの固定幅 audioID エントリーがフラットな配列として並びます。

2 + 12 + 14 + 11 + 1 = 40 です。この幅は推奨ではありません。固定幅 ASCII であり、13 文字の UID を書き出すライターは「少し変わった」表ではなく、壊れた表を作ったのです。

ID の規約も重要です。0x0FFF 以下の値は ADM の共通定義 — あらかじめ定義された標準のチャンネルフォーマットとパックフォーマット — を指し、0x1000 以上は axml に存在しなければならないカスタム定義を示します。AP_00010003 は共通定義による 5.1 で XML を必要としません。AP_00031001 はカスタムのオブジェクトパックなので XML が必要であり、なければ参照は宙に浮きます。

numUIDs が numTracks を正当に上回ることもあります。EBU のガイダンスは、"the audio elements of a track may be [defined] differently in the course of a file … there will be a different UID for each definition"（あるトラックのオーディオ要素はファイルの途中で異なる定義を持ちうるため、定義ごとに別の UID が存在する）と述べています。つまり一つの trackIndex が複数のエントリーに現れうるのです。1 トラックにつき UID は 1 つと決めてかかる QC ツールは、正しいファイルを壊れていると報告します。

axml は <audioFormatExtended> ツリーを含む UTF-8 の XML 文書です。これが ADM であり、興味深い不具合はほぼすべてここに住んでいます。data はただのインターリーブ PCM で、その中身はオブジェクトについて何も知りません。

順序について。ds64 は常に最初、fmt は data の前です。ただし axml は data の後 に置かれても正当であり、実際よくそうなります。BS.2088 が指摘するとおり、収録中は "the XML metadata will likely be of an unknown length."（XML メタデータの長さは未知であろう）だからです。末尾に axml があるファイルは不正ではありませんが、先頭 1 メガバイトしか走査しないリーダーは「ADM は存在しない」と報告します。「自分のファイルにメタデータがない」という報告の驚くほど多くが、これで説明できます。

ADM はグラフであり、不具合は切れた辺である

ITU-R BS.2076 の階層は audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat と下り、葉が audioTrackUID で、物理トラックに対応する唯一の要素がこれです。

これは入れ子の文書ではなく参照のグラフであり、深刻な納品事故はどれもその中の切れた辺です。宙に浮いた参照が危険なのは、辺が切れたときの挙動が一つに定まらないからです。XML に存在しないパックを指す audioPackFormatIDRef を解決しようとしたレンダラーは、パースを中止してファイルを却下するかもしれませんし、そのオブジェクトを飛ばして残りをレンダリングし、ステムが一つ静かに欠けたミックスを作るかもしれませんし、共通定義にフォールバックして 0x1000 以上のカスタム域の ID に一致がないと判断し、無音で置き換えるかもしれません。三つとも結果は「ファイルは開いた」です。耳で捕まえられるのは一つだけで、それも何があるはずだったかを知っている場合に限られます。

却下の大半を占める四つの不具合

fmt のトラック数が chna と食い違う。 fmt .nChannels は 16 と言い、chna.numTracks は 14 と言う。最初の二つのチャンクの時点でファイルは内部矛盾しています。たいていは、メタデータを作った後にトラック数が変わったバウンスか、chna を書き直さずにトラックを落としたツールが原因です。検出は整数を二つパースして比べるだけ。パイプライン中で最も安価な検査でありながら、驚くほどの割合の不具合を捕まえます。同時に、すべての trackIndex が 1 … fmt .nChannels の範囲にあることも確認してください。

どのオブジェクトからも参照されていない audioTrackUID。 どの audioObject も参照しない chna 内の UID は、何もレンダリングしないオーディオが存在することを意味します。その鏡像、すなわち対応する chna エントリーのない XML 内の audioTrackUIDRef は、メタデータが存在しないトラックを期待していることを意味します。chna から UID の集合を、axml から UID の集合を作り、対称差を取ってください。空であるべきです。EBU Tech 3392 は意図を直接述べています。"If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."（audioObject が audioPackFormat を参照するなら、対応する audioTrackUID も参照すべきである。）

時間が逆行するブロック。 BS.2076 は明確です。"When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present."（audioChannelFormat 内に audioBlockFormat が複数ある場合、rtime と duration の両方が存在しなければならない。）EBU Tech 3392 はこれを連続性まで締めます。"rtime + duration of an audioBlockFormat should match the rtime of the following block"（ある audioBlockFormat の rtime + duration は、次のブロックの rtime に一致すべきである）— さらに、オブジェクトの最初のブロックは 00:00:00.00000 から始まり、1 サンプルより短いブロックはなく、duration の総和は親の audioObject に一致します。文書順にブロックをたどり、rtime[n] + duration[n] == rtime[n+1] を検証してください。破綻の形は三つです。すきま — レンダラーの挙動が未定義で、直前の位置を保持するものもあればミュートするものもあります。重なり — ブロック同士がぶつかります。そして時系列の乱れ — 番組の途中でオートメーションが逆行しているということです。

XML では記述されているのに、ディスクに書き出されなかったベッド。 XML は 7.1.4 の DirectSpeakers パック — 12 チャンネル — を宣言しているのに、実際に書き出されたのは 5.1 のサブセットだけだったり、ハイトチャンネルがバウンス時にミュートされてデジタル無音として書き出されていたりします。参照グラフは無傷で、オーディオが無傷ではありません。構造的な検査ではこれを捕まえられません。実体の解析、つまり DirectSpeakers パックが主張するすべてのチャンネルにそもそも信号があるかの測定が必要です。宣言されたベッドのチャンネルがデジタル無音であること自体は自動的に誤りとは限りません — 正当なミックスでトップリアが空のままということはありえます — が、常に人間が判断する価値があります。

イマーシブのラウドネスについて公表されていること、いないこと

ステレオからの移行を生き延びない数字が一つあり、その理由は述べておく価値があります。

BS.1770-5（2023 年 11 月）が現行版で、BS.1770-4 は置き換えられています。もっとも、実際に出回っているメーターの多くはいまだに -4 を挙げています。その中核アルゴリズムは L、R、C を 1.0、Ls と Rs を 1.41（約 +1.5 dB）で重み付けし、LFE を除外し、適用範囲は "from one to five channels"（1 から 5 チャンネルまで）とされています。BS.1770-5 は附属書でその先へ拡張し、BS.2051 の先進音響システムとオブジェクトベース・オーディオを扱いますが、後者は測定の前に レンダリング されなければなりません。したがってイマーシブのラウドネスはファイルの性質ではなくレンダリングの性質であり、目標レイアウトを変えれば数字も変わります。BS.2127 に準拠したレンダリングを、名前のついた BS.2051 のレイアウトに対して行い、BS.1770-5 のメーターで測って、三つとも納品ノートに記録してください。BS.2127 が参照 ADM レンダラーを定義しており、その姉妹であるオープンソースの EBU ADM Renderer（EBU Tech 3388）が、再現可能な数字を得る実務的な手段です。

イマーシブ納品向けの積分ラウドネス目標値を公表している音楽ストリーミングサービスは一つもありません。 フォーラムやベンダーの研修資料には数字が流通していますが、どれも公表された仕様ではなく、この記事はそれを仕様であるかのように繰り返しません。公表されているのはチャンネルベースのステレオについてのものです — Spotify の積分目標値 −14 LUFS とトゥルーピーク上限 −1 dBTP、−14 LUFS より大きい場合は −2 dBTP に締まること、そして AES TD1008 の音楽向け −16 LUFS（その −18 LUFS は話し声主体のコンテンツに適用される数字であり、−18 を音楽の目標値として述べるのはよくある、そして深刻な誤りです）。

Dolby Atmos は Dolby Laboratories が権利を持つライセンス技術であり、Sony 360 Reality Audio は MPEG-H の上に構築された専有システムです。それぞれの要件は権利者が定めるもので、ITU や EBU の日程とは無関係に変わるため、ここには記載しません。提携も推奨も主張しません。ライセンサー自身の最新のドキュメントを読んでください。

送る前に確認すること

まず構造的な検査から。速く、そしてそれ以降のすべてを無効化しうるからです。

• 先頭 4 バイトが BW64 であること。RIFF と読めるなら、それはただの WAV であり 4 GB を超えられません。
• ds64 がシグネチャの直後の最初のチャンクであり、その 64 ビットのサイズがディスク上のファイルサイズおよび data サイズと一致し、data 以外の巨大なチャンクには表に ChunkSize64 エントリーがあること。
• axml を data の後も含めて明示的に探すこと。部分的な走査から「ADM なし」と結論してはいけません。
• fmt のサンプリング周波数とビット深度が納品仕様と厳密に一致すること。ADM を作成した後にサンプリング周波数を変換してはいけません。サンプル単位で表現されたすべての rtime と duration が無効になります。
• fmt .nChannels が chna.numTracks と等しいこと。すべての trackIndex が範囲内で 1 始まりであること。
• すべての chna エントリーがちょうど 40 バイトで、固定幅フィールドが正しくパディングされていること。0x1000 以上のすべての packRef が axml に存在するカスタム定義に解決されること。
• すべての audioContentIDRef、audioObjectIDRef、audioPackFormatIDRef、audioChannelFormatIDRef、audioTrackUIDRef が解決されること。どちらの向きにも宙に浮いた辺がゼロで、循環参照もないこと。
• 複数ブロックのチャンネルフォーマットは、すべてのブロックに rtime と duration の両方を持つこと。ブロックが連続かつ単調であること。オブジェクトは 00:00:00.00000 から始まること。
• 宣言されたベッドのすべてのチャンネルに、あるべきものが入っていること。デジタル無音は調べること。
• bext の開始タイムコードが納品セット全体で整合していること。ステレオとバイノーラルのコンフォームが 現行の マスターから再レンダリングされていること。イマーシブの親に対して 40 ms 早いコンフォームは、ファイルの有無の検査は通り、同期して聴けば落ちます。
• すべての納品物にチェックサムを取り、マニフェストを保管し、ADM XML は BW64 とは別にアーカイブすること。差分を取れる XML は、再パースしかできないバイナリより、後になって値打ちが出ます。

BW64 と ADM は公開され、公表され、自由に読める規格です。それは使う価値があります。BS.2088 と BS.2076 は自分で読めますし、chna チャンクは 40 行ほどのコードでパースできますし、ベンダーのエクスポーターがダイアログで何を主張したかではなく実際に何を書いたかを検証できます。不要なイマーシブ却下のほとんどは、バリデーターが 1 秒足らずで捕まえる参照整合性の誤りです。

Mazufa の無料 BW64/ADM インスペクターは mazufa.com/immersive-master-check にあります。コンテナとメタデータをすべてあなたの端末上で解析し、何もアップロードしないので、契約上その建物から出せない素材にも使えます。Mazufa 自体はリリース無料、手数料 0%、そして完全な応募すべてを人間が審査する招待制です。

出典

ITU-R 勧告

• ITU-R BS.2088-2 (11/2025), Long-form file format for the international exchange of audio programme materials with metadata (BW64) — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2088-2-202511-I!!PDF-E.pdf
• ITU-R BS.2076-3 (02/2025), Audio Definition Model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-3-202502-I!!PDF-E.pdf
• ITU-R BS.1770-5 (11/2023), Algorithms to measure audio programme loudness and true-peak audio level — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
• ITU-R BS.2051-2 (07/2018), Advanced sound system for programme production — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2051-2-201807-S!!PDF-E.pdf
• ITU-R BS.2127-1 (11/2023), Audio Definition Model renderer for advanced sound systems — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2127-1-202311-I!!PDF-E.pdf

EBU 技術文書

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285（および補遺）, Specification of the Broadcast Wave Format — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3285s7.pdf
• EBU Tech 3392, ADM Broadcast Production Profile — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3392.pdf
• EBU Tech 3388, ADM Renderer for use in Next Generation Audio broadcasting — https://tech.ebu.ch/publications/tech3388
• EBU ADM Guidelines — CHNA chunk — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 and ADM — https://adm.ebu.io/reference/excursions/bw64_and_adm.html
• EBU ADM Guidelines — audioTrackUID — https://adm.ebu.io/reference/adm_elements/audio_track_uid.html
• libbw64 リファレンス実装 — https://github.com/ebu/libbw64

AES

• AES TD1008, Recommendations for loudness of internet audio streaming and on-demand distribution — https://www.aes.org/community/technical-council/technical-document-aestd1008/

サービスのドキュメント

• Spotify, Loudness normalization — https://support.spotify.com/us/artists/article/loudness-normalization/