John Stafford wrote: Reducing the gain in the digital domain is the same as reducing the precision, and when you are summing several samples, it's very unlikely that whatever comes out at the other end will not have some unwanted side-effects after rounding the numbers up or down. You have to throw away some of the information.

I do not agree with this John. When an int is cast into a float, the accuracy of any math including gain changes becomes enormous, way above any artifacts of manipulation, there is no loss of precision. You could master a CD at 4000dB FS and its just as accurate as -.2dB FS. This is the WHOLE POINT of converting all audio sample amplitudes to floats BEFORE any calcs. You never lose precision UNTIL the final dither and resample back to a 16bit int. Then it doesn't make any sonically significant difference anyway.

Hi,
there seems to be a lot of interesting discussions going on here. But I think most of it misses the point.

There is a well known marketing story about Rolex watches. A lot of the owners can quote various things about how very good the movement inside the case is. And yet, just about none of them has ever seen one of the movements. And even less seen a few different brands to compare with. (Mind you, I´m not saying anything about the quality of the product, I´m talking about the owners).

And here we are, with a lot of talk about how IEEE 32 bit flots do truncation and so on. This is very much off the point if you ask me. The main point is how the fundamental operations are really used. And how they are combined with other stuff that is not that fundamental. But we will never really get to look inside that watch case. We can speculate any amount about how things are done inside the DAW, but the truth is that very few here on this forum really knows.

So could we please go back to the real issue, do they sound different? And how can we find out using a black-box approach, that is not looking inside the case?

Gunnar

Just to put a few things into perspective. I am sure that Tenor2b who is very forthright in showing his credentials is not the only person on this forum with a bit of background in number theory. I for myself once was part of the team doing the operating system and compiler support for a few nuclear power plants. This was early 80-s and we did it all in assembly language, and did roll our own IEEE floating point routines as they were not supported by the Motorola 68000 at that time. Some things may have changed since, shure, but I think the basic things remain the same.

John Stafford wrote:
Reducing the gain in the digital domain is the same as reducing the precision, and when you are summing several samples, it's very unlikely that whatever comes out at the other end will not have some unwanted side-effects after rounding the numbers up or down. You have to throw away some of the information.

You could also simply reduce the 'gain' to turn a 24-bit sample to 16-bit, and then chop of the unwanted 0s, but most would argue that other ways to do it that sound a lot better.

John

Well, John, that is true when you work in fixed precision. But it is not necessarily true in working on floating point. For example decreseaing the gain by any factor of two can be done by only changing the exponent and will not loose any precision whatsoever. Not necessarily that this is how it is done though.

A working tool working with digital audio is to translate the number of bits into a S/N ratio. (That is, how far away from the Signal does the Noise floor is). I´ve forgotten most of the math, it was on the very top of my once level, but the results are rather simply to use. Making it very simplified, each bit represents about 6dB of S/N. So given 16 bits we get about 96dB SN and 24 bits give about 144db SN. Now this last number is a bit obscene when you compare it to real world AD-s and DA-s used in audio equipment. And especially if you actually measure it including the analog part of the circuitry. (Look up your favourite audio card and read the specs).

So if we take a 24 bit signal, remember something less than 144dB S/N, and divide it by, say 16 which is a gain reduction, we end up with 20 bits of precision or about 120dB of SN.

On the other hand if we do this on a floating point number, we loose no SN, we actually loose no precision at all in the idealized case. In real world we will get a rounding error at the last bit.

This is all a bit counter-intuitive first time you go around it. I know, I´ve been there doing all the math although it was a long time ago.

But all of this only points to the fact that the programmer doing the work has to know his tools. Use the tools incorrectly and you end up with a mess.

As far as summing goes, the difference in algorithms will probably not start showing up until you start adding quite a lot of channels.

The really big difference between different DAW-s though, seems to be other stuff. Such as how effects are implemented, all from pan laws to EQ-s to compressors. It takes a lot "carefullness" to not stumble on things.

Sorry, in bed with a flue, rambling on.

Gunnar

