flac --bps used incorrectly in basics-and-workflow.md

[tenturestept]

The --bps option is meant to set the bits per sample to assume when reading raw input. When attempting to use it, flac should fail and output:

ERROR: raw format options (--endian, --sign, --channels, --bps, and --sample-rate) are not allowed for non-raw input

Reduction of bit-depth needs to be done before handing the wav file off to flac, probably in ffmpeg. I'm not sure what the exact ffmpeg options should be for maximal quality dithering.

[tenturestept]

on a certain music tracker, the recommended settings for both bit depth reduction and resampling at the same time are

sox -R -G {input} -b 16 {output} rate -v -L {sample rate} dither

when not resampling, you can just do

sox -R -G {input} -b 16 {output}

since the dither effect is applied automatically when output bit depth is less than 24. do we try to figure out the equivalent ffmpeg aresample filter syntax? or ask people to download sox?

EDIT: thinking about it a little more... why don't we just let people keep the bit depth of the input file. the linked article from xiph's monty basically says that 24 bits is beyond the limit of human hearing, but so is lossless audio in general. the argument in preparation.md:

Some people like the idea of having a (theoretically) perfect copy of the master audio file, don’t mind the increase in size, and state that lossless is the only way to go when archiving

also applies to maintaining bit depth.

[FichteFoll]

Disclaimer: I don't have any money in the contents of this site. I only maintain it.

That said, I think requiring sox if we know a working command line to achieve the desired outcome is preferrable over a non-working ffmpeg command line and we don't have a working one to substitute with. I'm also okay with the stance of "24 bit is good because archival", though I'd personally never do it because of how FLAC pads 24 bit samples to 32. As long as this information is mentioned somewhere, I'd be fine with making bit-depth reduction "optional".

[tenturestept]

I'm also okay with the stance of "24 bit is good because archival", though I'd
personally never do it because of how FLAC pads 24 bit samples to 32. As long as this
information is mentioned somewhere, I'd be fine with making bit-depth reduction
"optional".

Do you know where this is documented? I wasn't able to find anything about this in the
FLAC format documentation and I'm too lazy to read the libFLAC source code.

After a quick trial I was unable to notice any significant reduction in compression
efficiency with 24-bit samples as opposed to 16-bit samples. The steps I took:

1. Generate random audio data of 1 hour with 32 bits of precision using

   sox -V3 -R -n o.wav synth 1:00:00 whitenoise
   

2. Create 24-bit and 16-bit versions using

   sox -V3 -R -G o.wav -b 24 o24.wav
   sox -V3 -R -G o.wav -b 16 o16.wav
   

3. Compress all of them

   flac -8 *.wav
   

If you compare their sizes you will notice that o24.flac is about 1.5 times the size of
o16.flac. This is because 24 is 1.5 * 16. If flac does actually pad each 24-bit sample
to 32 bits before compressing it clearly doesn't affect the encoded file size. Note that I
deliberately didn't use real-world audio data since it introduces the confounding
variable of input entropy.

[tenturestept]

Ok, I double-checked the FLAC format specification and it definitely supports a 24-bit sample size. Both libFLAC and the ffmpeg encoder use that feature. It's easy to verify using a hex editor.

[FichteFoll]

Perhaps this has changed in recent years. From my last tests with this, a flac file with 24-bit samples was twice as big as the dithered-down version to 16-bit (using sox), indicating they were instead stored with twice the size of the 16-bit file. I'll check this again later when I have more time.