In addition to the common WAVE chunks, the following extension chunks can appear in a Broadcast Wave file: • Original Bext chunk (Broadcast Extension - 'bext') •
iXML chunk ('iXML') • Quality chunk ('qlty') • MPEG audio extension chunk ('mext') • Peak Envelope chunk ('levl') • link chunk ('link') • axml chunk ('axml') Since the only difference between a BWF and a "normal" WAV is the extended information in the file header (Bext-Chunk, Coding-History, etc), a BWF does not require a special player for playback. This compatibility also preserves the
filesize limitation that WAV files have (4 GB of audio data per data chunk). In order to be able to store audio which would exceed this limit, 2 different chunks exist allowing the audio material to be spread across several files:
cont &
link (see list above) Since there is no official naming convention for these subsequent files, and it is still desirable to see at a glance which ones belong to a continuous piece of audio, a lot of programs apply a numbering scheme to the file suffix:
.wav, .w01, .w02, ..., .wNN. Each of those segments is a regular Wave/BWF file, but players that are aware of the continue/link chunk will treat all segments as one single, long piece of audio when opening the first segment ".wav". As an extension,
RF64 is a BWF-compatible multichannel file format enabling file sizes to exceed 4 GB was specified in 2006. The axml (additional XML) chunk allows users to incorporate data compliant with the XML format with the audio; the chunk may contain data fragments from one or more schema. In August 2012, the European Broadcasting Union published a specification for embedding
International Standard Recording Code (ISRC) in the axml chunk of the Broadcast Wave Format. BWF is specified for use in
MXF by
SMPTE standard 382. BWF is specified for use in
AES31. == See also ==