13. Top Front Left - TFL
14. Top Front Center - TFC
15. Top Front Right - TFR
16. Top Back Left - TBL
17. Top Back Center - TBC
18. Top Back Right - TBR
The channels in the interleaved stream corresponding to these spatial positions must
appear in the order specified above. This holds true even in the case of a non-contiguous
subset of channels. For example, if a stream contains left, bass enhance and right, then
channel 1 is left, channel 2 is right, and channel 3 is bass enhance. This enables the
linkage of multi-channel streams to well-defined multi-speaker configurations.
Warning: Content intended for the Low Frequency channel may not be rendered on the
speaker that the data is sent to. This is because there is no way to guarantee the
frequency range of the low frequency speaker in a user's system. For this reason, a
speaker that is receiving low frequency audio might filter the frequencies that it cannot
handle.
Representing High-Resolution Audio
Ambiguity within WAVE_FORMAT_PCM
It is important to enumerate the assumptions made by WAVE_FORMAT_PCM. One
assumption is that the nBlockAlign field contains exactly one set of samples (one block).
Also, each sample must be byte-aligned within the block. The byte-aligned space that each
sample consumes is called the sample's "container." Additionally, there cannot be any
extra space between the end of the last sample container and the actual end of the block.
In other words, nBlockAlign must be an integer multiple of nChannels, and that multiple
is considered the "container size" for the sample.
Although it was not necessarily the original intent, some entities treat wBitsPerSample as
equivalent to the container size. In other words, the number of bits of valid data was
assumed equal to the size of the container. This assumption held well for 8-bit and 16-bit
audio. With the coming of high fidelity audio equipment for render and capture, 20-bit and
24-bit streams emerged. Specifying the actual bit resolution of the samples in a byte-
aligned stream became important; the accepted interpretation of wBitsPerSample started
to unravel, because its value is not rigidly enforced by all software. In many cases, it
continued to be the container size. In other cases, however, the field was used to indicate
the bits of actual valid data, while the container size was inferred from nBlockAlign and
nChannels (an example would be wBitsPerSample = 20, nBlockAlign = 8, nChannels
= 2).
It was not considered feasible to resolve this issue either way without causing many legacy
problems for WAVE_FORMAT_PCM, so the new formats include an additional field that
clarifies this ambiguity. The new formats are intended to handle those cases in which the
actual bits of precision are not equal to the container size, as well as all cases in which the
container size is greater than sixteen bits.
It is not the purpose of this article to resolve the ambiguity of wBitsPerSample for
WAVE_FORMAT_PCM. However, this same field will be used unambiguously in the new
formats.
Specifying the Actual Bit Depth
Pa
e 3 of 13Multi
le Channel Audio Data and WAVE Files
2002-11-05htt
://www.microsoft.com/hwdev/tech/audio/multichaudP.as