This multi-part article will deconstruct the Broadcast Wave File as it's used in Film and Television production. We will examine the BWF from a historical, structural and practical perspective.

All of the non-linear recorders that are used to record audio for film and TV productions record audio to a Broadcast Wave File. As varied as the Fostex, Sound Devices, Aaton, Tascam, Edirol, Zaxcom and even Gallery and VOS Games products are, the Broadcast Wave file is the single common feature among them – the most basic unit of currency of the location audio world. Despite the apparent “standard”, each of these devices records with with slight variations to the Broadcast Wave specification, which can potentially create havoc with post-production work flows.

A Broadcast Wave file is really just a plain old Wave file, with some extra “bits” added. Note that despite the fact that it is commonly referred to as a BWF file, it should NOT end with BWF as a file extension, but it instead should respect its origins and end with WAV. This is because the WAV file is “extensible” - it was designed for future growth and forward compatibility.

The Wave format is based on a philosophy of data storage envisioned in 1985 by Jerry Morrison and a small group of programmers from the video game company Electronic Arts and the home computer company Commodore-Amiga. Morrison and his colleagues were looking for a way that personal computer software could exchange data in an efficient, extensible and non-proprietary way. Borrowing from the computer science concept of data abstraction, the “Interchange File Format”, or “IFF” structure stores the data, the descriptions of the data (“meta data”), and how to access it, as “chunks” in a file.

Fortunately, Morrison wasn't just thinking of video games, and encouraged other programmers to use the IFF format for data from all kinds of media:

Think ahead when designing an object. It should serve many purposes and allow many programs to store and read back all the information they need; even squeeze in custom data. Then a programmer can store the available data and is encouraged to include fixed contextual details. Recipient programs can read the needed parts, skip unrecognized stuff, default missing data, and use the stored context to help transform the data as needed.”

The effect of Morrison's seminal EA IFF 1985 proposal can still be seen today, some twenty years later - an eternity in computer terms. Besides  Wave files,  .AVI, .TIFF and even Quicktime files all owe their origins to IFF.

With the introduction of Windows 3.1 in 1991, Microsoft and IBM modified the “IFF” format for use on the Intel 8086 platform and made it the default file structure format for Windows multimedia files, calling it “RIFF” or “Resource Interchange File Format”. The humble WAV file is merely a subset of the RIFF specification.

A WAVE file therefore is really a collection of “chunks”. In fact, for a WAVE file to be “legal” it needs to have only two chunks: The Format chunk (called 'fmt ') which contains information about the sampling rate, bit depth and number of channels; and the Data chunk, which contains the actual audio samples. All other chunks (such as those specifying cue points, instrument sampler info, etc) are optional, and any application dealing with WAVE files  must be able to ignore but preserve unknown chunks.

It is this characteristic of  forward compatibility envisioned by Morrison that paved the way for the successful development of the BWF standard.  Just as Morrison was looking for an open, extensible way to exchange data between different software, John Emmet and the P/DAPA (Digital Audio Production and Archiving) sub-committee of the European Broadcast Union were looking for a standard method of exchanging audio files for radio broadcast, in the Spring of 1995.  According to Emmet:

Someone suggested we had a try at exchanging Wave files, (the ones that your computer sound card uses). Someone else asked innocently “Are Wave files restricted to low quality audio?” To be honest, I doubt if anyone at that meeting really knew the answer, but walking in the sunshine along the riverside…something just seemed very hopeful.

WAV-suffix audio sample files are recognized by many different types of audio applications, and these applications will look at the “chunks” of data in order to see if they recognize any data which is relevant to that application.  It will leave all other chunks alone, a fact that has enabled us to insert the broadcast-specific information into Wave files without disabling any low-cost existing applications such as simple players.

And so the BWF specification was officially born in July 1997 with EBU document Tech 3285, specifying the “Broadcast Extensions” or “bext” chunk. This  bext chunk contains the “timestamp” (the computer file equivalent to timecode), recorder information, and, with the introduction of the Zaxcom DEVA in 2000,  track names, and scene, take and notes information.

Next month, we'll examine in detail the anatomy of a BWF file, and explain how ambiguities in the implementation of the BWF specification  can break different work flows. We'll also look at how the new iXML standard solves many of these issues.

REFERENCES:
http://www.ebu.ch/en/technical/trev/trev_285-emmett.pdf
http://www.borg.com/~jglatt/tech/wave.htm
http://www.szonye.com/bradd/iff.html
http://www.ebu.ch/CMSimages/en/tec_doc_t3285_tcm6-10544.pdf
KEEPING IT SIMPLE; BWF AND AES31 – by John Emmet - Paper presented at AES 2004