Replay Gain - A Proposed Standard

Replay Gain .wav File Format

Existing format

The RIFF WAV format is defined here. The rules in this rather complex document become a little clearer when implemented! If you want to implement this, please remember that .wav files use little endian byte order.

The RIFF format is based around data chunks. Each chunk has the following basic format: NAME,SIZE,DATA. Wave files always contain a WAVEfmt chunk, and a data chunk. The WAVEfmt chunk contains information such as number of channels, sampling rate, bits per sample etc etc. The data chunk contains the actual audio data. The entire file is contained within a RIFF chunk.

There are several other optional chunks, which may be placed between the WAVEfmt chunk, and the data chunk. These include Cue and Playlist chunks.

The standard requires that software can sucessfully read .wav files containing unknown chunks. Should an unknown chunk NAME be encountered, then the accompanying SIZE field should be read, and the DATA field should be skipped. This means that new chunks can be defined without breaking compatibility with legacy software.

Replay Gain Adjustment chunk

In the language of the standard document, the format is extended thus:

               <WAVE-form> ->
                      RIFF( 'WAVE'
                           <fmt-ck>               // Format
                           [<rgad-ck>]            // Replay Gain Adjustment
                           [<fact-ck>]            // Fact chunk
                           [<cue-ck>]             // Cue points
                           [<playlist-ck>]        // Playlist
                           [<assoc-data-list>]    // Associated data list
                           <wave-data>   )        // Wave data


                <rgad-ck> ->   rgad( <rPeakAmplitude:REAL>
                                     <wAudiophileRgAdjust:WORD>
                                     <wRadioRgAdjust:WORD> )

In English, we're defining a new chunk called "rgad" (Replay Gain Adjustment). The size will always be 8 bytes long. The first value stored will be the Radio Replay Gain Adjustment (2-bytes); the second value stored will be the Audiophile Replay Gain Adjustment (2-bytes); the third and final value stored will be the Peak Amplitude (4-bytes).

Example .wav header

Here is a real example, which should make things clearer. You can see how the "RIFF" chunk wraps around all the other chunks, and also how each chunk starts with its name, followed by its size. The new "rgad chunk" is highlighted in light blue.

The "rgad" chunk is new. I stress this just in case you've web searched directly onto this page - what we're discussing here is an extension to the .wav format, not the existing standard.

In this example, looking at the "rgad" chunk:

• The "fPeakamplitude" value of 1 means that the digital data in the .wav file peaks at digital full scale (equivalent to -32768 for this 16-bit file).
• The "nRadioRgAdjust" value of 110822 (0010101001000110) represents a -7.0dB Radio Replay Gain Adjustment, user set.
• The "nAudiophileRgAdjust" value of 18999 (0100101000110111) represents a -5.5dB Audiophile Replay Gain Adjustment, user set.

See the data format explanation if you don't understand how the binary codes were calculated.

The rest of the header information shows that this file is a standard 44.1kHz, 16bit, 2 channel wavefile (the kind you might rip off a CD). It runs for 1 second, and is 176458 bytes long.

Does it work?

I hacked the MATLAB wavwrite function to create the above file. It plays without problems in Winamp, and Loads correctly into Cool Edit Pro. Neither of the programs understand the "rgad" chunk, and both simply ignore it.

Suggestions and Further Work

If you can see any problem with this proposal, please let me know. No software implements this (as yet).

[ File Format ] . [ CONTENTS ] . [ Player Requirements ]