Support of 32-PCM (copy mode)

[JeromeMartinez]

No FLAC encoder supports 32-bit but we could support 32-bit PCM input by using a raw copy, no compression gain but at least we have a single package, checksums...

[retokromer]

but we could support 32-bit PCM input by using a raw copy

Indeed!

[ktmf01]

I could look into this from a FLAC perspective if you like, but I have no material to test with. Furthermore, I'm really curious what 32-bit storage is used for? As far as I understand, there exists no hardware that can handle audio with a low enough noise floor to justify the use of 32 bit?

Just to make sure: this concerns 32-bit integer audio? The FLAC encoder is unable to handle 32-bit int, but the FLAC format is not able to handle 32-bit float material.

[JeromeMartinez]

but I have no material to test with.

I don't have real content either (could have some if needed). In the meanwhile:
ffmpeg -f lavfi -i "sine=frequency=1000:duration=5" -c:a pcm_s32le test_int.wav
ffmpeg -f lavfi -i "sine=frequency=1000:duration=5" -c:a pcm_f32le test_int.wav
But then need to inject some random data in the file because they have lot of zeroes.

As far as I understand, there exists no hardware that can handle audio with a low enough noise floor to justify the use of 32 bit?

I will not judge about the relevance of the characteristics of the input, I just see that I have a request to support this input in the tool.

this concerns 32-bit integer audio?

In practice both int and float.

The FLAC encoder is unable to handle 32-bit int, but the FLAC format is not able to handle 32-bit float material.

In practice interpreting float as int is usually fine (we use a kind of hack for using FFV1 with float, FFV1 encoder sees int and compress the content well), but lack of metadata makes it definitely as a hack.

I could look into this from a FLAC perspective if you like,

From my point of view the effort is not worth it except for a proof of concept, because I guess that the compression will not be good, lower bits being more "random" than something else (like 16-bit per component for video), and effort should not be on that. But I don't want to prevent you to try for having technically an encoder supporting 32 bits! :)

[ktmf01]

I know this is probably a bit too late for RAWcooked and quite contrary to my own goals of promoting FLAC usage, but there is another open-source (BSD licensed) lossless audio codec supported in both encoding and decoding by ffmpeg that is already able to properly process 32-bit ints and 32-bit floats without any hacks: WavPack. It also supports DSD as input, which is something FLAC doesn't. WavPack isn't as widespread as FLAC, but there is quite some software support as well.

Just a suggestion. I can write a small patch to let FLAC accept 32-bit audio as store-only, or a slightly larger patch to give it some compression with only fixed subframes, but if (properly) compressing formats like DSD and 32-bit float audio is somewhere on a wishlist, maybe switching wouldn't be a very bad idea.

I see that the ffmpeg wavpack encoder already supports floating point as an input sample format.

[JeromeMartinez]

I can write a small patch to let FLAC accept 32-bit audio as store-only

May be nice and we would test on real content and see if the other bits are well compressed. But it would need to be in FFmpeg as we currently use FFmpeg for the encoding.

WavPack isn't as widespread as FLAC

We try to promote the most widespread format when no need of more in order to have a minimal compression formats "package", but using another format is not incompatible with RAWcooked and could be chosen as default in the future if it becomes more used. Issue there is that 32-bit is not so much needed :-p.

[retokromer]

Furthermore, I'm really curious what 32-bit storage is used for?

We use from time to time the 32-bit quantisation to digitise analogue magnetic tapes which are heavily degraded. This opens up more possibilities for restoration work. Sorry to respond late.

[ktmf01]

May be nice and we would test on real content and see if the other bits are well compressed. But it would need to be in FFmpeg as we currently use FFmpeg for the encoding.

Ah, I saw a copy of libFLAC under Source/Lib/ThirdParty/flac and assumed libFLAC was being used, but I see now that this has been stripped to only decoding functions. Is this being used, or is ffmpeg also used for decoding? I have done some testing, and it seems ffmpeg only needs patching of its FLAC encoder, not its decoder, when verbatim subframes (copy mode) is used. Any form of compression needs patching of both encoders and decoders.

