BW64 と ADM ―― イマーシブ音声の納品を技術的に正しく行うための実務リファレンス

22.2マルチチャンネル音響、オブジェクトベース制作、そして「聴けない環境で正しさを証明する」ための手順書。

短い答え

ADM（Audio Definition Model、勧告 ITU-R BS.2076）は、ファイル内の各トラックが何であるか ―― 固定スピーカーのチャンネルなのか、動く音源オブジェクトなのか、アンビソニックスの成分なのか ―― と、それらがどう組み合わさって一つの番組になるのかを記述する、公開されたメタデータ規格です。それを運ぶ容れ物が BW64（勧告 ITU-R BS.2088）で、古典的な RIFF/WAVE の 4 GB 上限を越えるために 64 ビットのサイズを持てるように拡張したコンテナです。イマーシブ納品が QC で落ちる理由のほぼすべては、音そのものではなく、音とメタデータという二つの別物が一致していないことにあります。しかもファイルフォーマットの側には、両者を一致させる強制力が何もありません。fmt のチャンネル数と chna のトラック数が食い違う、どのオブジェクトからも参照されない audioTrackUID が残っている、ブロックの時刻が逆行している、XML には書いてあるベッドが実際には書き出されていない ―― これらは波形編集ソフトでは一切見えず、レンダラーにとっては致命的です。イマーシブの QC とは、耳で聴く作業ではなく、参照整合性の検査です。

1. 日本から始めるのが最短距離である理由 ―― 22.2マルチチャンネル音響

イマーシブ音声を日本語で説明するとき、海外の資料を経由する必要はありません。三次元音響の代表的なスピーカー配置そのものが、日本で生まれているからです。

22.2マルチチャンネル音響は NHK が スーパーハイビジョン（8K UHDTV）のために開発した方式で、ITU の報告書 ITU-R BS.2159-9 は次のように明記しています ―― 「The 22.2 multichannel sound system was developed by NHK (Japan Broadcasting Corporation).」 そして構成については 「It has nine channels at the top layer, ten channels at the middle layer, three channels at the bottom layer and two low-frequency effects (LFE) channels.」（Report ITU-R BS.2159-9）。同報告書は運用実績についても 「The advanced satellite digital broadcasting of UHDTV with 22.2 multichannel sound started in Japan in December 2018.」 と記述しています。

これは日本ローカルの独自方式ではありません。勧告 ITU-R BS.2051（Advanced sound system for programme production）が定める国際標準のスピーカー配置の一つとして、システム H の名前で収録されています。BS.2051 は各配置を「上層＋中層＋下層」のチャンネル数で表記し、システム H は 9+10+3 です。

（配置一覧は ITU-R BS.2051-2 による。）

1.1 三層とは具体的に何か

「9+10+3」を音として理解しておくことが、あとで出てくるレンダリングの話を全部わかりやすくします。BS.2051 の表 10 が示すシステム H のチャンネルは、以下のとおりです。

• 中層（middle layer、聴取者の耳の高さ）― 10ch：M+030 (FLc)、M+060 (FL)、M+000 (FC)、M−030 (FRc)、M−060 (FR)、M+090 (SiL)、M−090 (SiR)、M+135 (BL)、M−135 (BR)、M+180 (BC)。前方に 5 個、側方に 2 個、後方に 3 個。5.1 の輪よりも前方が細かく、後方が独立しています。
• 上層（upper layer、天井方向）― 9ch：U+045 (TpFL)、U+000 (TpFC)、U−045 (TpFR)、U+090 (TpSiL)、U−090 (TpSiR)、U+135 (TpBL)、U+180 (TpBC)、U−135 (TpBR)、そして真上の T+000 (TpC)。
• 下層（bottom layer、耳の高さより下）― 3ch：B+045 (BtFL)、B+000 (BtFC)、B−045 (BtFR)。前方の床側だけに 3 個。
• LFE ― 2ch：LFE1（前方右寄り）と LFE2（前方左寄り）。BS.2051 の表では LFE1 が方位 +30〜+90°／仰角 −15〜−30°、LFE2 が −30〜−90°／−15〜−30° の範囲に置かれます。

合計 22 本の主スピーカー＋2 本の LFE、つまり 24 チャンネル。「22.2」の 22 と.2 はそのまま上の数を指しています。下層 3ch と LFE が 2ch ある点、そして真上 (TpC) が独立している点が、他のどの BS.2051 配置とも違う特徴です。

1.2 「5.1 の世界で作った ADM」が 22.2 に落ちると何が起きるか

ここが日本の制作者にとって一番実利のある論点です。5.1 前提で作られた ADM ファイルは、22.2 に対して構文上は正しく、音楽的にはほぼ確実に失敗します。 理由は三つあります。

（1）下層が空になる。 5.1 の世界には「耳より下」という概念がありません。オブジェクトの仰角はほぼ 0° か正の値しか使われず、BtFL / BtFC / BtFR の 3 本には何も来ません。24 本のうち 3 本が構造的に無音のまま鳴らない状態は、レンダラーのエラーにはなりませんが、システム H を組んだ部屋で聴けば「下がすっぽり抜けている」と即座にわかります。太鼓の胴鳴りや床を伝わる低い成分を持つ素材ほど、この欠落が目立ちます。

（2）上層の解像度が要求に届かない。 5.1.4（システム D）を想定して書かれた ADM は、上方の音像を実質 4 方向でしか動かしません。それを 9ch の上層に配置すると、レンダラーは 4 点分の情報を 9 本に分配することになり、天井の音場は「4 点をぼかして広げたもの」になります。真上 (TpC) を明示的に使う素材がなければ、システム H の最大の特徴である「頭上の一点」は永久に鳴りません。

