BW64 and ADM: A Technical Reference for Immersive Audio Delivery

A working reference for engineers preparing object-based and scene-based masters, and for musicians who have been handed an "Atmos deliverable" and told to make it pass QC.

The 150-word answer

The Audio Definition Model (ADM) is an open metadata standard, Recommendation ITU-R BS.2076, that describes what every audio track in a file is — a speaker channel, a moving object, or an Ambisonic component — and how those tracks combine into a programme. It is carried as XML inside a BW64 container (Recommendation ITU-R BS.2088), a 64-bit extension of RIFF/WAVE that escapes the 4 GB ceiling of classic WAV. Immersive delivery keeps failing QC because the audio and the metadata are two separate things that must agree exactly, and nothing in the file format forces them to. A track count in fmt that disagrees with the chna table, an audioTrackUID referenced by no object, a block format whose timing runs backwards, a bed described in XML that was never printed to disk — each is silent to a waveform editor and fatal to a renderer. ADM QC is reference-integrity checking, not listening.

1. Three kinds of audio, and why the distinction decides the format

Before the container, the model. Every immersive delivery problem starts with a confusion about which of three things a track actually is.

Channel-based audio assigns each track to a fixed loudspeaker position. Stereo is channel-based. So is 5.1, and 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, defining loudspeaker 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, and System H is 9+10+3, the 22.2 configuration. In ADM, channel-based content uses 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, and how, based on the layout actually 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 a set of spherical-harmonic components. No component corresponds to a direction on its own; direction emerges from the linear combination. This is typeDefinition HOA, typeLabel 0004. ADM also defines Matrix (0002) for matrixed signals such as Mid-Side or Lt/Rt, and Binaural (0005) for headphone-ready pairs.

Channel-based audio tells the file where the loudspeakers are; object-based audio refuses to guess, and scene-based audio describes the field rather than the sources.

This is not taxonomy for its own sake. 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 the entire reason BW64 and ADM exist, and the entire reason immersive QC is harder than stereo QC.

2. BW64: what it is and precisely why it exists

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 file as a whole 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 the limit routinely, and a WAV writer that hits it produces either a truncated file or a file whose declared sizes have silently wrapped.

The EBU addressed this first with RF64 (EBU Tech 3306). The ITU then took that work forward as Recommendation ITU-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata — BW64. 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 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.

BW64 is best understood as the third generation of a single lineage. RIFF/WAVE gave the chunked container. Broadcast Wave (BWF, EBU Tech 3285) added the bext chunk — originator, timecode reference, coding history — turning WAV into a broadcast interchange format. BW64 keeps all of that, adds 64-bit addressing, and adds the chunks that carry ADM. A BW64 file under 4 GB is byte-compatible with a WAV reader in every respect except the four-character file signature; many tools accept it, and some stubbornly do not.

3. The chunk layout in detail

A BW64 file, per BS.2088, is expected to contain at least <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (with <bxml-ck> and <sxml-ck> as alternative metadata carriers) and <wave-data>.

ds64 — the 64-bit size table

Must be the first chunk after the BW64 signature, because a reader has to know the real sizes before it can walk anything else. Its fields are 32-bit halves of 64-bit quantities:

The table[] matters more than it looks. An axml chunk describing thousands of objects with sample-accurate automation can itself approach or exceed 4 GB; the table is how any chunk other than data declares a 64-bit size.

fmt — the essence description

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

chna — the channel allocation table

chna is the bridge between physical tracks and the ADM. It opens with:

• ckID — 4 bytes, 'chna'
• ckSize — 4 bytes
• numTracks — 2 bytes, tracks in the file
• numUIDs — 2 bytes, audioTrackUID entries that follow

Then a flat array of fixed-width audioID entries. Each entry is exactly 40 bytes:

2 + 12 + 14 + 11 + 1 = 40. The field 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.

Note also the ID convention: 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 the axml chunk. A packRef of 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.

A track UID is the file's serial number for one physical track's identity, and it exists so that a track can legitimately change what it carries partway through a programme.

That last point is the reason numUIDs can 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." A trackIndex may therefore appear in several entries. QC tools that assume one UID per track flag correct files as broken.

axml — the ADM itself

An XML document, UTF-8, containing the <audioFormatExtended> tree. This is the ADM. It is text, it is inspectable, and it is where essentially all of the interesting failures live.

data — the interleaved PCM

Plain interleaved samples, exactly as in WAV. Nothing in data knows anything about objects.

Ordering. ds64 first, always. fmt before data. axml may legitimately be placed after data, and often is, 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; a reader that only scans the first megabyte will nonetheless report no ADM at all. This single fact accounts for a surprising share of "my file has no metadata" reports.

4. The ADM object model

ITU-R BS.2076 splits the model into two halves. The format part "describes the technical nature of the audio so it can be decoded or rendered correctly" and can be authored before any audio exists. The content part describes "the language of dialogue, the loudness, etc." and can only be completed once signals exist. Understanding which half an element belongs to tells you which stage of production introduced a given error.

The hierarchy, top down:

• audioProgramme — one complete deliverable presentation. References one or more audioContent.
• audioContent — a component of the programme with editorial meaning: dialogue stem, music stem, a language version. References one or more audioObject.
• audioObject — the join between editorial intent and technical format. It carries start time and duration, and it references zero or more audioPackFormat, zero or more nested audioObject, and zero or more audioTrackUID. This is where content meets essence.
• audioPackFormat — a group of channels that belong together: a 7.1.4 bed, a stereo pair, an HOA set of a given order. References audioChannelFormat elements, and may nest other packs.
• audioChannelFormat — one channel's behaviour over time. Contains one or more audioBlockFormat.
• audioBlockFormat — the atom. For Objects, a position (azimuth/elevation/distance or Cartesian X/Y/Z), gain, size, diffuseness, plus rtime and duration. A static object is one block; a moving object is a sequence.
• audioTrackUID — the leaf, and the only element that corresponds to a physical track. Carries optional sampleRate and bitDepth attributes and references an audioTrackFormat and an audioPackFormat.

audioStreamFormat and audioTrackFormat sit between channel format and track UID and describe stream encoding. BS.2076-3 notes that for PCM they are effectively redundant — "the audioStreamFormat and the audioTrackFormat should be omitted" — but that readers "should be aware that existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain" them. Both shapes are legal. A validator that insists on one is wrong about the other.

ADM is a graph of references, not a nested document, and every serious delivery failure is a broken edge in that graph.

What actually goes wrong when a reference dangles. There is no single behaviour, which is the problem. 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 that is quietly missing a stem; or may fall back to the common definitions, find an ID in the 0x1000+ custom range with no match, and substitute silence. All three outcomes are "the file opened". Only one of them is caught by listening, and only if you happen to know what should have been there. Dangling references are the reason ADM QC has to be automated: a human ear cannot hear an absence it was never told to expect.

5. The common QC failures, and how to detect each

5.1 Channel count mismatch between fmt and chna

fmt.nChannels says 16; chna.numTracks says 14. The file is internally inconsistent from the first two chunks. Usually caused by a bounce that changed track count after the metadata was authored, or by a conforming tool that dropped tracks without rewriting chna.

Detection: parse both chunks and compare integers. This is the cheapest check in the entire pipeline and catches a startling proportion of failures. Also verify that every trackIndex in chna lies within 1 … fmt.nChannels.

5.2 Orphaned track UIDs

A UID present in chna that no audioObject references, or an audioTrackUIDRef in the XML with no matching chna entry. The first means audio exists that nothing will render; the second means metadata expects a track that isn't there.

Detection: build the set of UIDs from chna and the set from axml, and take the symmetric difference. It should be empty. EBU Tech 3392 makes the intent explicit: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

5.3 Block formats with missing or non-monotonic timing

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 it to a contiguity rule — "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 the sum of durations matching the parent audioObject.

