id             chunkid;
  long           chunksize;

  short          wformattag;
  unsigned short wchannels;
  unsigned long  dwsamplespersec;
  unsigned long  dwavgbytespersec;
  unsigned short wblockalign;
  unsigned short wbitspersample;

/* note: there may be additional fields here, depending upon wformattag. */

} formatchunk;
</pre>

<p>the id is always &quot;<b>fmt </b>&quot;. the chunksize field is the number of bytes in
the chunk. this does not include the 8 bytes used by id and size fields. for the format
chunk, chunksize may vary according to what &quot;format&quot; of wave file is specified
(ie, depends upon the value of wformattag). </p>

<p>wave data may be stored without compression, in which case the sample points are stored
as described in <b>sample points and sample frames</b>. alternately, different forms of
compression may be used when storing the sound data in the data chunk. with compression,
each sample point may take a differing number of bytes to store. the wformattag indicates
whether compression is used when storing the data.</p>

<p>if compression is used (ie, wformattag is some value other than 1), then there will be
additional fields appended to the format chunk which give needed information for a program
wishing to retrieve and decompress that stored data. the first such additional field will
be an unsigned short that indicates how many more bytes have been appended (after this
unsigned short). furthermore, compressed formats must have a fact chunk which contains an
unsigned long indicating the size (in sample points) of the waveform after it has been
decompressed. there are (too) many compressed formats. details about them can be gotten
from microsoft's web site.</p>

<p>if no compression is used (ie, wformattag = 1), then there are no further fields.</p>

<p>the wchannels field contains the number of audio channels for the sound. a value of 1
means monophonic sound, 2 means stereo, 4 means four channel sound, etc. any number of
audio channels may be represented. for multichannel sounds, single sample points from each
channel are interleaved. a set of interleaved sample points is called a sample frame.</p>

<p>the actual waveform data is stored in another chunk, the data chunk, which will be
described later.</p>

<p>the dwsamplespersec field is the sample rate at which the sound is to be played back in
sample frames per second (ie, hertz). the 3 standard mpc rates are 11025, 22050, and 44100
khz, although other rates may be used.</p>

<p>the dwavgbytespersec field indicates how many bytes play every second. dwavgbytespersec
may be used by an application to estimate what size ram buffer is needed to properly
playback the wave without latency problems. its value should be equal to the following
formula rounded up to the next whole number:</p>

<p>dwsamplespersec * wblockalign</p>

<p>the wblockalign field should be equal to the following formula, rounded to the next
whole number:</p>

<p>wchannels * (wbitspersample % 8)</p>

<p>essentially, wblockalign is the size of a sample frame, in terms of bytes. (eg, a
sample frame for a 16-bit mono wave is 2 bytes. a sample frame for a 16-bit stereo wave is
4 bytes. etc).</p>

<p>the wbitspersample field indicates the bit resolution of a sample point (ie, a 16-bit
waveform would have wbitspersample = 16).</p>

<p>one, and only one, format chunk is required in every wave.</p>

<hr>

<h3>data chunk</h3>

<p>the data (data) chunk contains the actual sample frames (ie, all channels of waveform
data).</p>

<pre>
#define dataid 'data'  /* chunk id for data chunk */

typedef struct {
  id             chunkid;
  long           chunksize;

  unsigned char  waveformdata[];
} datachunk;
</pre>

<p>the id is always <b>data</b>. chunksize is the number of bytes in the chunk, not
counting the 8 bytes used by id and size fields nor any possible pad byte needed to make
the chunk an even size (ie, chunksize is the number of remaining bytes in the chunk after
the chunksize field, not counting any trailing pad byte). </p>

<p>remember that the bit resolution, and other information is gotten from the format
chunk.</p>

<p>the following discussion assumes uncompressed data.</p>

<p>the waveformdata array contains the actual waveform data. the data is arranged into
what are called <em>sample frames</em>. for more information on the arrangment of data,
see &quot;sample points and sample frames&quot;.</p>

<p>you can determine how many bytes of actual waveform data there is from the data chunk's
chunksize field. the number of sample frames in waveformdata is determined by dividing
this chunksize by the format chunk's wblockalign.</p>

<p>the data chunk is required. one, and only one, data chunk may appear in a wave.</p>

<h4>another way of storing waveform data</h4>

<p>so, you're thinking &quot;this wave format isn't that bad. it seems to make sense and
there aren't all that many inconsistencies, duplications, and inefficiencies&quot;. you
fool! we're just getting started with our first excursion into unnecessary
inconsistencies, duplications, and inefficiency. </p>

<p>sure, countless brain-damaged programmers have inflicted literally dozens of compressed
data formats upon the data chunk, but apparently someone felt that even this wasn't enough
to make your life difficult in trying to support wave files. no, some half-wit decided
that it would be a good idea to screw around with storing waveform data in something other
than one data chunk. noooooooooooooo!!!!!!</p>

<p>for some god-forsaken reason, someone came up with the idea of using an imbedded iff
list inside of the wave file. nooooooooooooooooo!!!!!!!! and this &quot;wave list&quot;
would contain multiple 'data' and 'slnt' chunks. noooooooooooooooo!!!! the type id for
this list is 'wavl'.</p>

<p>i strongly suggest that you refuse to support any wave file that exhibits this wave
list nonsense. there's no need for it, and hopefully, the misguided programmer who
conjured it up will be embarrassed into hanging his head in shame when nobody agrees to
support his foolishness. just say &quot;noooooooooooooo!!!!&quot;</p>

<hr>

<h3>cue chunk</h3>

<p>the cue chunk contains one or more &quot;cue points&quot; or &quot;markers&quot;. each
cue point references a specific offset within the waveformdata array, and has its own
cuepoint structure within this chunk. </p>

