Bouncing in 32bit WAV

[Billy+]

if you then take the file and convert to low quality MP3 the bit depth is reduced even further

So exporting a 0db file from Reason at 24 bit and slamming it into a low quality MP3 could potentially make the audio clip..

MP3s (and other lossy formats) have a bit rate, not a bit depth.

It is true that encoding PCM audio into an MP3 and then decoding for playback it can produce values that clip, but it's not because of the change in bit depth.

Going back to MP3s not having a bit depth. They use a process called a discrete cosine transform. Basically they spit an audio signal into a number of signals represented by cosine functions with different amplitudes. When those functions are added back together you get (approximately) the original signal. The more (and higher frequency) cosine waves you use, the closer you can represent the original signal. Just how many you can fit into a unit of time is the rate of the MP3. The cosine function can be computed to infinite resolution, but in practice it's usually only done to 24-bits (use to be 16 in the past). The amplitude of each cosine individually won't be more than the 24-bit integer can hold, but when you sum all the different frequencies together it's possible that in some places the final value will clip.

So if you know you're audio is going to be encoded into a lossy format (e.g. its doing to be streamed), it's probably best to leave 1 dB of headroom. So that the reconstructed signal won't add up to anything greater than 0 dBfs.

Ah got yah

So it's not the compression that causes the problem but the decompression

You should come here more often especially during these types of conversations I've actually learned two new things today and both came from you.

Thanks

[ScuzzyEye]

Wait...floating point is about the lowest volume but many want 32 bit floating point bounce to help with stopping clipping and clipping is going over 0dB.

Yes, and no. Yes, audio stored in a floating point format can go over 0 dBfs without clipping. No, you can't make your mixes louder with this, because it'll get clipped on playback. What it does allow is for you to turn it down later in the processing chain. So if you have a kick sample that you need to turn up to get the sustain to boom just right, but that makes the attack go above 0 dBfs, it won't clip the channel that it's on. You can then catch that "over" somewhere else in the mixing process. Or if you're exporting your mix in a DAW that supports 32-bit float, someone else can pick up from there, and handle that over, so the final product can be played back.

[Goriila Texas]

ahhhaaa! That makes sense!!

Wait...floating point is about the lowest volume but many want 32 bit floating point bounce to help with stopping clipping and clipping is going over 0dB.

Yes, and no. Yes, audio stored in a floating point format can go over 0 dBfs without clipping. No, you can't make your mixes louder with this, because it'll get clipped on playback. What it does allow is for you to turn it down later in the processing chain. So if you have a kick sample that you need to turn up to get the sustain to boom just right, but that makes the attack go above 0 dBfs, it won't clip the channel that it's on. You can then catch that "over" somewhere else in the mixing process. Or if you're exporting your mix in a DAW that supports 32-bit float, someone else can pick up from there, and handle that over, so the final product can be played back.

[ScuzzyEye]

So it's not the compression that causes the problem but the decompression

You should come here more often especially during these types of conversations I've actually learned two new things today and both came from you.

Thanks

Yep. In fact it's possible to change the playback volume of an MP3 losslessly by changing the cosine coefficients. So if you do have one that clips on playback, you can use something like MP3Gain (this was the original program I knew about, but it appears that lots of people have copied the idea now).

And thanks. I'm going to try to be more active here this year. I used to be around a lot, but have been off playing with other DAWs (that support 32-bit export ) for a couple years.

[Goriila Texas]

I agree we need you here more . Do you know of any other software with MP3 gain?

So it's not the compression that causes the problem but the decompression

You should come here more often especially during these types of conversations I've actually learned two new things today and both came from you.

Thanks

Yep. In fact it's possible to change the playback volume of an MP3 losslessly by changing the cosine coefficients. So if you do have one that clips on playback, you can use something like MP3Gain (this was the original program I knew about, but it appears that lots of people have copied the idea now).

And thanks. I'm going to try to be more active here this year. I used to be around a lot, but have been off playing with other DAWs (that support 32-bit export ) for a couple years.

[ScuzzyEye]

I agree we need you here more . Do you know of any other software with MP3 gain?

When I was searching for this program again, I saw a bunch of sites listing that feature. But looking closer it appears they're just webservers running mp3gain in the background.

If you're wanting something easier to use, I did find a webapp that's ported the mp3gain idea to run in JavaScript. It doesn't submit the file to a server and process it there, it's a page that does the processing on your computer.

https://mp3gain.flowsoft7.com/

That's similar to the way https://www.loudnesspenalty.com/ works. But this just computes the Integrated LUFS of a file, and tells you how much a streaming service will turn it down.

[Goriila Texas]

Thanks

I agree we need you here more . Do you know of any other software with MP3 gain?

When I was searching for this program again, I saw a bunch of sites listing that feature. But looking closer it appears they're just webservers running mp3gain in the background.

If you're wanting something easier to use, I did find a webapp that's ported the mp3gain idea to run in JavaScript. It doesn't submit the file to a server and process it there, it's a page that does the processing on your computer.

https://mp3gain.flowsoft7.com/

That's similar to the way https://www.loudnesspenalty.com/ works. But this just computes the Integrated LUFS of a file, and tells you how much a streaming service will turn it down.

[integerpoet]

FWIW, because I have absolutely no life, I found this fascinating.

https://www.sounddevices.com/32-bit-flo ... explained/

One fun part: "…the greatest difference in sound pressure on Earth can be about 210 dB, from anechoic chamber to massive shockwave…" So 24-bit integers are already doing a pretty good job of capturing many of the sounds leading up to the apocalypse.