This thread came about, because of the ridiculous "this DAW" sounds better than "that DAW", without explanation, adding to the deluge of anecdotes which clog and pollute this industry. It helps no-one, especially for a topic that is deterministic and should be anecdote-proof.

I was trying to add some plain facts to the story, but as usual these threads get hijacked off to irrelevant tangents with red herrings by rude careless people who do not read or get the point of the thread, and who also can't express themselves.

I will publish the results of Jeremy's and my tests on mixing a couple of hi-res files for your edification and enjoyment when we finish.

DavidSpearritt wrote: This thread came about, because of the ridiculous "this DAW" sounds better than "that DAW", without explanation, adding to the deluge of anecdotes which clog and pollute this industry. It helps no-one, especially for a topic that is deterministic and should be anecdote-proof.

Wooooah there, big fella. It's simply a converation among folks of higher-than-average intelligence on this particular forum. No need to get your britches in a bunch if you don't agree with everything said here. It's not a white paper; just an idea swap at best.

From my own experience, I simply stated that I've heard such sentiments about Samp/Sequoia, and while I don't choose (or know enough) to get into it with any specifics, I'm happy to enjoy the reputation of the product I use as an added bonus. Call it "Blind Faith" if you want to, I really don't mind WHAT folks think of my choices, and you're certinaly free to prove/disprove all you like.

(And, it's no more ridiculous than dicsussing favorite microphone choices, or Pre-amps mainly based on intangibles. )

I was trying to add some plain facts to the story, but as usual these threads get hijacked off to irrelevant tangents with red herrings by rude careless people who do not read or get the point of the thread, and who also can't express themselves.

Harsh words for our fellow posters HERE, of all places, wouldn't you say? Rude and careless hardly describes this particular thread, either, unless I missed something. I've seen far far worse on some other forums, and "hijacking" (going off on a tangent, I assume you mean) is often part of the game with online back-and-forths between free thinking, intelligent people. Just because they're not saying what YOU want to hear doesn't invalidate their point of view, nor are you the only one allowed to have an opinion.

What a shame we're now debating the METHODS of discussing the question at hand, instead of the question itself.

I will publish the results of Jeremy's and my tests on mixing a couple of hi-res files for your edification and enjoyment when we finish.

Great! I will try to contain my enthusiasm until such time that you enlighten us all... 8) 8-)

JoeH, I was not referring to most of the posts on this thread only one in particular. And I am certainly not against people disagreeing with me as other topics show.

But it is frustrating when things go off the topic as they have done here, its boring, thats all.

I love people to disagree, but it has to be done politely and with relevance.

David
I think there may be some wires crossed here, but from your last post I realise I'm in total agreement with you.

Yes, of course you have to change to 32-bit floats (or some other format) BEFORE you do your calculations, otherwise you'll end up with nonsense. I never disagreed with this. That was the point of my first post about the impossibility of adding up numbers with the same bit-depth and expressing the result in a similar format. Imagine dealing with 48 fader movements otherwise! Of course you never lose precision until the very end. Nevertheless rounding errors are inevitable at this stage, although they may be tiny, given how big a 24-bit integer can be.

Gunnar
Yes I agree with you competely. Again, I have never disagreed about what happens in the high precision 32-bit stage where, of course, you don't have fixed precision. Again my point was that the rounding error at the last bit that you mention is inevitable when you go back to fixed precision. I think we're all agreed on this? When I mentioned reducing gain to make a number fit into a particular format I was talking about the very end when you are converting to a number with fixed precision, in which case you are throwing away some precision. Of course this is not the case when you are dealing with floating point numbers.

Can we agree to differ on how important this rounding just might be?

John

PS Gunnar, given that watches and clocks are my main hobby, I'm so glad to hear what you said about Rolex owners! I've never had a watch or clock that I didn't take apart, and a Rolex is probably the last watch I'd ever buy. I don't have the same taste as a drug dealer. One thing I love about serious watches is that they're made for people who aren't insecure enough to need status symbols -but you'd buy a hell of a lot of vintage Neumanns for the price of one!

Hope the flu gets better!

