.WAV File Format

Introduction

BW64 is the long-form audio file of Recommendation ITU-R BS.2088, “Long-form file format for the international exchange of audio programme materials with metadata”. It is a WAV file made for broadcast programmes that can run past 4 GB and that carry object-based or immersive sound: like EBU RF64, it gives large sizes in 64 bits in a ds64 chunk, and it carries Audio Definition Model (ADM) metadata, which says what each track is and where its sound belongs.

The ITU published BS.2088-0 in October 2015, BS.2088-1 in October 2019 and BS.2088-2 in November 2025. The Recommendation “uses the core elements of the format as described in EBU Tech 3306”, the RF64 specification. What the two revisions changed is not described here: the ITU’s documents could not be read for this page.

A file dropped on any page of this site opens in the explorer, which shows every chunk and field, the 64-bit sizes, the channel allocation and the ADM XML, and the waveform of PCM audio. No BW64 file was among the files examined for this site, so this page is written from the specifications and the reference software.

What makes it separate

A BW64 file starts with its own signature, BW64, where an RF64 file has RF64 and an ordinary WAV file RIFF. On this site a new signature makes a new format, since a reader that checks for one turns the other away. Apart from the signature, the layout is RF64’s:

• the outer size at offset 4 is 0xFFFFFFFF, and the real size is in the ds64 chunk;
• the ds64 chunk comes first, straight after WAVE, and holds the real sizes of the outer chunk and the data chunk, and of any other chunk too big for 32 bits;
• any chunk whose 32-bit size is 0xFFFFFFFF takes its size from ds64.

A reader that knows only 32-bit WAV reads the sizes of a large BW64 file as garbage.

What it adds

BW64 is built around ADM metadata (ITU-R BS.2076):

• an axml chunk holds the ADM description as XML;
• a chna chunk ties each track of the audio to the ADM’s IDs;
• bxml holds the XML in compressed form, and sxml holds XML split up to follow the audio in time. Their layouts are not confirmed here.

Wikipedia’s account adds that BW64 “replaces binary format metadata chunks”, such as bext, with XML, and that it no longer leans on the format chunk’s channel mask, since the ADM describes the loudspeaker positions itself. These points could not be checked against the Recommendation.

Structure

Every number is little-endian, as in an ordinary WAV file. See BW64 header and chunks.

The format chunk, the samples and the optional chunks are read as in an ordinary WAV file; only the sizes differ.

Telling it apart

The explorer’s parser for this format checks two things: bytes 0 to 3 are BW64 and bytes 8 to 11 are WAVE. After that it reads the file as it reads RF64. A missing ds64 chunk, a ds64 chunk that is not first, an outer size that is not 0xFFFFFFFF, and a ds64 size that disagrees with the file’s length are reported, not refused.

Other readers are stricter. libbw64, the EBU’s reference library, refuses a BW64 file whose first chunk is not ds64 (“mandatory ds64 chunk for BW64 or RF64 file not found”), and FFmpeg’s format probe gives a BW64 file full marks only when ds64 is at offset 12.

Browsers do not play BW64 files as a rule. The explorer decodes the samples itself, up to a limit, to draw and play the waveform.

Variants

• Waveform audio (RIFF) – the usual WAV file: little-endian chunks with 32-bit sizes
• Big-endian waveform audio (RIFX) – the same chunks with big-endian numbers
• EBU RF64 audio (RF64) – 64-bit sizes in a ds64 chunk, for files over 4 GB
• ITU-R BW64 audio (BW64) – RF64’s layout with Audio Definition Model metadata

Links