（3）中層の前方分解能が使われない。 5.1 の前方は L / C / R の 3 点です。システム H の前方は FL / FLc / FC / FRc / FR の 5 点あります。5.1 由来のオブジェクトは ±30° と 0° の付近に固まりがちで、FLc / FRc は補間の産物としてしか鳴りません。会話や独奏楽器の定位が「粗い」と言われるのはこの構造が原因です。

要するに、BS.2127 のレンダラーはアップミックスをしません。存在しない情報を作り出す仕事はレンダラーの担当外です。上層 4ch・下層 0ch で書かれたメタデータからは、上層 4ch 相当・下層 0ch 相当の音場しか出てきません。22.2 を納品先に含める可能性があるなら、オーサリングの段階で下層と真上を明示的に扱っておくしかありません。

チャンネルベースは「スピーカーがどこにあるか」をファイルに書き込む。オブジェクトベースは推測を拒否し、シーンベースは音源ではなく場を記述する。だから 5.1 前提のチャンネルベース素材は、22.2 の部屋に持っていくと 5.1 のままである。

2. 三つの音声形式と、日本の伝統音楽が示す教科書的な実例

ADM は音声の性質を typeDefinition で分類します。分類を間違えると、その後のすべてが狂います。

• チャンネルベース（DirectSpeakers、typeLabel 0001）：各トラックが固定スピーカー位置に割り当てられる。ステレオ、5.1、7.1.4 の「ベッド」。位置はチャンネルの正体そのもの。
• オブジェクトベース（Objects、typeLabel 0003）：モノ（またはパック単位）の信号＋時間変化する位置メタデータ。どの実スピーカーで鳴らすかは、再生側の配置を見てレンダラーが決める。
• シーンベース（HOA、typeLabel 0004）：高次アンビソニックス。個々の成分は方向を持たず、線形結合として方向が現れる。
• このほか Matrix（0002、Mid-Side や Lt/Rt など）と Binaural（0005、ヘッドホン用ペア）が定義されています。

この区別を日本語で説明するのに、これ以上ない題材が身近にあります。

2.1 雅楽 ―― 座り位置が儀式的に決まっている、という特異な条件

雅楽の管絃は、演奏者の配置が演奏者の裁量ではなく様式として決まっています。三管（篳篥・龍笛・笙）、両絃（楽琵琶・楽箏）、三鼓（鞨鼓・太鼓・鉦鼓）が、それぞれ定まった位置に着座します。西洋のオーケストラの配置が指揮者や会場の都合で動くのに対し、雅楽の配置は動かないことに意味があります。

これは ADM のモデルにきれいに対応します。位置が固定されていて、かつ演奏中に変わらないなら、それは静的なオブジェクト、すなわち audioBlockFormat が一つだけの audioChannelFormat です。 篳篥を Objects として方位 −20°・仰角 0°・距離 0.7 に置き、rtime="00:00:00.00000" の単一ブロックで書けば、それで完結します。時間変化しないからといってチャンネルベースにする必要はありません。むしろオブジェクトにしておく利点は、5.1 でも 22.2 でもバイノーラルでも、その角度がそのまま再現されることです。三管を L / C / R の 3 本のスピーカーに割り付けてしまうと、システム H の前方 5 点を使う機会を自分で捨てることになります。

対して舞楽は、話が変わります。舞人は舞台上を移動します。これは定義上、時間変化するオブジェクトです。audioBlockFormat を連続する複数ブロックで書き、rtime と duration を全ブロックに付け、rtime[n] + duration[n] == rtime[n+1] を満たす連続列にする必要があります。舞人に付けたワイヤレスマイクの信号を一本のトラックとして持ち、その位置を舞の進行に合わせて自動化する ―― これがオブジェクトベース制作の、日本音楽における最も素直な用例です。

なお、舞人の位置を「ステレオのパンニングで書いて、そのファイルをオブジェクトと呼ぶ」ことはできません。パンニング済みのステレオ 2ch はすでにチャンネルベースであり、22.2 のレンダラーはそれを 2 本のスピーカーに戻すだけです。オブジェクトにするなら、モノで録って位置を別に持つ必要があります。

2.2 能舞台 ―― 橋掛りという、距離と角度が音楽的意味を持つ実在の幾何

能舞台は、イマーシブ音声の説明のために設計されたのではないかと思うほど都合のよい構造をしています。

橋掛りは、鏡の間から本舞台へ斜めに伸びる通路です。シテはここを通って登場します。これは演出上の通路であると同時に、音響上は「遠くから、斜め後方から、時間をかけて近づいてくる音源」そのものです。距離が縮まり、角度が変わり、直接音と反射音の比が変わっていく。ADM の audioBlockFormat は azimuth / elevation / distance（またはデカルト座標の X / Y / Z）に加えて gain、size、diffuseness を持ちますから、橋掛りの登場はそのまま座標の時系列として書き下せます。5.1 のパンニングで「だんだん大きくして少し右に寄せる」のとは、記述の解像度が根本的に違います。

一方、囃子方は違う扱いを要求します。笛・小鼓・大鼓・太鼓は本舞台後方の後座に、決まった順で一列に座ります。動きません。したがってこれは 2.1 の雅楽と同じく、静的オブジェクトの並びとして書くのが正確です。地謡座に並ぶ地謡も同様です。

