"DaveC" wrote in message
al.net...
I'm listening to a stream via WMP. The Get Info box says:

Bit Rate: 24 Kbps
Audio Codec: Windows Media Audio 9
20 kbps, 32kHz, mono 1-pass CBR

Can someone please clarify what the bit rate means and what the audio
codec
numbers (20 kbps & 32 KHz) mean?

I believe they mean...

20 kbps = 20,000 (or 20480?) bits per second of data
through the network into your computer for this stream.

32kHz = the (original?) sample rate implying absolute
maximum 16KHz high frequency limit (likely lower).

CBR = constant (vs. variable/dynamic) bit-rate.

DaveC wrote:
On Thu, 20 May 2004 20:26:29 -0700, Richard Crowley wrote
(in article ):


"DaveC" wrote in message
al.net...
I'm listening to a stream via WMP. The Get Info box says:

Bit Rate: 24 Kbps
Audio Codec: Windows Media Audio 9
20 kbps, 32kHz, mono 1-pass CBR

Can someone please clarify what the bit rate means and what the
audio codec numbers (20 kbps & 32 KHz) mean?

I believe they mean...

20 kbps = 20,000 (or 20480?) bits per second of data
through the network into your computer for this stream.

My guess would be that the 24 Kbps is the network stream speed...

32kHz = the (original?) sample rate implying absolute
maximum 16KHz high frequency limit (likely lower).

CBR = constant (vs. variable/dynamic) bit-rate.

Anyone else?

Both definitions are correct...

With streaming audio, the kbps figure represents the number of Kilo Bits Per
Second being streamed down into your computer. The kHz figure represents
the sample rate, i.e. the number of samples per second when the source was
sampled.

CBR = Constant bit rate. That is to say the sample/rip was taken at a fixed
kbps value. Some encoders can calculate the 'best' (a-hem) bit rate on the
fly, this is known as VBR (Variable Bit Rate).

DaveC wrote:

An audio CD is digitized at 44.1 KHz, but there's no Kbps rating
associated with the digitizing, that I'm aware of.

16 bits per sample, two seperate channels no compression therefore
1411.2Kbps. The data rate from the disk though is higher as each byte is
encoded as 14 bits for resilience, so 2469.6Kbps.

You did ask.

DaveC wrote:

On Fri, 21 May 2004 10:44:41 -0700, Stimpy wrote
(in article ):


Bit Rate: 24 Kbps
Audio Codec: Windows Media Audio 9
20 kbps, 32kHz, mono 1-pass CBR

Can someone please clarify what the bit rate means and what the
audio codec numbers (20 kbps & 32 KHz) mean?


With streaming audio, the kbps figure represents the number of Kilo Bits Per
Second being streamed down into your computer. The kHz figure represents
the sample rate, i.e. the number of samples per second when the source was
sampled.

CBR = Constant bit rate. That is to say the sample/rip was taken at a fixed
kbps value. Some encoders can calculate the 'best' (a-hem) bit rate on the
fly, this is known as VBR (Variable Bit Rate).


So the 24 Kbps is how fast it's being delivered over the 'net;
32 KHz is the sample rate it was digitized at the source;
and 20 Kbps is ... hmm, I'm getting a bit lost here.


I think 20 kpbs is the encodde rate, and 24 is the
delivery/streaming rate - 4 kbps of overhead.

I *think*.

An audio CD is digitized at 44.1 KHz, but there's no Kbps rating associated
with the digitizing, that I'm aware of.

Sure there is. It's 1.44 M(bit)ps or something. It shows
up in Winamp when you play back 44.1 .wav files.


Clarification?

Thanks,


--
--
Les Cargill

DaveC wrote:

On Fri, 21 May 2004 18:52:15 -0700, Les Cargill wrote
(in article ):


An audio CD is digitized at 44.1 KHz, but there's no Kbps rating
associated
with the digitizing, that I'm aware of.


Sure there is. It's 1.44 M(bit)ps or something. It shows
up in Winamp when you play back 44.1 .wav files.


So it's 44.1 x 8 (or whatever a byte is) x 2 (stereo) + overhead +
errorchecking = encoding kbps?

44.1 kilo-samples per second x 1000 kHz/Hz * 8 bits/byte * 2 bytes/sample
* 2 channels + overhead = encoding bits/second.

So for CD-quality, it's 1,411,200 bits/second + overhead, which
could be in the neighborhood of 1.44 megabits/second if you
only have a few percent of overhead (which is feasible in
some cases).

- Logan

On Sun, 23 May 2004 09:14:58 -0700, DaveC wrote:

iTunes displays data about each audio file. This data includes "sample rate"
and "bit rate". (These are MP3 audio files, converted from CD.)

Sample rates include 44.1 and 22.05. These I understand. Bit rates include
128Kbps and 56Kbps. If these are not streamed sources, but just digitized
files, why is there a bit rate associated with them. It seems just a logical
to display a bit rate for a MS Word file...

Bit rates for MP3s are a measure of the filesize/quality trade off.
The lower the bit-rate, the smaller the resulting file, and the lower the
quality.
Bit rate is independent of sample rate.
So, you can encode a 44.1k mp3 at 128kbps, or 256kbps or whatever.
The sample rate remains the same, but the fidelity is less.

