5.1-- Supported PCM WAV file formats

The generic WAV file structure (see refs [1] ,[2] ) allows for a wide range of formats (identified by the FormatTag within the file header). Many of these formats are proprietary (to 3^rd-parties), involving various compression and storage methods. However, the simplest and most popular format (and the one which is usually implied when using the term "WAV file") is the (uncompressed) PCM (Pulse Code Modulation) format whereby the signal is quantized into a number of bins (or bits), linearly distributed over the amplitude range. The samples are generally stored as integers (fixed-point), though floating-point is used by some vendors for 32-bit files. ReSample currently supports integer-storage only. The following two types of uncompressed, linear, PCM WAV files are supported:

· WAV_FORMAT_PCM
· WAV_FORMAT_EXTENSIBLE (with PCM)

WAV_FORMAT_PCM (from Microsoft) is the most widely used format, supported by many applications. WAV_FORMAT_EXTENSIBLE (also from Microsoft, see ref [3]) is a relatively new extension to this format, designed specifically for multichannel data with prescribed speaker arrangements (e.g. "5.1 Surround Sound" etc).
The following rules are specific to integer-storage linear PCM WAV files, and are embodied in the ReSample WAV I/O functionality.

1. each sample is always written "left justified" within its container (only relevant when ValidBits is less than ContainerBits). The values in the remaining "right-hand" bits are set to zero.
2. for the case of an 8-bit container (i.e. ValidBits between 2 and 8 inclusive) each sample is written as an unsigned byte (8 bits uchar)
3. for the case of a 24-bit container, each sample is written as a sequence of three bytes (two 8-bit unsigned chars followed by an 8-bit signed char). The bytes are ordered starting with the least significant, ending with the most significant. This is known as the "24-bit packed format".
4. in the case of a 16-bit container, each sample is written as a signed short integer (16-bits).
5. in the case of a 32-bit container, each sample is written as a signed long integer (32-bits).

Notes:

1. in addition to its main purpose of incorporating the ability to prescribe the multichannel speaker allocation, the WAV_FORMAT_EXTENSIBLE format also clears up an ambiguity inherent to the WAV_FORMAT_PCM format when storing a sample with a given bit resolution in a "container" of a different (larger) size. For example, if the data is to be quantised using 20-bits, this will typically be stored in a 24-bit "container" (since WAV files always use multiples of 8-bits when storing the data). In the WAV_FORMAT_PCM format, there is an ambiguity associated with the BitsPerSample field. Some applications use the BitsPerSample field for its originally- intended purpose, i.e. to represent the number of "valid" bits per sample, 20 in this example. The container size would then be inferred from the BlockAlign field. However, other applications assume that BitsPerSample represents the "container" size i.e. 24 in this example. This ambiguity is cleared up in the WAV_FORMAT_EXTENSIBLE format whereby a new field is introduced, namely, the ValidBitsPerSample field to represent the valid bits (and the BitsPerSample field is then exclusively reserved for the container size). Note that the ambiguity never arose when working exclusively with 8- or 16-bit data. It only emerged when the newer (larger) bit-resolutions appeared.

2. Even though the FormatTag is always the same for WAV_FORMAT_EXTENSIBLE, there is full flexibility in the actual data storage format. This is facilitated via the SubFormat field which enables any format (e.g. proprietary compressed formats) to be specified. Currently this toolbox supports only PCM data storage, specified by a SubFormat field value which corresponds to the Microsoft GUID for PCM data, i.e. KSDATAFORMAT_SUBTYPE_PCM (see ref [3]).