Bouncing in 32bit WAV

[friday]

Just to be absolutely sure, Reason is not able to Bounce in 32bit?

Not that I think that this will sonically be a real issue, but the mastering studio (reputable one) recommended the following:
.
.

Screenshot 2022-01-07 132525.png (20.58 KiB) Viewed 2033 times

[orthodox]

Just to be absolutely sure, Reason is not able to Bounce in 32bit?

No it is not. And that is a real issue for me, because I have to keep the channel peaks below 0 dBFS so they won't clip on bounce. There is a Normalize option of course, but it breaks the volume balance between stems.

[ScuzzyEye]

You're correct. Reason cannot export 32-bit floating point wave files. I find it to be a major omission.

Though I don't 100% agree with their explanation. 32-bit floating point has 16,777,216 equally spaced steps between -1.0 and +1.0. 2^24 equals 16,777,216. So 24-bit integer data and 32-bit floating point data have exactly the same number of equally spaced quantization steps in the normal audio range. What integers can't do is represent values outside of that range.

For a 2-channel master, you really shouldn't be exceeding the -1.0 to +1.0 range. Anything outside of that will be clipping your audio interface. And if your mix is a little hot, you can turn it down until it no longer clips, and have exactly the same results. But if you're exporting stems for mixing or stem mastering, there's a chance that something like your drums might have peaks above 0 dBfs, and they're being caught by something in the 2-bus. If you lower the level of just one channel to keep it from clipping you've changed the balance of the mix. Not a huge deal if the stems are being sent for mixing, but someone doing a stem master expects the levels of the stems to match the final mix. The only work around for one channel clipping is to reduce it until it doesn't clip, and then reduce all other channels the exact same amount. If you have volume automation, this is even more difficult and time consuming to do. If Reason would just export 32-bit floating point, the exact format that it uses internally, all of this would be moot.

An interesting additional note. When bouncing channels to disk from Reason, you have option to normalize those stems. This does include turning the output level down, as well as up, so the loudest peak anywhere in the track hit 0 dBfs. But how does it know to turn down the beginning of the file, if the loudest part is at the end? Simple, Reason writes 32-bit floating point data to disk, and then scans through it to find the highest peak, then re-writes that data into a 24-bit integer wave file with the level adjusted. This is fine when you're expecting to hand the files to a mixing engineer, or will be finishing the mix yourself in another program. I likely don't have to say, setting all channels to max (non-clipping) level will completely change the mix you have inside of Reason, so the new mix will be starting from scratch. Regardless, I find it really silly that Reason is actually writing raw 32-bit floating point data to disk, and then throwing it away to make the final 24-bit file, instead of just making a 32-bit wave file.

[orthodox]

32-bit floating point has 16,777,216 equally spaced steps between -1.0 and +1.0. 2^24 equals 16,777,216. So 24-bit integer data and 32-bit floating point data have exactly the same number of equally spaced quantization steps in the normal audio range.

24-bit integer PCM representation range is 2 less, 16,777,214. That introduces rounding error on conversion between f32 and i24, which may take away one bit of precision without dithering.

[ScuzzyEye]

24-bit integer PCM representation range is 2 less, 16,777,214. That introduces rounding error on conversion between f32 and i24, which may take away one bit of precision without dithering.

I might be wrong here, but all the signed integer PCM code I've ever written uses −8,388,608 to +8,388,607 for 24-bits. Including 0 makes for exactly 16,777,216 values. Then 32-bit floating point uses 1 sign bit and 23 fraction bits to make up the significand. Without involving the exponent bits, that's what gives the same number of equally spaced quantitation steps (as you involve the exponential bits the size of the steps increases or decreases).

[orthodox]

24-bit integer PCM representation range is 2 less, 16,777,214. That introduces rounding error on conversion between f32 and i24, which may take away one bit of precision without dithering.

I might be wrong here, but all the signed integer PCM code I've ever written uses −8,388,608 to +8,388,607 for 24-bits. Including 0 makes for exactly 16,777,216 values. Then 32-bit floating point uses 1 sign bit and 23 fraction bits to make up the significand. Without involving the exponent bits, that's what gives the same number of equally spaced quantitation steps (as you involve the exponential bits the size of the steps increases or decreases).

±8,388,607 (2^23-1) means ±1.0 (0 dBFS) in i24 PCM, so the actual range of i24 is from -8,388,607 to +8,388,607. 8,388,607 - (-8,388,607) gives 16,777,214 steps. Whereas f32 represents ±1.0 outside the 23-bit fraction domain, just by using a different exponent.

[friday]

