Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[cgc]

Nika Aldrich wrote on Fri, 28 January 2005 11:33

So do this question for me:  multiply two 25 bit numbers - lets say the binary equivalent of the first several digits of pi times itself (pick an exponent in the middle of the range).  Each is a 32 bit floating point number.  How are you going to figure out the answer without, at some point, rounding, truncating, or attempting to dither the result?

You get a 25 bit result and if that's enough precision for you then you use it, but if not you go up to a data type with more bits (PI is probably not a good value for this example since there is no exact value).  I don't really understand your point because we are dealing with fixed resolution systems.  You can't just add bits because you reach saturation because the system won't allow it.  You can add bits if you need more numbers at the end though.  Your point about rounding or truncation is very valid, but whether or not that is acceptable really depends on the results you require.  There are tradeoffs in all of these systems and it is good to illustrate them and make people aware of their effects ( denormals, indeterminate and overflows are worth pointing out as well).   In my experience 32 bit float systems tend to provide adequate results for my uses.  

The main point I'm making is that these system, no matter what the bit depth, have the same 0...N range when related to the outside world.  Adding bits allows for more values inside that range but never for N+1.  

Also, IEEE 754 defines single precision floats as 1 sign bit 23 precision bits and 8 mantissa bits.  

http://stevehollasch.com/cgindex/coding/ieeefloat.html
http://www.psc.edu/general/software/packages/ieee/ieee.html
http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.ht ml

I usually just assume everyone talking about PC and Mac software is going to equate float and double to this standard, but there are some DSPs that don't use it.  Sorry for any confusion caused by not stating this upfront.

[Nika Aldrich]

cgc wrote on Fri, 28 January 2005 13:11

Nika Aldrich wrote on Fri, 28 January 2005 11:33 So do this question for me:  multiply two 25 bit numbers - lets say the binary equivalent of the first several digits of pi times itself (pick an exponent in the middle of the range).  Each is a 32 bit floating point number.  How are you going to figure out the answer without, at some point, rounding, truncating, or attempting to dither the result? You get a 25 bit result and if that's enough precision for you then you use it, but if not you go up to a data type with more bits (PI is probably not a good value for this example since there is no exact value).  I don't really understand your point because we are dealing with fixed resolution systems.  You can't just add bits because you reach saturation because the system won't allow it.  You can add bits if you need more numbers at the end though.  Your point about rounding or truncation is very valid, but whether or not that is acceptable really depends on the results you require.  There are tradeoffs in all of these systems and it is good to illustrate them and make people aware of their effects ( denormals, indeterminate and overflows are worth pointing out as well).   In my experience 32 bit float systems tend to provide adequate results for my uses.

My point is as follows:

This is a discussion about the sound quality of various DAWs, and in this discussion we are talking about the use - or absence of use of dither as a contributing factor.  I mentioned that some algorithms don't dither or truncate their results probperly.  I also said that there are vast numbers of times in these algorithms where word-length reduction gets done.  You stated, at one point,

Quote:

You seem to be saying that every plugin does word length reduction, but I don't think that's the case with any of them that aren't designed as a 'mastering' plugin and specifically have options for redcution and dither. PT LE is 32 bit floats after the soundfile is read until final output (file or device driver), and the more recent TDM systems use 48 bits internally. There should not be dither between plugins because they aren't truncating word lengths (or they really will screw up your audio badly).

What I have shown you is that wordlength is indeed reduced after EVERY mathematical process.  The long version of your 32 bit math problem I gave you shows you that you created up to a 59 bit result.  Somehow you turned that into a 32 bit result, and this process created error.  You could have turned it into a 32 bit result because you simply didn't allow enough bits in the accumulator and the bottom ones were "dropped" or "truncated" at that process.  You could have turned it into 32 bits after the accumulator.  One way or another, though, after ANY math problem inside these floating point systems you are doing bit-depth reduction.  The way in which that is done can affect the sound quality of these DAWs.  Same holds true with fixed point systems - the way in which that bit depth reduction is done - when it is done - affects the sound quality of DAWs.

Quote:

Also, IEEE 754 defines single precision floats as 1 sign bit 23 precision bits and 8 mantissa bits.

