Media Servers

1. RIFF
2. RIFF/WAVE Standards by Year
3. WAVE (WAV)
4. RIFF File 64 (RF64)
5. Broadcast WAVE Format (BWF)
6. Broadcast WAVE Format 64 (BW64)
7. BWF vs BW64 vs RF64

Resource Interchange File Format (RIFF)

Resource Interchange File Format (RIFF) is a generic (audio/video) container format. RIFF is rarely encountered today in its pure form, though it is the basis for some of the most venerable and widespread audio file formats, including AIFF and WAVe containers. Today, using the original RIFF standard is discouraged due to a variety of limitations in its architecture. That said, RIFF-based standards are still widely in use today (such as WAVe), and there are plenty of viable use cases that support them.

RIFF's origin dates back to an ancient multimedia container standard introduced by Electronic Arts in 1985, called IFF (Interchange File Format). Designed to facilitate information sharing between incompatible systems, IFF was one of the very first file standards to incorporate metadata. RIFF derivatives have a maximum size limit of 4 GiB. Very old operating system/hardware platforms may not be capable of processing a RIFF, AIFF, or WAVe file over 2 GiB (up to the 4 GiB hard limit) unless the file's extension is .rf64 or .wav64, denoting a 64-bit addressing method within the file. Generally speaking, modern hardware/software combinations built after 2005 are unlikely to have issues with >2 GiB file sizes, and nearly all systems built in 2009 or later should not have any issues.

Standards:

File extensions: .riff
Contextual metadata: Yes¹

WAVE (WAV)

WAVE (frequently referred to as WAVe, Wav, or .wav) is both a container and sound file format. Built on the RIFF standard, and sometimes known as RIFF/WAVE, WAVE files store uncompressed audio using Pulse Code Modulation (PCM), Linear Pulse Code Modulation (LPCM), or ADPCM codecs. Released by Microsoft Corporation in 1991, WAVE remains quite popular in spite of being one of the oldest legacy container types still in use today.

WAVE is unusual in the sense it acts somewhat like a codec, yet it is not. WAVE is both an audio container and a file format. Initially, WAVE was limited to 2-channels, but in the early 2000's Microsoft expanded its capabilities in a way that removed any restriction on the number of channels. However, since WAVE is based on a 32-bit architecture it is limited by its architecture to 65,536 channels.

As it is based on the RIFF standard, WAVe files are limited to a maximum file size of 4 GB.

WAVE uses chunks to store information. While this is an advanced topic beyond the scope of this article, it's worth noting here that this characteristic of WAVE is partly responsible for the container format's popularity as WAVE allows the incorporation of custom named chunks with virtually whatever content you'd like in them. While this opens the door to flexibility, it also increases the possibility WAVE files created with custom applications may not be playable on all media players that read WAVE files. Some player applications and devices become confused with unusual WAVE chunks and could (incorrectly) determine the content isn't actually WAVE. Tread carefully if you are creating new content with a WAVE encoder if you wish the content playback to be ubiquitous.

BWF File Format Supplement 1: MPEG audio in BWF files (1997) illustrates a proposal for incorporating MP1 and MP2 codecs embedded inside a BWF file (a 2-channel limited RIFF standard heavily based on WAVE).

Standards: WAVE is the purest embodiment of the RIFF standard, released in 1992 as the official audio file format of the Windows 3.1 operating system.

See also:

File extensions: .wav | .wave
Contextual metadata: Yes¹

RIFF File 64 (RF64)

RF64 is a 64-bit WAVE file format, and functions exactly like a WAVE file, albeit with one important exception. RF64's 64-bit addressing architecture (compared with WAVE's 32-bits) allows RF64 files to cross WAVE's 4 GB file size threshold. WAVE's limitation on file size is due to its inability to address internal data pointers in a single file beyond 32-bits, limiting its reach to 4 GB of data. RF64 surpasses this limit.

Official support for RF64 ended in 2018.

RF64 is a multi-channel capable container created by the European Broadcasting Union (EBU), an audio standards authority focused on terrestrial broadcasting technologies and formats.^x75 RF64 supports up to 18 surround sound channels, plus a parallel stereo down mix for a combined total of 20 channels of bandwidth.^x74