ここで実務上の判断が一つあります。囃子方を「後方のオブジェクト群」と書くか、「後方を含むベッド」と書くか。 四人が固定で、相互の位置関係に音楽的意味があり（一列の順序は決まっている）、かつ舞台の響きと一体で録れているなら、部屋の響きをチャンネルベースのベッドとして持ち、囃子方の直接音を静的オブジェクトとして重ねる構成が最も破綻しません。ベッドは会場、オブジェクトは点音源 ―― この切り分けは、シテの移動を書くときにも効いてきます。移動するオブジェクトが、動かないベッドの上を通っていく形になるからです。

2.3 歌舞伎 ―― 花道と、舞台外にいる音源

歌舞伎はさらに極端です。花道は客席を貫いて走っており、役者は文字どおり客の横を通ります。BS.2051 の配置で言えば、これは中層の側方（SiL / SiR、M±090）から後方（BL / BR、M±135）にかけての領域を、音源が実際に通過するということです。5.1 のサラウンドチャンネルに「なんとなく回す」のではなく、通過の軌跡が実在する。

さらに歌舞伎には、舞台上に見えない音源が構造的に存在します。下手の黒御簾の中で演奏される下座音楽は、観客からは見えませんが、位置は決まっています。義太夫の床は上手にあります。これらは「見えないから位置がない」のではなく、見えないが位置が確定している音源です。ADM ではこれを迷わず静的オブジェクトとして書けます。逆に、これをステレオの中に埋めてしまうと、22.2 の部屋で再生したときに「下座が上手から聞こえる」といった、実演を知っている人には即座にわかる誤りが生じます。

2.4 和太鼓 ―― 円弧と高低差

和太鼓の合奏は、多くの場合半円状に並びます。宮太鼓が弧を描き、締太鼓が前列に入り、大太鼓が後方の櫓の上に高く据えられる編成も一般的です。

この「高く据えられる」が、22.2 において意味を持ちます。大太鼓が櫓の上にあるなら、仰角は 0° ではありません。上層のチャンネル（U+180 TpBC や U±135 TpBL/TpBR の付近）に実際に成分が行く配置です。同時に、和太鼓は下層が最も生きる素材でもあります。床を伝わる胴の低い成分は、BtFL / BtFC / BtFR の 3 本が担当できる帯域と位置です。

つまり和太鼓合奏は、上層・中層・下層の三層すべてに音楽的な理由がある、数少ない編成です。前節で述べた「5.1 由来の ADM は下層が空になる」問題が、最も具体的な損失として現れる素材でもあります。半円配置を 5.1 のサラウンドに畳んでしまうと、弧の中の一台一台の位置は失われ、櫓の高さも失われ、残るのは「広い太鼓の音」だけになります。

3. BW64 ―― なぜ必要なのか、数字で

古典的な WAV は RIFF ファイルです。1991 年の RIFF は、すべてのチャンクの先頭に 32 ビットのサイズフィールドを置きます。32 ビットが表せるのは 4,294,967,296 バイト（4 GB）で、これがファイル全体にも data チャンクにも効く硬い上限です。

自分で計算して確かめておきましょう（2^32 = 4,294,967,296 バイト）。

計算は 1 チャンネルあたり 3 バイト（24 bit）× サンプルレート × チャンネル数。たとえば 24ch × 3 B × 96,000 Hz = 6,912,000 B/s、4,294,967,296 ÷ 6,912,000 = 621.38 秒。

ステレオなら 4 時間強という、実質無関係な数字です。ところが 22.2 のベッドを 96 kHz で持っただけで、上限は 10 分 21 秒まで落ちます。舞楽の一曲、能の一番、太鼓の組曲 ―― どれも普通に超えます。オブジェクトを足せばもっと短くなります。上限に当たった WAV ライターが吐くのは、切り詰められたファイルか、宣言サイズが黙って桁あふれしたファイルのどちらかです。

この問題に最初に対処したのが EBU の RF64（EBU Tech 3306）で、それを ITU が引き継いだのが 勧告 ITU-R BS.2088、Long-form file format for the international exchange of audio programme materials with metadata ―― すなわち BW64 です。BS.2088 は仕組みをはっきり書いています。「The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file」、そして 32 ビットのフィールドはエスケープ用の目印に転用されます ―― 「If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead.」

BW64 は RIFF のサイズフィールドを広げてはいない。そこに 0xFFFFFFFF という番兵を置き、本当の 64 ビットサイズを、ファイル先頭に置かれた ds64 チャンクに書く。それだけである。

系譜としては三代目にあたります。RIFF/WAVE がチャンク構造を与え、Broadcast Wave（BWF、EBU Tech 3285）が bext チャンク（制作者、タイムコード基準、コーディングヒストリー）を足して放送用交換フォーマットにし、BW64 がそれを引き継いだうえで 64 ビットアドレッシングと ADM 運搬用チャンクを加えました。4 GB 未満の BW64 ファイルは、先頭 4 バイトの識別子を除けば WAV リーダーとバイト単位で互換です。受け付けるツールは多いですが、頑として受け付けないツールもあります。

4. チャンクの並びを、バイト単位で

BS.2088 の想定では、BW64 ファイルは少なくとも <ds64-ck>、<fmt-ck>、<chna-ck>、<axml-ck>（代替のメタデータ搬送体として <bxml-ck>、<sxml-ck>）、そして <wave-data> を含みます。

4.1 ds64 ―― 64 ビットサイズの表

