Each WAV file is saved with certain parameters.
The following is a typical example of such parameters ...

PCM, 44.1kHz, 16bit, stereo, 172 kbps

I know what the "44.1kHz" (sampling rate) means,
and what the "172kbps" (bitrate) means.

But what does the "16bit" refer to?

Is there a FAQ that explains these items?

"wylbur37" wrote ...
Each WAV file is saved with certain parameters.
The following is a typical example of such parameters ...

PCM, 44.1kHz, 16bit, stereo, 172 kbps

I know what the "44.1kHz" (sampling rate) means,
and what the "172kbps" (bitrate) means.

"172kbps" sounds like a highly compressed format such as
would be used for DVD, etc. If you do the math, a 44.1k x
16 bit WAV calculates to 5.292mbps (30 times bigger than
"172kbps")

But what does the "16bit" refer to?

The "width" of the sample. 16-bit is the standard for CDs
and most music recording. Some high-end systems use 24-
bits.

Is there a FAQ that explains these items?

There are many. Google is your friend.

For example, here is an explanation of the WAV file header and
file format...

http://ccrma.stanford.edu/courses/42...ts/WaveFormat/

RC [Fri, 24 Sep 2004 05:53:11 -0700]:
"wylbur37" wrote ...
Each WAV file is saved with certain parameters.
The following is a typical example of such parameters ...

PCM, 44.1kHz, 16bit, stereo, 172 kbps

I know what the "44.1kHz" (sampling rate) means,
and what the "172kbps" (bitrate) means.

"172kbps" sounds like a highly compressed format such as

More likely, the person doesn't understand or appreciate
using proper units:

176,400 bytes per second is the CD data rate

176400/1024 = 172.266 KB/sec (not kbps, wrong on two counts)


For the curious, 176400 bytes/sec = 44100 Hz x 2 ch x 2 bytes/sample/ch.

176400 bytes 44100 samples 2 channels 2 bytes
----------- = ------------ x x ---------
sec sec sample / channel

Channels and samples cancel, leaving bytes and sec. 176400 bytes/sec.
In kbps, that's 176400*8= 1411200/1000= 1411.2 kbps.

Here, LITTLE k (as in kbps) is 1000. Little b is bits.
BIG K, as in KB, is 1024. Big B is bytes.

Usually, you only see kb -OR- KB, but not kB, nor Kb. Why?
Because bits are usually described in 1000s (k) of,
and bytes in 1024s (K) of. The K symbol was purposely
made "close to" the standard metric k symbol (kilo = 1000)
since 1024 is "close to" 1000, but a little more (capital K).

(You'd have known this if you didn't skip that day.)

--
40th Floor - Software @ http://40th.com/
iPlay : the ultimate audio player for iPAQs
mp3, ogg, mp4, m4a, aac, wav, play & record
parametric eq, xfeed, reverb - all on a ppc

Hmm, good reply, hel. Only your forgot 16 bits: That's the
width of the data stream, meaning 16 bits at a time is
transmitted in the data stream. Or, ultra-simply, a combination
of 16 zeroes and ones of data at a time is transmitted around the
system. The wider the virtual or literal buss (bit rate), the
faster things are internally and the less problem with
bottlenecks. 32 bit is twice as fast as 16 bit (well, about,
anyway, neglecting some added control bits) and so on.

Pop


wrote in message
...
| RC [Fri, 24 Sep 2004 05:53:11 -0700]:
| "wylbur37" wrote ...
| Each WAV file is saved with certain parameters.
| The following is a typical example of such parameters ...
|
| PCM, 44.1kHz, 16bit, stereo, 172 kbps
|
| I know what the "44.1kHz" (sampling rate) means,
| and what the "172kbps" (bitrate) means.
|
| "172kbps" sounds like a highly compressed format such as
|
| More likely, the person doesn't understand or appreciate
| using proper units:
|
| 176,400 bytes per second is the CD data rate
|
| 176400/1024 = 172.266 KB/sec (not kbps, wrong on two counts)
|
|
| For the curious, 176400 bytes/sec = 44100 Hz x 2 ch x 2
bytes/sample/ch.
|
| 176400 bytes 44100 samples 2 channels 2 bytes
| ----------- = ------------ x x ---------
| sec sec sample / channel
|
| Channels and samples cancel, leaving bytes and sec. 176400
bytes/sec.
| In kbps, that's 176400*8= 1411200/1000= 1411.2 kbps.
|
| Here, LITTLE k (as in kbps) is 1000. Little b is bits.
| BIG K, as in KB, is 1024. Big B is bytes.
|
| Usually, you only see kb -OR- KB, but not kB, nor Kb. Why?
| Because bits are usually described in 1000s (k) of,
| and bytes in 1024s (K) of. The K symbol was purposely
| made "close to" the standard metric k symbol (kilo = 1000)
| since 1024 is "close to" 1000, but a little more (capital K).
|
| (You'd have known this if you didn't skip that day.)
|
| --
| 40th Floor - Software @ http://40th.com/
| iPlay : the ultimate audio player for iPAQs
| mp3, ogg, mp4, m4a, aac, wav, play & record
| parametric eq, xfeed, reverb - all on a ppc

