Hi all,
I just noticed this:
https://sourceforge.net/p/flac/feature-requests/91/
a request for support of 32 bit audio data. The request has been around
since 2008.
Had two inial impressions:
* Would adding this break brackwards compatibility too badly? Obviously
decoding of 32 bit encoded data would not work with older versions of
flac.
* This is nuts. 24 bits has a dynamic range of ~140dB which is roughly
the difference between a quiet whisper in a quiet room, to the sound
of a jet engine at 10 meters. Surely that is enough?
Thoughts?
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
Op 26-09-15 om 09:22 schreef Erik de Castro Lopo:> Had two inial impressions: > > * Would adding this break brackwards compatibility too badly? Obviously > decoding of 32 bit encoded data would not work with older versions of > flac.Probably not. I know that Josh at some point added a second residual coding method (rice2) to support 24-bit, but that only broke backward compatibility for 24-bit files back then.> * This is nuts. 24 bits has a dynamic range of ~140dB which is roughly > the difference between a quiet whisper in a quiet room, to the sound > of a jet engine at 10 meters. Surely that is enough?Yes, this is nuts. First, 24-bit is already overkill, as there is no hardware (ADC or DAC) that can handle more than 120dB of dynamic range anyway. There probably never will be hardware that can handle the full 24 bits, because at this point that hardware is already pushing the boundary of thermal noise. Second, most 32-bit material is 32-bit float, and that is something the FLAC format can't handle. I really wonder why anyone would have 32-bit integer material anyway.
On 26 September 2015 at 09:22, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote:> https://sourceforge.net/p/flac/feature-requests/91/ > [...] > Thoughts?The last comment on the page makes a valid point. If companies start to sell 32bit tracks these days, flac may as well start to support it. Personally, I'd say the discussion whether music *needs* 32bit resolution is a different topic :-) Best regards Riggs
On Sat, Sep 26, 2015 at 10:36 AM, Martijn van Beurden <mvanb1 at gmail.com> wrote:> > * This is nuts. 24 bits has a dynamic range of ~140dB which is roughly > > the difference between a quiet whisper in a quiet room, to the sound > > of a jet engine at 10 meters. Surely that is enough? > > Yes, this is nuts. First, 24-bit is already overkill, as there > is no hardware (ADC or DAC) that can handle more than 120dB of > dynamic range anyway. There probably never will be hardware that > can handle the full 24 bits, because at this point that hardware > is already pushing the boundary of thermal noise. Second, most > 32-bit material is 32-bit float, and that is something the FLAC > format can't handle. I really wonder why anyone would have > 32-bit integer material anyway.I second that... -- Pierre-Yves http://www.mjuware.com, home of FlacNetLib -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20150926/bb457f00/attachment.htm
At 10:38 26.09.2015, you wrote:>On 26 September 2015 at 09:22, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > >> https://sourceforge.net/p/flac/feature-requests/91/ >> [...] >> Thoughts? > >The last comment on the page makes a valid point. If companies start >to sell 32bit tracks these days, flac may as well start to support it. >Personally, I'd say the discussion whether music *needs* 32bit >resolution is a different topic :-)I completely agree with this. Flac should support available formats. If 32bit or even 64bit is necessary is a discussion that should not take place here IMHO. Best regards Olav Sunde>Best regards >Riggs >_______________________________________________ >flac-dev mailing list >flac-dev at xiph.org >http://lists.xiph.org/mailman/listinfo/flac-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20150926/8c2be89f/attachment.htm
On Sat, 26 Sep 2015 17:22:40 +1000 Erik de Castro Lopo <mle+la at mega-nerd.com> wrote:> * Would adding this break brackwards compatibility too badly? > Obviously decoding of 32 bit encoded data would not work with older > versions of flac. > * This is nuts. 24 bits has a dynamic range of ~140dB which is roughly > the difference between a quiet whisper in a quiet room, to the sound > of a jet engine at 10 meters. Surely that is enough?On the narrow question of legitimate requirements for very high resolution data, Audacity uses 32-bit float so that it's essentially impossible to either clip or loose into noise any intermediate signal, no matter how strong or weak. As every intermediate goes to disk (for undo, save and so on), we use uncompressed .AU 32-bit float format files at the moment. It would be nice to be able to reduce the size of projects (for archive and sharing) by lossless compressing them, but at the moment we don't have many sensible options. Now this probably doesn't need full floating point support, something that normalised short blocks and stored the normalisation coefficients to restore them at decode would be adequate. Richard
Martin,> Yes, this is nuts. First, 24-bit is already overkill, as there is no > hardware (ADC or DAC) that can handle more than 120dB of dynamic range > anyway. There probably never will be hardware that can handle the full > 24 bits, because at this point that hardware is already pushing the > boundary of thermal noise.Very low impedance hardware might have 144 dB S/N ratio (full 24 bit) in some not so far future. A 10 ohm resistance has an audio band RMS noise voltage of about 57 nV, this means that with a 1 V signal you have a S/N ratio of 145 dB, so thermal noise isn't the bottlenecck. A good opamp may have about 100 nV at low gain. The electronic components may improve in the future so that they can attain this S/N even at higher gains. However, what cannot likely improve in the near future is the dynamic range of our ear! In any case, the applications of lossless coding not necessarily reduce to what can be converted or heard. For instance, collaborative internet audio processing may require sharing massive intermediate results at full 32-bit or even higher precision under some protocol to be developed (if it hasn't been developed yet)> Second, most 32-bit material is 32-bit float, and that is something > the FLAC format can't handle. I really wonder why anyone would have > 32-bit integer material anyway.Theoretically any 32-bit float can be converted to a 150 bit integer (roughly 127 + 23), so at least in theory the FLAC method could be applied. May be it wouldn't render any compression at all since we would be converting a sparse numeric format into a full 150 bit one, since in 32 bit float most of the 150 bit numbers cannot be represented. But perhaps an adaptive version could do a decent job. The idea is that if one could use an intermediate format with more than 23 bit fraction precision, the exponent wouldn't change so often. Regards, Federico -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20150926/6ea44363/attachment.htm
On 9/26/2015 9:22 AM, Erik de Castro Lopo wrote:> Hi all, > > I just noticed this: > > https://sourceforge.net/p/flac/feature-requests/91/ > > a request for support of 32 bit audio data. The request has been around > since 2008. > > Had two inial impressions: > > * Would adding this break brackwards compatibility too badly? Obviously > decoding of 32 bit encoded data would not work with older versions of > flac.16bit/24 bit files encoded with the "new" encoder would be playable in old decoders, right? So backwards compatibility is not really broken, only for new 32 bit files, which will hopefully be rare. How about implementing 32/64 bit support, but also creating a fork of the project (FLAC32/64/etc.) at the same time? 32 bit files will get a separate header/file extension, and will decode only with either the "new" master branch decoder, or the "new" 32 bit decoder. Therefore it will be crystal clear that this is a new "form" of FLAC, which is not supported by the mainline decoder (at least not the old one). The 32 bit decoder can be phased out later down the line when adoption of the "new" mainline decoder has become ubiquitous. I know this is far from ideal, but IMHO it's better than dealing with cases where projects/products claim to have "FLAC support", but the user finds out he/she is unable to play his 32 bit "FLAC" files. Like I said, usage will hopefully be rare, especially as a delivery format. On the other hand, nobody can expect FLAC to support everything that's possible. I think it's perfectly fine to "stick" to 24 bits and lower.> * This is nuts. 24 bits has a dynamic range of ~140dB which is roughly > the difference between a quiet whisper in a quiet room, to the sound > of a jet engine at 10 meters. Surely that is enough?Professionals who want to use FLAC for archival might want to store the data in the format they use in their DAW (though, arguably, if it's an audio recording the data was not recorded with anything close to 32 bit, not even 24 or 20 bit), so I see a "need" for that format. In reality the data they store in the lower bits is pure noise. Ideally they set the lower 12 bits to zero anyway, to make use of FLACs compression efficiency (like, for example, lossyFLAC does), but I rather suspect this results in badly compressible FLAC files, due to the fact that they're mostly compressing noise.> > Thoughts? > > Cheers, > ErikChristoph
Erik de Castro Lopo wrote:> a request for support of 32 bit audio data. The request has been around > since 2008. > > Thoughts?As far as I understand: FLAC tries to predict an input signal, calculates the difference between real and predicted signal (=residual). Currently libFLAC stores residual signal as 32-bit signed int. And there are the following comments in stream_encoder.c: 1) bps + FLAC__MAX_EXTRA_RESIDUAL_BPS is the maximum assumed size of the average residual magnitude 2) abs(INT_MIN) is undefined, but if the residual is INT_MIN we have bigger problems So it seems that current libFLAC algorithms require 36 bits for residual signal if an input signal is 32 bit. Of course, it's possible to allow only verbatim and constant subframes for signals with bps > 28(?). Not sure that it's a good solution.
Op 01-10-15 om 18:14 schreef lvqcl:> Currently libFLAC stores residual signal as 32-bit signed int. And there > are the following comments in stream_encoder.c:The residual is stored as a Golomb/Rice code. As far as I know, that is not limited to 32-bit in the format itself, only in the implementation. However, there are two residual coding methods now: rice and rice2. rice2 was added when it turned out rice (with a 4 bit rice parameter) wasn't able to cope with the larger residuals that 24-bit material. It looks like a 5-bit rice parameter is enough for 32-bit material as well (highest divisor is 2^30, whereas a 4-bit parameter is limited to 2^14), but maybe a rice partition with 6 bits has to be added, who knows? Anyway, I don't think the format is in any way unsupportive of 32-bit int material, it's just the current implementation of the codec.