BW64 識別子の直後、必ず最初のチャンクでなければなりません。リーダーは他を走査する前に本当のサイズを知る必要があるからです。フィールドは 64 ビット量を 32 ビットずつ二つに割った形で並びます。

ckID と ckSize を除いた固定部分は 8 + 8 + 8 + 4 = 28 バイト、ヘッダを含めて 36 バイト、そこに table[] が続きます。

table[] は見た目より重要です。axml 自身が 4 GB に近づくことがあります。 サンプル精度のオートメーションを持つオブジェクトが数千個ある番組では現実に起こります。data 以外のチャンクが 64 ビットサイズを宣言する手段はこのテーブルしかありません。

4.2 fmt ―― 実体（essence）の記述

標準的な WAVE フォーマットチャンクです。サンプルフォーマット、サンプルレート、チャンネル数、ビット深度、ブロックアライン。data に実際に何チャンネルがインターリーブされているかを述べる唯一の権威がここです。以降のすべては、そのチャンネル群「についての」メタデータであり、メタデータは嘘をつけます。

4.3 chna ―― チャンネル割当表と、40 バイトの内訳

chna は物理トラックと ADM をつなぐ橋です。冒頭は次のとおり。

• ckID ― 4 バイト、'chna'
• ckSize ― 4 バイト
• numTracks ― 2 バイト、ファイル内のトラック数
• numUIDs ― 2 バイト、後続の audioTrackUID エントリ数

その後に、固定幅の audioID エントリが平坦に並びます。1 エントリはちょうど 40 バイトです。

2 + 12 + 14 + 11 + 1 = 40。 実際に文字数を数えて確かめられます ―― ATU_00000001 は ATU_ の 4 文字＋数字 8 桁で 12 文字、AT_00031001_01 は AT_ 3 ＋ 8 ＋ _ 1 ＋ 2 = 14 文字、AP_00031001 は AP_ 3 ＋ 8 = 11 文字。フィールド幅は目安ではなく固定幅 ASCII です。 13 文字の UID を書き出したライターは「少し変わったファイル」を作ったのではなく、壊れた表を作っています。

したがって chna チャンクのサイズは、numTracks と numUIDs（2 + 2 = 4 バイト）＋ 40 × エントリ数 になります。22.2 のベッド 24ch に静的オブジェクトを 12 個足した 36 トラックの素材で、トラック定義が途中で変わらないなら、エントリは 36 個 ―― 4 + 40 × 36 = 1,444 バイト。この数字が合わないファイルは、その時点で疑ってかまいません。

ID の規約も押さえておきます。0x0FFF 以下の値は ADM の共通定義（common definitions） ―― 規格側にあらかじめ用意されたチャンネル／パックフォーマット ―― を指し、0x1000 以上はカスタム定義で、axml チャンクの中に実体がなければなりません。packRef が AP_00010003 なら共通定義の 5.1 なので XML は不要、AP_00031001 はカスタムのオブジェクトパックなので XML がなければ参照が宙に浮きます。

トラック UID は「一本の物理トラックの正体」に振られた通し番号であり、番組の途中でトラックの中身が正当に変わりうることを前提に存在している。

これが 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」と述べています。同じ trackIndex が複数のエントリに現れることは正常です。「トラック 1 本につき UID 1 個」を前提にした QC ツールは、正しいファイルを不正と判定します。

4.4 axml ―― ADM 本体

<audioFormatExtended> ツリーを含む UTF-8 の XML 文書です。テキストであり、目で読めて、diff が取れます。そして興味深い失敗のほとんどはここに住んでいます。

日本語の実務で一点。audioProgramme や audioObject の audioProgrammeName / audioObjectName には、規格上は UTF-8 の任意文字列が入りますから「舞楽・振鉾」のような日本語名を書くこと自体は妥当です。ただし受け手側のログやレポートが Shift_JIS 前提の古いツールを経由すると化けます。日本語名を入れるなら、同じ内容を ASCII でも併記する運用（audioObjectName="Bugaku Furihoko / 舞楽・振鉾" のような形）が、いまのところ最も事故が少ない選択です。断定はできませんが、混在させて困った例は減ります。

4.5 data ―― インターリーブされた PCM

WAV とまったく同じ、素のインターリーブサンプルです。data の中身はオブジェクトのことを何も知りません。

4.6 並び順と、全員がはまる罠

ds64 は常に先頭。fmt は data より前。そして axml は data の後ろに置かれてよく、実際しばしばそうなっています。 BS.2088 が理由を書いています ―― 収録中は「the XML metadata will likely be of an unknown length」。末尾に axml があるファイルは不正ではありません。しかし先頭数 MB しか走査しないリーダーは「ADM がない」と報告します。「メタデータが入っていない」という問い合わせの相当数が、この一点で説明できます。

5. ADM のオブジェクトモデル ―― 参照のグラフ

ITU-R BS.2076 はモデルを二つに分けます。フォーマット部は「describes the technical nature of the audio so it can be decoded or rendered correctly」で、音がまだ存在しない段階でも書けます。コンテント部は「the language of dialogue, the loudness, etc.」を扱い、信号ができて初めて完成します。どちらの半分に属する要素かがわかると、そのエラーが制作のどの工程で入り込んだかもわかります。

階層は上から順に：

