[Cowboy Pinkhat]

Hello,
 
When I convert a certain .ape file to .flac (uncompressed) it is 65Mb (1411 kbps)
But when I use compression level 5, it is 34Mb (746 kbps)
 
I see that in Foobar2000.
 
Is there a difference in audio quality between the two? I know there shouldn't be, but aren't kbps's dropped in favor of the compression? Aren't here supposed to be identical kbps?
 
Thank you

 

[Somnambulist]

I think when you see the kbps thing it's like an implied average based on the file size after compression, as lossless file formats are containers which house the untouched WAV or whatever inside. The only thing different about levels of compression is the resulting file size with lossless as the file within the container is bit-for-bit identical with the CD/WAV), and the time it takes for your CPU to decode it (which given today's multi-core, multi-threaded CPUs shouldn't be an issue). When you play back the file it's decoded and the real kbps will be the same for wav/flac/flac level 5/ALAC etc. That's my understanding anyway!

 

[Cowboy Pinkhat]

I thought so.
But when I play the (compressed) file in Foobar, it says it 'has' 746 kbps. So when does the decompression/decoding take place?

 

[Satellite_6]

I think the bit rate is correct, it's just that FLAC throws away a lot of zeros. (empty data) correct me if I'm wrong. I'll have to go read about it because I'm curious now. . . 
 
Does FLAC decompress to 1411 kbps on playback or does it completely throw away empty data? I actually don't know.

 

[Cowboy Pinkhat]

TThanks all. I think the answer is here somewhere.
 
It states that Foobar shows the input kbps, not the decoded/decompressed kbps.

 

[Satellite_6]

http://flac.sourceforge.net/faq.html#general__not_wave_compressor
 
"FLAC's purpose is not to reproduce a WAVE file, including all the non-audio data that is in it, it is to losslessly compress the audio."
 
I think I may actually be right. FLAC can be decompressed into a bit perfect WAVE file but it is decoded on playback, not decompressed, because decompression is pointless since no actual audio data is lost?
 
EDIT: Nah, I'm dead wrong. I'll never understand this tech stuff. 

 
http://www.hydrogenaudio.org/forums/index.php?showtopic=89536&hl=

 

[Fraiz]

Formats such as FLAC and APE are kind of like a lossless version of a VBR MP3 file.
 
The encoder will look at each individual sample of the audio track and decide how much bits it has to allocate to that sample in order to keep it lossless.
 
You'll find that different tracks in FLAC or APE will show up in different bitrates. Thats just the average bitrate thats been applied to that particular track.
 
Complex tracks tend to have an average of around 1000kbps where as simplistic tracks can have an average as low as about 600kbps.
 
You'll find that these lossless formats have different encoding levels. The lower the level you pick, the faster it will take to encode the WAV files to the lossless format, but the average file sizes will be bigger, where as, if you select a high compression level, it will take longer to encode the WAV files to the lossless format, but it will do a better job of downsizing.
 
Either way, you can be assured that it is an exact replica of the WAV file (or CD of course)

 

[DougofTheAbaci]

I think the simplest way to put it, and correct me if I've got this wrong, is that FLAC and other similar formats are the audio equivalent of a ZIP file.

 

[JesperZ]

Try to look at it this way:
 
This stream of bytes represent a 1 second frame of audio: 12345666667
The stream consists of 13 bytes.
 
Now if one was to compress this stream it could be done in several ways, for example counting replications of bytes and replacing common patterns.
Say 12345 is a common pattern. It could be replaced by @x (@ indicating a fixed length pattern replacement). @x takes up 2 bytes while 12345 takes up 5 bytes, and as such 3 bytes are saved.
Now we have 66666, which are five 6's. This could be denoted by &56 (& indicating replication, 5 the amount of bytes and 6 the actual byte). &56 takes up 3 bytes while 66666 takes up 5 bytes, and as such 2 bytes are saved.
 
The stream now looks like this:
@x&567
and is now only 6 bytes long while it was 13 before. Since it was a 1 second frame of audio and one byte equals 8 bits it is now compressed to 48 bps instead of 104 bps. On playback the patterns and replications would occur and restore the original stream, so all details are retained.
 
This is not quite how lossless compression works but I think this illustration gives you an idea of how a smaller file can equal same quality. You trade size for processor power, but since processors these days are so fast it is barely a tradeoff anymore.

 

[Cowboy Pinkhat]

Thanks all for your answer, it's clear.
When I was googlin'myself on the subject, I came across this site which explain a lot of (computer-)audio terminology: http://www.thewelltemperedcomputer.com/KB/1_intro.htm
and especially http://www.thewelltemperedcomputer.com/KB/BitRate.htm



 
Thanks again.