WAV

A RIFF file is a tagged file format. It has a specific container format (a chunk) that includes a four-character tag (FourCC) and the size (number of bytes) of the chunk. The tag specifies how the data within the chunk should be interpreted, and there are several standard FourCC tags. Tags consisting of all capital letters are reserved tags. The outermost chunk of a RIFF file has a RIFF form tag; the first four bytes of chunk data are a FourCC that specify the form type and are followed by a sequence of subchunks. In the case of a WAV file, those four bytes are the FourCC WAVE. The remainder of the RIFF data is a sequence of chunks describing the audio information.

The advantage of a tagged file format is that the format can be extended later without confusing existing file readers.[11] The rule for a RIFF (or WAV) reader is that it should ignore any tagged chunk that it does not recognize.[12] The reader won't be able to use the new information, but the reader should not be confused.

The specification for RIFF files includes the definition of an INFO chunk. The chunk may include information such as the title of the work, the author, the creation date, and copyright information. Although the INFO chunk was defined in version 1.0, the chunk was not referenced in the formal specification of a WAV file. If the chunk were present in the file, then a reader should know how to interpret it, but many readers had trouble. Some readers would abort when they encountered the chunk, some readers would process the chunk if it were the first chunk in the RIFF form,[13] and other readers would process it if it followed all of the expected waveform data. Consequently, the safest thing to do from an interchange standpoint was to omit the INFO chunk and other extensions and send a lowest-common-denominator file. There are other INFO chunk placement problems.

RIFF files were expected to be used in international environments, so there is CSET chunk to specify the country code, language, dialect, and code page for the strings in a RIFF file.[14] For example, specifying an appropriate CSET chunk should allow the strings in an INFO chunk (and other chunks throughout the RIFF file) to be interpreted as Cyrillic or Japanese characters.

RIFF also defines a JUNK chunk whose contents are uninteresting.[15] The chunk allows a chunk to be deleted by just changing its FourCC. The chunk could also be used to reserve some space for future edits so the file could be modified without being rewritten. A later definition of RIFF introduced a similar PAD  chunk.[16]

The toplevel definition of a WAV file is:[17]

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

The definition shows a toplevel RIFF form with the WAVE tag. It is followed by a mandatory <fmt-ck> format chunk that describes the format of the sample data that follows. The format chunk includes information such as the sample encoding, number of bits per channel, the number of channels, the sample rate. The WAV specification includes some optional features. The optional fact chunk reports the number of samples for some compressed coding schemes. The cue point (cue ) chunk identifies some significant sample numbers in the wave file. The playlist chunk allows the samples to be played out of order or repeated rather than just from beginning to end. The associated data list allows labels and notes (labl and note) to be attached to cue points; text annotation (ltxt) may be given for a group of samples (e.g., caption information). Finally, the mandatory wave data chunk contains the actual samples (in the specified format).

Note that the WAV file definition does not show where an INFO chunk should be placed. It is also silent about the placement of a CSET chunk (which specifies the character set used).

The RIFF specification attempts to be a formal specification, but its formalism lacks the precision seen in other tagged formats. For example, the RIFF specification does not clearly distinguish between a set of subchunks and an ordered sequence of subchunks. The RIFF form chunk suggests it should be a sequence container.[18] The specification suggests a LIST chunk is also a sequence: "A LIST chunk contains a list, or ordered sequence, of subchunks."[19] However, the specification does not give a formal specification of the INFO chunk; an example INFO LIST chunk ignores the chunk sequence implied in the INFO description.[20] The LIST chunk definition for <wave-data> does use the LIST chunk as a sequence container with good formal semantics.

The WAV specification allows for not only a single, contiguous, array of audio samples, but also discrete blocks of samples and silence that are played in order. Most WAV files use a single array of data. The specification for the sample data is confused:[21]

The <wave-data> contains the waveform data. It is defined as follows:
  <wave-data>  → { <data-ck> | <data-list> }
  <data-ck>    → data( <wave-data> )
  <wave-list>  → LIST( 'wavl' { <data-ck> | // Wave samples
                                <silence-ck> }... ) // Silence
  <silence-ck> → slnt( <dwSamples:DWORD> ) // Count of silent samples

These productions are confused. Apparently <data-list> (undefined) and <wave-list> (defined but not referenced) should be identical. Even if that problem is fixed, the productions then allow a <data-ck> to contain a recursive <wave-data> (which implies data interpretation problems). The specification should have been something like:

<wave-data>  → { <data-ck> | <wave-list> }
  <data-ck>    → data( <bSampleData:BYTE> ... )
  <wave-list>  → LIST( 'wavl' { <data-ck> | // Wave samples
                                <silence-ck> }... ) // Silence
  <silence-ck> → slnt( <dwSamples:DWORD> ) // Count of silent samples

to avoid the recursion.

WAV files can contain embedded IFF "lists", which can contain several "sub-chunks".[22][23][24]

In spite of their large size, uncompressed WAV files are used by most radio broadcasters, especially those that have adopted a tapeless system.

• BBC Radio in the UK uses 48 kHz 16-bit two-channel WAV audio as standard in their SCISYS dira audio editing and playout system.
• The UK Commercial radio company Global Radio uses 44.1 kHz 16-bit two-channel WAV files in the Genesys playout system, and throughout their broadcast chain.
• The ABC "D-Cart" system, which was developed by the Australian broadcaster, uses 48 kHz 16-bit two-channel WAV files, which is identical to that of Digital Audio Tape.
• The Digital Radio Mondiale consortium uses WAV files as an informal standard for transmitter simulation and receiver testing.