• audioProgramme ― 完成した一つの提示形態。一つ以上の audioContent を参照。
• audioContent ― 編集上の意味を持つ構成要素（台詞ステム、音楽ステム、言語版）。一つ以上の audioObject を参照。
• audioObject ― 編集意図と技術フォーマットの接合点。開始時刻と長さを持ち、0 個以上の audioPackFormat、0 個以上の入れ子 audioObject、0 個以上の audioTrackUID を参照する。ここでコンテントと実体が出会う。
• audioPackFormat ― まとまって扱われるチャンネル群（7.1.4 のベッド、ステレオペア、ある次数の HOA セット）。audioChannelFormat を参照し、他のパックを入れ子にできる。
• audioChannelFormat ― 一チャンネルの時間的なふるまい。一つ以上の audioBlockFormat を含む。
• audioBlockFormat ― 最小単位。Objects なら位置（azimuth/elevation/distance またはデカルトの X/Y/Z）、gain、size、diffuseness、そして rtime と duration。静的オブジェクトはブロック 1 個、動くオブジェクトはブロックの列。
• audioTrackUID ― 葉。物理トラックに対応する唯一の要素。任意属性 sampleRate / bitDepth を持ち、audioTrackFormat と audioPackFormat を参照する。

audioStreamFormat と audioTrackFormat はチャンネルフォーマットとトラック UID の間に位置し、ストリームの符号化を記述します。BS.2076-3 は PCM では実質不要だとして 「the audioStreamFormat and the audioTrackFormat should be omitted」 と述べる一方、リーダー側は 「existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain」 それらを含みうることに留意すべきだとしています。両方の形が合法です。 片方しか受け付けないバリデータは、もう片方について間違っています。

ADM は入れ子の文書ではなく参照のグラフであり、深刻な納品失敗はすべてそのグラフの辺が切れていることに帰着する。

参照が宙に浮いたとき、実際に何が起きるか。 単一の挙動が決まっていない、というのが厄介な点です。XML に存在しないパックを指す audioPackFormatIDRef を解決しようとしたレンダラーは、パースを中断してファイルを拒否するかもしれませんし、そのオブジェクトだけ飛ばして残りをレンダリングし、ステムが一つ静かに欠けたミックスを出すかもしれませんし、共通定義にフォールバックして 0x1000 以上のカスタム範囲に一致がないと判断し、無音を代入するかもしれません。三つとも「ファイルは開いた」に分類されます。耳で捕まえられるのは一つだけで、それも「本来そこに何があるべきか」を知っている人が聴いた場合に限られます。存在しないはずのないものの不在は、聴いてもわからない。 だから ADM の QC は自動化するしかありません。

6. レンダリング ―― BS.2127 が BS.2051 の配置へ落とす

ADM ファイルは、それ自体では音になりません。レンダラーが、実際にある配置に向けて解く必要があります。その参照実装を定義しているのが 勧告 ITU-R BS.2127、Audio Definition Model renderer for advanced sound systems です。BS.2127 は BS.2051 が定めるスピーカー配置（システム A〜J）を出力先として想定します。実務で再現可能な数値を得るには、その公開実装である EBU ADM Renderer（EAR、EBU Tech 3388） を使うのが現実的です。

ここから、日本の制作者にとって重要な帰結が二つ出ます。

第一に、一つの ADM ファイルには「正解の音」が複数あります。 同じファイルをシステム B（5.1）に解いた結果と、システム J（7.1.4）に解いた結果と、システム H（22.2）に解いた結果は、別の音です。どれも正しい。したがって「このファイルはこう聞こえる」という言い方は、どの配置に、どのレンダラーで解いたかを言わない限り成立しません。納品メモにはこの三点（レンダラー名・バージョン、出力配置、測定値）を必ず書いてください。

第二に、レンダラーはアップミックスもダウンミックスの創作もしません。 1.2 で述べたとおり、下層 0ch で書かれた ADM を 22.2 に解いても下層は鳴りません。逆に、22.2 前提で真上 (TpC) に置いたオブジェクトを 5.1 に解けば、その音は中層の水平面に畳まれます。畳まれても消えないように書くのが、複数配置に納品する場合のオーサリングの要点です。真上にしか置いていない要素、下層にしか置いていない要素は、5.1 での再生時に位置的な意味を失います。

7. BS.1770-5 によるイマーシブ音声のラウドネス測定

ここは「公開されているもの」と「流通しているだけのもの」を厳密に分けて書きます。

7.1 勧告が定めていること

現行版は ITU-R BS.1770-5（2023 年 11 月）です。BS.1770 には -0（2006）、-1（2007）、-2（2011）、-3（2012）、-4（2015）、-5（2023-11）の 6 版があり、BS.1770-4（2015 年 10 月）は廃止（superseded）されています。実際に流通しているメーターの多くはいまも -4 を表示しますが、現行と呼ぶべきは -5 です。

BS.1770-5 の中身：

• K 特性重み付けは 2 段のフィルタ。剛球モデルに由来するハイシェルフ（「ヘッド」フィルタ）と、それに続く RLB ハイパスです。この曲線の 1 kHz におけるゲインは +0.698 dB（リニアで 1.0836）。
• 測定は 400 ms のゲーティングブロックを 75 % オーバーラップさせて行います。
• 絶対ゲート：−70 LUFS を下回るブロックを捨てる。
• 相対ゲート：絶対ゲートを通過したブロックの平均を基準に、そこから −10 LU オフセットした値。ゲート前の全体平均ではありません。 ここは実装が頻繁に間違える箇所です。
• ラウドネスレンジ（LRA）は EBU Tech 3342 の定義で、相対ゲートは −20 LU です。−10 LU ではありません。 LRA に −10 を使うのはよくある実装バグです。
• ショートタームは 3 秒窓、モメンタリーは 400 ms（EBU Tech 3341）。
• トゥルーピークはオーバーサンプリングした信号で測ります（BS.1770 の最低要件は 4 倍、8 倍のほうが良い）。サンプルピーク ≠ トゥルーピークで、サンプル間ピークは最大サンプル値を超えることがあります。

