When a field recorder, a radio studio and an edit bay swap files all day long, you need more than sound: you need to know when it was recorded, with what, and where it sits on the timeline. That is the job of Broadcast Wave Format, the BWF, defined by the European Broadcasting Union. Behind the name sits an almost ordinary .wav file, extended with a metadata layer the whole production chain can read.
A standardized WAV, compatible everywhere
A BWF is still a WAV file in RIFF format, the block-based structure (the “chunks”) inherited from Microsoft and IBM. You find the usual header, the fmt chunk describing sample rate, bit depth and channel count, then the data chunk holding the PCM audio. A player that ignores broadcast metadata opens the file without complaint and plays the sound. Backward compatibility is total, and that is the first reason for the format’s success.
The difference is one extra block, the bext chunk, for “broadcast extension”. It travels with the audio, inside the same file, with no sidecar file to lose.
The bext chunk, the file’s ID card
The bext gathers the information production needs. A Description field freely describes the content. The Originator and OriginationDate or OriginationTime fields note the device and the moment of the take. A CodingHistory field logs successive coding steps, useful when a file has passed through several formats.
The most valuable field is TimeReference. It stores, as a sample count since midnight, the timecode position of the very first sample in the file. In other words, the BWF knows its exact place in a shooting day. That is the key to sync in picture editing, a topic tied closely to double-system sound with timecode. Newer bext versions add loudness fields aligned with EBU R128 targets, carrying the measurement with the media.
iXML, the field recorder’s companion
Alongside the bext, many recorders write a second block, the iXML chunk. It describes the scene, the take, each track name and the project, in a structured form. Field recorders, from Sound Devices to Zaxcom, rely on it so the editor can see at a glance which track matches which microphone. The bext gives the time context, iXML gives the editorial context.
Large files and RF64
The original RIFF format codes block sizes on 32 bits, which caps a file at four gigabytes. A long multitrack capture passes that limit quickly. The answer is RF64, a standardized extension that lifts the ceiling while keeping the BWF logic. A recorder switches to RF64 automatically when the take grows too long, with no operator input.
Where BWF becomes essential
In radio, automation and playout systems archive and replay BWFs, whose metadata drives imaging and the timing of elements, from the control room to the self-op studio. In television and post, the TimeReference guarantees that sound relocks to picture in the right place. During a remote transfer, a BWF sent over a contribution codec or a file transfer arrives with its full context.
One pitfall is worth knowing: some operations silently erase the metadata. Converting a BWF to MP3, reopening it in an editor that does not preserve the bext, or renaming it carelessly can make the timecode vanish. The field rule fits in one line: keep the master in BWF and work only on copies.
My take
BWF is one of those invisible standards that hold a whole industry together without ever showing up. Its strength is that it breaks nothing: a BWF stays a WAV, so it opens anywhere, and it carries all the context editing needs on top. The day a file loses its timecode between the shoot and post, you suddenly measure the value of those few bytes of metadata. Looking after the chain that preserves them costs less than a day of manual resyncing.
