32-bit float rocks!

RainbowStorm · 23rd December 2005, 11:40 PM

Tonight I tested the Waves L2 limiter for the first time in 32-bit float, what a difference between that and the 24-bit version! I actually had a hard time hearing any kinds of harshness in the signal when I tested limiting by 100% at 32-bit float! The result was much more pleasant to listen to... I will never use the L2 in a bit depth of less than 32-bit float again...! I must say that this changed my view on the quality of the L2 quite much and also my view on the importance of 32-bit float!

Bob Olhsson · 23rd December 2005, 11:58 PM

The biggest difference I've found between a TDM L-2 and a 32 bit float (actually it's 64 bit internally) is that the 32 bit float version can accept signals above full sample rate without distorting. Both can output no more than 24 bits.

RainbowStorm · 24th December 2005, 12:09 AM

Quote:

Originally Posted by Bob Olhsson

The biggest difference I've found between a TDM L-2 and a 32 bit float (actually it's 64 bit internally) is that the 32 bit float version can accept signals above full sample rate without distorting. Both can output no more than 24 bits.

I agree. I think what happens under the hood is a lot of gain calculations with a much better significance which in combination with the great IDR dithering process results in a more exact output. So the distortion due to quantization errors in the process is much lower in amplitude. Quantization errors can make some of the samples break through the clip level in 24-bit so that it causes an amount of distortion that is audible. But in 32-bit float this amount is so little that you can push the signal at 100% limiting and still not hear any distorsion.

Lawrence · 24th December 2005, 12:11 AM

Quote:

Originally Posted by TonyCrazyMan

Tonight I tested the Waves L2 limiter for the first time in 32-bit float, what a difference between that and the 24-bit version! I actually had a hard time hearing any kinds of harshness in the signal when I tested limiting by 100% at 32-bit float! The result was much more pleasant to listen to... I will never use the L2 in a bit depth of less than 32-bit float again...! I must say that this changed my view on the quality of the L2 quite much and also my view on the importance of 32-bit float!

What daw are you using? Are you recording inidividual 32-bit float files?

Just as an FYI ... all native daws operate at (at least) 32-bit float internally. If you've got an L2 across the mix bus (or inserted on an individual track) it's operating at 32-bit float and always had been. Even if your source files are 24-bits.

Are you saying that recording 32-bit float tracks is making the difference in the behavior of the L2? It should not be because (again) everything that passes through the native daw's mixer is 32-bit float anyway.

I'm not sure what you're getting at here. Please go into more details. Are you talking about a hardware L2?

Lawrence

TanTan · 24th December 2005, 12:12 AM

Is there any recomandation on an ideal sample rate for 32Bit ?
i'm currently working at 88.2Khz is there any connection between sample rate and bit being used or is it the most detailed sound using the highest sample rate and bit your hardware support ?

Zooey · 24th December 2005, 12:25 AM

Quote:

Originally Posted by Lawrence

Just as an FYI ... all native daws operate at (at least) 32-bit float internally. If you've got an L2 across the mix bus (or inserted on an individual track) it's operating at 32-bit float and always had been. Even if your source files are 24-bits.

Are you saying that recording 32-bit float tracks is making the difference in the behavior of the L2? It should not be because (again) everything that passes through the native daw's mixer is 32-bit float anyway.

I'm not sure what you're getting at here. Please go into more details. Are you talking about a hardware L2?

Three excellent points. Everyone should read this. Everyone who is tracking to individual 32 bit tracks should read it twice.

Lawrence · 24th December 2005, 12:35 AM

I feel a long discussion coming....

There are no 32-bit converters. You cannot record a true 32-bits with the hardware available. I'm sure if I'm wrong someone will chime in and correct me on this but...

1. You pass 24-bits to the native daw which makes it 32-bit float in the dsp engine and can, if you choose, write the 32-bit float data to a file to avoid truncation back to 24-bits. SX can do that and I'm sure most other native daws also allow that option.

2. There is really no point in doing that to individual tracks. Everytime you play back your 24-bit tracks through the daw with the same plugs, eq, etc. in place they'll be "first generation" 32-bit float inside the daw. No need to waste the disk space saving the result of that. It's all saved in the daw with the mix settings. It's recreated everytime you hit play.