チャンネル重み付けは、コアのアルゴリズムでは L・R・C が 1.0（0 dB）、Ls・Rs が 1.41（約 +1.5 dB）、LFE は除外です。ここが重要なのですが、この基本アルゴリズムの適用範囲は「1〜5 チャンネル」と規定されています。BS.1770-5 はそれを附属書で拡張し、BS.2051 の高度音響システム ―― 任意位置のスピーカーと上層チャンネルを含む配置 ―― と、オブジェクトベース音声を扱えるようにしています。オブジェクトベース音声は、測る前にレンダリングしなければ測れません。

イマーシブのラウドネスはファイルの属性ではなく、レンダリング結果の属性である。出力配置を変えれば数値は変わる。

これがステレオとの決定的な差です。ステレオのマスターにはラウドネス値が一つしかありません。オブジェクトベースのマスターには、レンダリング先の数だけ値があります。22.2 に解いた値と 5.1 に解いた値は別の数字になります。だから正直な書き方は一つしかなく、測定した配置とレンダラーを併記することです。

7.2 音楽について公開されているもの

チャンネルベースのステレオ音楽については、Spotify が統合ラウドネスの目標値 −14 LUFS、トゥルーピーク上限 −1 dBTP（マスターが −14 LUFS より大きい場合は −2 dBTP）を公開しています。AES TD1008 は音楽については −16 LUFS を推奨します。TD1008 に出てくる −18 LUFS はニュース・トーク・ドラマなど話者主体のコンテンツに対する数値であり、これを音楽の目標値として述べるのは頻出かつ重大な誤りです。放送では EBU R 128 が番組ラウドネス −23 LUFS を定めますが、これは放送のノーマライゼーション実務であって音楽配信の仕様ではありません。

なお、正規化は再生側で行われます。目標より大きいマスターは差分だけ下げられます。上方向の正規化も実在しますが条件付きです ―― Spotify は「Positive gain is applied to softer masters so the loudness level is -14 dB LUFS」と述べる一方で、「We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality」とも述べています。つまり、ピークの高い小音量マスターは目標まで上げてもらえないことがあります。「小さいマスターは上げられない」も「小さいマスターは必ず目標まで上がる」も、どちらも不正確です。過剰なリミッティングが買えるのは音量ではなく平板さだけ、というのが動かない結論です。

7.3 公開されていないもの

イマーシブ配信について、統合ラウドネスの目標値を公開している音楽配信サービスは存在しません。 フォーラムやベンダーの研修資料には数字が広く流通しており、いくつかはもっともらしく、おそらく正しいものもあります。しかしどれも公開仕様ではないので、本稿はそれを仕様のように書きません。

ステレオについても同様で、Apple Music、YouTube Music、Amazon Music、TIDAL、Deezer はいずれもノーマライゼーションの目標値を公開していません。よく引用される数値（Apple ≈ −16、YouTube Music ≈ −14、Amazon ≈ −14、TIDAL ≈ −14、Deezer ≈ −15）は、広く報じられているがサービス自身は公表していないものです。この区分をつけずに扱ってはいけませんし、そこからゲイン量を計算してもいけません。

放送と映画のほうが音楽より文書が整っているのは、放送局が公表するからです。今日、根拠を示せるイマーシブのラウドネス値が必要なら、BS.2127 準拠のレンダラーで、名前を明記した BS.2051 の配置に解き、BS.1770-5 のメーターで測り、その三点を納品メモに書いてください。 それが唯一、検証可能な言い方です。

7.4 プロプライエタリな方式について

Dolby Atmos はドルビーラボラトリーズのライセンス技術であり、Sony 360 Reality Audio は MPEG-H を基盤とする同社の方式です。それぞれの納品要件は権利者が定めるもので、ITU や EBU の改訂スケジュールとは無関係に変わります。本稿はそれらの企業の要件について何も述べませんし、いかなる提携・認定・推奨も主張しません。ライセンサーが要件を公開している場合は、必ずライセンサー自身の最新資料を読み、それを引用してください。

8. 正直な話 ―― 多くの人はイマーシブでモニターしていない

日本国内でも、放送局と一部のポストプロダクションを除けば、22.2 はもちろん 7.1.4 のモニター環境すら常設されていないのが現実です。個人スタジオや小規模なレコーディングスタジオで、下層 3ch を含む三層のスピーカーを恒久設置している例はごく少数です。これは能力の問題ではなく、部屋と天井高と予算の問題です。

だからこの文書は、スピーカーを買うべきだとは一言も言いません。 モニターできない環境で価値を出せる場所は、はっきりしています。

1. 正しいコンテナで出すこと。 4 GB を超える可能性があるなら BW64、ds64 が先頭、サイズが実ファイルと一致していること。
2. 正しいメタデータを書くこと。 fmt と chna が一致し、参照が一つも宙に浮いておらず、ブロックの時刻が連続していること。
3. 聴けないファイルの正しさを、聴かずに証明すること。 参照整合性の検査は、モニター環境がなくても 100 % 実行できます。むしろ、モニター環境がある人ですら耳では捕まえられない種類の誤りを捕まえます。