<p>in conjunction with the playlist chunk, the cue chunk can be used to store looping
information.</p>

<h4>cuepoint structure</h4>

<pre>
typedef struct {
  long    dwidentifier;
  long    dwposition;
  id      fccchunk;
  long    dwchunkstart;
  long    dwblockstart;
  long    dwsampleoffset;
} cuepoint;
</pre>

<p>the dwidentifier field contains a unique number (ie, different than the id number of
any other cuepoint structure). this is used to associate a cuepoint structure with other
structures used in other chunks which will be described later. </p>

<p>the dwposition field specifies the position of the cue point within the &quot;play
order&quot; (as determined by the playlist chunk. see that chunk for a discussion of the
play order).</p>

<p>the fccchunk field specifies the chunk id of the data or wave list chunk which actually
contains the waveform data to which this cuepoint refers. if there is only one data chunk
in the file, then this field is set to the id 'data'. on the other hand, if the file
contains a wave list (which can contain both 'data' and 'slnt' chunks), then fccchunk will
specify 'data' or 'slnt' depending upon in which type of chunk the referenced waveform
data is found.</p>

<p>the dwchunkstart and dwblockstart fields are set to 0 for an uncompressed wave file
that contains one 'data' chunk. these fields are used only for wave files that contain a
wave list (with multiple 'data' and 'slnt' chunks), or for a compressed file containing a
'data' chunk. (actually, in the latter case, dwchunkstart is also set to 0, and only
dwblockstart is used). again, i want to emphasize that you can avoid all of this
unnecessary crap if you avoid hassling with compressed files, or wave lists, and instead
stick to the sensible basics.</p>

<p>the dwchunkstart field specifies the byte offset of the start of the 'data' or 'slnt'
chunk which actually contains the waveform data to which this cuepoint refers. this offset
is relative to the start of the first chunk within the wave list. (ie, it's the byte
offset, within the wave list, of where the 'data' or 'slnt' chunk of interest appears. the
first chunk within the list would be at an offset of 0).</p>

<p>the dwblockstart field specifies the byte offset of the start of the block containing
the position. this offset is relative to the start of the waveform data within the 'data'
or 'slnt' chunk.</p>

<p>the dwsampleoffset field specifies the sample offset of the cue point relative to the
start of the block. in an uncompressed file, this equates to simply being the offset
within the waveformdata array. unfortunately, the wave documentation is much too
ambiguous, and doesn't define what it means by the term &quot;sample offset&quot;. this
could mean a byte offset, or it could mean counting the sample points (for example, in a
16-bit wave, every 2 bytes would be 1 sample point), or it could even mean sample frames
(as the loop offsets in aiff are specified). who knows? the guy who conjured up the cue
chunk certainly isn't saying. i'm assuming that it's a byte offset, like the above 2
fields.</p>

<h4>cue chunk</h4>

<pre>
#define cueid 'cue '  /* chunk id for cue chunk */

typedef struct {
  id        chunkid;
  long      chunksize;

  long      dwcuepoints;
  cuepoint  points[];
} cuechunk;
</pre>

<p>the id is always <b>cue </b>. chunksize is the number of bytes in the chunk, not
counting the 8 bytes used by id and size fields. </p>

<p>the dwcuepoints field is the number of cuepoint structures in the cue chunk. if
dwcuepoints is not 0, it is followed by that many cuepoint structures, one after the
other. because all fields in a cuepoint structure are an even number of bytes, the length
of any cuepoint will always be even. thus, cuepoints are packed together with no unused
bytes between them. the cuepoints need not be placed in any particular order.</p>

<p>the cue chunk is optional. no more than one cue chunk can appear in a wave.</p>

<hr>

<h3>playlist chunk</h3>

<p>the playlist (plst) chunk specifies a play order for a series of cue points. the cue
chunk contains all of the cue points, but the playlist chunk determines how those cue
points are used when playing back the waveform (ie, which cue points represent looped
sections, and in what order those loops are &quot;played&quot;). the playlist chunk
contains one or more segment structures, each of which identifies a looped section of the
waveform (in conjunction with the cuepoint structure with which it is associated). </p>

<h4>segment structure</h4>

<pre>
typedef struct {
  long    dwidentifier;
  long    dwlength;
  long    dwrepeats;
} segment;
</pre>

<p>the dwidentifier field contains a unique number (ie, different than the id number of
any other segment structure). this field should correspond with the dwindentifier field of
some cuepoint stored in the cue chunk. in other words, this segment structure contains the
looping information associated with that cuepoint structure with the same id number. </p>

<p>the dwlength field specifies the length of the section in samples (ie, the length of
the looped section). note that the start position of the loop would be the dwsampleoffset
of the referenced cuepoint structure in the cue chunk. (or, you may need to hassle with
the dwchunkstart and dwblockstart fields as well if dealing with a wave list or compressed
data).</p>

<p>the dwrepeats field specifies the number of times to play the loop. i assume that a
value of 1 means to repeat this loop once only, but the wave documentation is very
incomplete and omits this important information. i have no idea how you would specify an
infinitely repeating loop. certainly, the person who conjured up the playlist chunk
appears to have no idea whatsoever. due to the ambiguities, inconsistencies,
inefficiencies, and omissions of the cue and playlist chunks, i very much recommend that
you use the sampler chunk (described later) to replace them.</p>

<h4>playlist chunk</h4>

<pre>
#define playlistid 'plst'  /* chunk id for playlist chunk */

typedef struct {
  id        chunkid;
  long      chunksize;

  long      dwsegments;
  segment   segments[];
} playlistchunk;
</pre>

<p>the id is always <b>plst</b>. chunksize is the number of bytes in the chunk, not
counting the 8 bytes used by id and size fields. </p>

<p>the dwsegments field is the number of segment structures in the playlist chunk. if