3. The *only* benefit I can see using 32-bit float files anytime is maybe *rendering* (and only rendering, if it leaves the converters or hit any digital I/O pipe it'll be truncated to 24 again) a 32-bit float in-the-box final mix file. What this does is keep the daw from truncating your mix to 24-bits. It is *subjectively and theoretically* useful if you plan on doing more dsp processes later in a mastering app like Wavelab or Sound Forge (or the same daw) which I think also operate as 32-bit float internally. In this case you won't be applying more dsp to a file that's already been truncated.

Some (like me) choose instead to just add 24-bit dither at the mix bus (with no noise shaping) and render 24-bit mix files, with the dither (theoretically & subjectively) minimizing the effect of the truncation from 32-bit float to 24. Most do neither.

There's much debate about how many times a file has to be truncated before you actually start to hear it. I think it's probably many, many times in most cases. IMHO recording 32-bit float tracks is a waste of hard disk space

Lawrence

RainbowStorm · 24th December 2005, 12:46 AM

Quote:

Originally Posted by Lawrence

What daw are you using? Are you recording inidividual 32-bit float files?

Just as an FYI ... all native daws operate at (at least) 32-bit float internally. If you've got an L2 across the mix bus (or inserted on an individual track) it's operating at 32-bit float and always had been. Even if your source files are 24-bits.

Are you saying that recording 32-bit float tracks is making the difference in the behavior of the L2? It should not be because (again) everything that passes through the native daw's mixer is 32-bit float anyway.

I'm not sure what you're getting at here. Please go into more details. Are you talking about a hardware L2?

Lawrence

I understand your point. Actually I'm not sure about this, but I have thought that since the DAW is 32-bit fixed it operates at 32-bit fixed on 24-bit data, but when the data coming in is 32-bit float it operates at 32-bit float, hence resulting in much more precise calculations when 32-bit float data is coming in.

Lawrence · 24th December 2005, 01:23 AM

Quote:

When I record and store files at 24-bit in Nuendo v2.2, Nuendo cannot process 32-bit fixed point even if the DAW is 32-bit, resulting in 24-bit operation.

I'm not sure who gave you this information but it's just plain wrong.

The architecture of the dsp engine is 32-bit float and there are no options to change that. You couldn't force it to operate at a straight 24-bits even if you wanted to. Really ... you might have poorly designed shareware plugin that is doing something goofy in the middle there but the engine is designed to work at 32-bit float and will never operate at 24-bits internally. No modern native daw would (should) ever do dsp at 24 bits. There is just not enough math headroom to do the kinds of calculations that need to be done. There would be lots more quantanization distortion and it would not sound as good.

Changing the "record options" to 32-bit float does nothing unless you actually record something and then that file will be 32-bit float. Regardless of whether you record 24-bit or 32-bit float files the audio engine in Nuendo, and everything that succesfully passes through it, always operates at 32-bit float.

The method it uses to change 24-bit to 32-bit float (to my limited understanding) is simply adding a string of zeros to the data word. Now as soon as you push a fader or turn a knob those zeros become "active", there is some valuable data contained in what was once just filler bits. If you did the same dsp operation at 24 bits (without the additional math headroom) it wouldn't sound nearly as good, especially across multiple tracks. Think back to when that was the case with Cubase VST and some other daws. Much harsher sound than the current 32-bit float engines provides.

Lawrence

RainbowStorm · 24th December 2005, 01:27 AM

Quote:

Originally Posted by Lawrence

I'm not sure who gave you this information but it's just plain wrong.

The architecture of the dsp engine is 32-bit float and there are no options to change that. You couldn't force it to operate at a straight 24-bits even if you wanted to. Really ... you might have poorly designed shareware plugin that is doing something goofy in the middle there but the engine is designed to work at 32-bit float and will never operate at 24-bits internally. No modern native daw would (should) ever do dsp at 24 bits. There is just not enough math headroom.

Changing the "record options" to 32-bit float does nothing unless you actually record something and then that file will be 32-bit float. Regardless of whether you record 24-bit or 32-bit float files the audio engine in Nuendo, and everything that succesfully passes through it, always operates at 32-bit float.

There are no 24-bit dsp operations in Nuendo that I know of ... except 24-bit dither.

I give up. If if sounds better to you ... do it.

Lawrence

I was stating that a little incorrectly, by saying it operates at 24-bit what I meant was that it operates at 32-bit fixed internally, not at 32-bit float.

RainbowStorm · 24th December 2005, 01:35 AM

Quote:

Originally Posted by Lawrence

I'm not sure who gave you this information but it's just plain wrong.

The architecture of the dsp engine is 32-bit float and there are no options to change that. You couldn't force it to operate at a straight 24-bits even if you wanted to. Really ... you might have poorly designed shareware plugin that is doing something goofy in the middle there but the engine is designed to work at 32-bit float and will never operate at 24-bits internally. No modern native daw would (should) ever do dsp at 24 bits. There is just not enough math headroom.

Changing the "record options" to 32-bit float does nothing unless you actually record something and then that file will be 32-bit float. Regardless of whether you record 24-bit or 32-bit float files the audio engine in Nuendo, and everything that succesfully passes through it, always operates at 32-bit float.

There are no 24-bit dsp operations in Nuendo that I know of ... except 24-bit dither.

I give up. If if sounds better to you ... do it.

Lawrence

If I record in 32-bit float I get of course 24-bit data in the conversion, but the file is stored in 32-bit float for Neundo to be able to directly calculate the data on 32-bit float instead of 32-bit fixed on a 32-bit Windows platform. But if you have read that Nuendo is doing all its operations at 32-bit float and not 32-bit fixed, then I guess there's no difference...

RainbowStorm · 24th December 2005, 01:56 AM

Quote:

Originally Posted by Lawrence

I'm not sure who gave you this information but it's just plain wrong.
The method it uses to change 24-bit to 32-bit float (to my limited understanding) is simply adding a string of zeros to the data word.
Lawrence

In my opinion it cannot be that simple. 24-bit is fixed point. That means in order to translate that into 32-bit float point it needs to process the bits (describing the base, exponent and significand), which I think should be quite consuming in the context to do both ways during the real-time processes due to the differences in the byte description (especially at 192KHz). That's why I think it doesn't actually process everything at 32-bit float all the time on a 32-bit Windows platform, only if the data coming in is stored as 32-bit float it will process it with such a precision since then it can do the job efficiently enough. On 24-bit recorded and stored files I think it will only add bits to make it 32-bit fixed point and then calculate on a 32-bit fixed point precision, which is much less precise than calculating on 32-bit float point precision. When you record at 24-bit and choose to store the file as 32-bit float it can do the translation fast enough since it's only a one way operation. In such a situation it becomes efficient to process the effects on 32-bit float point since there is no translation needed. That's only my thoughts about it... I have no real CPU cost figures of the translation of 24-bit fixed to 32-bit float (and back, is it even possible without getting too bad truncation and then be worthless) so maybe this cost is much smaller than I think. But to me it seems to be most efficient using fixed all the way or float all the way.

The difference in using 32-bit float was really huge I thought! That has to be because of the added precision in the operations...

BTW, a 32-bit float point converter would be really nice!

RainbowStorm · 24th December 2005, 03:20 AM

Quote:

Originally Posted by Lawrence

I feel a long discussion coming....

There's much debate about how many times a file has to be truncated before you actually start to hear it. I think it's probably many, many times in most cases. IMHO recording 32-bit float tracks is a waste of hard disk space

Lawrence

It might be a waste of disk space, but if all processing is to be 32-bit float it is also a way of saving CPU power since the data is already formatted for the 32-bit float operations, so no translations are needed.

Lawrence · 24th December 2005, 04:25 AM

I'm not a math guy but I imagine turning a 24-bit stream into 32-bit float is nothing compared to the math calculations going on in the daw for typical dsp processes like summing levels, pan, eq, compression, convolution reverb and the like. Those are really cpu intensive operations at times which is indicative of how difficult those math operations are. A Waves Linear Broadband EQ takes about 5-7% of my cpu juice. Much more difficult realtime math going on there than just pushing 48 tracks through the daw.

Whatever has to be done is done at the input and it's obviously pretty efficient. I'm not one who can put up a scope to verify but I do believe it's 32-bit float from just after input to just before output. Can I prove it? No.

I don't think that the Windows OS being 32-bit has anything to do with it but again, I could be wrong about that. But to say that XP being a 32-bit OS puts a limit on a *math operation* at 32-bits is saying that math calculations on a PC could never go beyond a depth of 32-bits. I'm talking just *math calculations* not 48 or 64-bit data paths through a 32-bit system or OS. Entirely different thing I believe. But again, I could be wrong.

It's the depth of the math (DSP) calculation (number of available places for precise numbers before rounding begins) not 48 or 64-bits of data traveling in blocks through a 32-bit data path or OS. But... well you know... I could be wrong.

Math is not my thing so I'll yield to those who know better.

Thanks. I appreciate this conversation and the chance to discuss something interesting. The beauty of audio engineering is that it's not always just about sound, its often about theory and science. This science is WAY over my head.

Take care Tony. Good luck to you friend.

Lawrence

bobby yarrow · 24th December 2005, 04:41 AM

32-bit float remains a mystery to me. I track to it, but I don't understand what it even means, as my convertors are (obviously) 24-bit. The resulting audio files, however, are 32-bit float, and can't be read by software that can only read 24-bit. So I have to convert the files back to 24-bit to use certain software. What's mysterious is 1. what happens in the 24-bit to 32-bit fp process, and, 2. what happens when it's converted back to 24 bit.

mogWai · 24th December 2005, 10:49 AM

Quote:

Originally Posted by TonyCrazyMan

It might be a waste of disk space, but if all processing is to be 32-bit float it is also a way of saving CPU power since the data is already formatted for the 32-bit float operations, so no translations are needed.

Tony, I think you may be missing the point slightly.

You cannot get anything above 24bits into your computer. There is only 24bit converters. If you set your Nuendo project to 32bit float, any file you record is simply 24bits with 8 0s stuck on the end.

A complete waste of space (although are 8 0s bigger than 0 0s ? Well, yes because you still need to store those 8 extra bits, even if they are just 0).

Nuendo works at 32bit float all the time regardless of bit depth of the file size. This allows you to process 24bit data in a 32bit float environment and utilize the theoretically huge digital headroom.

This means that any process you apply to a 24bit word will increase the word-length, and the result can quite comfortably be stored by 32bit float.

But since your converters (everyone's converters) are 24bit you will never, ever. ever record more than 24bits and it will always, always, always and forever be processed at 32bit float by Nuendo. Some plug-ins work at 64bit internally, but they will always dither their output back to 32bit before delivering it back to the audio engine.

Actually, because the best converters only have a dynamic range of about 120dB - the most you can hope for is to capture a 20bit word.. so 24bits is more than enough to record anything you can physically..er .. record.

Of course, the same thing happens at the other end. You have a 32bit float word that needs to be delivered to a 24bit DAC. This is why some people always dither their master bus back to 24bits. I used to.. but I feel the truncation errors we are talking about are probably on the cusp on the audible world, and I prefer 32bit float mix files for further processing.

RainbowStorm · 24th December 2005, 10:53 AM

Quote:

Originally Posted by Lawrence

I'm not a math guy but I imagine turning a 24-bit stream into 32-bit float is nothing compared to the math calculations going on in the daw for typical dsp processes like summing levels, pan, eq, compression, convolution reverb and the like. Those are really cpu intensive operations at times which is indicative of how difficult those math operations are. A Waves Linear Broadband EQ takes about 5-7% of my cpu juice. Much more difficult realtime math going on there than just pushing 48 tracks through the daw.

Whatever has to be done is done at the input and it's obviously pretty efficient. I'm not one who can put up a scope to verify but I do believe it's 32-bit float from just after input to just before output. Can I prove it? No.

I don't think that the Windows OS being 32-bit has anything to do with it but again, I could be wrong about that. But to say that XP being a 32-bit OS puts a limit on a *math operation* at 32-bits is saying that math calculations on a PC could never go beyond a depth of 32-bits. I'm talking just *math calculations* not 48 or 64-bit data paths through a 32-bit system or OS. Entirely different thing I believe. But again, I could be wrong.

It's the depth of the math (DSP) calculation (number of available places for precise numbers before rounding begins) not 48 or 64-bits of data traveling in blocks through a 32-bit data path or OS. But... well you know... I could be wrong.

Math is not my thing so I'll yield to those who know better.

Thanks. I appreciate this conversation and the chance to discuss something interesting. The beauty of audio engineering is that it's not always just about sound, its often about theory and science. This science is WAY over my head.

Take care Tony. Good luck to you friend.

Lawrence

Thanks for the kind words Lawrence, I downloaded the sdk and had a look at how the VST plug-in process methods are declared and it WAS in 32-bit float, so obviously they think they get more than they lose by doing this data conversion. So you are absolutely right! That means all operations are of 32-bit float point precision even if the data is in 24-bit fixed, everything consists of in-memory translations. So what was I experiencing yesterday when I thought it sounded much cleaner than it usually sounds? I don't know, to me this seems to be a placebo effect now, maybe I only happened to try limiting cleaner stuff than I usually limit or something... One thing I've thought of though is the way it applies dithering. If the material is in 24-bit fixed and the effect processing is 32-bit float but there is IDR dithering to be applied too, there is a small chance that they in such cases have converted the data stream back to 24-bit before they apply dithering separately and excluded that process from the real-time operations, because it might be programmed so that Nuendo handles dithering in a separate from-disk process and that it is actually a post-time process that is applied on the final data stream, so if that data stream is stored as 32-bit float, the L2 is actually able to do a much more precise dithering job after the limiting when the data is stored as 32-bit float, that might be a possible explanation for what I experienced too, meaning it would convert the signal from 24-bit fixed to 32-bit float, then apply limiting at 32-bit float, then downsample that to 24-bit fixed data again (that would be the loss) and apply dithering separately by converting the data back to 32-bit float, apply dithering at 32-bit float and then downsample that to 16-bit. The argument for doing that would be to be able to do the limiting and dithering processes more complex by applying them in totally separate processes and to implement the dithering on a separate process call by Nuendo (if the host for some reason needs to control the dithering separately or the dithering needs more information than the process methods can handle at a time). But if this would be true it would be quite inefficient compared to their 32-bit float effect operations ideology. So I suspect that's not the case... But this is pretty hard to know, it depends totally on how they have implemented the host and the L2. To me it seems most efficient to stay in 32-bit float as long as possible once the conversion is done, even so that both the limiting and the dithering is done on 32-bit float data stream in only one process. I suspect that's the case too and that would make the L2 equally powerful no matter if the data is stored in 24-bit or 32-bit float.

RainbowStorm · 24th December 2005, 09:19 PM

Now I know why I experienced a cleaner limit with the L2. Recording in 32-bit float (storing 24-bit conversion as 32-bit float) is recommended because it makes the recorded tracks not clipping because of the extra headroom. That's why it's very important that recording with effect processing is done in 32-bit float. When recording at 24-bit you need to be much more careful with levels and you get clipping in some degree much easier. If you apply effects directly on the files you will lose sound quality as well due to the conversion to 24-bit from 32-bit float. When the input track records the file it will do all the 32-bit float calculation on the effects, but if the selected storing resolution is 24-bit it needs to be converted back to 24-bit before the recorded material is stored on the disk, resulting in quality loss due to quantization errors. As I understood this, the only risk of losing quality when storing with a bit depth of less than 32-bit float is when data is being written to a file, such as when recording and applying effects directly on the files.

Besides these advantages with storing the audio in 32-bit float you also lower the CPU load because the data doesn't have to be translated to 32-bit float before it is processed.

Dennis Edlund · 19th January 2006, 09:12 AM

CUBASE and probably all other 32bit-float systems are using (+1 to -1) value range.
And 32bit float has a linear precision dynamic range by 150dB = log10(2^25)*20.
And it's all up to the Plugin creator to use 80bit-float or something so the plugin won't affect the dynamic range badly.

ProTools TDM uses 48bit between plugs that are on the same TDM bus and DSP, so the transfer between PLUG-INS is 289dB.

The weakest point in that system should be the PANNING/FADER/SUMMING MIXER.
But if they're all done in the same calculation in the FPU you should have 80bit-float (INTEL x87) and that makes it =log10(2^65)*20=391dB.
And that 80bit is used in every calculation in the computers FPU, but it can be rounded down to 64 or 32bit float when being outputted.

Just to make a comparison with ProTools TDM system the SUM MIXER is at 48bits = 289dB.

---------------------------------------------
Best Regards / Dennis from Sweden

Ruudman · 19th January 2006, 11:02 AM

Quote:

ProTools TDM uses 48bit between plugs that are on the same TDM bus and DSP, so the transfer between PLUG-INS is 289dB.

But each TDM plugin ouput 24Bit, right?

ruudman

allstar · 19th January 2006, 01:18 PM

Quote:

Originally Posted by Lawrence

Some (like me) choose instead to just add 24-bit dither at the mix bus (with no noise shaping) and render 24-bit mix files, with the dither (theoretically & subjectively) minimizing the effect of the truncation from 32-bit float to 24. Most do neither.

Which plugins do you use to achieve 24-bit dither ?

The only ones I know of that go as high as 24-bit is the L2 and L3. Even waves own IDR plugin only goes up to 20-bit as does the stock Digidesign dither and POWr dither.

I guess an L2/3 with it's threshold at 0dBfs doesn't effect the audio (?), but it would be nice to be able to use a simple dither plugin instead.

Dennis Edlund · 19th January 2006, 11:40 PM

The resolution is keept at 48bit when you have a plugin chain that are on the same DSP.
But as soon as you leave one DSP the data will be dithered and truncated to 24bit.

With the mixer the data are keept at 48bit even if the data are going between DSP's, the data are send in 2x24bit between DSP's.

Boby Stoica · 20th January 2006, 03:17 PM

Funny thing - I ALWAYS preffer the sound of my hardware 48bit double precision L2 over the native L2 /pc/CUBASE SX2. I use the hardware one as the last thing on the 2bus chain.
Did lots of testing - aplying the L2 on the native environment over a 24bit file, passing a 24 bit file through the hardware unit, both having dither for 16bit (clients preffer to master stuff in-house). I think the 48bit sounds less harsh and has more depth . And I really like using the hardware unit having the 2 channels unlinked, with autorelease on both channels.

Different strokes for different folks, ha ? :).

Almost Human · 2nd February 2006, 09:39 PM

Interesting topic that I'm just now jumping into...this is what I was told before...what are your thoughts on this:

"24-bit integer processing can introduce progressive deterioration, (as will any integer system) whereas 32-bit floating point won't. This is why programs like Adobe Audition can outperform ProTools in its internal processing.

It's only called 32-bit because it is 23-bit mantissa + sign bit + 8-bit exponent, which is effectively 24-bit. The reason for working like this (32 bit floating point) is to retain the resolution when audio has any sort of amplitude-related operation carried out on it - which it can do over about a 1500dB range. If Audition worked in 24-bit integer mode, this range would be restricted to about 144dB.

Your DAC is operating in 24-bit integer mode because it has to - it's a hardware device. Audition has no such limitation, and is accordingly engineered to take the best advantage possible from it. And there's no such thing as a 'standard' 24-bit file anyway - there are several formats, and everybody uses their own 'standard'. That's why there are translators available. Mind you, I'm not saying that it wouldn't be a good idea to have a proper standard for audio file transfer - but if there was one, nobody would accept the ProTools 24-bit integer one anyway, because it's too limiting. The IEEE 32-bit standard that Audition uses would be a far better bet.

There are a few other issues about operating in 32-bit mode, but they're all good things, not bad ones. Probably the most important is that as long as it sounds good, you really don't have to worry about the mixdown level, even if its way undermodded, or even overloaded slightly, because normalising the FP mixdown will restore everything to the correct peak levels without any loss of resolution at all - this is the magic of Floating Point, and that's something that you just can't achieve with a 24-bit integer system. Mind you, if you have an overloaded mix running, it doesn't usually sound too good when you monitor it, because at that stage, the soundcard can't cope with it - this is ultimately why the mixdown needs to be normalised so that the peaks don't exceed 0dBFS, or slightly below. This way, it converts back to integer levels that the card can cope with.

Pro Tools claim of 48-bit precision mixing with nearly 300dB of dynamic range implies that this is integer-based, not Floating Point arithmetic. The actual dynamic range this gives is 289dB, which is presumably what they mean by "nearly 300dB." Now, compare this to Audition. 32-bit Floating Point internal processing gives nearly 1500dB of internal dynamic range. The Pro Tools system is inherently dated architecture."

What's everyone's thoughts on that?

juicemaster1500 · 2nd February 2006, 10:08 PM

Quote:

Originally Posted by allstar

Which plugins do you use to achieve 24-bit dither ?

Sony Oxford Dynamics has a great 24 bit dither.

Teacher · 2nd February 2006, 11:27 PM

Quote:

Originally Posted by allstar

Which plugins do you use to achieve 24-bit dither ?

Cranesong Dither

mogWai · 3rd February 2006, 09:15 AM

Quote:

Originally Posted by allstar

I guess an L2/3 with it's threshold at 0dBfs doesn't effect the audio (?), but it would be nice to be able to use a simple dither plugin instead.

Waves L3 only has to come within a mile of your audio and it messes with the sound. Even with everything 'off' it still sounds like cack.

Chris Kress · 6th February 2006, 02:07 AM

According to this document:
http://akwww.digidesign.com/support/...48BitMixer.pdf

the Digidesign plug in bus is 24 bit, with each plug upsampling, doing calculations at 48 bit, and then truncate/dither back to 24-bit... Saying again; pro tools upsamples and truncates/dithers between each plug in at 24-bit. This is absolutely evil. See page 2, read end of 3rd paragraph of this docment.

If you want to approximate how bad this sounds, load three or four dither plug ins (set to 24-bit) onto the output of your 32-bit mixer. Listen to the shine in your cymbals roll off,

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
When recording @ 16 bit with 24 bit soundcards will the 16 bit recordings sound same?	rokuez	Music computers	4	12th March 2008 02:43 AM
32-bit float to 24-bit -- is this a problem?	bobby yarrow	Music computers	31	4th October 2007 09:52 AM
32 bit Float in Samplitude: please explain how this works???	Alex Wyler	Music computers	27	30th July 2007 05:58 PM
Can a standard Version of windows xp pro (32 bit) run on a 64 bit machine	heathen	Music computers	8	19th March 2006 01:46 AM
Float down to the cool shallow bottom	zxcv	Work in progress / advice requested / Show & Tell / Artist showcase	1	31st October 2005 01:57 AM

23rd December 2005, 11:40 PM	#1
RainbowStorm Lives for gear Join Date: Aug 2005 Posts: 1,322	32-bit float rocks! Tonight I tested the Waves L2 limiter for the first time in 32-bit float, what a difference between that and the 24-bit version! I actually had a hard time hearing any kinds of harshness in the signal when I tested limiting by 100% at 32-bit float! The result was much more pleasant to listen to... I will never use the L2 in a bit depth of less than 32-bit float again...! I must say that this changed my view on the quality of the L2 quite much and also my view on the importance of 32-bit float!

23rd December 2005, 11:58 PM	#2
Bob Olhsson Motown legend Join Date: Jun 2002 Location: Songwriter Gulch, Nashville TN Posts: 5,057	The biggest difference I've found between a TDM L-2 and a 32 bit float (actually it's 64 bit internally) is that the 32 bit float version can accept signals above full sample rate without distorting. Both can output no more than 24 bits. __________________ Georgetown Masters 615 254-3233 Bob's room 615 385-8051 Music Industry 2.0