datanet wrote:
Hmm, good reply, hel. Only your forgot 16 bits: That's the
width of the data stream, meaning 16 bits at a time is
transmitted in the data stream. Or, ultra-simply, a combination
of 16 zeroes and ones of data at a time is transmitted around the
system. The wider the virtual or literal buss (bit rate), the
faster things are internally and the less problem with
bottlenecks. 32 bit is twice as fast as 16 bit (well, about,
anyway, neglecting some added control bits) and so on.

Pop


wrote in message
...
| RC [Fri, 24 Sep 2004 05:53:11 -0700]:
| "wylbur37" wrote ...
| Each WAV file is saved with certain parameters.
| The following is a typical example of such parameters ...
|
| PCM, 44.1kHz, 16bit, stereo, 172 kbps
|
| I know what the "44.1kHz" (sampling rate) means,
| and what the "172kbps" (bitrate) means.
|
| "172kbps" sounds like a highly compressed format such as
|
| More likely, the person doesn't understand or appreciate
| using proper units:
|
| 176,400 bytes per second is the CD data rate
|
| 176400/1024 = 172.266 KB/sec (not kbps, wrong on two counts)
|
|
| For the curious, 176400 bytes/sec = 44100 Hz x 2 ch x 2
bytes/sample/ch.
|
| 176400 bytes 44100 samples 2 channels 2 bytes
| ----------- = ------------ x x ---------
| sec sec sample / channel
|
| Channels and samples cancel, leaving bytes and sec. 176400
bytes/sec.
| In kbps, that's 176400*8= 1411200/1000= 1411.2 kbps.
|
| Here, LITTLE k (as in kbps) is 1000. Little b is bits.
| BIG K, as in KB, is 1024. Big B is bytes.
|
| Usually, you only see kb -OR- KB, but not kB, nor Kb. Why?
| Because bits are usually described in 1000s (k) of,
| and bytes in 1024s (K) of. The K symbol was purposely
| made "close to" the standard metric k symbol (kilo = 1000)
| since 1024 is "close to" 1000, but a little more (capital K).
|
| (You'd have known this if you didn't skip that day.)
|
| --
| 40th Floor - Software @ http://40th.com/
| iPlay : the ultimate audio player for iPAQs
| mp3, ogg, mp4, m4a, aac, wav, play & record
| parametric eq, xfeed, reverb - all on a ppc


The number of bits has nothing to do with speed. It is simply the width
of each sample. For the audio CD, there are 44,100 of these 16-bit
samples for every second of sound. For the ultimate DVD audio disc there
are 192,000 24-bit samples for every second of sound. The width of the
sample, be it 16 bits or 24, determines the dynamic range you can
capture in digital audio. The rule of thumb is to multiply the bits by 6
to get the maximum dynamic range capability. For 16 bits, that would be
16*6 or 96 db, and for 24 bits it would be 24*6=144db. In reality, due
to limitations in electronics and such, 24 bit systems haven't even come
close to 144 db capabilty. It's more like 108-110db, and 16 bit systems
are around 80 to 85 db.

CD

"datanet" wrote in message ...
Each WAV file is saved with certain parameters.
The following is a typical example of such parameters ...

PCM, 44.1kHz, 16bit, stereo, 172 kbps

I know what the "44.1kHz" (sampling rate) means,
and what the "172kbps" (bitrate) means.