DavidSpearritt wrote: I do not agree with this John. When an int is cast into a float, the accuracy of any math including gain changes becomes enormous, way above any artifacts of manipulation, there is no loss of precision. You could master a CD at 4000dB FS and its just as accurate as -.2dB FS. This is the WHOLE POINT of converting all audio sample amplitudes to floats BEFORE any calcs. You never lose precision UNTIL the final dither and resample back to a 16bit int. Then it doesn't make any sonically significant difference anyway.

Hmm. Not so sure I'm buying this. Sure, when you convert from Int to Float you maintain all accuracy, but as soon as a single process is completed in the floating point domain and the resultant data has to be bit-adjusted to come out of the accumulator you lose "precision." You may not lose much precision at a single sample from a single process, but the accumulated error from multiple samples builds up. Because there is no way to properly bit-reduce a floating point signal the errors (and then accumulated errors) build up undesireably.

The advantage to fixed point is that there is a method by which one can maintain infinite dynamic range throughout the processing of the data (though most of this dynamic range exists below the noise floor). Fixed point systems (Integer) continue to reflect the values of all bits - to an infinite precision - even when only maintained as 24 bit values, though again much of this precision is granted below a noise floor that gets added. Floating point systems cannot do this. While they try to constantly maintain 25 bits of precision (in 32 bit float) anything that happened below the 25th bit is lost. Sure, there is a constant 25 bits of instantaneous precision at any individual sample value, but the aggregate precision is much lower than that of fixed point systems. We humans hear more in terms of a windowed FFT analysis, wherein we analyze long stretches of audio at one time, so the instantaneous precision is not as important to us as the aggregate precision.

I hope I'm not jumping into a problem here?

Nika

Nika wrote: Hmm. Not so sure I'm buying this. Sure, when you convert from Int to Float you maintain all accuracy, but as soon as a single process is completed in the floating point domain and the resultant data has to be bit-adjusted to come out of the accumulator you lose "precision."

Hi Nika. This was never in dispute, if you are referring to the compromise of dithering of a 32 bit final WAV after all mastering and processing in the DAW back to 24 or 16bits for the CD/DVD.

Right at the end and only at the end is this compromise made.

I was arguing that all DAWS should sound the same, they have the same influence on the calcs. Dither plugs are a different matter.

The 32float has maintained precision to well beyond 24bit ampitude steps all the way. The last conversion back and the quality of it depends on the dither and resample plugins used.

You may not lose much precision at a single sample from a single process, but the accumulated error from multiple samples builds up. Because there is no way to properly bit-reduce a floating point signal the errors (and then accumulated errors) build up undesireably.

Don't you mean multiple "calcs" not "samples". When are you saying this occurs within a DAW mastering process?

While they try to constantly maintain 25 bits of precision (in 32 bit float) anything that happened below the 25th bit is lost.

Surely this occurs only at dither time, right at the end.

Sure, there is a constant 25 bits of instantaneous precision at any individual sample value, but the aggregate precision is much lower than that of fixed point systems. We humans hear more in terms of a windowed FFT analysis, wherein we analyze long stretches of audio at one time, so the instantaneous precision is not as important to us as the aggregate precision.

By aggregate precision, do you mean aggregate error of calcs?

I hope I'm not jumping into a problem here?

Please jump in, its good to have a well mannered informed response to think about.

Wavelabs author explains FP in simple terms ....

Integer numbers have a fixed finite range: eg. a 16-bit integer can represent 65535 different discrete values. These integer number have the disadvantage that as the number they try and represent get smaller, the number of bits that the number uses to represent itself, falls. Therefore the SIGNIFICANT ERROR in representing a small analog sample increases as the number gets smaller as the number can only be 1, 2, 3.... n.

On the other hand, the "32 bit float" system uses an exponential representation of numbers. This means, numbers can be represented with a precision that is related to their "size". It's like a percentage: let's say a number can be represented with a precision of 1% (just to simplify). As such, this precision allows us to represent values such as 1.00, 1.01, 1.02, ... and at another level, 100, 101, 102, etc. In other words, floating-point numbers differ from integer numbers in that they can scale themselves internally to be able to represent very big and very small numbers without losing significant detail.