Detection: for each audioChannelFormat, walk the blocks in document order and assert that rtime[n] + duration[n] == rtime[n+1]. Failures cluster into three shapes: gaps (renderer behaviour undefined — some hold the last position, some mute), overlaps (blocks fighting), and blocks out of chronological order (automation that jumps backwards mid-programme).

5.4 Incorrect sample rate or bit depth

audioTrackUID may carry sampleRate and bitDepth attributes. When they contradict fmt , you have two claims about the same essence. EBU Tech 3392's position is that these "Should be ignored if available from the audio essence" — but not every renderer follows that guidance, and a file that says 48 000 in one place and 96 000 in another will be interpreted differently by different tools. Separately, confirm that the rate is the one the delivery specification asks for: sample-rate conversion applied after ADM authoring invalidates every rtime and duration expressed in samples.

Detection: compare fmt against every sampleRate/bitDepth attribute in the XML; flag any disagreement even though it is nominally tolerable.

5.5 Conformed stereo or binaural deliverable missing, or out of sync

Most immersive deliveries require a stereo (and often a binaural) conform alongside the immersive master. The recurring failure is not absence — absence is obvious — but drift: the conform was rendered from an earlier version, is a few frames offset, or has a different start timecode. A stereo file that is 40 ms early against its immersive parent will pass a file-presence check and fail a synchronised listen.

Detection: compare durations sample-for-sample, compare start timecode from bext, and cross-correlate the conform against a null render of the master. Treat any conform that is not byte-derivable from the current master as suspect and re-render rather than re-check.

5.6 Metadata describing a bed that isn't in the file

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.

Detection: structural checks cannot catch this. You need essence analysis: for every channel claimed by a DirectSpeakers pack, measure whether the track 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.

The container can be perfectly valid, the XML perfectly well-formed, and the deliverable still wrong; the only check for an empty bed channel is to look at the samples.

A free browser-based BW64/ADM inspector at mazufa.com 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.

6. Loudness for immersive audio — what is actually specified

Here it is important to separate what is published from what circulates.

What ITU-R BS.1770 specifies. BS.1770 defines K-weighting: a high-shelf "head" filter modelling a rigid sphere, followed by an RLB high-pass. The curve's gain at 1 kHz is +0.698 dB (linear 1.0836). Measurement uses 400 ms gating blocks with 75 % overlap, an absolute gate discarding blocks below −70 LKFS, and a relative gate computed from the mean of the blocks that survived the absolute gate, then offset by −10 LU. That relative gate is computed from the surviving blocks, not the ungated mean — a distinction implementations get wrong often enough to matter.

Channel weighting in the core algorithm is 1.0 (0 dB) for L, R and C, and 1.41 (≈ +1.5 dB) for Ls and Rs, with LFE excluded. The base algorithm is scoped to "from one to five channels". BS.1770-5 extends beyond this in its annexes, covering the advanced sound systems of BS.2051 — arbitrarily positioned loudspeakers and height channels — and object-based audio, which must be rendered before it can be measured.

Immersive loudness is not a property of the file; it is a property of a render, and changing the target layout changes the number.

That is the substantive difference from stereo. A stereo master has one loudness value. An object-based master has as many as it has render targets, and the honest way to state a figure is to name the layout it was measured on and the renderer used — ITU-R 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 number.

Related EBU documents. EBU Tech 3341 defines the meter behaviours (momentary 400 ms, short-term 3 s). EBU Tech 3342 defines Loudness Range, which uses a −20 LU relative gate — not −10 LU; using −10 for LRA is a common implementation bug. EBU R 128 sets the broadcast programme target of −23 LUFS. R 128 is a broadcast normalisation practice, not a music-streaming spec.

What is published for music. For channel-based stereo music, Spotify publishes an integrated target of −14 LUFS and a true-peak ceiling of −1 dBTP, tightening to −2 dBTP for masters louder than −14 LUFS. AES TD1008 recommends −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.

What is not published. No music streaming service publishes an integrated loudness target for immersive delivery. Figures circulate widely in forums and in vendor training material; several are plausible and some are probably right. None of them is a published specification, and this document will not repeat one as if it were. Apple Music, YouTube Music, Amazon Music, TIDAL and Deezer publish no normalisation target for stereo either — the commonly cited numbers for those services are widely reported but not published by the services themselves, and should never be treated as a spec you can compute a gain change from.

