Ripping To .flac, Compression Level ?'s

[masonwinston]

hiya.

I'm ripping my library to .flac, but I'm confused about the compression levels. I interpreted the 0 thru 8 scale to mean that a level 0 rip would mean less compression, which I equate with (theoretically) better sound.

Whether or not my theory on better sound is true, am I reading/understanding the 0-8 scale properly, or do I have it backwards (meaning that level 8 is least compressed)?

thanks!

[dypsis]

Re: Ripping To .flac, Compression Level ?'s

Audio quality should be the same on all compresssion levels, as FLAC is lossless.

The compression level just makes the files smaller.
The higher the compression level (8 being highest level), the smaller the file.

[sredmyer]

Re: Ripping To .flac, Compression Level ?'s

Audio quality should be the same on all compresssion levels, as FLAC is lossless.

The compression level just makes the files smaller.
The higher the compression level (8 being highest level), the smaller the file.

Higher compression levels also take longer to encode. So if speed of the process is important you may want to consider that.

[EliC]

Re: Ripping To .flac, Compression Level ?'s

It takes longer to compress the file more and longer to uncompress it.

Quality with FLAC is always exactly the same as the original file.

[dypsis]

Re: Ripping To .flac, Compression Level ?'s

Higher compression levels also take longer to encode. So if speed of the process is important you may want to consider that.

I have read that a number of times, but I would have to get out my stop watch to be able to discern the difference.

[Porcus]

Re: Ripping To .flac, Compression Level ?'s

It takes longer to compress the file more and longer to uncompress it.

Disregard the latter -- if true, it should be insignificant. See the table at the near-bottom of http://flac.sourceforge.net/comparison.html

I use -8 (smallest file, takes most time to encode) -- since I have a dual-core CPU (and the Reference version of dBp), the encoding is done in one core while the next track is ripped by the other, and usually ripping takes more time (i.e. no time loss). The exception is of course the last track on a CD.

Since decoding time is anyway short, the file is verified after encoding -- that means, dBp decodes it and compares it to the uncompressed, to ensure there are no write errors.