SOS doesn't like the sound of floating point math?

He may only live with PT. I don't think he knows what he is talking about or what is going on in the box.

Well Bit you may be right but I know that Sonar 7 sounds a lot better then Sonar 3 did when its pushed. Same hardware but different audio engine. For me its a whole new world. Sonar seems able to deal with this issue. BTW its doing this while monitoring to a 24 bit interface. So whether its going to a file or out its always going to be 24 bits.

When Cakewalk moved to a 64Bit Float mix engine, they made "rounding error" such a non-issue... it's not even worth discussing.

If your mix doesn't sound good in Sonar 7, I guarantee that mixing with 24Bit integer resolution won't fix it.

When you use a non-floating point representation, every calculation in the end has to fall on an integral number. So if you divide 10 by 3, the actual value is 3.333333333..... forever. But in an integral system, that has to either become 3 or 4, since there is no in between. So you've either lost a third or gained two thirds. No biggie in a single operation, but over the course of possibly thousands of operations that a particular sample might go through from tracking out to the final resulting mixdown, it can add up.

With a floating point system, the result is 3.33333..... out to the number of possible fractional digits within the 32 or 64 bit floating point representation (38 I think for 32 and 308 for 64 bit.) So the rounding error is incredibly small for a 64 bit floating point system, and pretty darned small for a 32 bit one.

It is way more accurate, definitely. And I agree that I'm not sure how the author came to that conclusion necessarily.

But if you have 308 decimal digits to work with, the fact that certain numbers cannot be represented doesn't have quit as much of an effect. Probably many such calculations would introduce less of a problem than a single integral division would, right? The difference between the exact integer and the repeated fractional representation would be in the last fractional digit, which would be a tiny deviation in a 64 bit floating point value. How many of those would it take to make a difference of 1/3 or 2/3 that a single integral division of the above type would cause? So if you can't actually store 0.1, but you can store 0.999999999999999999999999999999999999999999999999999999999 (for instance), how many additions of such a number would it take to drift as much as that single integral division? The deviation is only 0.000000000000000000000000000000000000000000000000000000001 in that case.

And the converter is just one of the operations each sample goes through. It would be overwhelmed probably by the downstream manipulations during processing, I would think. So the fact that the conversion is integral wouldn't seem to me to be much of a factor, unless you never did any processing of the recorded smples.

THat must have taken a ton of time. Wow.

In reply to mike_mccue. Mike I'm not going to quote all that!

With the subtraction you are probably correct for the rest probably not. Reason is that your decimal representation is an approximation of the binary floating point value and already involves some rounding just to display it. So add them together and the last digit may flop around a little because your now rounding the sum of bits subject to individual rounding before. Ditto the multiplication.

re: "already involves some rounding just to display it."

I'm failing to see how

32 bit fixed:

00000000000000000000000000000003.

or

00000000000000000000000000000004.

is any more or less arbitrary than this

32 bit float

3.3333333333333333333333333333333

in either case the intial sample value is arbitrary and rounded at it's last digit.

I'm non plussed by the interface conversion... that's seems to me to be symptomatic of contemporary technology.

But I would enjoy seeing some specific examples where you could see how points along the stream are effected by some basic audio operations. I'd like to see Dean's theory (which my farmer logic is sympathetic too) played out to see how the rounding plays out in a head to head comparison.

Other than that I'm pretty much sold on SONAR's 64bit engine... I just figure there's always something to learn... even if it's just another perspective rather than a collection of facts.

Does anyone know of a comparative analysis rather than an anecdote?



best regards,
mike

OK, with regards to my last post I see now that it only applies to the A/D.

On the D/A the Integer is theoretically complete where obviously the float point has to finally round.

best,
mike

If I have 8 tracks going to 8 D/A converters then it is happening 8 times. If I mix those down to stereo on a bus the number of times it happens will be a design decision on the part of the developers. It might still be 8. This could account for some of the reported differences in behaviour in the original SOS piece.