The 32 bit floating point representation is useful for audio, because our ear work in the same way, with an exponential sensitivity. Eg. you need to change the linear level (imagine a waveform) from 20 to 40 to feel the same loudness increment than a change from 10 to 20. In other terms, a change from 1.00 to 1.01 is as much "hear-able" than a change from 100 to 101.

This is why the decibel (dB) scale has been invented: a linear scale to hide the exponential nature of the loudness, which is not easy to grasp for the mind.

With the 32 bit floating point representation, WaveLab has more than sufficient accuracy to represent the finest detail BUT still have a massive head room (someone once calculated 1500 dB headroom - but I think that gives false impression)

DavidSpearritt wrote: [quote=Nika]Hmm. Not so sure I'm buying this. Sure, when you convert from Int to Float you maintain all accuracy, but as soon as a single process is completed in the floating point domain and the resultant data has to be bit-adjusted to come out of the accumulator you lose "precision."

Hi Nika. This was never in dispute, if you are referring to the compromise of dithering of a 32 bit final WAV after all mastering and processing in the DAW back to 24 or 16bits for the CD/DVD.

Right at the end and only at the end is this compromise made.

Actually, right at the end is the only time there is any hope of maintaining the precision. At every intermediate process in a floating point system the accuracy is sacrificed as the result has to be reduced to fit within the confines of the allowable space of the mantissa. Preferrably there would be some sort of dither that could be added during this process, but dither cannot be properly added in a floating point environment. The result is that any precision that would occur after the 25th bit is lost and an artificial distortion is created as a result.

I was arguing that all DAWS should sound the same, they have the same influence on the calcs.

Hmm. There are so many choices about how one generates coefficients, dither, etc. that unfortunately they may not sound the same (of course, aside from such issues as pan-law, where deliberate choices make differences that are separate from quality differences). Yes, ideally they SHOULD all sound the same, and depending on the process they MIGHT sound the same. I can easily see, however, how the choices and sacrifices made by the programmer can affect the results of a mix that might be more complex.

You may not lose much precision at a single sample from a single process, but the accumulated error from multiple samples builds up. Because there is no way to properly bit-reduce a floating point signal the errors (and then accumulated errors) build up undesireably.

Don't you mean multiple "calcs" not "samples". When are you saying this occurs within a DAW mastering process?

No, I meant samples, though I should have said "samples and calcs." The accumulated error from successive samples causes the distortion. We don't hear the error at a single sample. We hear the aggregate errors from multiple, successive samples. It is with this in mind that 32 bit floating point systems are less-than-desirable for various aspects of a DAW. One simply cannot maintain the precision below the 25th bit throughout multiple processes.

While they try to constantly maintain 25 bits of precision (in 32 bit float) anything that happened below the 25th bit is lost.

Surely this occurs only at dither time, right at the end.

Definitely not! The dither is the only chance where there is an opportunity to SAVE the information below the 25th bit! That is the purpose of the dither - essentially to bring forth the data represented below the remaining LSB so that upon truncation it is still represented. This simply cannot happen as floating point systems continually shed excess bits without preserving the information that they shed!

Sure, there is a constant 25 bits of instantaneous precision at any individual sample value, but the aggregate precision is much lower than that of fixed point systems. We humans hear more in terms of a windowed FFT analysis, wherein we analyze long stretches of audio at one time, so the instantaneous precision is not as important to us as the aggregate precision.

By aggregate precision, do you mean aggregate error of calcs?

No, not really. I mean that the error at one sample is insignificant to our ears. What is significant is the error from multiple samples. If we truncate excess bits (like a floating point system does after every calc) we create signal-dependent error. We effectively add a signal-dependent waveform to our signal, and any added component that is correlated to the waveform is, by definition, distortion. This distortion is the aggregate problem to which I was referring. We don't experience this in properly implemented fixed point systems because any error in the system is not signal-dependent. It is not correlated to the signal.

Let me know if there are questions.

Nika

DavidSpearritt wrote: Wavelabs author explains FP in simple terms

Hmm. I found that to be unhelpful and misleading. The following is an example:

The 32 bit floating point representation is useful for audio, because our ear work in the same way, with an exponential sensitivity. Eg. you need to change the linear level (imagine a waveform) from 20 to 40 to feel the same loudness increment than a change from 10 to 20. In other terms, a change from 1.00 to 1.01 is as much "hear-able" than a change from 100 to 101.

This is why the decibel (dB) scale has been invented: a linear scale to hide the exponential nature of the loudness, which is not easy to grasp for the mind.

It is interesting that he would say that the floating point system is more akin to the way in which the ear works. In some respects this is true. The human ear experiences temporary threshold shift (TTS) and other issues which affect its instantaneous dynamic range capability, which gives it good parallel with floating point systems.

This argument, however, falls on its face when we discuss the maximum dynamic range of the ear, which is around 100-120dB. Since the range of a 24 bit fixed point system far exceeds the entire dynamic range of the ear, the sales pitch having to do with floating the instantaneous precision in order to make it more compatable with the ear's hearing is utterly rubbish.

Further, what he's really getting at is confusion between the exponentially-based precision of a floating point system and the exponential perception of human hearing. To try to explain in simple terms why these really cannot be mixed in the same thought process would be confusing for certain. It is simply in poor taste to say "the ear hears in exponents and therefore, by putting some exponents into our numerical nomenclature makes the stuff sound better." This is pure and utter bunk. I suppose it may be effective as a sales pitch but it certainly has no function in a discussion about the design or merits of different processing systems!

I hope that gives an adequate example of my concerns from that stultiloquoy.

Cheers!
Nika

Let me know if there are questions,

Plenty. :) Can we quantify these errors with an example, to put it in perspective. Also I am still not understanding your terminology about samples and calculations.

Lets take two 24 bit waveforms A and B and add them togther (mix), concentrating on two corresponding "samples" at the same time point.

My impression of your argument is that you are referring to the error in the calculation of A+B as a percentage of A or B. Is this correct?

Are you saying that the maximum error in a 32 float calculation is epsilon or 1/2^24 and that this is greater than 24bit int precision?

Can you put some numbers to your example. This would help my understanding a lot.

The limit of my understanding is that a 24bit fixed int sample words and calcs have quantisation or amplitude errors inversely proportional (used loosely) to signal level, ie they are higher for lower amplitude signal.

Whereas a 32bit float has a 24bit mantissa which means its amplitude error is constant (2^24 steps) and independent of amplitude as the exponent is separated out.

So for adding small audio levels to big audio levels and everything in between, the 32 float is a more accurate and versatile and hence used in "all" DAW's, I think.

Nika, I know this is a simplification but I am at my level of incompetance now, after this, so can you fine tune or correct this statement perhaps?

David,

Let's forget all of that for now and let me instead try to give an example:

Take a 100Hz sine wave and (mentally) record it at full scale in both a fixed point and a floating point system. Now, get a digital signal generator from inside the DAW and add a 1kHz sine wave at an amplitude that is equivalent to 26 bits back from full scale - say an amplitude of -156dB FS. What happens in each system?

If you look at an STFT (waterfall plot) in the floating point system you'll see that there is a 100Hz sine wave at an amplitude of FS and a strange, oscillating 1kHz sine wave that is modulated by the 100Hz sine wave, because the 1kHz only shows up when the 100Hz sine wave is in its rarefaction cycle. This modulation produces additional frequencies at 1100Hz and 900Hz (at minimum) and these will be clearly noticeable on your chart. These are distortion byproducts. You also see modulated noise that peaks at an amplitude of -150dB FS, but has its own distortion characteristics (and is thus not ACTUALLY noise) that oscillates along with the 100Hz sine wave.

Now do the same on the fixed point system. You see a 100Hz sine wave at FS. You see a noise floor at -141dB FS and you see a 1kHz sine wave at -156dB FS. That bloody sine wave is still there! You have preserved the integrity of the data, capturing "precision" all the way down to the 26th bit (and lower) though you have added a noise floor to the mix at -141dB FS. Everything about that lower level sine wave - the one that was far below the "capabilities" or "precision" of the system was maintained. No distortion was added. This is, as I was alluding, the more "precise" system, because the aggregate precision is greater (no added distortion, preservation of the original data when looked at over time).

