Live data from Hacker News

FLAC 1.4.0 released – added support for 32-bit audio

xiph.org

21–30 of 119 posts

Re: FLAC 1.4.0 released – added support for 32-bit audio

#21
post #11

Sadly still no support for variable blocksize.

I made my own encoder and experimented with variable block size (with dynamic programming) plus a massive amount of brute-force search for LPC parameters. But the amount of compression gain I could achieve over libflac was small and not worth the hours of encoding time. https://www.nayuki.io/page/benchmark-of-nayukis-flac-encoder

Re: FLAC 1.4.0 released – added support for 32-bit audio

#22

After reading "How Music Works" by David Byrne, it seem like FLAC is solving the wrong problem. No one needs over 4 billion discrete levels.

You're correct; lossless formats aren't needed by the average consumer. But the problem they solve is a very real thing. Think of the difference between a repeatedly edited JPG vs. a repeatedly edited PNG. Every save of the JPG destroys information irretrievably, whereas every save of the PNG keeps it all. It's the same with MP3 vs. FLAC: MP3 throws away information each export, but FLAC doesn't. For an example, musi…

16 bit is not enough?

Re: FLAC 1.4.0 released – added support for 32-bit audio

#23

Earlier quoted context omitted.

Nyquist-Shannon simply says that you need 2x the sample rate of the highest frequency to perfectly recreate something. So, to recreate a 20 kHz wave that was sampled at 16 bits, you'd need 40 kHz sample rate. Bump that up to 22.05 kHz (for anti-aliasing) and you get CD audio. The bit depth, OTOH, is your signal-noise ratio (noise floor) when sampling/quantizing said audio. It's unrelated to Nyquist-Shannon. More bits…

Yes, you only need that many samples given you know a maximum frequency. But to actually perform the conversion from discrete samples to continuous wave takes infinitely many steps. The number a given DAC actually does varies. Some do hundreds, some thousands, a couple rare (very expensive) ones do 100k or more. That's what I'm saying. Increase the number of samples in the audio itself, and the DAC can get closer to…

Except it's not. The video shows that. In the real world, the DAC doesn't immediately jump from code N to N+1; it slides (the "slew rate" of the opamp). More bits just makes the difference between codes N and N+1 smaller; i.e. where it slides to is more accurate to the original. The "stair step" or "straight line" view you get from programs like Audacity is a lie.

Re: FLAC 1.4.0 released – added support for 32-bit audio

#25
post #5

After reading "How Music Works" by David Byrne, it seem like FLAC is solving the wrong problem. No one needs over 4 billion discrete levels.

I am a recording engineer and I will choose 32 bits over 24 any day when recording. Of course you need the right (exceptionally good!) preamps to even make a difference here, but when you are manipulating audio 32 bits and upwards (for summing) are the default (for a reason). Having something to store those files with a little bit of lossless compression is a welcome addition

> I will choose 32 bits over 24 any day

why?

Re: FLAC 1.4.0 released – added support for 32-bit audio

#26

Earlier quoted context omitted.

You're correct; lossless formats aren't needed by the average consumer. But the problem they solve is a very real thing. Think of the difference between a repeatedly edited JPG vs. a repeatedly edited PNG. Every save of the JPG destroys information irretrievably, whereas every save of the PNG keeps it all. It's the same with MP3 vs. FLAC: MP3 throws away information each export, but FLAC doesn't. For an example, musi…

16 bit is not enough?

[deleted]

Re: FLAC 1.4.0 released – added support for 32-bit audio

#27

After reading "How Music Works" by David Byrne, it seem like FLAC is solving the wrong problem. No one needs over 4 billion discrete levels.

You're correct; lossless formats aren't needed by the average consumer. But the problem they solve is a very real thing. Think of the difference between a repeatedly edited JPG vs. a repeatedly edited PNG. Every save of the JPG destroys information irretrievably, whereas every save of the PNG keeps it all. It's the same with MP3 vs. FLAC: MP3 throws away information each export, but FLAC doesn't. For an example, musi…

(I think) They're not saying FLAC is pointless, just that 32 bit audio is. Even music producers record and export at 24bit, 32/64bit is only used for the effects and mixing (because compounding quantization noise and rounding errors is very real).

You can't find 32 bit PCM music anywhere, even hifi DVD audio is 24bit/96khz.

Re: FLAC 1.4.0 released – added support for 32-bit audio

#28
post #18

After reading "How Music Works" by David Byrne, it seem like FLAC is solving the wrong problem. No one needs over 4 billion discrete levels.

While I doubt that human ears need 4 billion discrete levels, I think it's important for archival purposes.

Is it? What is your reasoning? And why would you pick 32-bit, instead of 24-bit or 64-bit or something else?

Actual audio equipment has a noise floor. The encoding depth you use also has a noise floor. If the noise floor of the encoding is far below the noise floor of the signal, then it won't be perceptible.

So you choose to put your noise floor at some amount below the existing noise floor. Not infinitely below, because that would require infinite bits. This is the reasoning you'd use for 24-bit audio, which has a very comfortable noise floor of -144 dB, which leaves a large margin even for extreme low-noise professional equipment (you might see -120 dB ish for extremely good equipment).

At 24-bit, even passive components like transformers and resistors are contributing measurable amounts of noise.

The reason you might pick 32-bit in practice is so that you can have lots of headroom for some DSP algorithm, or do lots of sums of different signals without accumulating quantization error. The final "archive" file will still have worse than 24-bit precision.

Re: FLAC 1.4.0 released – added support for 32-bit audio

#29

I had no idea FLAC didn't store 32-bit. I'll need to look over my library and make sure nothing strange is going on. I'm curious if sites like Qobuz will suddenly replace some of their existing files with higher-bit copies if they already had them and just had no way to encode them as FLAC.

It is extremely hard to justify 32-bit audio from a technical standpoint, since it requires that every component in your audio chain has better than 144 dB dynamic range. In practice, just about none of the analog components in your audio chain will have that kind of dynamic range, and any analog components in the recording chain are unlikely to have that range either. The kind of equipment I'd expect to see in order…

I could see it as part of a pipeline/workflow where having that dynamic range lets you not worry about losing meaningful information through everything, even if you're going to compress it and take it back to 16bit cd quality at the end. Being able to losslessly store the results of each step in a FLAC file should be better than raw data since it'll be compressed and easier to manage then. That said, at the edges of that I totally agree even 24-bit can be questionable there since a lot of the analog side doesn't have a noise floor that would let it be meaningfully used.

Re: FLAC 1.4.0 released – added support for 32-bit audio

#30

I had no idea FLAC didn't store 32-bit. I'll need to look over my library and make sure nothing strange is going on. I'm curious if sites like Qobuz will suddenly replace some of their existing files with higher-bit copies if they already had them and just had no way to encode them as FLAC.

It is extremely hard to justify 32-bit audio from a technical standpoint, since it requires that every component in your audio chain has better than 144 dB dynamic range. In practice, just about none of the analog components in your audio chain will have that kind of dynamic range, and any analog components in the recording chain are unlikely to have that range either. The kind of equipment I'd expect to see in order…

Even if you did have a recording setup like that I'd expect it to work better with float samples.
Post reply on HN