24th December 2005, 12:35 AM	#7
Lawrence Lives for gear Join Date: Aug 2004 Posts: 638	I feel a long discussion coming.... There are no 32-bit converters. You cannot record a true 32-bits with the hardware available. I'm sure if I'm wrong someone will chime in and correct me on this but... 1. You pass 24-bits to the native daw which makes it 32-bit float in the dsp engine and can, if you choose, write the 32-bit float data to a file to avoid truncation back to 24-bits. SX can do that and I'm sure most other native daws also allow that option. 2. There is really no point in doing that to individual tracks. Everytime you play back your 24-bit tracks through the daw with the same plugs, eq, etc. in place they'll be "first generation" 32-bit float inside the daw. No need to waste the disk space saving the result of that. It's all saved in the daw with the mix settings. It's recreated everytime you hit play. 3. The only benefit I can see using 32-bit float files anytime is maybe rendering (and only rendering, if it leaves the converters or hit any digital I/O pipe it'll be truncated to 24 again) a 32-bit float in-the-box final mix file. What this does is keep the daw from truncating your mix to 24-bits. It is subjectively and theoretically useful if you plan on doing more dsp processes later in a mastering app like Wavelab or Sound Forge (or the same daw) which I think also operate as 32-bit float internally. In this case you won't be applying more dsp to a file that's already been truncated. Some (like me) choose instead to just add 24-bit dither at the mix bus (with no noise shaping) and render 24-bit mix files, with the dither (theoretically & subjectively) minimizing the effect of the truncation from 32-bit float to 24. Most do neither. There's much debate about how many times a file has to be truncated before you actually start to hear it. I think it's probably many, many times in most cases. IMHO recording 32-bit float tracks is a waste of hard disk space Lawrence __________________ The Audio Cave NFL Pool 2008

24th December 2005, 04:25 AM	#14
Lawrence Lives for gear Join Date: Aug 2004 Posts: 638	I'm not a math guy but I imagine turning a 24-bit stream into 32-bit float is nothing compared to the math calculations going on in the daw for typical dsp processes like summing levels, pan, eq, compression, convolution reverb and the like. Those are really cpu intensive operations at times which is indicative of how difficult those math operations are. A Waves Linear Broadband EQ takes about 5-7% of my cpu juice. Much more difficult realtime math going on there than just pushing 48 tracks through the daw. Whatever has to be done is done at the input and it's obviously pretty efficient. I'm not one who can put up a scope to verify but I do believe it's 32-bit float from just after input to just before output. Can I prove it? No. I don't think that the Windows OS being 32-bit has anything to do with it but again, I could be wrong about that. But to say that XP being a 32-bit OS puts a limit on a math operation at 32-bits is saying that math calculations on a PC could never go beyond a depth of 32-bits. I'm talking just math calculations not 48 or 64-bit data paths through a 32-bit system or OS. Entirely different thing I believe. But again, I could be wrong. It's the depth of the math (DSP) calculation (number of available places for precise numbers before rounding begins) not 48 or 64-bits of data traveling in blocks through a 32-bit data path or OS. But... well you know... I could be wrong. Math is not my thing so I'll yield to those who know better. Thanks. I appreciate this conversation and the chance to discuss something interesting. The beauty of audio engineering is that it's not always just about sound, its often about theory and science. This science is WAY over my head. Take care Tony. Good luck to you friend. Lawrence __________________ The Audio Cave NFL Pool 2008

24th December 2005, 12:12 AM	#5
TanTan Lives for gear Join Date: Feb 2005 Location: Israel Posts: 658	Is there any recomandation on an ideal sample rate for 32Bit ? i'm currently working at 88.2Khz is there any connection between sample rate and bit being used or is it the most detailed sound using the highest sample rate and bit your hardware support ?

24th December 2005, 04:41 AM	#15
bobby yarrow Gear addict Join Date: Jan 2005 Posts: 350	32-bit float remains a mystery to me. I track to it, but I don't understand what it even means, as my convertors are (obviously) 24-bit. The resulting audio files, however, are 32-bit float, and can't be read by software that can only read 24-bit. So I have to convert the files back to 24-bit to use certain software. What's mysterious is 1. what happens in the 24-bit to 32-bit fp process, and, 2. what happens when it's converted back to 24 bit.

24th December 2005, 09:19 PM	#18
RainbowStorm Lives for gear Join Date: Aug 2005 Posts: 1,322	Now I know why I experienced a cleaner limit with the L2. Recording in 32-bit float (storing 24-bit conversion as 32-bit float) is recommended because it makes the recorded tracks not clipping because of the extra headroom. That's why it's very important that recording with effect processing is done in 32-bit float. When recording at 24-bit you need to be much more careful with levels and you get clipping in some degree much easier. If you apply effects directly on the files you will lose sound quality as well due to the conversion to 24-bit from 32-bit float. When the input track records the file it will do all the 32-bit float calculation on the effects, but if the selected storing resolution is 24-bit it needs to be converted back to 24-bit before the recorded material is stored on the disk, resulting in quality loss due to quantization errors. As I understood this, the only risk of losing quality when storing with a bit depth of less than 32-bit float is when data is being written to a file, such as when recording and applying effects directly on the files. Besides these advantages with storing the audio in 32-bit float you also lower the CPU load because the data doesn't have to be translated to 32-bit float before it is processed.

19th January 2006, 09:12 AM	#19
Dennis Edlund Gear interested Join Date: Jan 2006 Location: Sweden Posts: 12	CUBASE and probably all other 32bit-float systems are using (+1 to -1) value range. And 32bit float has a linear precision dynamic range by 150dB = log10(2^25)20. And it's all up to the Plugin creator to use 80bit-float or something so the plugin won't affect the dynamic range badly. ProTools TDM uses 48bit between plugs that are on the same TDM bus and DSP, so the transfer between PLUG-INS is 289dB. The weakest point in that system should be the PANNING/FADER/SUMMING MIXER. But if they're all done in the same calculation in the FPU you should have 80bit-float (INTEL x87) and that makes it =log10(2^65)20=391dB. And that 80bit is used in every calculation in the computers FPU, but it can be rounded down to 64 or 32bit float when being outputted. Just to make a comparison with ProTools TDM system the SUM MIXER is at 48bits = 289dB. --------------------------------------------- Best Regards / Dennis from Sweden

19th January 2006, 11:40 PM	#22
Dennis Edlund Gear interested Join Date: Jan 2006 Location: Sweden Posts: 12	The resolution is keept at 48bit when you have a plugin chain that are on the same DSP. But as soon as you leave one DSP the data will be dithered and truncated to 24bit. With the mixer the data are keept at 48bit even if the data are going between DSP's, the data are send in 2x24bit between DSP's. __________________ ------------------------------------- Best Regards / Dennis from Sweden

20th January 2006, 03:17 PM	#23
Boby Stoica Gear maniac Join Date: Dec 2003 Location: Bucharest, Romania Posts: 281	Funny thing - I ALWAYS preffer the sound of my hardware 48bit double precision L2 over the native L2 /pc/CUBASE SX2. I use the hardware one as the last thing on the 2bus chain. Did lots of testing - aplying the L2 on the native environment over a 24bit file, passing a 24 bit file through the hardware unit, both having dither for 16bit (clients preffer to master stuff in-house). I think the 48bit sounds less harsh and has more depth . And I really like using the hardware unit having the 2 channels unlinked, with autorelease on both channels. Different strokes for different folks, ha ? :).

