Content
ADM stands for Audio Definition Model. It is an XML metadata format, standardised as ITU-R BS.2076, that describes what each audio track in a file is and where it belongs in space. It carries no audio itself. It is the document that tells a renderer how to turn a pile of channels back into a scene.
Disclaimer: the first draft of this article came out of an AI and was mostly adjectives. I rewrote it around the parts that matter when you actually have to deliver a file.
ADM is a description language for object-based audio. Where a stereo file assumes track one is left and track two is right, an ADM file makes no assumptions at all. Every track is described explicitly: what it contains, whether it is a channel, an object or a sound field, and if it is an object, where it sits and how that position changes over time.
It was developed at the request of BBC R&D and standardised by the ITU. The point was to have one neutral way of describing a spatial production, so that a mix could survive the trip between a studio, a broadcaster and a consumer device that nobody had specified in advance.
Classically, the audio chain has five steps: record, mix, monitor while mixing, deliver, and play back at the consumer. In the traditional workflow, step two is chained to step four. You mix in exactly the format you deliver. A 7.1 delivery means an eight-channel mix, monitored on eight speakers.
Object-based audio breaks that chain. You no longer mix a channel layout, you mix a scene, and the renderer at the far end decides what comes out of how many speakers. That only works if the scene travels with the audio, described precisely enough that a renderer which has never seen your studio can reconstruct it. ADM is that description.
The metadata sits inside a BW64 file, the 64-bit successor to Broadcast Wave defined in ITU-R BS.2088. Two chunks do the work:
| Chunk | Contents |
|---|---|
axml |
The complete ADM description as XML |
chna |
The mapping from each audio track in the file to its ADM identifier |
Inside the XML, the model is a hierarchy:
The practical consequence: an ADM BWF is a single self-contained file. Hand it over and the recipient needs no session, no plugin list and no explanation of your bussing.
If you have delivered a Dolby Atmos music master, you have already made an ADM file. The Atmos deliverable is an ADM BWF, written by the Dolby Atmos Renderer, containing the bed channels, the objects and their automation.
There is a limitation worth knowing before you rely on the format for a headphone-first release. Dolby Atmos does not transmit distance information. Position, yes. How far away the object is, no. If you want distance you tag it by hand, usually by managing reverb and level yourself, because the format will not carry the intent for you.
This is also why an Atmos mix can arrive technically correct and still sound flat over headphones. The metadata described where things were, not how far.
The standard ADM sits in a file, which is fine for a finished production and useless for a live broadcast. For that there is Serial ADM, standardised as ITU-R BS.2125, which chops the same model into time-aligned frames that can be carried alongside a live stream.
The relevance for most people is indirect but real. It is the reason a live event can be produced object-based at all, rather than being flattened to a fixed channel layout at the outside broadcast truck.
The Dolby Atmos Renderer in the Production Suite and Mastering Suite writes and reads ADM BWF. Nuendo and Pro Tools can deliver into it. The EBU and the ITU publish open reference tools, including a free renderer, which is the honest way to check whether your file says what you think it says.
The important habit is to verify before delivery rather than after rejection. An ADM file that opens is not the same as an ADM file that is correct, and the failure mode is silent: objects land in the wrong place instead of the file refusing to load.
The push behind it was ORPHEUS, an EU Horizon 2020 research project that built an end-to-end object-based audio pipeline with broadcasters, research institutes and manufacturers involved. The goal was infrastructure rather than a product: recording, production, distribution and playback that all speak the same object language.
That origin explains the shape of the standard. It is deliberately not tied to a vendor, which is also why it works as a neutral exchange format between systems that otherwise share nothing.
Audio Definition Model, the ITU-R BS.2076 metadata standard for describing object-based and scene-based audio productions.
A BW64 wave file that carries the audio tracks plus the ADM description of them in its axml chunk. It is the standard deliverable for Dolby Atmos music.
No. It stores no audio and compresses nothing. It is metadata that describes audio stored alongside it, which is exactly why it can be used with different codecs downstream.
It will usually play as a multichannel wave file, because the audio is stored uncompressed. What you will not get is the spatial arrangement, since a normal player ignores the metadata chunk.
The model has provision for it, but Dolby Atmos does not transmit distance information, so in the most common workflow you handle distance yourself through reverb and level.
ADM describes a complete file. Serial ADM, ITU-R BS.2125, carries the same model as a stream of frames so it can be used live.
Back to the BlogNeed to deliver object-based and want to know whether your ADM arrives clean?
Get in touch →Related Articles
VRTonung learning - THE spatial audio course for immersive media
Martin Rieger, 3D Audio expert committing his life to immersive experience
MPEG-H Audio vs. "Dolby Atmos" - there is a winner!
What Is Spatial Computing? A New Dimension in Digital Communication
Spatial Computing Sound Experiences with Apple's RealityKit Audio - VRTONUNG - Virtual Reality Sound