[HN Gopher] FLAC 1.4.0 released - added support for 32-bit audio
___________________________________________________________________
FLAC 1.4.0 released - added support for 32-bit audio
Author : thrdbndndn
Score : 93 points
Date : 2022-09-14 19:02 UTC (3 hours ago)
(HTM) web link (xiph.org)
(TXT) w3m dump (xiph.org)
| ZoomZoomZoom wrote:
| Finally! I can ditch away 32b special casing in my project
| cleanup and backup automation! As much as I love WavPack[1] (it's
| great and has 32 bit integer/fp support since forever), Flac is
| much faster and probably more future-proof. Thanks a lot everyone
| at XIPH, your work really makes a difference.
|
| Edit: oops, I can't. No fp support yet.
|
| 1. https://www.wavpack.com/
| pavon wrote:
| Nice! I (ab)use FLAC to store waveform data that isn't audio, but
| compresses better using audio codecs than with general purpose
| compression algorithms. This will let me remove some hacks to
| compress 32-bit data as multiple channels.
| colejohnson66 wrote:
| What data are you compressing?
| nimish wrote:
| I've used it to record oscilloscope captures. Especially
| useful since audio cards are cheap high res adc's.
| mywittyname wrote:
| I'm amazed that consumer-grade audio cards are still
| available and cheap, to be honest. I can't recall having
| seen one in years, then again, I haven't had a reason to
| look for them in years either.
| zymhan wrote:
| Creative is still marketing them to gamers, amazingly.
|
| Can't say I haven't been tempted.
| ska wrote:
| Pretty common for any hobbiest who wants to record things
| too.
| pavon wrote:
| A variety of sensor data. Nothing coming straight off an ADC
| needs 32-bits, but I do have need for it in various cases.
|
| * The sensor system wants to do unit conversion for me. This
| data doesn't really have 32-bits of dynamic range, but for
| archival purposes I'd like to store the exact bits without
| adding another quantization step - that can happen later.
|
| * The sensor system combines multiple ADC channels HDR style.
| I'd rather get the raw readings and do the combining myself,
| but don't always have access to it.
|
| * Some more advanced preprocessed results, akin to a GPS
| solution. Linear predictor based algorithms are perfect here
| since the full possible set of values does have high dynamic
| range, but the upper bits change very slowly.
| messe wrote:
| I'm kinda curious. What kind of sensors? (If you're able to
| divulge it that is; which given how you've phrased it, I
| wouldn't be surprised if you're under NDA or similar)
| LeoPanthera wrote:
| 32-bit integer, not float.
|
| I didn't even know 32-bit integer was a thing. Float is far more
| common. (For audio.)
| Night_Thastus wrote:
| 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.
| klodolph wrote:
| 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 to record that
| kind of range is where you'd have something like multiple
| microphones, and switch back and forth between them based on
| the level of the material you're recording (which would have to
| be something like actual gunfire or explosions).
|
| I don't know what kind of equipment you'd need to reproduce
| this dynamic range, but I don't think it's audio equipment.
|
| My guess is that the main real application of this is going to
| be compression of non-audio data that happens to compress well
| with FLAC.
| radiowave wrote:
| In audio production, the relevance of 32 bit audio is that
| it's using the same 32 bit _float_ representation of the
| audio that most of the signal processing stages are also
| using. In contrast, when people talk about 16 or 24 bit
| audio, they are customarily referring to an _integer_
| representation.
|
| In principle, every time you convert from the 32 bit float
| back to 24 bit integer, there's an opportunity for a careless
| human to screw up the scaling, and throw away some of the
| available integer range. Rinse and repeat until you have an
| audible problem.
|
| So this forms the basis for an argument in favour of keeping
| the audio in a float representation for as much of the
| production process as can reasonably be achieved.
|
| I don't see any benefit in 32 bit representation for delivery
| of the finished content, but I suppose that if, as part of
| the production process, you're transferring the audio online
| between different sites/people/whatever, then having lossless
| compression that works without having to convert back to
| integer might be useful.
|
| EDIT: Just read the thing more carefully, and realised that
| it's specifically talking about 32 bit int, _NOT_ float. So
| right now, I can 't see much practical use for this.
| simcop2387 wrote:
| 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.
| klodolph wrote:
| > 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.
|
| It's not _that hard_ to beat 16-bit, which is 96 dB, using
| easy-to-find, off-the-shelf equipment. One example scenario
| is that you are recording something but you don 't have a
| precise idea of how loud it will be ahead of time, so you
| record at low levels and rely on 24-bit capture to give you
| headroom above and noise floor below. Trying to capture at
| 16-bit can, in practice, be annoying and difficult because
| it is more likely that you will ruin takes by setting the
| gain wrong.
| hunter2_ wrote:
| The 55% compression ratio (or whatever the case may be)
| seems much more useful at the end (where it nearly doubles
| how long a consumer can listen before swapping media) then
| along the way (where it nearly doubles how much raw
| material a studio can capture before swapping media).
| Dylan16807 wrote:
| Even if you did have a recording setup like that I'd expect
| it to work better with float samples.
| jrajav wrote:
| You're absolutely right insofar as you're speaking about
| static audio that's already been produced and finished -
| there is almost no point in storing anything above 24-bit
| integer as far as dynamic range even for archival purposes.
|
| However, there is a legitimate purpose behind having higher
| dynamic range for production purposes and sample sources.
| There are some recording sources that can actually produce
| 32-bit audio. Plus, you might want to do some processing on
| the sound that would end up affecting the dynamic range, or
| otherwise benefit from the increased resolution. One example
| is nonlinear processing that generates new musical
| information from the original signal - you can of course just
| reduce the gain after processing, but you are then
| sacrificing some of the resolution of the new combined
| signal, which itself could otherwise be used by further
| downstream processes. This all happens post-recording, but
| can still be musically important before getting to the
| finished product.
|
| This is why DAWs work in 32-bit or 64-bit processing
| internally, and why many high-quality sample libraries will
| come in 32-bit, especially smaller one-shots. I often convert
| samples to .flac for space reasons, and have to either skip
| 32-bit .wavs or downsample them to 24.
| duped wrote:
| DAWs use floating point numbers, which are not applicable
| to this discussion. They also waste about half the bits
| most of the time.
| klodolph wrote:
| > However, there is a legitimate purpose behind having
| higher dynamic range for production purposes and sample
| sources.
|
| This is the justification for 24-bit audio... is there a
| reason why 24 bits is not enough here?
|
| If you're capturing audio sources directly, you'd use
| something like a 24-bit ADC, which you can find easily
| enough. The "raw" output of the ADC is 24 bits.
|
| If you're doing intermediate processing in your DAW, then
| the DAW is using single-precision floats (or possibly
| double), which cannot be losslessly converted either to 32
| bit or 24 bit integers, so how would you choose the right
| format to store? It seems to me that you'd either store the
| original floating-point data, or you'd perform some kind of
| lossy conversion to a high-quality archival format... but
| if you do that, isn't 24 bits good enough? You're
| quantizing either way, and at 24 bits, you can have plenty
| of headroom and noise floor at the same time. Loads, even.
| jrajav wrote:
| There are two justifications, one, for recording - 24-bit
| is the standard in the studio yes (and more than you need
| for that context indeed), but 32-bit is more and more the
| standard for field recordings where the hardware is
| capable of it and it provides genuine utility, where you
| often have extremely soft and subtle sounds captured that
| you want to increase in gain to a more useful level.
|
| Also, once inside the digital world, there are many
| processes you can perform that add new musical
| information to the original sound that might be higher in
| gain but that you want to preserve for downstream
| processing until you're ready to actually "print" and
| quantize the final product, at which point, yes, 24-bit
| will be more than enough.
| duped wrote:
| A microphone, preamp, and ADC that have > 144dB of
| dynamic range are extraordinarily rare outside of lab
| equipment.
|
| Physically, you are talking about signals measured in the
| tens of nano-volts (or nano-amps, depending on the
| mechanism of the microphone).
| jrajav wrote:
| The latest Zoom field recorders support 32-bit float
| recording and achieve a wider dynamic range than that
| (upwards of 210db) by having a circuit with two different
| ADCs.
|
| Also, it's less about the absolute resolution, and more
| about the ability to boost the gain, often by a lot,
| while still having a wide and useful dynamic range after
| the fact.
| dsr_ wrote:
| Note that 144dB range is what you get from 24 bits per
| sample. 32 bits gets you another 48dB more.
|
| Some of your ADC/DAC chain can reasonably claim 125dB range.
| Some amplifiers can claim 17 or even 18 bits above their
| noise floor - 108dB.
|
| No full-spectrum microphones, headphones or speakers can
| reasonably claim 125dB without distortion, but if they did
| you would still want to limit your exposure to "never". Long-
| term damage begins with long-term exposure under 96dB.
| klodolph wrote:
| People will use microphones to record audio like gunshots
| and explosions for use as sound effects. The humble snare
| drum will produce loads of dBs too, and is usually close-
| miked. You then take the same microphone and use it to
| record something much quieter. You end up with microphones
| that definitely do reasonably claim >125 dB range. The
| TLM102 claims something like 130 dB. How much you care
| about distortion will depend on the situation.
|
| My thought is that it would be very hard to get that 130 dB
| range all the way from an audio source to your ADC, and it
| would be very hard to get it back out all the way to
| speakers again.
| retcore wrote:
| >The TLM102 claims something like 130 dB. How much you
| care about distortion will depend on the situation.
|
| Neumann makes no such claims. They do claim max spl of
| 144 dB. But the TLM and is 10 dB less and this is prior
| to ADC of variable ability. Distortion isn't a ceteris
| paribus value for signal to noise calculations.
| retcore wrote:
| This unfortunately discontinued mic could comfortably
| exceed your claimed limits:
|
| https://en-de.neumann.com/d-01
|
| 156 dB max spl 86 dB snr 130 dB dynamic range
|
| Neumann patented a dual ADC preamp to make this possible.
| dsr_ wrote:
| 86dB signal-to-noise.
| retcore wrote:
| As noted in my third para :~)
|
| Additionally from the product page:
|
| "Unprecedented fidelity and detail, 130 dB dynamic range"
|
| I've just realized that the product page I linked is
| extremely unusual for stating a dynamic range value.
|
| However this makes sense if you read the papers covering
| Neumann's dual ADC and pre design of which they were
| justifiably proud. System D was a mid nineties
| introduction.
| babypuncher wrote:
| I don't know that 32-bit audio is exactly common.
|
| As far as human hearing goes, 24-bit is already overkill. Even
| 16-bit should be an imperceptible downgrade for anything with a
| naturally low dynamic range (i.e. most music).
| sprash wrote:
| Sadly still no support for variable blocksize.
| nayuki wrote:
| 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
| sprash wrote:
| Sometimes encoding time doesn't matter. Archiving is done
| once in a lifetime. I encode everything with "--lax -8Vepl32"
| which takes ages but since it runs as a low priority
| background task I don't care. Also, you can use heuristics to
| choose the right blocksize instead of brute-forcing it. If
| the algorithm is clever enough you might achieve slightly
| better results at almost zero costs.
| aaaaaaaaaaab wrote:
| 32bit _float_ would be more interesting for music production.
| theandrewbailey wrote:
| > Compression of preset -3 through -8 was slightly improved at
| the cost of a small decrease in encoding speed by increasing the
| precision with which autocorrelation was calculated (Martijn van
| Beurden)
|
| Would love to see some benchmarks on this. Since FLAC hit 1.0
| over 20 years ago, CPU speed has increased by ~100x, so a small
| hit on encode speed for better compression mostly doesn't matter.
| Then again, storage space has increased by the same amount, too.
| mmozeiko wrote:
| Btw there are alternative flac encoders, like FLACCL using GPU:
| http://cue.tools/wiki/FLACCL It compresses much faster than
| software libflac and gives smaller output files.
| michaelwww wrote:
| 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.
| atoav wrote:
| 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
| michaelwww wrote:
| > I will choose 32 bits over 24 any day
|
| why?
| squeaky-clean wrote:
| It's very unlikely your audio interface can actually record
| at 32 bit resolution.
|
| https://www.mojo-audio.com/blog/the-24bit-delusion/
|
| 32bit or more makes sense for dsp and summing, and non-
| musical data storage. But your I/O is most likely not giving
| 32 bits
| jrajav wrote:
| 32-bit is common in field recordings, like with a Zoom (and
| there's reason to believe they can legitimately take
| advantage of it).
| ZoomZoomZoom wrote:
| > I will choose 32 bits over 24 any day when recording.
|
| There's probably no point since your audio interface doesn't
| produce 32 bit audio anyway.
|
| For _transient_ formats it 's another story: if a bit of
| audio gets re-printed multiple times with some processing
| between renders, then it's beneficial to store it in a DAW-
| native format (32/64 fp) to avoid quantization or multiple
| additions of dither noise. For recording you just waste
| space.
|
| > Having something to store those files with a little bit of
| lossless compression is a welcome addition
|
| You'd probably want to store 32/64 bit _floating point_ , and
| WavPack works really well. On comparable formats it achieves
| ratios really on par with Flac.
| colejohnson66 wrote:
| 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, music artists/producers can't afford to lose
| information when they "bounce" a track. FLAC solves that.
| "People" don't need lossless, but for those that do, it's
| great.
| michaelwww wrote:
| 16 bit is not enough?
| [deleted]
| squeaky-clean wrote:
| (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.
| ZoomZoomZoom wrote:
| > You can't find 32 bit PCM music anywhere
|
| The real reason is that there's no 32-bit floating point
| digital audio converters, so distributing the audio in a
| format which needs to be quantized to be played anyway has
| no purpose (outside of deceptive marketing, of course).
|
| Even integer 32 bit makes no sense for a final format - the
| available noise floor is just beyond reasonable, 24 bit is
| more than enough. In practice, 16 bit is too.
| jrajav wrote:
| We don't always record and export at 24-bit, though that's
| always the end result from mastering (if not 16-bit). In
| some contexts, 32-bit files are common for samples and for
| transferring in-progress artifacts like mixed tracks that
| are ready for mastering.
| pwiecz wrote:
| "People" don't need just lossless, they need The Beatles to
| release all of their pre-master tracks to be released in
| lossless format, so they of them can create their own
| remastered versions of a the tracks.
| jlouis wrote:
| I don't think it's for storing music.
| matheusmoreira wrote:
| How do you know no one needs it for anything? How do you know
| no one will _ever_ need it in the future? It 's not possible to
| know that. All we can do is capture the real world data with as
| much quality and precision as possible.
| adgjlsfhk1 wrote:
| There are definitely scientific uses that might want to (ab)use
| FLAC to store sound-like data that would benefit from 32 bit.
| mmastrac wrote:
| There's a real use case for storing original tracks and masters
| in 32-bit and down-sampling for consumer use.
| _joel wrote:
| Nyquist Shannon theorem, sure. There are situations where you'd
| use 32bit audio but not for mastered music you'd listen to at
| home really. Although people still won't believe you, hence the
| market for thousand dollar cables and other snake oil.
| Night_Thastus wrote:
| From my understanding, doesn't Nyquist-Shannon assume you
| take infinite steps to refine the discrete steps into the
| final waveform?
|
| Since real-world DACs don't have infinite taps, either
| increasing the number of samples per second in the original
| audio or the number of steps done by the filter will improve
| how close it gets to the original waveform.
|
| Would that apply to the number of bits used to represent the
| level as well? I thought that was mainly useful to give some
| additional headroom when editing?
|
| (Obviously there's diminishing returns either way)
| [deleted]
| colejohnson66 wrote:
| 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 gives you less noise when
| reproducing it. For CD audio, 16 bits was chosen to give an
| acceptable SNR of 96 dB.
|
| Monty Montgomery (of xipf.org) has a nice YouTube video
| related to this:
| https://www.youtube.com/watch?v=cIQ9IXSUzuM
| Night_Thastus wrote:
| 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 the
| original.
| colejohnson66 wrote:
| 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.
| jrmcauliffe wrote:
| A final low pass filter (tuned to remove anything above
| half the sample rate) allows the accurate reconstruction
| of the original analogue waveform from the sampled
| digital data. ( The vertical 'stair step' of sampled data
| is very high frequency information which gets removed,
| 'bending' the output back into it's original shape). The
| video linked above is well worth a watch.
| tombert wrote:
| While I doubt that human ears need 4 billion discrete levels, I
| think it's important for archival purposes.
| klodolph wrote:
| 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.
| tombert wrote:
| Fair enough! That's what I get for commenting on something
| I'm not as familiar enough with as I should be.
| thrdbndndn wrote:
| I personally can't care less about 32-bit, but unfortunately a
| few digital music stores I buy from use this format (delivered in
| WAV). And I don't want to downscale them simply for archival
| reasons.
|
| Now I can at least re-compress them losslessly in FLAC.
| (previously I have to use Wavpack, which isn't bad but I'd prefer
| to have a single format in my media library.)
| mixmastamyk wrote:
| ffmpeg can downsample audio to a more manageable rate. I use it
| to reduce hi-res flacs to 16-48, which cuts it down to a ~third
| of its original size and is supported in my car stereo and
| everywhere else. Can't tell any difference on playback.
| thrdbndndn wrote:
| Audiophiles usually recommend using some better algorithms
| such as SSRC resampler (foobar2000 have it as plugin handily)
| than whatever FFMPEG provides.
|
| I can't say I personally can tell the difference, but based
| on my (limited) knowledge of DSP, artifact-free resampling
| definitely isn't a straightforward thing.
| aaaaaaaaaaab wrote:
| Boomkat?
| thrdbndndn wrote:
| I've heard of that too, but in my case it's batch of Japanese
| distributors like e-onkyo [1] or Ototoy [2].
|
| [1] https://www.e-onkyo.com/music/ [2] https://ototoy.jp/top/
| foxhill wrote:
| the noise floor at 16 bit is already low. 24 bit, much more
| common (and imo needless for consumers), is 256x lower than
| that.
|
| there's no part of the analogue capture process that can
| utilise such a low noise floor (as far as i'm aware): is there
| anything of value worth preserving there?
| thrdbndndn wrote:
| >is there anything of value worth preserving there?
|
| Not really in term of audio itself, just easier to do bitwise
| comparison with the original file, in term of file integrity.
___________________________________________________________________
(page generated 2022-09-14 23:01 UTC)