Why an immersive master passes a waveform editor and fails QC

An immersive deliverable can open in a waveform editor, show twelve or sixteen healthy-looking tracks, play back sensibly, and still be rejected. The reason is structural: in a BW64 file the audio and the metadata are two separate things that must agree exactly, and nothing in the format forces them to. A renderer resolves references. An editor draws samples. Different jobs — which is why ADM QC is reference-integrity checking, not listening. Here is what the two standards say, where the references break, and which check catches which failure.

Three kinds of audio, and why the distinction decides everything

Every immersive delivery problem starts with confusion about which of three things a track is.

Channel-based audio assigns each track to a fixed loudspeaker position. Stereo is channel-based, so is 5.1, so is a 7.1.4 bed. The position is baked into the channel identity: track 3 is the centre speaker, and it is the centre speaker on every system that plays it. ITU-R BS.2051 formalises this for advanced sound systems, describing layouts as Upper + Middle + Bottom layer counts — System A is 0+2+0 (stereo), System B is 0+5+0 (5.1), System D is 4+5+0, System J is 4+7+0, System H is 9+10+3, the 22.2 configuration. In ADM this is the DirectSpeakers typeDefinition, typeLabel 0001.

Object-based audio carries a mono (or multichannel pack) signal plus positional metadata that changes over time. The renderer decides which real loudspeakers reproduce it, based on the layout present in the room. Nothing about the track presumes a speaker. This is typeDefinition Objects, typeLabel 0003.

Scene-based audio, in practice Higher-Order Ambisonics, encodes the whole sound field as spherical-harmonic components. No component corresponds to a direction on its own; direction emerges from the linear combination. This is HOA, typeLabel 0004. ADM also defines Matrix (0002) for matrixed signals such as Mid-Side or Lt/Rt, and Binaural (0005).

The distinction is not taxonomy. A channel-based deliverable is self-describing enough to survive as a bare WAV — get the channel order right and it plays. An object-based or scene-based deliverable is meaningless without its metadata: the audio is a pile of undifferentiated mono streams, and the ADM is the only thing that says otherwise. That asymmetry is why BW64 and ADM exist.

BW64 exists because of a 32-bit number

Classic WAV is a RIFF file. RIFF, from 1991, prefixes every chunk with a 32-bit size field. Thirty-two bits addresses 4,294,967,296 bytes — 4 GB — and that is the hard ceiling on both the whole file and the data chunk inside it.

For stereo at 48 kHz / 24-bit the data rate is 288,000 bytes per second, so 4 GB is about 4 hours 8 minutes. Irrelevant. For a 128-track object-based master at 96 kHz / 24-bit the rate is 36,864,000 bytes per second, and 4 GB is under two minutes — 116.5 seconds.

Immersive masters cross that limit routinely, and a WAV writer that hits it produces either a truncated file or one whose declared sizes have silently wrapped. The EBU addressed this first with RF64 (EBU Tech 3306); the ITU took it forward as Recommendation ITU-R BS.2088 — BW64.

The sentinel trick: 0xFFFFFFFF and a ds64 chunk

BS.2088 is explicit about the mechanism. "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", and the original 32-bit size fields become escape flags: "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

That is the whole trick, and it is worth stating plainly: BW64 does not widen the RIFF size fields. It fills them with 0xFFFFFFFF as a sentinel and puts the true 64-bit sizes in a ds64 chunk that must sit first in the file. So a BW64 file under 4 GB is byte-compatible with a WAV reader in every respect except the four-character signature. Many tools accept it; some stubbornly do not.

The chunks, and the one that is exactly 40 bytes per entry

Per BS.2088 a BW64 file is expected to contain at least ds64, fmt , chna, axml (with bxml and sxml as alternative metadata carriers) and the wave data.

ds64 must be the first chunk after the signature, because a reader has to know the real sizes before it can walk anything else. It carries 32-bit low/high halves for the whole-file size and the data size, plus a table of ChunkSize64 entries for any other oversized chunk — an axml chunk describing thousands of objects with sample-accurate automation can itself approach or exceed 4 GB.