Broadcast and film are better documented than music, because broadcasters publish. If you need a defensible immersive loudness figure today, measure a BS.2127-conformant render to a named BS.2051 layout using a BS.1770-5 meter, and state all three in your delivery notes.

On proprietary systems. Dolby Atmos is a proprietary, licensed technology of Dolby Laboratories, and Sony 360 Reality Audio is a proprietary system built on MPEG-H. Their delivery requirements are set by their owners and change without reference to ITU or EBU timetables. Nothing in this document constitutes a statement of any of those companies' requirements, and no affiliation, certification or endorsement is claimed or implied. Where a licensor publishes a requirement, read the licensor's own current documentation and cite that.

7. Practical delivery checklist

Work through this in order. Structural checks first — they are fast and they invalidate everything downstream.

Container

1. First four bytes are BW64. If they are RIFF, the file is a plain WAV and cannot exceed 4 GB.
2. ds64 is the first chunk after the signature, and its 64-bit sizes match the actual file and data sizes on disk.
3. Any oversized non-data chunk has a ChunkSize64 entry in the ds64 table.
4. Locate axml explicitly, including after data. Do not conclude "no ADM" from a partial scan.

Essence

1. fmt sample rate and bit depth match the delivery spec exactly. No SRC after ADM authoring.
2. fmt.nChannels equals chna.numTracks.
3. Every trackIndex in chna is within range and 1-based.

chna integrity

1. Every entry is exactly 40 bytes with correctly padded fixed-width fields.
2. Every packRef at 0x1000 or above resolves to a custom definition present in axml.
3. Repeated trackIndex values are intentional (a track legitimately changing definition), not duplication errors.

ADM graph

1. Every audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef and audioTrackUIDRef resolves. Zero dangling edges.
2. No orphaned audioTrackUID in either direction.
3. No circular or self-referencing elements.
4. typeLabel on each audioChannelFormat matches its parent audioPackFormat.

Timing

1. Multi-block channel formats carry both rtime and duration on every block.
2. Blocks are contiguous and monotonic; durations sum to the parent audioObject duration.
3. Objects begin at 00:00:00.00000.

Content

1. Every channel of a declared bed contains what it should; investigate digital black.
2. Object count and bed configuration match the delivery spec.
3. bext start timecode is correct and consistent across all deliverables in the set.

Renders and conforms

1. Stereo and binaural conforms are re-rendered from the current master, not carried forward.
2. Durations and start timecodes match the master sample-for-sample.
3. Loudness measured on a named render to a named layout with a named renderer, and all three recorded in the delivery notes.

Reproducibility

1. Checksum every deliverable and keep the manifest.
2. Archive the session and the ADM XML separately from the BW64; XML you can diff is worth more later than a binary you can only re-parse.

An immersive deliverable is not finished when it sounds right; it is finished when a machine that has never heard it can prove its references resolve.

8. Closing note

BW64 and ADM are open, published, freely readable standards. That is unusual in this corner of the industry and it 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. Immersive audio is where the largest share of unnecessary rejections still happen, and almost all of them are reference-integrity errors that a validator catches in under a second.

Mazufa's distribution is free — no upload fee, no subscription, no per-release charge — with a 5% share of royalties received.

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.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.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
• ITU-R BS.2127 landing page — https://www.itu.int/rec/R-REC-BS.2127

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/docs/tech/tech3388.pdf and https://tech.ebu.ch/publications/tech3388
• 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 R 128, EBU Tech 3341 (meters), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• 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) documentation, BW64 I/O — https://ear.readthedocs.io/en/latest/BW64.html
• libbw64 reference implementation — https://github.com/ebu/libbw64
• libadm reference implementation — 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/

Service documentation

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

Last reviewed September 2026. Standards are revised; always check the ITU and EBU pages above for the current edition before quoting a clause number.