Thanks for all your detailed feedback. Hope someone from RS will look over that thread and we will see 32bit export when they did the deeper VST3/M1 rebuild

[Ahornberg]

24-bit audio does not require dithering, as the noise level of the digital converter is always louder than the required level of any dither that might be applied. 24-bit audio could theoretically encode 144 dB of dynamic range, but based on manufacturer's datasheets no ADCs exist that can provide higher than ~125 dB.

see: https://en.wikipedia.org/wiki/Audio_bit_depth

I export with 24 bit and then I convert the audio file to 32 bit in Audacity.

[orthodox]

24-bit audio does not require dithering, as the noise level of the digital converter is always louder than the required level of any dither that might be applied. 24-bit audio could theoretically encode 144 dB of dynamic range, but based on manufacturer's datasheets no ADCs exist that can provide higher than ~125 dB.

When you add 60dB (digitally) before the DAC to listen to some silent part of an audio, -144 dB becomes -84 dB, and dithering can make a difference.

[selig]

Super confused about the claims that greater dynamic range on a bounce gives better “clarity” or “warmth” or whatever “dimensionality” means.
All it gives is greater dynamic range, period. I would guess the reason 32 bit files are requested is the same as the request for peaks at -6 dB. Which is that even when you tell folks to not clip, folks still clip, especially these days with so many bedroom producers. So to avoid this you instead ask for 6 dB headroom. And if folks STILL send files that are clipped, your only other option is to ask for 32 bit float files.
Seriously, if you don’t clip then the file can be successfully mastered.

[selig]

24-bit audio does not require dithering, as the noise level of the digital converter is always louder than the required level of any dither that might be applied. 24-bit audio could theoretically encode 144 dB of dynamic range, but based on manufacturer's datasheets no ADCs exist that can provide higher than ~125 dB.

When you add 60dB (digitally) before the DAC to listen to some silent part of an audio, -144 dB becomes -84 dB, and dithering can make a difference.

But if you’re adding 60 dB gain (which is the entire dynamic range of much of todays music) just to listen, why dither?
You could also say that if you add 144 dB gain then even 24 bits isn’t enough dynamic range to begin with.
What am I missing?

[orthodox]

When you add 60dB (digitally) before the DAC to listen to some silent part of an audio, -144 dB becomes -84 dB, and dithering can make a difference.

But if you’re adding 60 dB gain (which is the entire dynamic range of much of todays music) just to listen, why dither?
You could also say that if you add 144 dB gain then even 24 bits isn’t enough dynamic range to begin with.
What am I missing?

Dithering is harmful for intermediate processing, so I'm talking only about the final master/record, whether to dither it or not. When it's released by someone else and I can't have any other source material.
And in classical concert recordings the dynamic range can be higher than 60 dB.

[selig]

But if you’re adding 60 dB gain (which is the entire dynamic range of much of todays music) just to listen, why dither?
You could also say that if you add 144 dB gain then even 24 bits isn’t enough dynamic range to begin with.
What am I missing?

Dithering is harmful for intermediate processing, so I'm talking only about the final master/record, whether to dither it or not. When it's released by someone else and I can't have any other source material.
And in classical concert recordings the dynamic range can be higher than 60 dB.

Yes and in jazz, bluegrass, and many other formats too, despite analog tape being limited to less than that (without noise reduction). But that's not the point - I guess I was just confused about gaining up 60 dB, and why dither a 24 bit file just to check the soft parts?
Reason being, even if you deliver 24 bit files to consumers, they are not likely to have the ability to ever gain it up that much unless I'm missing something here.

[ScuzzyEye]

All it gives is greater dynamic range, period. I would guess the reason 32 bit files are requested is the same as the request for peaks at -6 dB. Which is that even when you tell folks to not clip, folks still clip, especially these days with so many bedroom producers. So to avoid this you instead ask for 6 dB headroom. And if folks STILL send files that are clipped, your only other option is to ask for 32 bit float files.
Seriously, if you don’t clip then the file can be successfully mastered.

It's exactly this. Rather than receiving files that have peaks at -6 dBfs, but those peaks having been obviously clipped, I just want 32-bit floating point. And I'll generate the headroom myself.

Of course, trying to make the process fool proof, will just make better fools. For example one could export a 24-bit, clipped file from Reason, open it in Audacity, turn it down 6 dB, and export it as 32-bit float.

[ScuzzyEye]

Interestingly, you can (ab)use the bounce channels to disk to get a master bus export without the chance of clipping. You start like you're going to bounce channels, but then uncheck all the channels, and instead check the master output. Then enable normalization, and save as 24-bit wave. Reason will render the song to disk as 32-bit (as mentioned above), and then normalize it to 0 dBfs and write the wave with no clipping.