The authors obviously want to sell you a 32-bit float audio device. This link is not an attempt to contradict any prior posts from the wonderful very smart contributors to this thread about the usefulness (or lack thereof) of 32-bit float samples.

[ScuzzyEye]

The authors obviously want to sell you a 32-bit float audio device. This link is not an attempt to contradict any prior posts from the wonderful very smart contributors to this thread about the usefulness (or lack thereof) of 32-bit float samples.

98% of what they say there is good information. Though I'd split hairs on how the "dynamic range" of floating point audio is described. If you notice, I tried to use terms like quantization steps (or levels), and signal to noise ratio. There are two types of uniquely digital distortion. Frequency aliasing, when you attempt to encode signals more than double the sampling rate, and quantization noise that comes from rounding the sampled signal level to the nearest available "step". When doing floating point math, you can choose any value above 0.0 and then a matching negative below 0.0, and you're guaranteed to have 16,777,216 (2^24) steps between them. So you can get at least as good a signal to noise ratio as 24-bit integer audio. But when you start doing things like looking at the smallest possible value that can be stored in a float, and then the largest possible value. You're not understanding how floating point math actually works. You can't subtract the smallest possible value from the largest possible value. They are on different scales, and use different step sizes between them. The difference between the largest possible value, and the second largest possible value is so many times bigger than the smallest possible value. So yes, floats can store vary large numbers and very small numbers, but you can't work with both at the same time. So keeping audio in the -1.0 to +1.0 range is perfectly fine, but going to +2, +4, +8, the steps get larger. It may be that mixing a very quiet sound into a channel that's +24 dBfs, will have no effect at all (in the most extreme cases unlikely to actually occur).

As for their hardware, I've also dabbled in hardware design. So I was curious how they're getting 32-bit floating point from an ADC, because I don't know of any such part. One might exist, but I don't think that's what they're doing. I think they're taking fixed point data from an ADC (or a couple different ADCs each behind a different gain stage) and doing some DSP processing to it to make the 32-bit floating point output. They have a video (

) talking about how to use their recorder as an audio interface. There are a few telling lines in their instructions. One, it only works on the Mac (I mentioned in another thread that Core Audio can accept 32-bit floats from audio programs, and does its mixing as floats). So it is possible to feed floating point audio into macOS's mixer. But at 1 minute into the video they're showing a graph of 16-, 24-, and 32-bit dynamic ranges. With -144 dBfs clearly labeled for 24-bit audio, as they say, "...preservers the full 142 dB dynamic range..." Hmm, 142 is less than 144. So there's no reason to use 32-bit floats. The could store the full dynamic range captured in 24-bits.

[littlejam]

hello,

learning a lot of @$#@%!!! cool knowledge from ScuzzyEye and others

thank you,

j

[integerpoet]

When doing floating point math, you can choose any value above 0.0 and then a matching negative below 0.0, and you're guaranteed to have 16,777,216 (2^24) steps between them. So you can get at least as good a signal to noise ratio as 24-bit integer audio. But when you start doing things like looking at the smallest possible value that can be stored in a float, and then the largest possible value. You're not understanding how floating point math actually works. You can't subtract the smallest possible value from the largest possible value. They are on different scales, and use different step sizes between them. The difference between the largest possible value, and the second largest possible value is so many times bigger than the smallest possible value. So yes, floats can store vary large numbers and very small numbers, but you can't work with both at the same time. So keeping audio in the -1.0 to +1.0 range is perfectly fine, but going to +2, +4, +8, the steps get larger. It may be that mixing a very quiet sound into a channel that's +24 dBfs, will have no effect at all (in the most extreme cases unlikely to actually occur).

Thanks for that. I suspected as much after recently re-encountering an article explaining how and why floats can't represent 0.1.

(The rest of you: You heard me. Look it up.)

So a floating sample can't clip, but that doesn't mean there's no downside of letting amplitude approach "nuclear explosion".

[ScuzzyEye]

Thanks for that. I suspected as much after recently re-encountering an article explaining how and why floats can't represent 0.1.

(The rest of you: You heard me. Look it up.)

So a floating sample can't clip, but that doesn't mean there's no downside of letting amplitude approach "nuclear explosion".

Correct, on both statements.

If you want to play with floating point numbers, and see how the bits are actually set in the CPU, here's a site I have bookmarked and have used for reference at many times over the years.

https://www.h-schmidt.net/FloatConverter/IEEE754.html

And go ahead and type 0.1 in the "You entered" field, and press enter to see what value will actually be stored. The +1 and -1 buttons will count up "step" by step, so you can also see the minimum incremental increase for what ever scale the float is currently storing.

[selig]

Wait...floating point is about the lowest volume but many want 32 bit floating point bounce to help with stopping clipping and clipping is going over 0dB.

Yes, and no. Yes, audio stored in a floating point format can go over 0 dBfs without clipping. No, you can't make your mixes louder with this, because it'll get clipped on playback. What it does allow is for you to turn it down later in the processing chain. So if you have a kick sample that you need to turn up to get the sustain to boom just right, but that makes the attack go above 0 dBfs, it won't clip the channel that it's on. You can then catch that "over" somewhere else in the mixing process. Or if you're exporting your mix in a DAW that supports 32-bit float, someone else can pick up from there, and handle that over, so the final product can be played back.

Or you can just turn down the master so it doesn’t clip…

[selig]

And thanks. I'm going to try to be more active here this year. I used to be around a lot, but have been off playing with other DAWs (that support 32-bit export ) for a couple years.

Good to hear, your knowledge is much appreciated!