そして一つだけ、耳で有効な検査があります。バイノーラルレンダリングです。ヘッドホンでの BS.2127 バイノーラル出力は、22.2 の部屋の代わりにはなりませんが、「オブジェクトが前後で反転している」「橋掛りの移動が逆走している」「上層に何も来ていない」といった大きな構造的誤りは、確実に聞き取れます。小さな定位の差は判断できません。その限界を承知したうえで使う分には、有効です。

mazufa.com にはブラウザで動く BW64/ADM インスペクタがあり、コンテナとメタデータの解析をすべて利用者の端末上で行い、音声を一切アップロードしません。契約上、素材を社外に出せない案件でも使えます。

9. よくある QC 不合格と、その検出方法

9.1 fmt と chna のチャンネル数不一致

fmt.nChannels が 16、chna.numTracks が 14。最初の二つのチャンクの時点で内部矛盾しています。メタデータをオーサリングした後にトラック構成が変わるバウンス、あるいは chna を書き直さずにトラックを落としたツールが原因です。

検出：両方のチャンクをパースして整数を比較するだけ。パイプライン中で最も安いチェックで、驚くほど多くの失敗を捕まえます。あわせて、chna のすべての trackIndex が 1 … fmt.nChannels の範囲にあることも確認します。

9.2 孤立したトラック UID

chna にあるのにどの audioObject からも参照されない UID、あるいは XML の audioTrackUIDRef に対応する chna エントリがない状態。前者は「誰もレンダリングしない音声が存在する」、後者は「メタデータが存在しないトラックを期待している」を意味します。

検出：chna 側の UID 集合と axml 側の UID 集合の対称差を取る。空集合でなければ不合格。EBU Tech 3392 は意図を明示しています ―― 「If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs.」

9.3 ブロックの時刻が欠落／非単調

BS.2076 は明確です ―― 「When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present.」 EBU Tech 3392 はこれを連続性の規則に締めます ―― 「rtime + duration of an audioBlockFormat should match the rtime of the following block」。加えて、オブジェクトの最初のブロックは 00:00:00.00000 から始まり、1 サンプル未満のブロックはなく、duration の総和は親 audioObject の長さに一致すべきとされます。

検出：各 audioChannelFormat についてブロックを文書順に走査し、rtime[n] + duration[n] == rtime[n+1] を検査する。失敗の形は三種類 ―― 隙間（レンダラーの挙動は未定義。最後の位置を保持するものも、無音にするものもある）、重なり（ブロック同士が競合）、時刻の逆行（番組の途中でオートメーションが過去に飛ぶ）。舞楽や花道のように移動そのものが内容であるオブジェクトでは、これが直接、音の破綻として出ます。

9.4 サンプルレート／ビット深度の不一致

audioTrackUID は sampleRate と bitDepth を属性として持てます。これが fmt と矛盾すると、同じ実体について二つの主張が存在することになります。EBU Tech 3392 の立場は 「Should be ignored if available from the audio essence」 ですが、すべてのレンダラーがそれに従うわけではなく、48,000 と 96,000 が別々の場所に書かれたファイルはツールによって解釈が変わります。あわせて、そのレートが納品仕様のレートであることも確認してください。ADM オーサリング後のサンプルレート変換は、サンプルで表現されたすべての rtime と duration を無効にします。

検出：fmt と XML 内のすべての sampleRate / bitDepth 属性を突き合わせ、名目上は許容される不一致でもフラグを立てる。

9.5 ステレオ／バイノーラルのコンフォームが欠落、または同期していない

多くのイマーシブ納品は、イマーシブマスターと並べてステレオ（しばしばバイノーラルも）のコンフォームを求めます。繰り返し起きる失敗は「無い」ことではなく（無ければすぐわかります）、ずれていることです ―― 古いバージョンからレンダリングされている、数フレームずれている、開始タイムコードが違う。イマーシブの親に対して 40 ms 早いステレオファイルは、ファイル存在チェックを通過し、同期試聴で落ちます。

検出：長さをサンプル単位で比較し、bext の開始タイムコードを比較し、コンフォームをマスターのヌルレンダリングと相互相関にかける。現行マスターからバイト単位で導出できないコンフォームは、再チェックではなく再レンダリングするのが正しい扱いです。

9.6 XML にあるベッドがファイルにない

XML は 7.1.4 の DirectSpeakers パック ―― 12 チャンネル ―― を宣言しているのに、実際には 5.1 のサブセットしか書き出されていない、あるいはハイトチャンネルがバウンス時にミュートされてデジタルブラックのまま書かれている。参照グラフは完全、音声は不完全です。22.2 では、下層 3ch がまるごと無音というかたちで最も頻繁に現れます。

検出：構造チェックでは捕まりません。実体の解析が必要です ―― DirectSpeakers パックが主張するすべてのチャンネルについて、そのトラックに信号が存在するかを測ります。宣言されたベッドチャンネルのデジタルブラックが自動的にエラーだとは限りません（正当なミックスで後方上層が空なこともあります）が、常に人間の判断を仰ぐ価値があります。

コンテナは完全に妥当で、XML も完全に整形式で、それでも納品物が間違っていることがある。空のベッドチャンネルを検出する方法は、サンプルを見る以外にない。

9.7 typeLabel の不一致

audioChannelFormat の typeLabel が親の audioPackFormat と一致していない。Objects（0003）のパックの下に DirectSpeakers（0001）のチャンネルがぶら下がっている、といった状態です。パースは通り、レンダラーの解釈は分かれます。

検出：各 audioChannelFormat の typeLabel を親パックのものと突き合わせる。

10. 納品チェックリスト

