Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: The product of constants is a constant: a bit rate question. (Read 5959 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

The product of constants is a constant: a bit rate question.

Hi Folks,

I have a simple bit rate question regarding FLAC files. (I have been looking at the bit rate values of various FLAC files using JRiver and MediaMonkey.)

If bit rate is the product of constants why do FLAC files have unique bit rates? That is, all FLAC files ripped with a given bit depth, sample rate, and channel number, all constants, should share an identical value for bit rate. For example, FLAC files ripped at CD quality should all display an identical bit rate, 1,411.2 kbps (bit depth x sample rate x # of channels; 16 x 44100 x 2).

It seems it might somehow be connected to compression because the values listed for bit rates are all less than expected.

Of course I am too uninformed about the technical aspects of digital sampling to justify this question; nevertheless, bit rate is related to bit depth and sample rate and does not include file size, so how can its value be altered when considering compression? Why would compression/decompression change the bit rate?

Thanks for any help with this question!

The product of constants is a constant: a bit rate question.

Reply #1 –
Quote
bit rate is related to bit depth and sample rate and does not include file size

No.
Bitrate = filesize/duration. (or audio_data_size/duration, if a file contains metadata, cover art, etc).

The product of constants is a constant: a bit rate question.

Reply #3 –
Consider the following:

00000000000000000000000000000000000000000000000000

I could just say that's '50 "0"s' which saves about 80+% characters, ie. ~80% compression.

12345678901234567890123456789012345678901234567890

That I need to say is '"1234567890" repeated 5 times' which is around 50% compression.

The original data length is the same in both cases, but one can be described more briefly. So it is with FLACs and WAVs. WAVs are the full 50 characters in both cases, and thus are the same size, but the shorter, compressed versions are different, because the characters themselves are different. It'd probably be helpful if I did the math and gave more precise figures, but meh. The point is still clear.

The product of constants is a constant: a bit rate question.

Reply #4 –
Quote from: Canar on
Consider the following:
12345678901234567890123456789012345678901234567890

That I need to say is '"1234567890" repeated 5 times' which is around 50% compression.


You could also say
"00000000000000000000000000000000000000000000000000123456789012345678901234567890123456789012345
67890 but ignore the leading zeroes"
which has resulted in triple the "bitrate" but identical content.


@tdxloki - it is important to note that bitrate and quality are not the same thing.  Bitrate is only a measure of the file size.  In simple non-technical terms, FLAC files eliminate redundant data to reduce the bitrate without changing the data or the quality.  Some music files contain more redundancy than others.

The product of constants is a constant: a bit rate question.

Reply #5 –
Quote from: lvqcl on
Quote
bit rate is related to bit depth and sample rate and does not include file size

No.
Bitrate = filesize/duration. (or audio_data_size/duration, if a file contains metadata, cover art, etc).


Thanks for the reply!

Ok, but now I have two definitions for bit rate.  One indicates that bit rate is the product of bit depth, sample rate, and number of channels.  This I found on various digital sampling websites and wikipedia.  Your definition makes sense too because dividing file size by a time gives a rate.

I did some quick math on a few files (converted file size from MB to bits and divided by the length in seconds) and found the number very closely matched what was displayed by JRiver.  Those files all have meta so the calculated bit rate would be lower when only using the audio data size.

I guess I am getting too caught up in bit rate.  What does bit rate really convey anyway given that bit depth and sample rate are more descriptive of the content.

The product of constants is a constant: a bit rate question.

Reply #6 –
You are confusing compressed and uncompressed bitrates. The bitrate of a compressed file is file size divided by length, but the data becomes larger when it is uncompressed (which it must be in order to play it), so the bitrate of the uncompressed data is a function of bit depth, sample rate and channels.

The product of constants is a constant: a bit rate question.

Reply #7 –
Quote from: tdxloki on
I guess I am getting too caught up in bit rate.  What does bit rate really convey anyway given that bit depth and sample rate are more descriptive of the content.


Beyond making sure that you have enough bandwidth to stream the file over a network or read from a storage medium, it is completely meaningless.  There are meaningful factors that influence bitrate (bit depth and sample rate in PCM, data redundancy in lossless codecs like FLAC, quality and frequency content in transform codecs like MP3).  Because bitrate is effected by quality-related attributes, it is often misinterpreted as being a metric of quality itself.  It is not.

The product of constants is a constant: a bit rate question.

Reply #8 –
@lvqcl
@Canar
@Apesbrain
@benski
@pdq

Thanks for spelling it out for me!  This was my first post here and it has been very informative!  Very cool, thanks.

The product of constants is a constant: a bit rate question.

Reply #9 –
And, to add, this is why you will not get any better sound by storing as .wav.

This is also the way .zip works - it does not lose file content, it just packs it better.