RF64 is a 64-bit extension of the RIFF/WAVE standard. It is backward compatible with the 32-bit BWF and WAVE container and file format standards).^x76

Belonging to a family of WAVE/RIFF based containers indirectly associated with WAVE, the RF64 standard has a convoluted history. The European Broadcast Union (EBU) launched RF64 in 2007 in an effort to address BWF's file size constraints (4 GB hard limit). Two (2) years later in 2009, EBU applied minor tweaks in its first revision. Then in 2015, the International Telecommunication Union (ITU) - a competing multi-national industry standards organization - released a similar audio container and file format called BW64 (short for "BWF-64"). By 2018, the EBU was forced to acknowledge ITU's version held a markedly superior design and it no longer made sense for both organizations to publish such similar, competing standards. That year the EBU issued its final RF64 technical standard (EBU Tech 3360 Version 2 - FINAL), wherein it relinquished and assigned the responsibility of setting broadcast media standards for 64-bit RIFF/WAVE file and container formats henceforth to the ITU. RF64 was effectively dead.

RF64 is backward compatible with WAVE and BWF.

Standards:

File extension: .rf64
Contextual metadata: Yes¹

Broadcast WAVE Format (BWF)

Broadcast WAVE Format (BWF) is an audio media file standard derived from RIFF/WAVE.

Originally developed by the European Broadcast Union (EBU), BWF is and always has been intended as a long-term storage file format for the purpose of archiving and transferring broadcast media. Like WAVE, it has a 32-bit architecture, limiting file size to less than 4 GB.

Although backward compatible with WAVE, full support in media players is not guaranteed. At its core, BWF files are WAVE files with an additional chunk in the file called the Broadcast Audio Extension Chunk, which performs two functions: it identifies the file as a BWF formatted file; and it contains skeleton metadata specified in the BWF specification. Otherwise, BWF and WAVE files containing PCM or LPCM audio data are synonymous.

So, what's the big deal with BWF if it's just a re-branded WAVE file? BWF is more than just a WAVE file with a different file extension. BWF makes it possible to incorporate other (non-PCM) audio codecs into a WAVE/RIFF-type container, and it has more comprehensive technical metadata.

Like any other RIFF standard, BWF files may incorporate independent metadata schemas (e.g. XMP, ID3) inside of custom chunks, but support for such metadata is tenuous and varies by file reader. BWF has very limited structured, contextual metadata as part of its standard:

An advantage of BWF is its built-in compatibility with non-PCM/LPCM/ADPCM sound formats. This is the key that allows certain other audio codec data to be stored inside a BWF file. Which other codecs? Specifically, MPEG formats (MPEG Layer I or II). Alas, BWF only supports a maximum of 2 channels, thus only Layer I and II of MPEG-1 and MPEG-2 are supported (i.e. MP1 and MP2, but not MP3).

Astute observers will note an MPEG-in-a-BWF file entails placing a compressed, lossy audio stream inside an uncompressed, lossless container. Seems a bit pointless, eh? So, what is the point? Recall that BWF was designed as an archival file format. Neither MPEG-1 Audio Layers I nor II support metadata, but BWF does. Therefore, it can make sense to store such files inside a BWF container (particularly for archival purposes).

BWF files are limited to a maximum size of 4 GB.

The first version of BWF was released in 1997 (EBU TECH 3285 Version 0). The current specification is BWF Version 2, published in 2011.

Current specification: BWF - EBU TECH 3285 Version 2 (2011)

BWF specification version history is confusing. The gist of it is the EBU (European Broadcasting Union) created and has continued to own BWF, while the ITU (International Telecommunication Union) has provided important technical advice, which the EBU incorporated most of over time.

File extension: .bwf
Contextual metadata: No

Broadcast WAVE Format 64 (BW64)

Broadcast WAVE Format 64 (BW64) is the 64-bit companion to the BWF specification and the preeminent standard in 64-bit RIFF/WAVE container file formats.

BW64 was purpose-built largely to accommodate the Audio Definition Model (ADM). Officially known by its document designation: BS.2076. ADM was an ITU initiative supporting 3D spatial Audio Object presentation (e.g. Dolby Atmos) technical specifications within the context of broadcast media. Version 0 (BS.2076-0) was released in 2015. ITU BS.2088 is the BW64 technical specification series. The most recent version is ITU BS.2008-1 (Version 1), released in 2019.

