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
Zaxcom and even
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
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
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
Fortunately, Morrison wasn't just thinking of video games,
and encouraged other programmers to use the IFF format for data from all kinds
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
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:
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.
KEEPING IT SIMPLE; BWF AND AES31
– by John Emmet - Paper presented at AES 2004
[PRINTER FRIENDLY VERSION]