This is why some DAWs actually ARE fixed point systems! Take, for example, the Sony Oxford console, which is fixed point throughout.

Let me know if you have questions.

Cheers!
Nika

DavidSpearritt wrote: Whereas a 32bit float has a 24bit mantissa

Oops - one more point that may help reconcile the funny numbers above - a 32 bit float has a 25 bit mantissa.

Cheers!
Nika

Nika, your example is very strange. I am recording 24bit audio, so I dunno why I would ever want to add a -156dB signal ever, ie one that is lower than the LSB of my 24 bit audio.

Take a 100Hz sine wave and (mentally) record it at full scale in both a fixed point and a floating point system.

What bit depths for each?

Now, get a digital signal generator from inside the DAW and add a 1kHz sine wave at an amplitude that is equivalent to 26 bits back from full scale - say an amplitude of -156dB FS.

Record it with what depth system? We are already down at -26bits?

Can you give me a musically significant example?

It seems I may be vindicated ....

http://recforums.prosoundweb.com/index.php/m/0/2162/48/0
(dead link removed)

Okay, I've gotta jump back in here. It may just be because I'm cranky right now, but I'm getting kinda fed up with this thread. Alright already!!!! We have some programmers/mathmeticians in the crowd. Hurray for you!! The fact is simple:

Several of us here believe that we can hear significant differences between DAWs. And regardless of any results that Dave and I may come out with, we will likely still hold to this belief. Prove or disprove it on paper all you want - who are you helping. For the love of God - the amount of time some of you have spent preparing your lengthy and well-thought-out responses, you could have made some beautiful music.

Let's get back to the important stuff and let's face it - who gives a flying rat's ass how one DAW sounds compared to another as long as you are happy with yours, fine!

Sorry for the rant. I'm going to go drink some burboun now and get ready for 3 friggin recordings in one friggin day! 8)

J...

Ah... mathematics... love it. For all you floating point chaps out there maybe you can answer this for me.:

How much is a cross-grade from Nuendo 3 to Sequoi 8?

And don't worry, I won't mind of you round the total up to nearest whole figure! ;-)

I asked on the Samplitude forum about this question and the developers came back with an answer that to a certain extent both sides are right. Yes, things should sum perfectly, but there sometimes is a bit of "voodo" involved in the way that the DAWs work...

Anyways, I think this thread has pretty much run its course. The arguments are turning circular and neither side is budging.

If there is a truly useful post contact me and I'll unlock it, but I think it is time to end this one here...

--Ben

Great thread, wanted to bump it for search engines and to also see how any of these older members still feel about Samplitude or Sequoia. I bought Sequoia 11 last year after a very lengthy research on what DAW to move forward on and love it. Its so logical and it does sounds so good.

Never seen software better than ProTools

Not to be crass but most of the DAW software out there has better features than PT. If you like the PT workflow and it's the right set of features for you, then that is a reasoned decision.

TheJackAttack, post: 356899 wrote: Not to be crass but most of the DAW software out there has better features than PT. If you like the PT workflow and it's the right set of features for you, then that is a reasoned decision.

Could you say which features are they? Thanks.

There are several threads currently going on this subject that you should check out. A brief list of feature offered in others DAW's: true delay compensation for plugins as well as overdubs, use of VST plugs, spectral editng and phase analysis, generally more and better editing features both nondestructive and destructive, far better implementation of the programming code in regards to digital summing, 64 bit float, 64 bit code generally. All the features are available out of the box from many other DAW programs.

Now, as I said before, if you like the work flow of PT and you get good results that is great. But "best" is not really something I'm willing to concede to PT even in it's new version.

datiko, post: 356896 wrote: Never seen software better than ProTools

After I have been told I tend to bashing, I just give you this: 0049 8141 117 884
It is the telefon number of my favourite optician.
;-)

Attached files

Well, I cannot say that I have tried many other software (Sonar, Cubase, Adobe Audition), but besides them PT is best for me.
(I just use Peak pro for stereo track editing and mastering.)
Perhaps because I had no chance to compare those features.