It's still trivial. You have 16 million possible amplitude levels to use when tracking at 24 bits. It's just not an issue. The quantization of the amplitude levels is microsopically small. It will make no effective difference at all. If there are, say, 120dB of possible range, so that would come out to something like 133K values per dB. People can't even hear a tenth of a dB, much less a hundred thousandth of a dB.

Once on disk, then it comes into the summing engine and is converted to a float and passed through the engine and finally converted back on the way out. For playback during maxiing, it's just going to go back to a 24 bit value, so again the rounding in the final conversion back will be very small. So the 'display' here has plenty of bits. For the final 16 bit mixdown, it will be worse, but it would be worse for a 24/48 bit fixed point as well, since in either case you are having to down-convert.

So just can't see how a fixed point engine is ever going to be as accurate as a floating point engine, even including the possible conversions to/from fixed point that might have to occur.

People can't even hear a tenth of a dB, much less a hundred thousandth of a dB.

Agree 100% there Which is why real comparative analysis is likely to be thin on the ground.

In terms of the accuracy of fixed -v- floating point... both have their place. Packed decimal works really well in financial environments. I can appreciate your arguments, I can also imagine situations where poor engineering decisions could result very bad floating point performance. You are assuming good engineering decisions in all cases. It might also be possible for choice of audio bit-depth and sampling rates in a project to also muddy the waters here.

Certainly floating point math in a computer can be tricky and there are lots of gotchas to avoid, most in guiding a planetary probe probably than in a DAW, but still plenty of things to worry about.

the part that befuddles me is the idea that 3.3333333 may be a less accurate representation

Yeh, that's a difficult concept to grasp and seems counter-intuitive. In fact in the real world, decimals do make for a more accurate representation.

But we're talking about the binary world of a computer, not the real world. It is not possible to accurately emulate real numbers in a computer because of the fixed number of bits we have to store them in. It's a quirk of the way floating-point numbers are stored digitally, wherein floating-point numbers offer a very wide range of possible values at the expense of precision.

Consider that we're limited to the same 31 bits as an integer value (1 bit is the sign bit, so we really have only 31 bits to play with), and yet the float can represent a much larger number than the same 31-bit integer. How is this possible? It's because floats sacrifice accuracy for range. It's a fundamental flaw in the way computers do arithmetic.

As a float's value increases, we need to use more of those 31 bits to represent the whole number portion, and have fewer bits left over for the fractional part. Usually, we can live with that because the fractional part becomes less and less important as the whole number part gets bigger. But if we make a big number small again as a result of some mathematical operation (e.g. lowering levels with a fader) we don't get those lost bits back and we're stuck with the lost accuracy.

Every time you go over 0db, you lose one bit of resolution, even if its only +0.01db over. And if you go over in more than one stage of the mixing/processing (e.g. the track is > 0db, then the sum on a bus goes > 0db, and the master bus is > 0db), the loss is cumulative.

That's why you want to avoid going over 0db, even though it's permissible in a floating-point system. Of course in an integer system like PT HD, it is simply not possible to exceed 0db - you just get a nasty-sounding digital over. This is why I always say that the main advantage of 32-bit float is that it's tolerant of sloppiness and forgiving to beginners. It really offers no other advantage over PT's 48-bit integer system.

When you jump up to 64 bits, this phenomenon can be ignored because the consequence of losing a bit is way too trivial to worry about.

Well, a lot of this falls into the category of angels dancing on the head of a pin. In discussions about the minutia of digital audio processing, you rarely hear anybody ask "yes, but can you actually hear that?".

But like somebody pointed out in my dither-don't-matter thread, you still take these things into consideration even though they're trivial concerns individually, because the quality of the end product is the sum of many little things, not any one big thing you did. Just like you take care when performing each and every part of a song, despite knowing that it might end up ultimately buried in the mix.

The takeaway from this conversation, I think, is simple: leave yourself plenty of headroom at every step of the way.