Skip to content

ADM PLUGFEST No 1 - June 2026

("virtual" = file exchange)

CONCEPTION

Interoperability

The primary objective of this plugfest was to exercise the ability of various commercial and non-commercial tools to handle the ITU-R BS.2168-0 (Advanced Sound Systems Emission Profile). The ITU-R BS.2168-0 standard defines various operating levels. In order to constrain the scope of the plugfest, the following additional objectives had been established and are collectively known as Phase A:

  • ITU AdvSS Emission Profile Level 1
  • "DirectSpeakers"-only
  • Mono/2.0/5.1/5.1.4 pack formats only
  • No interactivity or gain control

Test Vectors

The plugfest revolved around the handling of ADM & S-ADM constrained by interoperability Phase A in the context of BW64 & MXF containers.
Various mappings were tested:

  • BW64 Profile A: <axml>
  • BW64 Profile B: <bxml> (gzip)
  • BW64 Profile S: <sxml>
  • MXF OP1A ST2131: wrapped BW64 Profile A
  • MXF OP1A ST2127: S-ADM

Regarding the BW64 variants, the objective is to test the level of support for Constrained BW64 Specification

Test Vector Objective
1.1.1 Single Stereo Program Mux two mono WAV files into a BW64 file with a single stereo program ITU-R BS.2168-0 Profile/Level 1 ADM metadata must be generated by the muxer
1.1.2 Single 5.1 Program Mux 6 mono WAV files into a BW64 file with a single 5.1 program ITU-R BS.2168-0 Profile/Level 1 ADM metadata must be generated by the muxer
1.1.3 Single 5.1.4 Program Mux 10 mono WAV files into a BW64 file with a single 5.1.4 program ITU-R BS.2168-0 Profile/Level 1 ADM metadata must be generated by the muxer
1.1.4 EBU R123 Dual 5.1 & Stereo Program Mux two mono & six mono WAV files into a BW64 file with a dual 5.1 & stereo program ITU-R BS.2168-0 Profile/Level 1 ADM metadata must be generated by the muxer R 123 8a & 8b
1.1.5 Four Stereo Programs Mux four stereo WAV files into a BW64 file with four stereo programs ITU-R BS.2168-0 Profile/Level 1 ADM metadata must be generated by the muxer
1.1.6 ARD/ZDF Delivery Specification Mux six multi-channel WAV files into a BW64 file with six programs ITU-R BS.2168-0 Profile/Level 1 ADM metadata must be generated by the muxer ARD/ZDF typical 16ch audio five stereo-files and a 5.1 file to four stereo + 5.1 + Stereo
1.1.7 RAI Delivery Specifications Mux two stereo WAV files + two multichannel WAV files into a BW64 file with four programs ITU-R BS.2168-0 Profile/Level 1 ADM metadata must be generated by the muxer.
1.1.8 ITU-R BS.1738-1 Program Scenario 2 Mux two mono & one stereo WAV files into a BW64 file with a stereo & two mono programs

After the plugfest, the Constrained BW64 Specification will be presented for review to EBU expert groups. After the review period and granted that the draft is accepted, the draft will be submitted to ITU as a request for consideration. The ITU group in charge of ADM-related documents may use the EBU draft to update the ITU documents

Workflows

The plugfest aimed at simulating real-world workflows where ADM & S-ADM content is assembled from simple audio elements (stems) and ADM & S-ADM metadata is generated by the participant's tool(s).
While it was expected that the participant's tools performs all the tasks programmatically, it was allowed to generate the ADM & S-ADM metadata manually.

The participants were encouraged to test their ability to encode & decode their own files as well as the ones generated by other participants for fully interoperability testing.

The MXF variants were be created from the BW64 ADM/S-ADM source files in order to simulate typical conversions occurring in real-world workflows The correct carriage of ADM & S-ADM metadata and container metadata correctness were key elements for a successful participation.

In addition a number of "features of interest" have been tested. Participants were required to report various issues encountered during ADM & S-ADM generation, parsing & validation, as well as file generation, conversion or trans-wrapping.

The issues were discussed at the group level and participants encouraged to fix their implementation and submit corrections.

Features of interest

The plugfest aimed at testing the capability of a participant's tool(s) to handle:

  • Profile(s) signaling
  • ADM & S-ADM metadata generation
  • Phase A constraints on ADM & S-ADM (e.g. loudness metadata, dialogue kind, etc)

CONCLUSIONS

Over a period of four weeks, some 400 files were created, exchanged, tested and evaluated by participating partners in weekly review sessions.
The steep learning curve lead to clarify previous misconceptions and helped to formulate best practices for numerous aspects in applying ADM such as:

  • MXF: Profile Signaling

    When wrapping ADM or S-ADM content in MXF ST2131 or MXF ST2127, it is highly recommended to signal the ADM/S-ADM profiles at the MXF header metadata level. This process requires the translation of ADM/S-ADM profile definitions into SMPTE ULs. SMPTE ULs are available for inspection via the SMPTE Registry tools. While this may be an easy task for specialists, the exact correspondence may not be obvious for everyone. Both ADM and S-ADM MXF mappings signal ADM Profile/Level in the same way – it's just that the property used has a different name in each For ADM (ST 2131) it's ADMProfileLevelULBatch in the ADMAudioMetadataSubDescriptor For S-ADM (ST 2127-10) it's SADMProfileLevelULBatch in the SADMAudioMetadataSubDescriptor Action Write-up and publish the advice (above) through the ADM-IG The participants recommend the creation of a simplified lookup table and published through ADM-IG.

  • MXF: Multi-Channel Audio (MCA) labeling approach

    Create one MCA "MGA/ADM Soundfield Group" for each audioProgramme element in the (S-)ADM metadata. The MXF Header Metadata contains a simple summary of the audioProgrammes in the (S-)ADM metadata (with their ADM ID, title/label, and language) MXF Header Metadata contains essential details about the properties of the video (resolution, video codec parameters, etc) and audio (sampling rate, bit depth, etc) etc so that the file can be handled appropriately without access to, and certainly without parsing, the essence. Action: Write-up and publish the advice (above) through ADM-IG.

  • Audio Programme Name & Labels

    Audio programme labels are optional. They are typically used by downstream encoders to produce selectable configurations for consumer devices where the programme name can be localised. Audio programme names are typically used by professional tools only and do not reach the consumer devices, unless audio programme labels are absent. It is expected that the audio programme names are unique in the ADM/S-ADM metadata, although they are not strictly speaking used by the ADM renderer to influence processing. The group recommends the verification of audio programme uniqueness and it enforcement during ADM metadata creation. A QC test should be defined to detect violations of this recommendation.

  • Dialogue Content Kind ITU-R BS.2076-3, section 5.7.3, table A1-35 defines a number of possible combinations for the attributes and value of the dialogue element. Some combinations are similar but not duplicates. However in the definition of delivery specifications, it is not always obvious to the reader which combinations must be selected (e.g. for audio description). It is highly desirable to define the preferred combinations for practical use cases and include the recommended combinations in delivery specifications to avoid content rejection during ingest or QC failure.