沉浸式母带为什么能通过波形编辑器，却过不了 QC

一份沉浸式交付件可以在波形编辑器里打开，显示十二或十六条看上去健康的音轨，播放起来也合情合理，却仍然被打回。原因是结构性的：在一个 BW64 文件里，音频和元数据是两样东西，它们必须严丝合缝地对得上，而格式本身并不强制这一点。渲染器解析引用。编辑器绘制采样。这是两种不同的工作——正因如此，ADM 的 QC 是引用完整性检查，而不是听。以下是两份标准各自怎么说、引用会在哪里断掉，以及哪一项检查抓得住哪一类失败。

三类音频，以及这个区分为什么决定一切

每一个沉浸式交付问题，起点都是搞不清一条音轨究竟属于三者中的哪一类。

声道式音频把每条音轨指派到一个固定的扬声器位置。立体声是声道式的，5.1 是，7.1.4 的床声道也是。位置被烤进了声道身份里：第 3 轨就是中置，而且在任何播放它的系统上都是中置。ITU-R BS.2051 为先进声音系统把这件事规范化了，用上层 + 中层 + 底层的声道数来描述布局——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。

场景式音频，实际使用中即高阶 Ambisonics，把整个声场编码为球谐分量。没有哪个分量单独对应一个方向；方向是从线性组合中浮现出来的。这是 HOA，typeLabel 0004。ADM 还为 Mid-Side 或 Lt/Rt 这类矩阵化信号定义了 Matrix（0002），以及 Binaural（0005）。

这个区分不是分类学。一份声道式交付件的自描述程度足以让它作为一个裸 WAV 存活下来——把声道顺序弄对，它就能放。而一份对象式或场景式交付件，脱离元数据就毫无意义：音频不过是一堆无差别的单声道流，唯一说明它不是这样的东西就是 ADM。正是这种不对称，才有了 BW64 和 ADM。

BW64 之所以存在，是因为一个 32 位的数

经典 WAV 是 RIFF 文件。RIFF 出自 1991 年，给每个 chunk 前置一个 32 位的大小字段。三十二位可寻址 4,294,967,296 字节——4 GB——这就是整个文件以及其中 data chunk 两者共同的硬上限。

对 48 kHz / 24-bit 的立体声来说，数据率是每秒 288,000 字节，因此 4 GB 大约是 4 小时 8 分钟。无关紧要。而对 96 kHz / 24-bit 的 128 轨对象式母带，数据率是每秒 36,864,000 字节，4 GB 不到两分钟——116.5 秒。

沉浸式母带经常越过这条线，而一个撞上它的 WAV 写入器产出的，要么是被截断的文件，要么是声明的大小已经悄悄回绕的文件。EBU 最先用 RF64（EBU Tech 3306）解决了这个问题；ITU 则把它推进为建议书 ITU-R BS.2088——BW64。

哨兵值的把戏：0xFFFFFFFF 与一个 ds64 chunk

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 chunk 里。所以一个小于 4 GB 的 BW64 文件，除了那四个字符的签名之外，在其余每一方面都与 WAV 读取器逐字节兼容。很多工具接受它；有些则固执地不接受。

各个 chunk，以及那个每条恰好 40 字节的

按 BS.2088，一个 BW64 文件应至少包含 ds64、fmt 、chna、axml（bxml 与 sxml 作为可选的元数据载体）以及波形数据。

ds64 必须是签名之后的第一个 chunk，因为读取器得先知道真实大小，才能往下遍历任何东西。它携带整个文件大小和 data 大小的 32 位高低两半，外加一张 ChunkSize64 条目表，用于任何其他超大 chunk——一个描述数千个对象、带采样级精确自动化的 axml chunk，自己就可能逼近甚至超过 4 GB。

fmt 是标准的 WAVE 格式 chunk——采样格式、采样率、声道数、位深、块对齐。它是关于 data 里到底有多少条交织声道的唯一权威声明。它下游的一切都是关于这些声道的元数据，而元数据是会撒谎的。

chna 是物理音轨与 ADM 之间的桥。在 ckID、ckSize、一个 2 字节的 numTracks 和一个 2 字节的 numUIDs 之后，它存放一个定宽 audioID 条目的扁平数组，每条恰好 40 字节：

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」时，同一个 trackIndex 可能出现在若干条目里。那些假定每条音轨只有一个 UID 的 QC 工具，会把正确的文件标成有问题。

axml 是一份 UTF-8 的 XML 文档，内含 <audioFormatExtended> 树。它就是 ADM，也是几乎所有值得一说的失败所在之处。data 是普通的交织 PCM；它里面没有任何东西知道对象是什么。

顺序：ds64 永远第一；fmt 在 data 之前。但 axml 合法地可以位于 data 之后，而且经常如此，因为——正如 BS.2088 所指出的——录制过程中「the XML metadata will likely be of an unknown length.」一个把 axml 放在尾部的文件并不畸形，但一个只扫描前一兆字节的读取器会报告说完全没有 ADM。「我的文件没有元数据」这类报告中，有相当可观的一部分正源于此。