You'll get a folder, with just one file in it, and I think that file will be called master.wav, but you can rename it to your song title.

[selig]

All it gives is greater dynamic range, period. I would guess the reason 32 bit files are requested is the same as the request for peaks at -6 dB. Which is that even when you tell folks to not clip, folks still clip, especially these days with so many bedroom producers. So to avoid this you instead ask for 6 dB headroom. And if folks STILL send files that are clipped, your only other option is to ask for 32 bit float files.
Seriously, if you don’t clip then the file can be successfully mastered.

It's exactly this. Rather than receiving files that have peaks at -6 dBfs, but those peaks having been obviously clipped, I just want 32-bit floating point. And I'll generate the headroom myself.

Of course, trying to make the process fool proof, will just make better fools. For example one could export a 24-bit, clipped file from Reason, open it in Audacity, turn it down 6 dB, and export it as 32-bit float.

Yea, I don't know any full time mixers that need this feature, but for the bedroom part timers I'm gonna have to say it's probably essential.

[Ahornberg]

24-bit audio does not require dithering, as the noise level of the digital converter is always louder than the required level of any dither that might be applied. 24-bit audio could theoretically encode 144 dB of dynamic range, but based on manufacturer's datasheets no ADCs exist that can provide higher than ~125 dB.

When you add 60dB (digitally) before the DAC to listen to some silent part of an audio, -144 dB becomes -84 dB, and dithering can make a difference.

We're talking about -6 dB headroom, not about -60 dB.

[integerpoet]

It seems in the rush to have a discussion of the comparative merits of differing formats we missed the essence of the specification.

This is understandable because the specification is (oddly, for a reputable mastering house) sorely confused about terminology. In particular, it confuses rate and width and seems to think there is some widely accepted notion of "full res(olution)" which doesn't exist. This makes it difficult to figure out what they really mean. The spec needs a pass from a copy editor with audio engineering experience.

But my sense is that the essence of what they want is "native" data. In other words, they want producers to avoid shooting themselves in the foot by pointlessly throwing away quality at the last moment. And that's completely and unambiguously righteous.

I suspect the practical issue here is figuring out what the "native" rate and width of your project are. A sample-heavy production — especially if you collect samples from random sources on the internet — is a mix of widths and rates. In that case, you're kinda screwed because those all get normalized in various ways by the mixer or effects or even whatever instrument (sampler, drum machine, wavetable synth, etc.) you load them into but in any case before you get anywhere near bouncing. So your project has a putative "native" quality that doesn't mean a whole lot because you threw some reverb on the crappiest sample, which hides the crappiness. But maybe if every source is a soft synth, you can meaningfully establish your "native" quality.

[ScuzzyEye]

But my sense is that the essence of what they want is "native" data. In other words, they want producers to avoid shooting themselves in the foot by pointlessly throwing away quality at the last moment. And that's completely and unambiguously righteous.

I suspect the practical issue here is figuring out what the "native" rate and width of your project are. A sample-heavy production — especially if you collect samples from random sources on the internet — is a mix of widths and rates. In that case, you're kinda screwed because those all get normalized in various ways by the mixer or effects or even whatever instrument (sampler, drum machine, wavetable synth, etc.) you load them into but in any case before you get anywhere near bouncing. So your project has a putative "native" quality that doesn't mean a whole lot because you threw some reverb on the crappiest sample, which hides the crappiness. But maybe if every source is a soft synth, you can meaningfully establish your "native" quality.

Pretty much. They're just trying to get the 2-bus mix without any possibility of clipping. For every current DAW, except for Reason, 32-bit floating point will give you that. It's now the most fool proof way of asking for the audio. It used to be they'd ask for the export with peaks no louder than -6 dBfs, and that would cause people to do silly things (like exporting and then loading into Audacity to turn it down). If a DAW supports floating point output, that's definitely the easiest way to get unclipped audio without giving a lot more instructions.

As for sampling rate, that's a bit more difficult. Their instructions for exporting at the rate you started the project with, is probably best. Most DAWs have pretty good resamplers at this point, but the mastering engineer probably has access to something that beats every DAW out there. So if they have a preferred working rate, its probably better for them to upsample it, than the DAW's export process. But in the case of soft synths and saturation effects, exporting at a higher rate may give better results. But then any digital audio in the project will be upsampled by the DAW. This is where it's better if you can work with the client and know how their productions are built. The person I work with often does have vocal tracks in their projects, but those vocals are heavily processed and distorted. The key elements in the project are generated by soft synths. To reduce the aliasing of those synths, I request 96kHz output. Then again, if the person is working at 44.1kHz, and they hear aliasing from their synths, they've probably considered that to be part of the sound design. So again, it's knowing the client, their expectations for the final master. Or just tell them to export at the rate they've been working.