But what does the "16bit" refer to?

Is there a FAQ that explains these items?
Hmm, good reply, hel. Only your forgot 16 bits: That's the
width of the data stream, meaning 16 bits at a time is
transmitted in the data stream. Or, ultra-simply, a combination
of 16 zeroes and ones of data at a time is transmitted around the
system. The wider the virtual or literal buss (bit rate), the
faster things are internally and the less problem with
bottlenecks. 32 bit is twice as fast as 16 bit (well, about,
anyway, neglecting some added control bits) and so on.

Ultra simple indeed but, unfortunately, ultra wrong. The 16 bits
cited has NOTHING WHATSOEVER to do with the "width of the data
stream." All the hoo-ha above about "vritual or literal buss" and
16 vs 32 bits and bottlenecks is utterly irrelevant to the question
at hand.

It is simply declaring that each audio sample will have
a precision of 16 bits.

Now, to answer the original question definitively: A WAVE file
is one particular kind of RIFF (Resource Interchange File Format)
file. A RIFF file is composed of individual "chunks" of data, each
chunk is dientified by a 4-character chunk identifier and a 32 bit
chunk size (in bytes).

A WAVE file MUST have at least 2 such chunks to be valid:

1. The 'fmt ' chunk: this holds the parameters describing the
properties of the audio data, and, in fact, it is the contents
of the 'fmt ' chunk that you are seeing. The 'fmt ' chunk is
broken down as follows:

wFormatTag - a 16-bit integer holding a format indicator for
the file. SOme examples of which a

1 - PCM
2 - ADPCM
6 - A-Law
7 - u-Law
48 - Dolbay AC3
80 - MPEG

nChannels - 16 bint integer of the number of audio channels
in the file

nSamplesPerSecond - 32 bit unsigned integer of the sample rate
of the audio

nAvgBytesPerSecond - 32 bit unsigned integer of the average
buffer rate for the audio.

nBlockAlign - block alignment (in bytes) for the waveform
data.

And, if the wFormatTag is 1 (PCM), the fmt chunk is extended to
include:

nBitsPerSample - number of bits per sample.

If it is another format, the chunk extension will include relevant
formation for that format.

2. the 'data' chunk. This actually hold the audio data samples, as
described in the 'fmt ' chunk.

There may well be other chuncks as well. FOr example, EBU Tech 3285
describes the so-called "Broadcast Wave Format" extensions, while
AES-46 describes additional chunk information for use in radio
applications.

So your are, in essence, seeing a human readable "dump" of the
contents
of the 'fmt ' chunk. Your reading:

"PCM, 44.1kHz, 16bit, stereo, 172 kbps"

is directly mappable as follows:

wFormatTag = 1 "PCM"
nChannels = 2 "Stereo"
nSamplesPerSecond = 44100 "44.1 kHz"
nAvgBytesPerSecond = 176400 "172 kbps" (a typo, perhaps?)
nBlockAlign = 4
wBitsPerSample = 16 "16 bits"

Now, nBlockALign is calculated as follows: each sample holds
16 bits. A byte is 8 bits, so 2 bytes are required to hold
a single sample. The file is in stereo, so two samples are
required (one for each channel) at each sample block, thus
2 (bytes/channel) * 2 channels = 4 bytes.

Then, the nAvgBytesPerSecond is (in the case of PCM), simply
the number of bytes per sample block times the number of sample
blocks per second, 44,100 * 4 = 176,400. Now, they used the term
"kilo" in the wrong sense here, they used the disk convention of
1024 as opposed to the normal 1000, thus 176,400/1024 = 172.26
kiloBYTES per second.

Now, the "16 bits" describes, as I mentioned, the width of each
sample word, or its "precision." A 16 bit sample can represent,
on a per-sample basis, one of 2^16 or some 65,536 unique values.
You can also view this as describing how wide a dynamic range
that a sample can represent. In the case of 16 bits, this is a
dynamic range of around 96 dB, that is, the difference between
the lowest unambiguous value and the highest that can be represented
by a 16 bit sample stream is 96 dB.

But, please, ignore the above nonsense about "virtual busses" and
"bottlenecks," it's a load of irrelevant hooey.

