Questions about FLAC encoding options

[XB-70 Valkyrie]

I have some questions about FLAC encoding options --specifically in MediaMonkey (found under the "settings" button under the "format" pull-down menu in the "rip CD window"), but more generally I think these should apply to other encoders as well:

1.) I did not see options for sample rate and bits per sample in WinAmp (which I had used previously for FLAC encoding). I assume it is OK to leave these at default. I also assume there is nothing to be gained by selecting anything higher than 44.1 kHz and 16 bits per sample for a standard CD. Is that correct? Does Default automatically select these for a standard CD, or would I be better off to select them myself (rather than leaving it at default)? For an SACD (of which I own only a few), I assume the higher settings would be useful?

2.) The amount of compression affects the time it takes to complete the rip, however does this affect final sound quality at all? What are the optimum settings? I currently have the slider in the middle.

I would like to preserve the highest sound quality possible and am not all that worried about drive space.

Thanks for your help!

[Wanderer]

I don't use MediaMonkey, but here are some general thoughts.

1) There is absolutely nothing to be gained by going above 44.1/16 kHz/bits when ripping a CD, in fact it's to be avoided. This is called upsampling, where the coding algorithm invents entirely new information for the waveform (if you're lucky, based on what followed and what is to follow) in order to sound more natural. This may sound good in theory, but in practice, unless it's one of those über-advanced, dedicated upsampling algorithms (like the one e.g. dCS uses in its upsamplers that cost more than cars) the process only introduces artefacts in the music and lowers the quality. So, upsampling when ripping CD's, big no.

As for SACD's, you're still ripping the CD, not the SACD layer, so the above also applies. There was a time when one could rip a SACD proper by using an old PlayStation console with a specific firmware, but Sony has closed that loophole years ago.

2) When you're using a lossless encoder no information that can't be retrieved is rejected so theoretically you have no compression artefacts like when you encode MP3s. Every time you play the encoded FLAC file, the algorithm is able to reconstruct the original WAV file.

[71 dB]

1) There is absolutely nothing to be gained by going above 44.1/16 kHz/bits when ripping a CD, in fact it's to be avoided.

Correct. Keeping the original sampling rate and bit depth is a truism in lossless coding.

This is called upsampling, where the coding algorithm invents entirely new information for the waveform (if you're lucky, based on what followed and what is to follow) in order to sound more natural.

Incorrect. There is something wrong with the upsampling algorithm if it tries to 'invent' new information. Bits and information are different things. We can have a lot of bits without much information. Ten minutes of silence on a CD means 10 minutes of no information (the only information we have here is that the silence lasts for 10 minutes, but such information really needs only 25 bits to encode!), but it takes about 100 MB ripped. Having the original band-limited information transformed into higher sampling frequency does not mean more information nor does it require new information. Similarly, reducing sampling rate does not mean losing information as long as the sampling frequency is at least twice the highest frequency in our signal.

Above applies within the limits of computational accuracy and bit depth (might be a problem with 16 bit, is not a practical problem with 24 bit).

In order to sound more natural? What is more natural? Signal processors make exact mathematical calculations and know nothing about (subjective) concepts like natural and unnatural.

This may sound good in theory, but in practice, unless it's one of those über-advanced, dedicated upsampling algorithms (like the one e.g. dCS uses in its upsamplers that cost more than cars) the process only introduces artefacts in the music and lowers the quality. So, upsampling when ripping CD's, big no.

Proper upsampling (and downsampling for that matter) is done using sinc-interpolation. I have myself wrote Matlab script to make very high-quality sampling rate conversion so I know what it takes. Since sinc-function starts from minus infinity and goes to infinity, in practice it has to be time-windowed. The wider the window, the more accurate sampling rate conversion, but the computational task increases. Luckily the shape of sinc-function means one does not need very wide time window to achieve very precise conversion.

In practice upsampling when ripping CDs only gives you bigger sound files and that's just stupid.

2) When you're using a lossless encoder no information that can't be retrieved is rejected so theoretically you have no compression artefacts like when you encode MP3s. Every time you play the encoded FLAC file, the algorithm is able to reconstruct the original WAV file.

Correct. Lossless coding gets rid of redundance in the signal. The trick is to find that redundance. Fast algorithms find some of that redundance and slower algorithms make more work to find more redundance.

[Gurn Blanston]

Of course as rules of the road, these last 2 posts are right on the money. But in answer to your question; I have used FLAC exclusively for the last 8 years, and specifically, there is no difference in quality from the various settings you see there. When you choose 'higher' or 'better', you get a more compact file (not really significantly in my experience), but it takes longer to encode it (which actually IS a noticeable time). I'm in no rush, so I always set my encoder at the highest level (8 in dBpoweramp). In theory this should give me the most compact files, which with my 6 Terabytes of storage is probably meaningless, but it's my nature. My files are no higher sound quality than they would be on the default (5) setting.   

[drogulus]

     Decode CDs at the same rate, nothing is gained by oversampling them. If there's HDCD encoding on the disk, though, ripping should produce a 24 bit file. dBPoweramp will do it right.

     How to rip HDCD albums ??

     There's some discussion about the quality of the reverse engineering dBPowerAmp does, to no practical effect.

[XB-70 Valkyrie]

Thanks for you thoughts. Does anyone know whether the "default" in MediaMonkey is for 44.1 and 16? Would it be best if I just set 44.1 and 16 manually instead of relying on the default?

Thanks

[Gurn Blanston]

Thanks for you thoughts. Does anyone know whether the "default" in MediaMonkey is for 44.1 and 16? Would it be best if I just set 44.1 and 16 manually instead of relying on the default?

Thanks

I have Media Monkey, but I only use it for playback. I just looked at the input/output codec for flac and it doesn't offer options in the setup tab, maybe it does when you are actually ripping?

Anyway, I can't imagine, even remotely, that the default on it would be anything other than 44.1 and 16. Or really, why they would even let you get at it to mess it up. If you wanted anything other than 44 & 16, you wouldn't be ripping with MM to begin with. Just sayin'...

[XB-70 Valkyrie]

Great thanks.

one more: "Standard Read", "Jitter-Corrected Read" or "Secure Read (takes extra time)"?

[Gurn Blanston]

Great thanks.

one more: "Standard Read", "Jitter-Corrected Read" or "Secure Read (takes extra time)"?

Yes, I would say that. Secure read, I believe, reads and then double checks before coding. I've used it, but don't feel it was a big advantage for my purposes. It does take longer. Jitter corrected is something else I haven't had to use, I will still keep it in reserve to try as a last resort on a disk which gives errors. I am not sure what process it applies, but I would guess it goes far more slowly to try and extract data off from questionable media. Both of those things would not be a normal option, just something you would try either if you are having a hard time reading a disk or else if you are making a special rip of something (borrowed??) that you can't afford to not get the best result in terms of data loss.