[integerpoet]

In the Possible Reason Futures department…

My understanding is that parts of the mixer internal to Reason work with 32-bit floating point samples and others work with 64-bit floating point samples. So the quality is "in there" and it's just a matter of how to surface it for the user.

In other words, any time we export through the usual path I can't see a way to avoid some dithering or down-sampling somewhere along the way, regardless of the check-box in that little alert, because the widest sample one can export has only 24 bits. (Maybe the "dithering" checkbox in that alert just means "scale rather than just throw away the least significant bits". I never export in 16-bit so I wouldn't know. )

I'm intrigued, however, by the post earlier about "exporting" by bouncing the master channel. I've only used that path for "printing" MIDI tracks within the project, which i merely hope preserves full quality.

But this doesn't have anything to do with VST3 or M1 support, so don't get your hopes up.

[selig]

In the Possible Reason Futures department…

My understanding is that parts of the mixer internal to Reason work with 32-bit floating point samples and others work with 64-bit floating point samples. So the quality is "in there" and it's just a matter of how to surface it for the user.

No, the 'quality' isn't in there. 32 bit isn't higher quality on any level, it just gives more dynamic range. The only real implication is mastering engineers don' have to worry about those folks who don't keep levels under 0 dBFS for whatever reasons.

And I'm certain Reason will eventually add the option as there is no technical limitation, but again the only time it makes any difference is if you don't keep the output level under 0 dBFS (which really isn't all that hard to do IMO).

[ScuzzyEye]

I'm intrigued, however, by the post earlier about "exporting" by bouncing the master channel. I've only used that path for "printing" MIDI tracks within the project, which i merely hope preserves full quality.

Make sure you don't have a limiter anywhere on the master output. Choose, Bounce Mixer Channels, Uncheck all, then only check the Master Section. Check the Normalize box, and set your Sample rate and Bit depth correctly. Where ever you tell it to export it will create a folder named "Bounce [song name]", and in that folder there will be a "Master Section.wav". You can rename that to match your song name, and it should have no clipped samples, without you having to adjust the master fader. The peaks will be at exactly 0 dBfs, and the file will be 24-bit. But it'll be the same "quality" as a 32-bit floating point export. You might want to open the file in a wave editor, convert it to 32-bit float, and adjust the peaks to be where the mastering engineer requests, or at least to -0.5 dBfs (so they don't see the full 0 peaks, and think something might have been clipped), then export it again.

[Billy+]

I always assumed that the export limit was due to the audio interface limits?

when I'm exporting without my dedicated interface switched on the export options is 16 bit
if I turn on my interface I can export at 24 bit or 16 bit....

I generally export at 24 bit from Reason at around -6db and the use ozone standalone to add the extra polish/volume (mastering) as I always find that even if I'm not clipping in Reason the exported files nearly always are but I'm under the understanding that this is due to the conversion from 64bit DAW to 24bit audio files.

[orthodox]

No, the 'quality' isn't in there. 32 bit isn't higher quality on any level, it just gives more dynamic range. The only real implication is mastering engineers don' have to worry about those folks who don't keep levels under 0 dBFS for whatever reasons.

I am those folks, and I find it ridiculous that I have to keep channel(!) peaks under 0 dBFS. Peaks is a thing I can deal with later on the master channel. I'm typically exporting stems for external mixing and I hate to have to adjust the channel faders to a sane state twice, first in Reason and then in the other DAW after they are normalized on the bounce from Reason.

[Billy+]

Make sure you don't have a limiter anywhere on the master output. Choose, Bounce Mixer Channels, Uncheck all, then only check the Master Section. Check the Normalize box, and set your Sample rate and Bit depth correctly. Where where every you tell it to export it will create a folder named "Bounce [song name]", and in that folder there will be a "Master Section.wav". You can rename that to match your song name, and it should have no clipped samples, without you having to adjust the master fader. The peaks will be at exactly 0 dBfs, and the file will be 24-bit. But it'll be the same "quality" as a 32-bit floating point export. You might want to open the file in a wave editor, convert it to 32-bit float, and adjust the peaks to be where the mastering engineer requests, or at least to -0.5 dBfs (so they don't see the full 0 peaks, and think something might have been clipped), then export it again.

I definitely think someone should put this as a sticky in the tutorial section as it's an excellent method