Repository navigation
flac --bps used incorrectly in basics-and-workflow.md #84
Description
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.
Activity
tenturestept commentedon Apr 17, 2024
on a certain music tracker, the recommended settings for both bit depth reduction and resampling at the same time are
when not resampling, you can just do
since the dither effect is applied automatically when output bit depth is less than 24. do we try to figure out the equivalent ffmpeg
aresamplefilter 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:
also applies to maintaining bit depth.
FichteFoll commentedon May 5, 2024
Disclaimer: I don't have any money in the contents of this site. I only maintain it.
That said, I think requiring
soxif we know a working command line to achieve the desired outcome is preferrable over a non-workingffmpegcommand 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 commentedon May 9, 2024
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:
Generate random audio data of 1 hour with 32 bits of precision using
Create 24-bit and 16-bit versions using
Compress all of them
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
flacdoes actually pad each 24-bit sampleto 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 commentedon May 9, 2024
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 commentedon May 13, 2024
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.
L4cache commentedon Jan 7, 2025
FLAC does not pad 24bit to 32bit. Even if it does, the "wasted bits" feature of it will eliminate nearly all of the padded zeros.
(Now FLAC actually supports 32bit, you can manually test this. Or even just pad 16bit to 24bit.)
Codecs that lack this kind of feature will suffer from padding.
The reason that for regular audio, 24bit flac is 2x larger than 16bit is just they are harder to compress.
(If they are euqally hard to compress, it should be roughly 1.5x, like the synthetic white noise test. Harder to compress + more data results in 2x)
For the resampling, FFmpeg can use SoX resampler as well, but I'm not sure how it compares to standalone sox program. I don't understand why you say it's "non-working".