上から順に。構造チェックが先です ―― 速く、かつ後続すべてを無効化する力があるからです。

コンテナ

1. 先頭 4 バイトが BW64 であること。RIFF なら普通の WAV であり、4 GB を超えられない。
2. ds64 が識別子直後の最初のチャンクで、その 64 ビットサイズが実ファイルと data の実サイズに一致する。
3. data 以外で 4 GB を超えるチャンクに、ds64 の table[] の ChunkSize64 エントリがある。
4. axml を明示的に探す。data の後ろも探す。 部分走査の結果から「ADM なし」と結論しない。

実体

1. fmt のサンプルレートとビット深度が納品仕様と完全一致。ADM オーサリング後の SRC なし。
2. fmt.nChannels ＝ chna.numTracks。
3. chna のすべての trackIndex が範囲内で、1 始まり。

chna の整合性

1. 全エントリがちょうど 40 バイトで、固定幅フィールドが正しくパディングされている。
2. 0x1000 以上の packRef はすべて axml 内のカスタム定義に解決する。
3. 同じ trackIndex の重複は意図されたもの（トラック定義の正当な変化）であり、重複エラーではない。

ADM グラフ

1. audioContentIDRef、audioObjectIDRef、audioPackFormatIDRef、audioChannelFormatIDRef、audioTrackUIDRef がすべて解決する。宙に浮いた辺はゼロ。
2. どちらの方向にも孤立した audioTrackUID がない。
3. 循環参照・自己参照がない。
4. 各 audioChannelFormat の typeLabel が親 audioPackFormat と一致する。

タイミング

1. 複数ブロックのチャンネルフォーマットは、全ブロックに rtime と duration を持つ。
2. ブロックが連続かつ単調で、duration の総和が親 audioObject の長さに一致する。
3. オブジェクトは 00:00:00.00000 から始まる。

内容

1. 宣言されたベッドの各チャンネルに、あるべきものが入っている。デジタルブラックは調査する。22.2 を含むなら下層 3ch を明示的に確認する。
2. オブジェクト数とベッド構成が納品仕様と一致する。
3. bext の開始タイムコードが正しく、セット内の全納品物で一貫している。

レンダーとコンフォーム

1. ステレオとバイノーラルのコンフォームが現行マスターから再レンダリングされている（過去のものを持ち越さない）。
2. 長さと開始タイムコードがマスターとサンプル単位で一致する。
3. ラウドネスは、名前を明記した配置に、名前を明記したレンダラーで解いた結果に対して測定し、その三点を納品メモに記録する。

再現性

1. すべての納品物のチェックサムを取り、マニフェストを保管する。
2. セッションと ADM の XML を、BW64 とは別に保管する。diff の取れる XML は、再パースするしかないバイナリより後々の価値が高い。

イマーシブの納品物は「良い音になったとき」に完成するのではない。その音を一度も聴いたことのない機械が、参照がすべて解決することを証明できたときに完成する。

11. おわりに

BW64 と ADM は、公開され、誰でも読める規格です。この業界の中では珍しいことで、利用する価値があります。BS.2088 も BS.2076 も自分で読めますし、chna チャンクは 40 行程度のコードでパースできます。ベンダーのエクスポーターのダイアログが何と言っていたかではなく、実際に何を書き出したかを自分で検証できるということです。

そして、日本で仕事をする者にとって特別な事情が一つあります。三層の代表的な配置である 22.2 は、ここで生まれ、ITU-R BS.2051 のシステム H として国際標準に収録されました。それを鳴らせる部屋がすぐ隣にあるかどうかは別として、その配置を前提に破綻しないファイルを書けるかどうかは、モニター環境とは無関係に、いま決められることです。イマーシブは不必要な差し戻しが最も多く発生する領域ですが、そのほとんどは、バリデータが 1 秒未満で捕まえる参照整合性の誤りです。

Mazufa のディストリビューションは無料です ―― アップロード料金なし、サブスクリプションなし、リリースごとの課金なし。差し引くのは受領したロイヤルティの 5 % のみで、完成したすべての申請には人間によるレビューが入ります。

出典

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.2076-2 (10/2019), Audio definition model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-2-201910-S!!TOC-HTM-E.htm
• ITU-R BS.2051-2 (07/2018), Advanced sound system for programme production（システム A〜J、システム H = 9+10+3）— 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
• 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
• Report ITU-R BS.2159-9 (03/2022), Multichannel sound technology in home and broadcasting applications（22.2 は NHK が開発、9+10+3+2LFE、2018 年 12 月に日本で UHDTV 放送開始）— https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BS.2159-9-2022-PDF-E.pdf
• ITU-R BS.2127 ランディングページ — https://www.itu.int/rec/R-REC-BS.2127

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/docs/tech/tech3388.pdf / https://tech.ebu.ch/publications/tech3388
• EBU Tech 3341（メーター）, EBU Tech 3342（ラウドネスレンジ）, EBU R 128 — https://tech.ebu.ch
• EBU Tech 3343, Practical guidelines for production and implementation in accordance with EBU R 128 — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3343v2_0.pdf
• 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
• EBU ADM Renderer (EAR) ドキュメント, BW64 I/O — https://ear.readthedocs.io/en/latest/BW64.html
• libbw64 リファレンス実装 — https://github.com/ebu/libbw64
• libadm リファレンス実装 — https://github.com/ebu/libadm

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/

最終確認 2026 年 9 月。規格は改訂されます。条項番号を引用する前に、必ず上記の ITU および EBU のページで現行版を確認してください。