would like more info…
I was reading a string about 16 bit vs. 24 bit. And in that string someone mentioned saving files to 32 bit. Is it possible to record in 32 bit to start with? If 24 bit gives you more headroom than 16 bit, I could only imagine what 32 bit would give you.
Volley 
Theoretically, you could… we just need some one to actually make hardware with 32 bit convertors on them. So practically speaking… no as such hardware does not exist.
It is technically very difficult to build high bit-depth converters. Even most 24-bit converters do not actually give full accuracy in the least-significant bits. Many are only good to 20 bits or so. 32 bit converters would be very difficult since every additional bit requires twice the accuracy (for all bits) to be meaningful.
Jim
That’s true jimbob. Just wait though… as soon as Digi comes out with ProTools ‘SUPER X-32’… they’ll sell a gazillion of 'em.
“So close to analog you can hear the tape hiss!”
"Now includes Wow and Flutter 2.0b RTAS plugin free of charge!"
I’m happy at 24 bits thank you. I am stone-cold certain I cannot HEAR all that my current gear is capable of reproducing.
TG
So, what is “floating” 32 bit?
Mind that the usual 32-bit format is a floating point construct, not an integral value like 24bit format.
The actual resolution of 32bit float is just the same as 24bit.
The difference is that it has 24bit resolution at any level.
You still get 24 bits worth of detail, even if the signal is way below 0dB.
And you don’t get clipped samples if you go over.
A AD-converter actually doing this for you is not very likely imho but the feature is very important when you perform lots of computations on the samples.
That’s why audio processing programs always use some floating point format internally.
| Quote (jsmyers24151 @ April 03 2006,14:29) |
| So, what is “floating” 32 bit? |
Remember way back when in algebra class where you could express 100000 either as 100000 or 10^5? That is essentially what floating point is all about. So instead of the math being done as 100000 + 100000, it is much quicker for the processor to add 10^5 + 10^5. That is amazingly painfully over simplified… the point is, the processor can look at only significant digits and ignore little crappy trailing zeros and other irrelavant overhead. The processor can look at 6.8723646872364^18 rather than 6872364687236400000. A fixed bit depth like 24 looks at a full 24 bit number for every sample which is very accurate. 32 bit float is not as accurate technically as say 32 bit fixed, but it is has so many more digits, the little 10 trillionths of a db you lose due to rounding is not signficant at all. (Did I say that right?)
a document explaining 24 bits / 96 KHz advantages :
2496-en.pdf
| Quote (Bubbagump @ April 03 2006,15:43) | ||
Remember way back when in algebra class where you could express 100000 either as 100000 or 10^5? That is essentially what floating point is all about. So instead of the math being done as 100000 + 100000, it is much quicker for the processor to add 10^5 + 10^5. That is amazingly painfully over simplified… the point is, the processor can look at only significant digits and ignore little crappy trailing zeros and other irrelavant overhead. The processor can look at 6.8723646872364^18 rather than 6872364687236400000. A fixed bit depth like 24 looks at a full 24 bit number for every sample which is very accurate. 32 bit float is not as accurate technically as say 32 bit fixed, but it is has so many more digits, the little 10 trillionths of a db you lose due to rounding is not signficant at all. (Did I say that right?) |
Actually, bubba, we don’t do it because it’s easier or faster for the computer – it isn’t. Integer math (fixed point arithmetic) is way, way faster than floating point operations. Rather, we use floating point when we need a wider range, or for the convenience of having fractions without using an “implied radix point”. Having written code using implied radix points, trust me it’s not easy – not theoretically difficult, just very tedious. (My code ran on a car’s engine control processor and controlled spark timing and fuel injection.)
You’re right that 32-bit float doesn’t have the resolution that 32-bit fixed does. With floating point, you trade off some resolution in exchange for range (either to much, much higher numbers, or much much smaller numbers – but each number has fewer significant digits of accuracy).
32-bit float has 24 bits of accuracy and 8 bits of exponent, with one exponent value reserved for “NaN” – “Not a Number”, used to represent plus or minus infinity and other strange things.
So, 32-bit float is everything 24-bit fixed is, and more. But there’s no point recording to it, for the reasons pointed out above: it would be REALLY hard, and it wouldn’t sound any better anyway.
It is interesting to note that 32-bit float does not clip. It’s considered an “over” when the signal goes over the value 1.0 (0 dBFS). But you don’t lose any signal quality simply by going over. However, if you feed that signal directly to a soundcard, it WILL clip – so avoid it or you’ll be making judgements based on listening to a clipping signal. Also, avoid feeding it to a plugin, because some (not all) plugins are optimized to get the best results in the normal audio range (0dBFS to -90dBFS or so), and you might be degrading the results.
You can actually clip 32-bit float, but not until you get to around 700 dBFS, which is roughly the volume of an atom bomb I suspect. You’d have to try really, really hard.
<!–QuoteBegin>
| Quote |
| Actually, bubba, we don’t do it because it’s easier or faster for the computer – it isn’t. Integer math (fixed point arithmetic) is way, way faster than floating point operations. Rather, we use floating point when we need a wider range, or for the convenience of having fractions without using an “implied radix point”. |
Duh, that’s why fixed point is used in every little DSP out there, right? I am thinking froma human readable standpoint and what you say from a CPU standpoint makes sense to me.
Thanks guys! Good stuff, here. Keep it coming.
Cool Edit Pro 2 does 32-bit float. So when I process in Cool Edit using a plug-in from n-Track, aren’t I feeding that plug-in a signal at 32-bit? Or is the 32-bit math an operation that happens after the plug-in does the process, and Cool Edit re-reads it for display and playback?
EDIT: The wav file I’m using is at 24-bit (for instance) if it’s not getting dealt with by the 32-bit thing. Right?
All processing is 32 bits and is some cases 64 bits. The 32 bit 24 bit format stuff being discussed here is how the data is stored in the wave file.
Ooohhhhhh… okay.