2

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

Improve this question

1 Answer 1

Reset to default
2

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
Improve this answer
3
  • 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, 2010 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, 2010 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, 2010 at 4:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .