Editing WAV (section)

===RIFF WAVE===
The top-level definition of a WAV file is:<ref>{{Harvnb|IBM|Microsoft|1991|loc=PDF p. 56}}</ref>
<pre><WAVE-form> → RIFF('WAVE'
                   <fmt-ck>            // Format of the file
                   [<fact-ck>]         // Fact chunk
                   [<cue-ck>]          // Cue points
                   [<playlist-ck>]     // Playlist
                   [<assoc-data-list>] // Associated data list
                   <wave-data> )       // Wave data
</pre>
The top-level RIFF form uses a <code>WAVE</code> tag. It is followed by a mandatory <code><nowiki><fmt-ck></nowiki></code> chunk that describes the format of the sample data that follows. This chunk includes information such as the sample encoding, number of bits per channel, the number of channels, and the sample rate. 

The WAV specification includes some optional features. The optional <code><nowiki><fact-ck></nowiki></code> chunk reports the number of samples for some compressed coding schemes. The <code><nowiki><cue-ck></nowiki></code> chunk identifies some significant sample numbers in the wave file. The <code><nowiki><playlist-ck></nowiki></code> chunk allows the samples to be played out of order or repeated rather than just from beginning to end.  The associated data list (<code><nowiki><assoc-data-list></nowiki></code>) allows labels and notes to be attached to cue points; text annotation may be given for a group of samples (e.g., caption information).  

Finally, the mandatory <code><nowiki><wave-data></nowiki></code> chunk contains the actual samples in the format previously specified.

Note that the WAV file definition does not show where an <code>INFO</code> chunk should be placed. It is also silent about the placement of a <code>CSET</code> 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.<!-- Compare ASN SET-OF and SEQUENCE-OF --> The RIFF form chunk suggests it should be a sequence container. Sequencing information is specified in the RIFF form of a WAV file consistent with the formalism: "However, <code><nowiki><fmt-ck></nowiki></code> must always occur before <code><nowiki><wave-data></nowiki></code>, and both of these chunks are mandatory in a WAVE file."<ref>{{Harvnb|IBM|Microsoft|1991|loc=PDF p. 56}}</ref> The specification suggests a <code>LIST</code> chunk is also a sequence: "A LIST chunk contains a list, or ordered sequence, of subchunks."<ref>{{Harvnb|IBM|Microsoft|1991|loc=PDF p. 23}}</ref> However, the specification does not give a formal specification of the <code>INFO</code> chunk; an example <code>INFO</code> <code>LIST</code> chunk ignores the chunk sequence implied in the <code>INFO</code> description.<ref>{{Harvnb|IBM|Microsoft|1991|loc=PDF p. 21}}, <code>INAM</code> appears before <code>ICOP</code></ref> The <code>LIST</code> chunk definition for <code><nowiki><wave-data></nowiki></code> does use the <code>LIST</code> chunk as a sequence container with good formal semantics.

The WAV specification supports, and most WAV files use, a single contiguous array of audio samples. The specification also supports discrete blocks of samples and silence that are played in order. The specification for the sample data contains apparent errors:<ref>Specification from {{Harvnb|IBM|Microsoft|1991}} which also describes how the production syntax is interpreted.</ref>
<pre>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
</pre>
Apparently <code><nowiki><data-list></nowiki></code> (undefined) and <code><nowiki><wave-list></nowiki></code> (defined but not referenced) should be identical. Even with this resolved, the productions then allow a <code><nowiki><data-ck></nowiki></code> to contain a [[Recursion (computer science)|recursive]] <code><nowiki><wave-data></nowiki></code> (which implies data interpretation problems). To avoid the recursion, the specification can be interpreted as:
<pre><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
</pre>

WAV files can contain embedded IFF ''lists'', which can contain several ''sub-chunks''.<ref>{{cite web |date=1999-11-15 |title=WAVE File Format |url=https://www.borg.com/~jglatt/tech/wave.htm |url-status=dead |archive-url=https://web.archive.org/web/19991115123323/https://www.borg.com/~jglatt/tech/wave.htm |archive-date=1999-11-15 |access-date=2010-03-16}}</ref><ref>{{cite web |url=https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ |title=WAVE PCM soundfile format |date=2003-01-20 |access-date=2010-03-16 |archive-url=https://web.archive.org/web/20090827003349/https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ |archive-date=2009-08-27 |url-status=dead }}</ref><ref>{{cite web |url=https://www.lightlink.com/tjweber/StripWav/WAVE.html |title=The WAVE File Format  |access-date=2010-03-16 |archive-url=https://web.archive.org/web/20110722003211/https://www.lightlink.com/tjweber/StripWav/WAVE.html |archive-date=2011-07-22 |url-status=dead}}</ref>