We use from time to time the 32-bit quantisation to digitise analogue magnetic tapes which are heavily degraded. This opens up more possibilities for restoration work. Sorry to respond late.

Would it be possible to explain this a little bit? Not only because I'm curious, but I'm definitely going to get questions about this when I submit a patch to ffmpeg. As I know audio bit depth (and I think most people concerned with this), 24 bit audio provides a 144dB signal-to-noise ratio, while even the very best of hardware (amplifiers, A/D converters etc.) cannot provide more than 120dB. That still provides 24dB of room to patch parts together that have been recorded with different amplifications. 32 bit provides an extra 48dB of headroom, but I cannot imagine a workflow that would need that.

[ktmf01]

A patch has been sent to ffmpeg: http://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/289794.html

Thorough description is in the linked patch. In short, I've found a way to add compression (actually quite reasonable, beating WavPack on the files I've tested) that can be decoded by existing decoders. libFLAC is capable of decoding since the release of flac 1.2.1 in September 2007 (although the flac command blocks any 32-bit files, libFLAC itself doesn't object) and ffmpeg is capable since release 2.7, May 2015. Because of that, VLC play the generated files fine.

[JeromeMartinez]

ffmpeg is capable since release 2.7, May 2015.

Great news! Especially because we can control well the encoder version but not the decoder version. We'll try this patch with RAWcooked and see how it behaves with content of users.

I see now that this has been stripped to only decoding functions.

Right, we embed libflac for decoding. FFmpeg is used for encoding. At long term we plan to use libflac also for encoding.

[ktmf01]

Right, we embed libflac for decoding. FFmpeg is used for encoding. At long term we plan to use libflac also for encoding.

Why? Seems like a lot of work with little benefit for the RAWcooked use case?

[ktmf01]

A newer patch has been sent to ffmpeg: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220103202608.56364-1-mvanb1@gmail.com/ Please don't use the patch sent earlier, it causes 24 bit input to be encoded as 32 bit FLAC.

To use this new patch, the use of command line option -bits_per_raw_sample 32 is necessary. This is because of a bug in ffmpeg: https://trac.ffmpeg.org/ticket/9563

[ktmf01]

it causes 24 bit input to be encoded as 32 bit FLAC.

Are such files valid from the point of reference standard? BTW, looks like it now causes this: xiph/flac#301

Those issues are not related. The issue you link is about WAV reading, the issue I mentioned is about converting any 24-bit input to 32-bit FLAC. The first is a problem in the reference encoder, the second is an issue with ffmpeg.

This is like TrueHD/MLP, MLP has metadata to diff 16 bit and 24, TrueHD does not, so it may be 16 bit in 24 or 24 (encoder is lossless in ffmpeg with ffmpeg's decoder). flac can be even 8 bit, see https://trac.ffmpeg.org/ticket/9270 (please check the issue, BTW, patches welcome)

No, that doesn't have anything to do with either issue.

As for your final 32 bit patch, do you propose reverting FFmpeg/FFmpeg@ab3ef54?

After all it also affects .wv

No, that would not be a proper fix.

I also propose you create some 24 bit in 32 and 32 bit samples issue in trac of ffmpeg, so that your patch is not lost. Or I can do it for you.

I've found an issue with this patch that is probably best fixed first, so it is perhaps best not to try to push this patch.

Why? Seems like a lot of work with little benefit for the RAWcooked use case?

Because there is a consensus that ffmpeg encoder that supports Multi-dimensional quantization and cholesky algo is better, you know that. Simple.

The discussion was about moving from ffmpeg to libFLAC, not the other way around

[retokromer]

The discussion was about moving from ffmpeg to libFLAC, not the other way around

Indeed, that’s the goal.

[ktmf01]

I forgot to mention it here, support for 32 bps FLAC in ffmpeg has been merged 2 weeks ago: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/d8f1404c50dfc3e3792b823e97abf56b5c5e9ee2