## FLAC --bps setting real meaning

1

I'm going to grab some audio from DVD in best possible quality. My software supports FLAC encoder and lets me to choose various bit per sample settings for it: 8, 16 or 24. And I got confused.

FLAC is a lossless format. So the results of encoding with --bps=8 and --bps=24 should be the same quality. My software indicates that expected filesize with --bps=8 will be much smaller. So why it lets user to choose this setting? The smaller filesize with same audio quality is always better! Is the deal in speed of encoding?

After some googling I found a few mentions about different audio hardware that supports bps < 16 and doesn't support bps 24 etc. So it might be not about encoding but about decoding - if you encode in bps=24 you may face with some problems with oldest hardware while playing. And with bps=8 newest hardware might not provide best quality...

So, I'm confused. What is a real meaning of --bps for FLAC? Or at least: Should I choose --bps=24 to save audio in max quality or --bps=8 is enough?

1We cannot really help until we know the precise format of the original soundtrack. Doing conversions for no reason is not going to get the best result. Your best bet is always to use the bit-depth & sample rate of the original, or at worst a 'simple arithmetical' alternative. e.g. it's never going to be as good going from 96kHz to 44.1 is it would be to 48. Equally, it's not going to do anything but take up more disk space if you convert 16-bit to 24-bit. – Tetsujin – 2016-08-30T18:47:44.967

1

According to the man page, --bps specifies the bits per sample. As far as I can tell, this parameter controls the data that will be encoded using FLAC, and can have a lossy effect. For example, here's a comparison of a short audio clip using 8, 16, and 32 bits:

You should never use 8 bits unless you're going for an effect, or building a telephone system. 16 bits is the standard for consumer music playback, and is probably just fine. 24 or 32 bits is the standard for music recording, production, and mastering, but is probably unnecessary for your application. Obviously, if the source DVD uses 16 bit audio, there's nothing to be gained by ripping in 24 bit.

1It's a lovely answer - but it misses the point... what's the point in trying to grab a lossless format from a DVD, without knowing what format it is already encoded in? If it's AC3, then just rip the AC3 unchanged. It's already lossy. Re-encoding a lossy format is going to be at best just 'bigger'. – Tetsujin – 2016-08-30T18:43:10.247

@tetsujin: That's a very good point - I forgot about the source media. Is the standard DVD codec for audio lossy? – Linuxios – 2016-08-30T18:44:48.413

Thing is... there is no 'standard' - or there is but it's very broad - see https://en.wikipedia.org/wiki/DVD-Video#Audio_data [It's actually one reason I now let my computer's built-in soundcard do the decode to my 5.1 amp & transmit as analog... to save double/triple decodes to what is actually a far better decoder in the amp - just ultimately less satisfying]

– Tetsujin – 2016-08-30T18:50:20.343

Hi, you're right I missed the fact that original DVD's track is in lossy AC3 48kHz 6 channels and 448 kb per sec. I just extracted it as AC3. But just for better understanding of a topic: I suppose if the source DVD uses 16 bit audio isn't applicable to AC3? Bcs I can't see any info about bits per sample in its codec description. Is it inapplicable to all lossy formats and is replaced by kbits per second statistic? – truf – 2016-08-30T19:09:58.083

I've always known AC3 to be the standard. I once heard off professionals, that they change the AC3 compression depending on the size of the video content. By the way, 448kbps @ 48kHz = (448/1024)bps/48000 = 9.6 bits per sample. Am I right? I'm not very good at maths. – Marc W – 2016-08-30T22:54:56.483

1Non-PCM formats, such as lossy compression formats, do not have associated bit depths. For example, in MP3, quantization is performed on PCM samples that have been transformed into the frequency domain. from Wikipedia – Marc W – 2016-08-30T22:59:38.150