"Codifus" wrote in message
...
| datanet wrote:
| Hmm, good reply, hel. Only your forgot 16 bits: That's the
| width of the data stream, meaning 16 bits at a time is
| transmitted in the data stream. Or, ultra-simply, a
combination
| of 16 zeroes and ones of data at a time is transmitted around
the
| system. The wider the virtual or literal buss (bit rate),
the
| faster things are internally and the less problem with
| bottlenecks. 32 bit is twice as fast as 16 bit (well, about,
| anyway, neglecting some added control bits) and so on.
|
| Pop
|
|
| wrote in message
|
...
| | RC [Fri, 24 Sep 2004 05:53:11 -0700]:
| | "wylbur37" wrote ...
| | Each WAV file is saved with certain parameters.
| | The following is a typical example of such parameters
....
| |
| | PCM, 44.1kHz, 16bit, stereo, 172 kbps
| |
| | I know what the "44.1kHz" (sampling rate) means,
| | and what the "172kbps" (bitrate) means.
| |
| | "172kbps" sounds like a highly compressed format such as
| |
| | More likely, the person doesn't understand or appreciate
| | using proper units:
| |
| | 176,400 bytes per second is the CD data rate
| |
| | 176400/1024 = 172.266 KB/sec (not kbps, wrong on two
counts)
| |
| |
| | For the curious, 176400 bytes/sec = 44100 Hz x 2 ch x 2
| bytes/sample/ch.
| |
| | 176400 bytes 44100 samples 2 channels 2 bytes
| | ----------- = ------------ x x ---------
| | sec sec sample /
channel
| |
| | Channels and samples cancel, leaving bytes and sec. 176400
| bytes/sec.
| | In kbps, that's 176400*8= 1411200/1000= 1411.2 kbps.
| |
| | Here, LITTLE k (as in kbps) is 1000. Little b is bits.
| | BIG K, as in KB, is 1024. Big B is bytes.
| |
| | Usually, you only see kb -OR- KB, but not kB, nor Kb. Why?
| | Because bits are usually described in 1000s (k) of,
| | and bytes in 1024s (K) of. The K symbol was purposely
| | made "close to" the standard metric k symbol (kilo = 1000)
| | since 1024 is "close to" 1000, but a little more (capital
K).
| |
| | (You'd have known this if you didn't skip that day.)
| |
| | --
| | 40th Floor - Software @ http://40th.com/
| | iPlay : the ultimate audio player for iPAQs
| | mp3, ogg, mp4, m4a, aac, wav, play & record
| | parametric eq, xfeed, reverb - all on a ppc
|
|
| The number of bits has nothing to do with speed. It is simply
the width
| of each sample. For the audio CD, there are 44,100 of these
16-bit
| samples for every second of sound. For the ultimate DVD audio
disc there
| are 192,000 24-bit samples for every second of sound. The width
of the
| sample, be it 16 bits or 24, determines the dynamic range you
can
| capture in digital audio. The rule of thumb is to multiply the
bits by 6
| to get the maximum dynamic range capability. For 16 bits, that
would be
| 16*6 or 96 db, and for 24 bits it would be 24*6=144db. In
reality, due
| to limitations in electronics and such, 24 bit systems haven't
even come
| close to 144 db capabilty. It's more like 108-110db, and 16 bit
systems
| are around 80 to 85 db.
|
| CD

You either didn't read or jumped to a conclusion. Rather than
argue, why didn't you just phrase a reasonable answer for the
guy? You're wrong, but you're right. And I'm right, in the
context he wanted to know, IMO. If not, then he has to say so.

Woof! EXCELlent response! Way to go.\

Pop


