Orbit Docs

ADM Basics ​

You don't need to be an ADM expert to use Orbit, but understanding a few key concepts will help you make sense of what you're seeing. This page covers the essentials — what ADM files contain, how beds and objects differ, and how Orbit interprets the format.

What is an ADM BWF file ​

An ADM BWF is a broadcast wave file that carries ADM (Audio Definition Model) metadata for immersive audio. It includes:

  • Programme information (what the mix is called, timing, and structure).
  • Beds (channel-based audio elements).
  • Objects (independent elements with positions that can change over time).

If you want deeper background:

Beds vs objects (and ambisonics) ​

ADM defines a small set of typeDefinition values for each audio element. The three that matter in practice:

  • Beds (DirectSpeakers) — a fixed channel layout that anchors the mix.
  • Objects (Objects) — elements that move freely in 3D space with automated position, gain, and width.
  • Ambisonics groups (HOA, Higher-Order Ambisonics) — a full 3D soundfield encoded as spherical-harmonic channels. Common in EBU-profile ADM where there's no bed and all content is HOA + objects.

(BS.2076-3 also defines Matrix and Binaural type definitions for specialised use cases; Orbit does not currently decode those.)

Orbit decodes beds, objects, and HOA. HOA groups are supported up to 3rd order (16 channels) in ACN channel ordering, with SN3D (default per BS.2076-3), N3D, or FuMa normalization — all of which are parsed from the <order>, <degree>, and <normalization> elements in the ADM metadata. HOA groups route through a precomputed decode matrix into the same 7.1.4 speaker bus as beds and objects, so binaural and stereo fold-down work identically regardless of whether the source is channel-based or ambisonics.

Bed format ​

BS.2076-3 doesn't cap the size of a DirectSpeakers bed — the ADM specification supports arbitrary speaker configurations. In practice, the size ceiling comes from whichever profile you're delivering to: the Dolby Atmos Master ADM Profile v1.1 fixes beds at 7.1.2 maximum (L, R, C, LFE, Ls, Rs, Lrs, Rrs, Ltf, Rtf — 10 channels). Orbit is optimized for that profile.

Orbit's internal monitoring bus is always 7.1.4 (12 channels), so a 7.1.2 bed is mapped directly onto that bus with the two rear-top channels (Ltb, Rtb) left silent. The detected bed format is displayed as a badge in the sidebar header.

Using other bed formats?

Orbit is built to read smaller bed configurations (such as 5.1 or 7.1) and will map them using VBAP, but these are less battle-tested as they're difficult to produce with mainstream Atmos tooling. If you're working with non-7.1.2 beds and encounter issues, get in touch — we'd love to chat and make sure Orbit reads your files correctly.

Why this matters in QC ​

  • Beds confirm channel mapping and overall stability.
  • Objects reveal motion errors, missing automation, or level issues.

How Orbit reads ADM (standards compliance) ​

  • Reads ADM metadata from the AXML and CHNA chunks inside the BWF container. Files without those chunks are rejected rather than loaded empty. (BS.2076-3 doesn't strictly mandate programme / content elements, but Orbit requires a usable structure to QC against.)
  • Follows ADM Cartesian coordinates per ITU-R BS.2076 (X=left/right positive-right, Y=back/front positive-front, Z=bottom/top positive-up), translating to the chosen monitoring output while preserving spatial intent.
  • Beds up to 7.1.2 are mapped onto Orbit's 7.1.4 monitoring bus; smaller bed configurations (5.1, 7.1) fall back to VBAP panning across the 7.1.4 layout. Object elements carry their position, gain, and metadata through to playback.
  • Object position keyframes are parsed as sparse points with linear interpolation between them. The jumpPosition attribute is parsed and preserved in the model, but Orbit does not currently constrain the interpolation length between jumps — a tight jump plays as a quick linear ramp rather than a hard step.
  • Objects are distributed across the 7.1.4 speaker set (excluding LFE) using position-driven panning. Users can choose LBAP (the Dolby-matched default) or VBAP (the forward-fallback legacy algorithm) as the object panning mode. Binaural and stereo outputs are derived from this same speaker field.
  • Beds also support two routing modes, selectable during playback: Direct (beds whose positions match a speaker go straight to that channel; others use VBAP) and Distributed (all beds pan through VBAP across the speaker set).

How Orbit differs from the Dolby Renderer ​

  • Orbit is a QC and playback tool; it does not author, encode, or export ADM/Atmos masters.
  • Uses its own rendering pipeline for 7.1.4 speakers, binaural, and stereo fold-down with clear channel mapping.
  • Not a replacement for Dolby's deliverable checks, encoding workflows, or certification processes.
  • Orbit is independent and not affiliated with or endorsed by Dolby. Always validate final deliverables in your Dolby toolchain if certification is required.

Dolby Atmos Master ADM Profile v1.1 ​

  • Orbit supports the Dolby Atmos Master ADM Profile v1.1, reading AXML and CHNA metadata from BWF containers.
  • DirectSpeakers beds (up to 7.1.2 per the profile) are mapped onto Orbit's 7.1.4 monitoring bus; objects carry their position, gain, and metadata through playback.
  • Uses ADM Cartesian coordinates (ITU-R BS.2076) throughout, mapping to speakers and then to binaural or stereo outputs.
  • Object position automation is parsed as sparse keyframes with linear interpolation. The jumpPosition attribute is preserved in the model but not yet constrained during playback.
  • Supports RF64/BW64 containers. Files missing the ADM chunks Orbit needs (AXML / CHNA) are rejected at load.
  • Content plays without strict URN enforcement, but you should validate deliverables in Dolby tools for certification.
  • Orbit does not read the Dolby Audio metadata (dbmd) chunk — dbmd is Dolby-proprietary and outside the BS.2076 ADM specification. Include and validate it in Dolby tools when preparing certified deliverables.

INFO

You do not need to edit or author ADM data in Orbit. The goal is to verify the playback behavior.

Orbit documentation by South Loop Studios

© 2026 South Loop Studios