History and Relationship Between BW64, RF64, and WAVE

BW64 has a convoluted history, intertwined with RF64 and of course, BWF. Though it is not based on RF64, it is worth noting RF64's history and the fact RF64 existed when BW64 was launched. While there was no need to circumvent a new product in the marketplace that performed the functions RF64 was already managing, the timing of BW64's launch ultimately led to the demise of RF64.

Conceived by the European Broadcast Union (EBU) in 2007 as a means to solve BWF files' 4 GB size limit issue, RF64 was a RIFF/WAVE standard designed explicitly to overcome the 4 GB file size limit of WAVE and BWF files. BW64 was originally based on the EBU's Broadcast WAVE Format (BWF) standard, itself in turn based on RIFF/WAVE. BW64 and RF64 are backward compatible with BWF, and all three (BW64, RF64, and BWF) are backward compatible with the WAVE file and container format (and hence the RIFF container format, upon which they are all derived).

After receiving minor updates in 2009, the RF64 (EBU) standard remained static until mid-2018 when the EBU released Version 2.0 of TECH 3306 (RF64's EBU technical specification designation). Reputed by the EBU as the "final" technical spec on RF64, labeling TECH 3306 Version 2 a "final" specification was a misnomer. There was nothing new defined in the spec itself. Rather, EBU TECH 3306 Version 2.0 was a sunset declaration by the EBU of their stewardship over RF64. The document served as EBU's formal announcement they were relinquishing control over the RF64 standard to the International Telecommunication Union (ITU), effective immediately. Effectively, the EBU was ackowledging the ITU had built a better mouse-trap in the form of BW64 (ITU's response to the >4 GB WAVE file problem). Why the sudden shift on EBU's part? Well, it actually wasn't that sudden. The ITU more-or-less picked up the proverbial ball in 2015 when it published its own rendition of RF64 in the form of its BW64 spec: ITU-R BS.2088-0 (BW64 Version 0). It simply took the EBU three (3) years to acknowledge this. Regardless, shortly after the EBU killed off the RF64 format, in 2019 the ITU released the current specification of BW64 as ITU-R BS.2088-1 (BW64 Version 1).

BW64 was produced to address a tidal wave of changes in the audio codec world, culminating in 2014 with the advent of Dolby Atmos. Notably, it was not Atmos particularly which was the catalyst, but rather the concept of Audio Objects (of which, incidentally, Dolby Atmos, DTS:X, and Auro-3D are all based).

The ITU (International Telecommunication Union) perceived a gap in capabilities and performance of archival media file types versus the needs of broadcasters, as this new "3D" audio technology concept began to become absorbed within the media distribution industry. The EDU's RF64 standard had solved the problem of large media files, successfully weathering the storm of high resolution audio and video files as they began to proliferate in the late 2000's. However, the EDU was ill prepared to accomodate a repeat of a change process on an even grander scale prompted by the advent of audio technologies that substantially increased the depth and complexity of embedded audio streams. The advent of the Audio Object concept from Dolby in 2014 was a watershed event of epic proportions to the audio industry, which heretofore had always viewed digital audio as a function of channel-based PCM. By reinventing the notion of audio content as objects and ideas rather than strict channel associations, Dolby had succeeded in turning the entire concept of audio management on its head. Suddenly, channels didn't necessarily matter, but the ability to identify which content belonged to what presentation layer did. The end result was a shift in the game. Now, no longer was file size the biggest concern (solved by RF64). Now, the issue was the ability (or lack of) to store sufficient technical metadata and appropriate chunk/packet management within a file, such that the original content could be reproduced accurately. As time moved forward, RF64 and WAVE increasingly struggled with this task. And meanwhile, the ITU moved much faster and more eloquently in addressing the problem hereto, versus their competitors at the EBU. As a result, just three (3) years later, RF64 was dead and BW64 was the only option on the table for large file, complex audio stream archiving in a single file. Such is life in 21st century audio!

Current specifications:

• ITU BS.2088-1 (2019)
• Original specification: ITU Recommendation BS.2088-0 (2015)
• BW64 technical metadata (not contextual) spec is Recommendation ITU-R BS.2127-0 (Audio Definition Model renderer for advanced sound systems). [2019]

File extension: .bw64
Contextual metadata: No