"Dick Pierce" wrote in message
om...
| "datanet" wrote in message
...
| Each WAV file is saved with certain parameters.
| The following is a typical example of such parameters ...
|
| PCM, 44.1kHz, 16bit, stereo, 172 kbps
|
| I know what the "44.1kHz" (sampling rate) means,
| and what the "172kbps" (bitrate) means.
|
| But what does the "16bit" refer to?
|
| Is there a FAQ that explains these items?
| Hmm, good reply, hel. Only your forgot 16 bits: That's the
| width of the data stream, meaning 16 bits at a time is
| transmitted in the data stream. Or, ultra-simply, a
combination
| of 16 zeroes and ones of data at a time is transmitted around
the
| system. The wider the virtual or literal buss (bit rate),
the
| faster things are internally and the less problem with
| bottlenecks. 32 bit is twice as fast as 16 bit (well, about,
| anyway, neglecting some added control bits) and so on.
|
| Ultra simple indeed but, unfortunately, ultra wrong. The 16
bits
| cited has NOTHING WHATSOEVER to do with the "width of the data
| stream." All the hoo-ha above about "vritual or literal buss"
and
| 16 vs 32 bits and bottlenecks is utterly irrelevant to the
question
| at hand.
|
| It is simply declaring that each audio sample will have
| a precision of 16 bits.
|
| Now, to answer the original question definitively: A WAVE file
| is one particular kind of RIFF (Resource Interchange File
Format)
| file. A RIFF file is composed of individual "chunks" of data,
each
| chunk is dientified by a 4-character chunk identifier and a 32
bit
| chunk size (in bytes).
|
| A WAVE file MUST have at least 2 such chunks to be valid:
|
| 1. The 'fmt ' chunk: this holds the parameters describing the
| properties of the audio data, and, in fact, it is the
contents
| of the 'fmt ' chunk that you are seeing. The 'fmt ' chunk is
| broken down as follows:
|
| wFormatTag - a 16-bit integer holding a format indicator for
| the file. SOme examples of which a
|
| 1 - PCM
| 2 - ADPCM
| 6 - A-Law
| 7 - u-Law
| 48 - Dolbay AC3
| 80 - MPEG
|
| nChannels - 16 bint integer of the number of audio channels
| in the file
|
| nSamplesPerSecond - 32 bit unsigned integer of the sample
rate
| of the audio
|
| nAvgBytesPerSecond - 32 bit unsigned integer of the average
| buffer rate for the audio.
|
| nBlockAlign - block alignment (in bytes) for the waveform
| data.
|
| And, if the wFormatTag is 1 (PCM), the fmt chunk is extended
to
| include:
|
| nBitsPerSample - number of bits per sample.
|
| If it is another format, the chunk extension will include
relevant
| formation for that format.
|
| 2. the 'data' chunk. This actually hold the audio data samples,
as
| described in the 'fmt ' chunk.
|
| There may well be other chuncks as well. FOr example, EBU Tech
3285
| describes the so-called "Broadcast Wave Format" extensions,
while
| AES-46 describes additional chunk information for use in radio
| applications.
|
| So your are, in essence, seeing a human readable "dump" of the
| contents
| of the 'fmt ' chunk. Your reading:
|
| "PCM, 44.1kHz, 16bit, stereo, 172 kbps"
|
| is directly mappable as follows:
|
| wFormatTag = 1 "PCM"
| nChannels = 2 "Stereo"
| nSamplesPerSecond = 44100 "44.1 kHz"
| nAvgBytesPerSecond = 176400 "172 kbps" (a typo, perhaps?)
| nBlockAlign = 4
| wBitsPerSample = 16 "16 bits"
|
| Now, nBlockALign is calculated as follows: each sample holds
| 16 bits. A byte is 8 bits, so 2 bytes are required to hold
| a single sample. The file is in stereo, so two samples are
| required (one for each channel) at each sample block, thus
| 2 (bytes/channel) * 2 channels = 4 bytes.
|
| Then, the nAvgBytesPerSecond is (in the case of PCM), simply
| the number of bytes per sample block times the number of sample
| blocks per second, 44,100 * 4 = 176,400. Now, they used the
term
| "kilo" in the wrong sense here, they used the disk convention
of
| 1024 as opposed to the normal 1000, thus 176,400/1024 = 172.26
| kiloBYTES per second.
|
| Now, the "16 bits" describes, as I mentioned, the width of each
| sample word, or its "precision." A 16 bit sample can represent,
| on a per-sample basis, one of 2^16 or some 65,536 unique
values.
| You can also view this as describing how wide a dynamic range
| that a sample can represent. In the case of 16 bits, this is a
| dynamic range of around 96 dB, that is, the difference between
| the lowest unambiguous value and the highest that can be
represented
| by a 16 bit sample stream is 96 dB.
|
| But, please, ignore the above nonsense about "virtual busses"
and
| "bottlenecks," it's a load of irrelevant hooey.