Best Recording Software

Posted: Wed Feb 09, 2005 6:58 pm

Nod, the precision is more accurate of a representation of the number, but that representation is still only guaranteed to a certain "decimal" and who is to say they didnt convert from an INT to a higher precision float?(more decimal places). Who is to say they didnt do less? What did the processor/fpu return as the starting single?

At least initially.. because lets say you had an int that was

24(being dumb)
then you change it to a float
and on "this" computer it makes it
23.54985794857948754985794 (again making this up as an example)
on this computer
23.54985794857948754763833 (again making this up as an

those are NOT the same number and this can happen. what your not understanding is that floats are NOT guaranteed to the infinite decimal place.

this means that anything past spot xyz is not guaranteed. So you can get different results. This is a fact, not an opinion.

Ok.. now thats a better statement Smile

.. saying that its something you wont notice because its removed when turned back into an int is possible.. based on the fact that floats are not "hugely" inaccurate.. however.

(btw the rounding part occurs in your processor or at your software layer depending on the coder/cpu, if you go past the requested precision so I was merely using that as another example of how its not guaranteed to be the same).

But again, the point here is that "you" cant gaurantee (and I DID say that if you could guarantee on the same machine you should be ok), that things are happening on the same level.

Thats all.. you cant guarantee just because they use floats that they dont do anything different with the numbers.

Whether its bugs(ones that arent totally noticable) or intentional for affects, it is possible to get different results.

However I do agree, and (with the concession that the programs have no bugs, and do everything guaranteed in the same order, using the same values for modifying the wav) that you have alot less chance, after it is rounded to an int(forced scalar values), that you would see little different in the number.. now whether you can hear it.. im not a voltage/db level expert Smile

.

So for the sake of ending this Smile

.

Ill agree that if you could prove they all do it all the same way(not just the data type cause that means squat).
(1.453453453454 * 3) + .15
isnt the same as
(1.453453453454 + .15) * 3

So if such modifications are done(to add affects or whatever) are done in a different order then it does come different.

Anyhoo Smile

, I only know that in code(when its written by others), no matter how much they try to use "shared" or "templated" code, can always, always come up with different results.

Bah im tired now Smile

.. and this is boring now.

Sorry all for the spam posts Smile

Posted: Wed Feb 09, 2005 7:11 pm

Wow… maybe I shouldn’t jump in here, but I think y’all are getting too hung up on math. There are other ways that DAW’s can differ from each other.

Audio engines in the major DAW’s run at high internal bit depth. We apply a high-quality dither when we bounce down to 16/44.1k for final distribution. But what happens when we listen to our monitors during mixdown?

The program I use – Samplitude -- runs at 32 bit float, but my DAC can’t deal with that. So (as I understand it) Samplitude dithers in realtime when passing a 24-bit word to my DAC. I assume this is some kind of proprietary dither optimized for speed, vs. quality. And I’ll bet it’s not the same process used by PT, Nuendo, or Logic. The programmers working with those systems are all going to have their own ideas of how to feed a 24 bit word from a higher bit depth audio engine through a DAC, so we can hear things in the outside world while mixing or mastering. Some programs may even just truncate, for the sake of realtime speed. As we all know, there are lots of different choices in how to do dither/noise-shaping, and if you can hear those differences, then different DAW’s will sound different from each other in a realtime feed to your DAC and monitors.

Another variable is pan law. I read a lot of DAW comparisons where people don’t take this into account. Like many other programs, Samplitude’s pan law can be set several different ways. Which version are we comparing? Different pan law settings can make one program sound slightly louder than another, which shifts your perception of audio quality.

Programmers can also play games with gain staging and metering. For years, there was a sort of urban myth among users of the Emu/Ensoniq Paris DAW that you could push the faders into the red (something like tape), without distortion. It turns out that the designers may have fudged the gain staging and meter calibration -- applying a gain reduction to the mixer section faders so it looks like you can push tracks into the red for a “fatter” sound, while they were applying invisible makeup gain in the master section. This may have fooled people into thinking that the Paris system had more headroom than other DAW’s. And of course it’s difficult to compare a mix with other DAW’s when the clipping point in the mixer section meters actually isn’t the clipping point in the audio engine!

Anyway, I’m no expert at this stuff, but these are just a few ways in which “math isn’t just math” when you’re comparing different DAW’s.

That said, I do believe the differences in current programs are so subtle that you’re better off choosing a program based on workflow preference instead of intrinsic sound. None of the current major programs are so bad that I’d reject them on sound quality alone. I like the sound of Samplitude, but I like the workflow better.

Mike

Posted: Wed Feb 09, 2005 11:02 pm

For the sake of simplicity, let's suppose we are dealing with an 8-bit setup. Each sample is an integer that can't be greater than 256. If one is 200, and another happens to be 200, when these are added together the number will be 400 which can't exist as an eight bit integer. You HAVE TO change these numbers to process them, and then downsample at the end. The simplest way is to represent them with a higer bitrate, supposing that we decide to process them as integers. I know that in practice we are dealing with a much more complex situation.

Can anyone disagree with this? No. It's a statement of fact. You can't use simple addition. It won't work.

You have to do someting else. That's an incontrovertible fact that can be shown without needing to go into the complexities of the way computers deal with numbers. It's going to sound different according to the way it's done. I can't see how anyone can fail to accept this.

John Stafford

Posted: Thu Feb 10, 2005 12:36 am

A 32 bit DAW, changes the 200 FIRST into 32bit float BEFORE the addition. Then it adds, to get 400 float and then you change the gain to fit it back on a CD. Simple.

Posted: Thu Feb 10, 2005 9:51 am

maybe someone could postulate this over on the Samlitude forum and see what the developers say. Assuming it's not some huge trade secret, perhaps they can explain what it is they do....

Posted: Thu Feb 10, 2005 11:23 pm

DavidSpearritt wrote:

A 32 bit DAW, changes the 200 FIRST into 32bit float BEFORE the addition. Then it adds, to get 400 float and then you change the gain to fit it back on a CD. Simple.

Hi David
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

Posted: Fri Feb 11, 2005 5:53 am

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.

Posted: Fri Feb 11, 2005 6:17 am

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.

Posted: Fri Feb 11, 2005 6:33 am

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

Posted: Fri Feb 11, 2005 2:43 pm

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.

Posted: Fri Feb 11, 2005 4:11 pm

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. )

Quote:

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.

Quote:

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... Cool

Posted: Fri Feb 11, 2005 4:18 pm

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.

Posted: Fri Feb 11, 2005 5:41 pm

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!

Posted: Fri Feb 11, 2005 8:32 pm

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

Posted: Fri Feb 11, 2005 9:39 pm

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.

Quote:

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?

Quote:

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.

Quote:

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?

Quote:

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.

This topic sponsored by: