|Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact|
|Full name||EBU Broadcast Wave Format, Version 1|
File format intended for the exchange of audio material between different broadcast environments and equipment based on different computer platforms. Based on the Microsoft WAVE audio file format, Broadcast Wave adds a required "Broadcast Audio Extension" (bext) chunk to hold the minimum information considered necessary for broadcast applications. Additional metadata chunks have also been developed; see Notes.
A good description has been provided by the PRONOM format registry (consulted May 27, 2010): "Broadcast WAVE is a chunk-based audio format developed by the European Broadcasting Union, and based on the Microsoft WAVE format, which is in turn based on the generic Resource Interchange File Format (RIFF) specification developed by Microsoft and IBM. Structurally, a BWAVE file is composed of a number of chunks, each comprising a four character code chunk identifier, the chunk size, and the chunk data. It comprises a RIFF header with a WAVE data type identifier, followed by a series of chunks. Every file must include a Broadcast Audio Extension ('bext') chunk, containing metadata required for exchange of information between broadcasters, a Format chunk, which describes the format of the audio data, and a Data chunk, containing the audio data itself. BWAVE files which contain MPEG-encoded audio data must also include a Fact chunk, containing file-dependent information about the audio data, and an MPEG Audio Extension chunk, containing extra information required to describe the MPEG encoding."
According to Indiana University's Sound Directions: Best Practices for Audio Preservation(consulted June 1, 2010): "The audio contained in a BWF file can be reproduced by any software that can read a .wav file, although software applications that do not support the format will not be able to access the metadata in the 'bext' chunk. A Broadcast Wave file also carries an embeddable sample accurate timestamp that enables it to be placed in the appropriate spot on a destination timeline on any computer workstation with software that supports the format."
For preservation reformatting, archivists prefer LPCM encoding. The Broadcast WAVE format, however, also wraps MPEG audio formats; one of the bext metadata elements (CodingHistory) lists the MPEG options in these terms: "layer (I or II) and the mode (mono, stereo, joint stereo or dual channel)."
|Production phase||Used for content in initial, middle, and final states.|
|Relationship to other formats|
|Modification of||WAVE, WAVE Audio File Format|
|May contain||LPCM, Linear Pulse Code Modulated Audio (LPCM)|
|May contain||MPEG-1 and MPEG-2 Layer I Audio Encoding, not described at this Web site|
|May contain||MPEG_layer_2_audio, MPEG-1 and MPEG-2 Layer II Audio Encoding|
|Has subtype||WAVE_BWF_LPCM_1, Broadcast WAVE File Format, Version 1, with LPCM Audio|
|Has earlier version||EBU Broadcast Wave File Format (1997, sometimes called "Version 0"), not described at this Web site.|
|Has later version||WAVE_BWF_2, Broadcast WAVE Audio File Format, Version 2|
|Has extension||MBWF / RF64: An extended File Format for Audio, not described at this Web site at this time.|
|LC experience or existing holdings||When reformatting analog sound recordings, the Broadcast WAVE format (either version), wrapping LPCM, is used as the archival master format for mono and stereo audio at the Packard Campus for Audio-Visual Conservation and by the American Folklife Center.|
The Broadcast WAVE format (either version), wrapping LPCM, is preferred as the archival master format for mono and stereo audio when reformatting analog sound recordings. The Library is a participant in the Federal Agencies Audio-Visual Working Group that published a recommended specification for BWF bext metadata conforming to version 1 in 2009, with an update conforming to version 2 in 2012.
The Library of Congress Recommended Formats Statement (RFS) includes WAVE file with embedded metadata (Broadcast WAVE) as a preferred format for media-independent audio works in digital form. The RFS does not specify versions of BWF.
|Disclosure||Open standard developed as a refinement of the WAVE format by the European Broadcast Union (EBU), a standards developing organization.|
|Documentation||EBU Tech 3285 - Specification of the Broadcast Wave Format (BWF) - Version 1 - second edition (2001); other related EBU standards are listed in the Formats Specifications section below. For documentation of the underlying WAVE format, see WAVE.|
|Adoption||Widely recommended, including as the preferred format for the delivery of music recordings to record companies in the Draft Recommendation for Delivery of Recorded Music Projects developed by the Delivery Specifications Committee of the Producer's and Engineer's Wing of the Recording Academy (National Academy of the Recording Arts and Sciences). Audio format specified in AES31-3, the Audio Engineering Society's specification for session project interchange, where LPCM encoding is implied but not specified.|
|Licensing and patents||None.|
|Transparency||The file format is transparent. For information on the transparency of the included audio encodings, see LPCM and MPEG_layer_II_audio. BWF metadata is human-readable.|
|Self-documentation||The Broadcast Audio Extension (bext chunk) holds metadata identifying the originator and the date and time of creation. Additional options for embedding metadata are outlined in Notes.|
|Technical protection considerations||None|
|Fidelity (high audio resolution)||Depends upon encoding; see WAVE_LPCM or MPEG_layer_II_audio.|
|Multiple channels||May depend upon encoding; see WAVE_LPCM or MPEG_layer_II_audio. Note that multichannel audio is supported in the MBWF ("RF64 with a bext chunk") specification, EBU-TECH 3306, MBWF / RF64: An extended File Format for Audio (2009).|
|Support for user-defined sounds, samples, and patches||Not supported|
|Functionality beyond normal rendering||Files greater than 4 GB in size may be produced using the MBWF ("RF64 with a bext chunk") specification, EBU-TECH 3306, MBWF / RF64: An extended File Format for Audio (2009). See Notes.|
|Internet Media Type||See related format.||
|Magic numbers||See related format.||
|Wikidata Title ID||Q27526471
Four metadata chunks beyond bext have been established for Broadcast WAVE files. First is AES46 (initially standardized in 2002 and revised in 2007): AES standard for network and file transfer of audio Audio-file transfer and exchange Radio traffic audio delivery extension to the broadcast-WAVE-file format. Its purpose is stated as "an interchange medium by audio production and on-air delivery systems to exchange audio data . . . along with basic scheduling, traffic or continuity information." Second is axml, developed by the EBU in 2003, with a corollary schema called aXML. This is potentially useful but seems not to have been widely adopted. See Specification of the Broadcast Wave Format; A Format for Audio Data Files in Broadcasting; Supplement 5: <axml> Chunk, accessed April 16, 2012. Third is iXML, developed by a British trade group, the Institute of Broadcast Sound (IBS), a group of audio hardware and software manufacturers who sought to facilitate transfer of production metadata across systems.. The current version of the specification is dated 2010; earlier versions of the specification can be found in the Internet Archive Wayback machine. The iXML website lists 16 companies and 23 products that use the data structure, and iXML is also being developed as a standard by the Audio Engineering Society (AES). Fourth is an implementation of Adobe's XMP Specification. This structure can exist as a "sidecar" file or be embedded in a variety of content-essence files, including WAVE (need not be Broadcast WAVE). XMP has been widely adopted by professional photographers because it is well supported in the ubiquitous family of Adobe imaging software, where it generally takes the form of the news-oriented metadata standard from International Press and Telecommunications Council (IPTC). Adobe and the IPTC are actively exploring ways to expand the use of XMP among audio and video producers, especially in the field of journalism.
From the Wikipedia article RF64 (consulted October 26, 2012): "RF64 is a BWF-compatible multichannel file format enabling file sizes to exceed 4 GB. It has been specified by the European Broadcasting Union. The file format is designed to meet the requirements for multichannel sound in broadcasting and audio archiving. It is based on the Microsoft RIFF/WAVE format and Wave Format Extensible for multichannel parameters. Additions are made to the basic specification to allow for more than 4 GB file sizes when needed (the new maximum filesize is now approximately 16 exabytes). . . . In its basic form, the 32-bit chunk size field at offset 4 in the file is set to -1 (0xFFFFFFFF), and immediately following that a new 'DS64' chunk is inserted (before the FMT chunk). This new DS64 chunk will contain the 64-bit sizes of the DATA chunk(s), using a simple sequential table mechanism to point to additional DATA chunks. The first 4 bytes of the file are then changed from 'RIFF' to 'RF64'. . . . An RF64 file with a bext chunk becomes an MBWF-file. The terms ‘RF64’ and ‘MBWF’ can then be considered synonymous.
There have been three iterations of the BWF format under the general specification number EBU Tech 3285. Version 0 (as it came to be called) was published in 1997. Version 1, which differs from Version 0 in the use of 64 of the 254 reserved bytes to contain a SMPTE UMID identifier, was published July 2001. Version 1 was followed by six supplements with additional information. Version 2 references these supplements and adds elements that pertain to loudness metadata.
How can you identify the version? One method is to take advantage of the facts that (a) the bext chunks in Version 0 files do not have a space reserved for the UMID and (b) the bext chunks for neither Version 0 or Version 1 files have spaces for loudness metadata. Thus, if a file has BEXT data but no UMID or loudness values, it is Version 0. (The version 0 value for the BEXT Version element is not specified in EBU Tech 3285; the Broadcast WAVE guideline from the Federal Agencies Digitization Guideline Initiative recommends using the value 0000h.) If a file has BEXT data and a UMID value but no loudness values, it is Version 1. (EBU specifies 0001h as the value for the Version element.) If a file has BEXT data and loudness values, it is Version 2. (EBU specifies 0002h as the value for the Version element.)