fmt is the standard WAVE format chunk — sample format, sample rate, channel count, bits per sample, block align. It is the only authoritative statement of how many interleaved channels are in data. Everything downstream is metadata about those channels, and metadata can lie.

chna is the bridge between physical tracks and the ADM. After ckID, ckSize, a 2-byte numTracks and a 2-byte numUIDs, it holds a flat array of fixed-width audioID entries, each exactly 40 bytes:

2 + 12 + 14 + 11 + 1 = 40. The widths are not advisory: they are fixed-width ASCII, and a writer that emits a 13-character UID has produced a corrupt table, not a slightly unusual one.

The ID convention matters too. Values of 0x0FFF and below refer to the ADM common definitions — the standard, pre-defined channel and pack formats — while 0x1000 and above indicate custom definitions that must be present in axml. AP_00010003 is 5.1 by common definition and needs no XML; AP_00031001 is a custom object pack and needs XML, or it dangles.

numUIDs can also legitimately exceed numTracks: EBU's guidance notes that where "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", so one trackIndex may appear in several entries. QC tools that assume one UID per track flag correct files as broken.

axml is a UTF-8 XML document containing the <audioFormatExtended> tree. That is the ADM, and where essentially all the interesting failures live. data is plain interleaved PCM; nothing in it knows anything about objects.

Ordering: ds64 first, always; fmt before data. But axml may legitimately sit after data, and often does, because — as BS.2088 observes — during recording "the XML metadata will likely be of an unknown length." A file with axml at the tail is not malformed, but a reader that only scans the first megabyte will report no ADM at all. That accounts for a surprising share of "my file has no metadata" reports.

ADM is a graph, and failures are broken edges

ITU-R BS.2076's hierarchy runs audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, with audioTrackUID as the leaf and the only element that corresponds to a physical track.

That is a graph of references, not a nested document, and every serious delivery failure is a broken edge in it. What makes a dangling reference dangerous is that there is no single behaviour when one breaks. A renderer resolving an audioPackFormatIDRef that names a pack absent from the XML may abort the parse and reject the file; may skip that object and render everything else, producing a mix quietly missing a stem; or may fall back to the common definitions, find an ID in the 0x1000-plus custom range with no match, and substitute silence. All three outcomes are "the file opened". Only one is caught by listening, and only if you know what should have been there.

The four failures that account for most rejections

A fmt track count that disagrees with chna. fmt .nChannels says 16; chna.numTracks says 14. The file is internally inconsistent from the first two chunks — usually a bounce that changed track count after the metadata was authored, or a tool that dropped tracks without rewriting chna. Detection is parsing two integers and comparing them: the cheapest check in the pipeline, and it catches a startling proportion of failures. Verify at the same time that every trackIndex lies within 1 … fmt .nChannels.

An audioTrackUID referenced by no object. A UID in chna that no audioObject references means audio exists that nothing will render; the mirror case, an audioTrackUIDRef in the XML with no matching chna entry, means metadata expects a track that isn't there. Build the set of UIDs from chna and the set from axml and take the symmetric difference; it should be empty. EBU Tech 3392 states the intent directly: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

Block timing that runs backwards. BS.2076 is unambiguous: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392 tightens that to contiguity — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — with the first block of an object starting at 00:00:00.00000, no block shorter than one sample, and durations summing to the parent audioObject. Walk the blocks in document order and assert rtime[n] + duration[n] == rtime[n+1]. Failures come in three shapes: gaps, where renderer behaviour is undefined and some hold the last position while others mute; overlaps, where blocks fight; and blocks out of chronological order, which is automation jumping backwards mid-programme.

A bed described in XML that was never printed to disk. The XML declares a 7.1.4 DirectSpeakers pack — twelve channels — but only the 5.1 subset was printed, or the height channels were muted at bounce and printed as digital black. The reference graph is intact; the audio is not. Structural checks cannot catch this: you need essence analysis, measuring whether every channel claimed by a DirectSpeakers pack contains signal at all. Digital black on a declared bed channel is not automatically an error — a legitimate mix may leave a top-rear channel empty — but it is always worth a human decision.