They are not 'just digitised files', they are MP3s, which bear very little
relation to the original uncompressed CD data. The data MP3s contain is
more like a description of the sound, rather than an analog of it.
The description can be less exact (Less kbps) but still be recognisable.

Confused (still)...

DaveC wrote:

On Sun, 23 May 2004 11:06:44 -0700, philicorda wrote
(in article pan.2004.05.23.18.06.40.307716@nospnospamspaammnt lworld.com):

Bit rate is independent of sample rate.
So, you can encode a 44.1k mp3 at 128kbps, or 256kbps or whatever.
The sample rate remains the same, but the fidelity is less.

So why not use the term "resample rate" rather than bit rate. The latter
implies streaming data, to me, at least. "Rate" implies a period of time over
which the "128K" -- or whatever -- takes place, when in fact it's just a
combination of the re-sample rate (ie, 22.05K) and the resultant file size.

Not just arguing terminology, here, but hoping that my premise is understood,
helping me better understand. (Understand?) :-)


Actually, the terminology is important. I think your error is
using the term "resample". Those rates may be different due to
the sample size (in bits) that was chosen.

The data isn't resampled to stream, it's compressed into an MP3
format in order to send over the net.

The original recording is sampled at a fixed rate (samples per
second) which produces a fixed number of bits per second (i.e.,
based on the bits per sample). That means to play it back exactly
as it was recorded, you have to play it back at that specific
fixed number of bits per second in order to regenerate the sound
at the original sample rate. However, that is a LOT of data and
bits per second and not really feasible for streaming over the
internet (impossible if you have a dialup connection).

MP3 provides a way to compress the data by digitally rearranging
it and throwing away MANY bits of audio data in a way that the
sound is not impacted too much. The more you throw away, the less
data that you have to stream over a given time and hence the
ability to use a lower speed connection (e.g., like a 56kbps
dialup connection). However, more data thrown away means less
quality of the sound compared to the original. On a higher speed
connection you can use less compression and keep more of the
original data and hence a better quality sound.

- Jeff

On Sun, 23 May 2004 21:23:18 -0700, DaveC wrote:


I think I understand everything except why a file that is not streamed has a
bit rate spec. Digitized content should be described by the sample rate and,
in some cases, sample size. But only streamed content should be described by
a bit rate. Any other use of these terms is misleading.

Just giving the sample rate would not tell you anything about the quality
of the encoding. The same sample rate can be mp3'd at a number of
different bit rates.

There is no difference to an MP3 decoder if the file is streamed from the
net or streamed from a hard drive.
The messy stuff about getting the data to the right place at the right
time is dealt with in another layer.

DaveC wrote:
But this only applies to a *streamed* file, not a stationary
on-your-hard-disk file. Why does a file that's already on your drive have a
bit rate associated with it? A sample rate, yes. But it shouldn't have a bit
rate unless it's being streamed.

I think I understand everything except why a file that is not streamed has a
bit rate spec. Digitized content should be described by the sample rate and,
in some cases, sample size. But only streamed content should be described by
a bit rate. Any other use of these terms is misleading.

That's one possibility. The other is that you don't understand what the
terms mean. :-)

All of those terms like "sampling," "encoding," "streaming,"
"resampling", and such have precise technical meanings and those
meanings are not the way they're being colloquially used in this thread.

The term "sampling" -- when used with respect to digital audio -- refers
to the original A/D "conversion" of the analog audio to digital data.
Someone else has already done a pretty good job of explaining the math
behind the 44.1kHz figure.

Once the data is in the digital domain as a wav file, all that can
really be said about it is that it is composed of two channels of
16-bit, 20-kHz samples that will require a processing rate of 1411 kbps
in order to convert back into analog sound.

The next step is *encoding* the data to mp3 (for all you non-purists --
*compressing* to ape or flac if you have an ear). As has been mentioned
earlier, just as a jpg file is a *model* of what the original graphic
looked like, so an mp3 is a model of what the original audio sounded
like. The mp3 encoding scheme can make very crappy, but small models,
all the way up to very mediocre, but larger models. The way that these
variously sized models are described is by indicating how many bits/sec
must be processed to convert (decode) them back into analog sound.

So a 320 kbps mp3 is one that will require processing at 320 kbps; that
will be about 20% the size of the equivalent wav file; and to some ears
in some environments will not be unpleasantly different from the
original audio. A 64 kbps mp3, on the other hand will be about 5% of
the original size, but will only be useful going down the road at 70 mph
on a crappy stock car stereo with the windows rolled down.

Now, as to "streaming." It is very unlikely that a streamed, encoded
file actually is transferring at the same speed it was encoded at.
Think about the overhead introduced by network packetization, for
instance. And how about the last leg of the way into your home, where
it's streaming across a 10mbps cable connection? More likely, the data
is "squirted" into a buffer on your computer at a much higher speed than
the "stream rate."

The only thing we can say for sure is that the data is coming *out* of
the buffer (on your computer) at an *average* rate equal to its
*encoding rate," or bps.

-- Rick