2nd February 2006, 09:39 PM	#24
Almost Human Gear addict Join Date: Jul 2005 Location: Germantown, MD Posts: 402	Interesting topic that I'm just now jumping into...this is what I was told before...what are your thoughts on this: "24-bit integer processing can introduce progressive deterioration, (as will any integer system) whereas 32-bit floating point won't. This is why programs like Adobe Audition can outperform ProTools in its internal processing. It's only called 32-bit because it is 23-bit mantissa + sign bit + 8-bit exponent, which is effectively 24-bit. The reason for working like this (32 bit floating point) is to retain the resolution when audio has any sort of amplitude-related operation carried out on it - which it can do over about a 1500dB range. If Audition worked in 24-bit integer mode, this range would be restricted to about 144dB. Your DAC is operating in 24-bit integer mode because it has to - it's a hardware device. Audition has no such limitation, and is accordingly engineered to take the best advantage possible from it. And there's no such thing as a 'standard' 24-bit file anyway - there are several formats, and everybody uses their own 'standard'. That's why there are translators available. Mind you, I'm not saying that it wouldn't be a good idea to have a proper standard for audio file transfer - but if there was one, nobody would accept the ProTools 24-bit integer one anyway, because it's too limiting. The IEEE 32-bit standard that Audition uses would be a far better bet. There are a few other issues about operating in 32-bit mode, but they're all good things, not bad ones. Probably the most important is that as long as it sounds good, you really don't have to worry about the mixdown level, even if its way undermodded, or even overloaded slightly, because normalising the FP mixdown will restore everything to the correct peak levels without any loss of resolution at all - this is the magic of Floating Point, and that's something that you just can't achieve with a 24-bit integer system. Mind you, if you have an overloaded mix running, it doesn't usually sound too good when you monitor it, because at that stage, the soundcard can't cope with it - this is ultimately why the mixdown needs to be normalised so that the peaks don't exceed 0dBFS, or slightly below. This way, it converts back to integer levels that the card can cope with. Pro Tools claim of 48-bit precision mixing with nearly 300dB of dynamic range implies that this is integer-based, not Floating Point arithmetic. The actual dynamic range this gives is 289dB, which is presumably what they mean by "nearly 300dB." Now, compare this to Audition. 32-bit Floating Point internal processing gives nearly 1500dB of internal dynamic range. The Pro Tools system is inherently dated architecture." What's everyone's thoughts on that?