What is published about immersive loudness, and what isn't

One number does not survive the move from stereo, and it is worth saying why.

BS.1770-5 (November 2023) is the current edition; BS.1770-4 is superseded, though most deployed meters still cite it. Its core algorithm weights L, R and C at 1.0 and Ls and Rs at 1.41 (about +1.5 dB), excludes LFE, and is scoped to "from one to five channels". BS.1770-5 extends past that in its annexes, covering the BS.2051 advanced sound systems and object-based audio — which must be rendered before it can be measured. Immersive loudness is therefore not a property of the file but of a render, and changing the target layout changes the number. Measure a BS.2127-conformant render to a named BS.2051 layout with a BS.1770-5 meter and record all three in your delivery notes; BS.2127 defines the reference ADM renderer, and its open-source sibling the EBU ADM Renderer (EBU Tech 3388) is the practical way to get a reproducible figure.

No music streaming service publishes an integrated loudness target for immersive delivery. Figures circulate in forums and vendor training material; none is a published specification and this article will not repeat one as if it were. What is published is for channel-based stereo — Spotify's integrated target of −14 LUFS with a true-peak ceiling of −1 dBTP, tightening to −2 dBTP above −14 LUFS, and AES TD1008's −16 LUFS for music (its −18 LUFS figure applies to speech-led content, and stating −18 as the music target is a frequent and serious error).

Dolby Atmos is a proprietary, licensed technology of Dolby Laboratories, and Sony 360 Reality Audio is a proprietary system built on MPEG-H. Their requirements are set by their owners, change without reference to ITU or EBU timetables, and are not stated here; no affiliation or endorsement is claimed. Read the licensor's own current documentation.

What to check before you send it

Structural checks first; they are fast and they invalidate everything downstream.

• First four bytes are BW64. If they read RIFF, it is a plain WAV and cannot exceed 4 GB.
• ds64 is the first chunk after the signature, its 64-bit sizes match the file and data sizes on disk, and any oversized non-data chunk has a ChunkSize64 entry in the table.
• Locate axml explicitly, including after data — never conclude "no ADM" from a partial scan.
• fmt sample rate and bit depth match the delivery spec exactly. No sample-rate conversion after ADM authoring — it invalidates every rtime and duration expressed in samples.
• fmt .nChannels equals chna.numTracks; every trackIndex is in range and 1-based.
• Every chna entry is exactly 40 bytes with correctly padded fixed-width fields, and every packRef at 0x1000 or above resolves to a custom definition present in axml.
• Every audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef and audioTrackUIDRef resolves. Zero dangling edges, in either direction, with no circular references.
• Multi-block channel formats carry both rtime and duration on every block; blocks are contiguous and monotonic; objects begin at 00:00:00.00000.
• Every channel of a declared bed contains what it should. Investigate digital black.
• bext start timecode is consistent across the set, and stereo and binaural conforms are re-rendered from the current master. A conform 40 ms early against its immersive parent passes a file-presence check and fails a synchronised listen.
• Checksum every deliverable, keep the manifest, and archive the ADM XML separately from the BW64 — XML you can diff is worth more later than a binary you can only re-parse.

BW64 and ADM are open, published, freely readable standards, which is worth using: you can read BS.2088 and BS.2076 yourself, parse a chna chunk with forty lines of code, and verify what a vendor's exporter actually wrote rather than what its dialog box claimed. Almost all unnecessary immersive rejections are reference-integrity errors a validator catches in under a second.

Mazufa's free BW64/ADM inspector at mazufa.com/immersive-master-check parses the container and the metadata entirely on your own device and uploads nothing, which makes it usable on material that contractually cannot leave the building. Mazufa itself is free to release on, takes 0% commission, and is invite-only with human review of every complete application.

Sources

ITU-R Recommendations

• 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 Technical documents

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (and supplements), 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 reference implementation — 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/

Service documentation

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