Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Using Uuntu 10.4 with Audacity. I'd like to store ripped tracks taken from vinyl with a Sony LX300 turntable (and some CD tracks) in an archival format that I can later convert for use on a portable mp3 player. I think I need flac but I have some questions.

First: Since CDDA is a 16 bit format is there any advantage to archive storage using flac with 24 bits instead of 16? I wouldn't think so but I'm new to this If not - I'm curious as to who uses the 24 bit option?

Second: If flac is "lossless" why does it have 8 different quality levels. Does "lossless" not mean what I thought it means? What is it I'm losing as quality drops since the files seem to be the same size at quality 8 and quality 4?

Initially I was using flac 24 bit, quality 8 (best) to store my ripped tracks but if I'd get the same result with flac 16 - 4 with 30% less file size I'd like to know.

Hotei

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

First: Since CDDA is a 16 bit format is there any advantage to archive storage using flac with 24 bits instead of 16? I wouldn't think so but I'm new to this If not - I'm curious as to who uses the 24 bit option?

No. You don't get any improvement by storing more bits than the source data offers.

Second: If flac is "lossless" why does it have 8 different quality levels. Does "lossless" not mean what I thought it means? What is it I'm losing as quality drops since the files seem to be the same size at quality 8 and quality 4?

What you refer to as "quality" levels are compression levels. If the computer spends more time, it can pack the audio data better. This is like the numeric compression levels for gzip. The tradeoff is faster, but compressed more poorly (larger output) or slower, and smaller output.

Initially I was using flac 24 bit, quality 8 (best) to store my ripped tracks but if I'd get the same result with flac 16 - 4 with 30% less file size I'd like to know.

You will get the same output. Whether the size is smaller may depend on your data (though I'd be surprised if 16 bits, compression level 4 was significantly smaller than 24 (8 unused) bits with compression level 8.

You can test this by encoding the same audio data using your two different methods, then decoding each result into a different file. The two resulting decoded files should be identical.

        /----> [encode @ 24bit x Q8]  ----> highQ ----> [decode] ----> highQ.out
Source
        \----> [encode @ 16bit x Q4]  ----> lowQ ----> [decode] ----> lowQ.out
share|improve this answer
    
Well, here's what happened in my case for the "Ambrosia" CD 16-4 took 232 MB, 16-8 took 231 MB, 24-8 took 428 MB. The increase from 16 bit to 24 bit was about 85% (I only expected 50% increase so that was a surprise) The size decrease from 232 to 231 isn't enough to worry about. If it's lossless how can you say it's highQ vs lowQ? If it reproduces EXACTLY the same waveform as original CDDA data (flac is a lossless encoder) then quality should be equal... the difference should be only encoding/decoding time (correct me if I'm wrong) –  hotei Jun 30 '10 at 2:11
    
Lossless data compression is a funny beast. Some files, when compressed, actually get larger. Sometimes changing the compression algorithm to one that tends to produce smaller files actually produces bigger files in some cases. Try: "touch /tmp/a ; gzip /tmp/a ; ls -l /tmp/a.gz". You'll see that the zero byte file "compressed" to a 22 byte file. It still decompresses to the same zero byte file. –  Slartibartfast Jul 1 '10 at 4:26
    
Second, 'highQ' and 'lowQ' were clearly not the terms I should have used. Please feel free to substitute 'low-speed' and 'high-speed' for highQ and lowQ respectively. The differences should be encoding time and output file size, but not the sound of the output. The only caveat is that it is possible that the two resulting files from the example I gave would differ because of the number of bits used in the encoding stage. That wouldn't make the quality any different at the output, but it would make the output file tend to be larger, and it might make it not match, byte-for-byte. –  Slartibartfast Jul 1 '10 at 4:32
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.