The mantissa is the precision part.  The other part is the exponent.  32 bit floating point in the IEEE 754 format allows for 25 bits in the mantissa and 8 bits in the exponent.  The first number in the mantissa, however, is always a "1," right?  Because if the first number was a "0" we would just change the exponent until the first bit of the mantissa was a 1.  For this reason, the first bit of every floating point mantissa is a "1" and with that in mind, we can drop it.  We don't need it.  We can "imply" its existence without stating it.  The mantissa, therefore, starts with the sign bit and then the remaining bits are essentially 3 through 25.  Make sense?

Nika

[cgc]

Nika Aldrich wrote on Fri, 28 January 2005 12:35

What I have shown you is that wordlength is indeed reduced after EVERY mathematical process.  The long version of your 32 bit math problem I gave you shows you that you created up to a 59 bit result.  Somehow you turned that into a 32 bit result, and this process created error.  You could have turned it into a 32 bit result because you simply didn't allow enough bits in the accumulator and the bottom ones were "dropped" or "truncated" at that process.  You could have turned it into 32 bits after the accumulator.  One way or another, though, after ANY math problem inside these floating point systems you are doing bit-depth reduction.  The way in which that is done can affect the sound quality of these DAWs.  Same holds true with fixed point systems - the way in which that bit depth reduction is done - when it is done - affects the sound quality of DAWs.

Ok, I think we are saying the exact same thing - the precision is finite.  That is an advantage with audio since signals can have the same resolution even at very different amplitudes.

Now the part about 'error' is a bit tricky.  If I decide that 32 bits provides enough numbers for my application then I live with those results.  If the application requires more numbers than that, double precision is a better choice.  Throwing in 64 bit accumulators just to drop immediately back down to 32 usually won't do much to the final result.  An entire chain of double precision math would potentially make more of a difference.

I don't know how much dither is really going to resolve the absolutely huge amount of difference in precision between floats and doubles.  Also, how one would implement it because the number of bits dithered would change depending on the magnitude of the signal.  Numbers approaching full scale would presumably have the bottom few bits dithered while those approaching 0 would have almost all of their bits dithered right?  I don't think I've ever seen a plugin or application really do that.  I am curious about the implementation and results though.

Quote:

32 bit floating point in the IEEE 754 format allows for 25 bits in the mantissa and 8 bits in the exponent. The first number in the mantissa, however, is always a "1," right? Because if the first number was a "0" we would just change the exponent until the first bit of the mantissa was a 1. For this reason, the first bit of every floating point mantissa is a "1" and with that in mind, we can drop it. We don't need it. We can "imply" its existence without stating it. The mantissa, therefore, starts with the sign bit and then the remaining bits are essentially 3 through 25. Make sense?

Yes, this makes sense, but I have rarely seen someone state 25/33 bits instead of 24/32.  The common computer science terminology looks exactly like those pages I linked to, and I don't have the actual IEEE spec because I've never paid for it.  Thanks for the info.

[Nika Aldrich]

cgc wrote on Fri, 28 January 2005 16:04

Ok, I think we are saying the exact same thing - the precision is finite.  That is an advantage with audio since signals can have the same resolution even at very different amplitudes.

Actually, no.  I mean, yes, it has the same statistical resolution at all samples, but this means that the quantization error oscillates (modulates) with the amplitude of the signal, and this creates distortion.  In other words, the precision is not actually finite because the error in the overall result is not-finite.  It changes with the changing amplitude of your input signal.  This makes it, actually, not an advantage in audio systems.  The notion that your precision is constant and that the accuracy floats is actually of no benefit in audio systems.  It does have certain benefits in processing - there are places in processing where it would be nice to do the math where the coefficients can float respectively, but to actually store and work with the signal itself as 32 bit floating point like this actually offers no benefit - it is actually a detriment with respect to the error that the system imparts.

Quote:

Now the part about 'error' is a bit tricky.  If I decide that 32 bits provides enough numbers for my application then I live with those results.

In a properly dithered fixed point system the error is kept at a constant level and the  error is maintained as random.  This ensures that the quantization error after either the initial sampling stage or any processing stages is kept as white noise at a constant level.