ADM 是一张图，失败就是断掉的边

ITU-R BS.2076 的层级是 audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat，audioTrackUID 是叶子，也是唯一与物理音轨对应的元素。

那是一张引用构成的图，不是一份嵌套文档，而每一个严重的交付失败，都是这张图上断掉的一条边。悬空引用之所以危险，在于断掉时没有单一的行为可言。一个渲染器在解析某个 audioPackFormatIDRef 时发现它指名的包在 XML 里不存在，可能中止解析并拒绝该文件；可能跳过那个对象、渲染其余一切，产出一份悄悄少了一条分轨的混音；也可能回退到通用定义，在 0x1000 以上的自定义区间里找到一个无匹配的 ID，然后代之以静音。这三种结果都是「文件打开了」。只有其中一种能靠听发现，而且还得是你知道本该有什么才行。

占了大多数退回的四种失败

fmt 的音轨数与 chna 不一致。fmt .nChannels 说 16；chna.numTracks 说 14。这个文件从头两个 chunk 起就自相矛盾——通常是元数据写定之后又改了音轨数的一次导出，或者是某个工具丢了音轨却没有重写 chna。检测方法就是解析两个整数并作比较：整条流水线上最便宜的一项检查，而它抓住的失败比例高得惊人。同时验证每一个 trackIndex 都落在 1 … fmt .nChannels 之内。

没有任何对象引用的 audioTrackUID。chna 里一个没有任何 audioObject 引用的 UID，意味着存在没有任何东西会去渲染的音频；镜像的情形，即 XML 中有一个 audioTrackUIDRef 却找不到对应的 chna 条目，意味着元数据在指望一条并不存在的音轨。把 chna 得出的 UID 集合与 axml 得出的集合作对称差；结果应为空。EBU Tech 3392 把意图说得很直白：「If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs.」

倒着走的块时间。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 开始，任何块都不短于一个采样，且各时长之和等于其父 audioObject。按文档顺序遍历各块，并断言 rtime[n] + duration[n] == rtime[n+1]。失败有三种形态：缝隙，此时渲染器行为未定义，有的会保持上一个位置而有的会静音；重叠，此时各块互相打架；以及块的时序错乱，那是自动化在节目中途往回跳。

XML 里描述了、却从未写到盘上的床声道。XML 声明了一个 7.1.4 的 DirectSpeakers 包——十二条声道——但只写出了 5.1 的子集，或者高度声道在导出时被静音，写成了数字黑。引用图是完整的；音频不是。结构检查抓不住这个：你需要的是实质内容分析，去测量一个 DirectSpeakers 包所声称的每条声道里究竟有没有信号。已声明的床声道上出现数字黑并不自动等于错误——一份合理的混音完全可能留空某个顶后声道——但它永远值得由人来做一次判断。

关于沉浸式响度，哪些是公布的，哪些不是

有一个数字从立体声搬不过来，值得说清楚为什么。

BS.1770-5（November 2023）是现行版本；BS.1770-4 已被取代，尽管多数已部署的表头引用的仍是它。其核心算法给 L、R 和 C 加权 1.0，给 Ls 和 Rs 加权 1.41（约 +1.5 dB），排除 LFE，且适用范围限定为「from one to five channels」。BS.1770-5 在附录中把这个范围向外延伸，涵盖了 BS.2051 的先进声音系统和对象式音频——后者必须先被渲染才能被测量。因此，沉浸式响度不是文件的属性，而是某一次渲染的属性，而改变目标布局就会改变这个数字。用 BS.1770-5 的表头去测量一次符合 BS.2127 的、渲染到某个具名 BS.2051 布局的结果，并把这三者全部记进你的交付说明；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 的时间表，这里不予陈述；本文不主张任何关联或背书。请阅读授权方自己的现行文档。

交付之前要检查什么

先做结构检查；它们快，而且一旦不过，下游的一切都失效。

• 头四个字节是 BW64。如果读到的是 RIFF，那就是一个普通 WAV，不能超过 4 GB。
• ds64 是签名之后的第一个 chunk，它的 64 位大小与盘上的文件大小和 data 大小一致，且任何超大的非 data chunk 在表中都有一条 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 分开归档——一份你能 diff 的 XML，日后比一份你只能重新解析的二进制更有价值。

BW64 和 ADM 是开放、公开、可自由查阅的标准，这一点值得用起来：你可以自己去读 BS.2088 和 BS.2076，用四十行代码解析一个 chna chunk，并核实某家厂商的导出器实际写了什么，而不是它的对话框声称写了什么。几乎所有不必要的沉浸式退回，都是校验器在一秒之内就能抓到的引用完整性错误。

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/