In non-properly dithered fixed point systems the error is kept at a constant level but the error is not random - it is correlated with the signal.  This causes the quantization error to manifest itself as distortion instead of noise.

In floating point systems of any form ("dithered" or not) the error changes as the signal changes and therefore is not at a constant level and is also not random (despite the attempts to dither it).  This causes the quantization error to manifest itself as distortion instead of noise.

This characteristic of floating point systems can DEFINITELY affect the sound quality of those systems.

Quote:

I don't know how much dither is really going to resolve the absolutely huge amount of difference in precision between floats and doubles.

None.  It is impossible (as I stated above) to adequately dither a floating point signal, because the dither amplitude or its precision would have to change along with the change in amplitude of the waveform, so the signal can never be totally decoupled from the dither added to it.  Therefore, the dither is not random and therefore is not adequate to prevent distortion.  Fixed point does not suffer from this problem, so no amount of dither can solve this problem in floating point systems.

Quote:

Also, how one would implement it because the number of bits dithered would change depending on the magnitude of the signal.  Numbers approaching full scale would presumably have the bottom few bits dithered while those approaching 0 would have almost all of their bits dithered right?

Precisely!  Though I don't like to refer to "dithering bits."  In theory, all bits always get "dithered" according to this nomenclature.  The appropriate terminology would be "dither noise of x amplitude is added."  For a signal approaching full scale indeed the dither noise would get added at a very low amplitude with respect to the precision bits.  For a signal closer to zero indeed the amplitude of the dither noise would exceed the amplitude of the signal.

Nika

[Loco]

Nika Aldrich wrote on Fri, 28 January 2005 17:52

In a properly dithered fixed point system the error is kept at a constant level and the  error is maintained as random.  This ensures that the quantization error after either the initial sampling stage or any processing stages is kept as white noise at a constant level. In non-properly dithered fixed point systems the error is kept at a constant level but the error is not random - it is correlated with the signal.  This causes the quantization error to manifest itself as distortion instead of noise. In floating point systems of any form ("dithered" or not) the error changes as the signal changes and therefore is not at a constant level and is also not random (despite the attempts to dither it).  This causes the quantization error to manifest itself as distortion instead of noise.

It's gonna be less distorted than the air circulating between the speaker's grille and your ear wax. Having said that, the grille and the wax generate more distortion than the air. Any distortion generated by the error on a 32 bit folating point system can't be heard. Dither on a floating point can be easily heard... so much that there are different types of dither being marketed for you to hear and use.

Of course, if you can't hear it, then it's not for you.

[Giovanni Speranza]

Considered that:
audio distortion, hiss, dither and other "artifacts" are not supposed to make the sound be worse. Do you remember tape and valves?

IMHO, given the cons of both approaches (32float vs. 24 fixed), i prefere the 32float. Maybe simply because comparing Alsihad and a 32 bit DAW i prefere hands on the 32 bit DAW over Alsihad.

And, apart the 2 methods differences, we should consider the mixing architecture. Some DAWs submix 10 cannels at a time and then sum the submixes.
Other do weird things. And again, let's use our ears to choose which architecture sounds better. Each tape brand has a different sound, and each DAW architecture too.

[David Schober]

Joe Speranza wrote on Mon, 07 February 2005 04:12

And again, let's use our ears to choose which architecture sounds better.

But you've also said;

Joe Speranza wrote on Wed, 02 February 2005 05:13

It's time to STOP saying: "use your ears". It's a big lie.

I'm not trying to be too critical....The earlier quote had stuck with me so this morning's quote seeemed a little ironic.

The earlier quote had another sentence I didn't follow.  Can you further explain it?

You also said:

"We can use our ears only once we have the full sound enginering history in our head."

See ya,

[Giovanni Speranza]

You can't extrapolate a sentence like some gurus do with the Bible.

When i say "use your ears" i mean use your very conscious and experienced ears.

And when i say "stop saying: use your ears" i mean that when one asks how to do something, the most idiot answer is "use your ears", because it's not enough.
No one is making a good mix "just using his ears". He must use his ears, but his ears must have a "culture" and a "know how" and a "tricks and tips encyclopedia" inside.