Best Recording Software

Posted: Wed Feb 09, 2005 5:37 am

Some short notes to earlier discussions.

There are severel different sizes of floats. The most common sizes are probably IEEE 32bit, 64 bit and 80 bit if my memory is correct (used to work on this in early 80-s). The types used to be supported in the Intel processor family Floating Point Units, but it is a long time since I did any assembly language work so that might have changed. There are, in my mind, generally few reasons to go beyond 32 bit for input and output, but internally an algorithm might want to go to longer floats to preserve the precision.

PT LE as far as I Know has always been 32 bit float.

PT TDM (and the other hardware types) is still and has been 48 bit fixed point for the summing bus. I believe parts are fixed 24 bit, most notably in and out for plugins.

Gunnar.

Posted: Wed Feb 09, 2005 7:34 am

Well, this has gotten real interesting. Everyone agrees that certain programs "sound" different, but Dave wants the cold hard facts. I don't think this should be that hard to provide. I still have a copy of Cubase SX, I can drop the same wav's in both of them, sum them and then determine the difference.

Dave, would this pass the litmus test? (Without causing planes to fall from the sky?)

Let me give just one example of the software that I work with that is "broken" as you put it. Biometrics collection - specifically fingerprint capture and comparison. As many different manufacturers are on the market is as many different variations of programs. All software views the same image (your fingerprint and all of its minutia points), all of them use the same 32bit float compiler to determine the output stream for what's called the "template." (A digital version of your fingerprint - not the image itself - privacy advocates would be all over companies if they actually stored copies of your fingerprint's image) Yet, one "template" cannot be read by a different vendors software/hardware.

They all use the same input and the same data configurator, but they all come up with different results. Not broken - just proprietary.

Quote:

I'm a newcomer to Samplitude, and I bought it because my ears told me it sounded better when I downloaded the demo . That is a conclusion I came to on my own, before I had heard anyone else's opinion so I'm not jumping on the Samplitude bandwagon.

Yeah, me too. I was actually on board to buy Pyramix. I'd used it, I liked it (still do), but then I put some stuff through the Samplitude demo and it truly sounded cleaner and clearer.

Dave, I'll work on the experiment.
Thumbs Up

J...

Posted: Wed Feb 09, 2005 1:25 pm

Cucco wrote:

Well, this has gotten real interesting. Everyone agrees that certain programs "sound" different, but Dave wants the cold hard facts. I don't think this should be that hard to provide. I still have a copy of Cubase SX, I can drop the same wav's in both of them, sum them and then determine the difference.

Dave, would this pass the litmus test? (Without causing planes to fall from the sky?)

Bingo. Yes Jeremy, lets do the tests. I will contact you off list first as I know a couple of hi-res wavs we can download to add together. This is progress. Wink

I am afraid a lot of people "surmise" what is going on, etc, because they have paid a lot of money etc.

Check out this thread on the WL forum.
http://forum.cubase.net/phpbb2/viewtopic.php?t=4341&sid=20ba15dc184d2b9f200e43532aea457c

Posted: Wed Feb 09, 2005 1:58 pm

ghellquist wrote:

Some short notes to earlier discussions.

There are severel different sizes of floats. The most common sizes are probably IEEE 32bit, 64 bit and 80 bit if my memory is correct (used to work on this in early 80-s). The types used to be supported in the Intel processor family Floating Point Units, but it is a long time since I did any assembly language work so that might have changed. There are, in my mind, generally few reasons to go beyond 32 bit for input and output, but internally an algorithm might want to go to longer floats to preserve the precision.

Gunnar, you are right of course. I think there is a double float, an 8 byte (64bit) datatype, but its not used generally due to the speed reduction, ie double clock cycles to process and move around, and its simply not necessary as you indicate.

The 32bit float gives such mind boggling accuracy for calcs down to miniscule levels of voltage/sound that the differences would certainly not be rendered in any file back to 32bit integer and certainly not back to 24bit int, let alone 16bit.

Lets get this stuff into perspective for God's sake. I tell you, if you are turned on by some marketing gumpf that says that internal "engines" are running 80bit and you think you might be able to hear this when its all rendered back to ints of either 24 or 16bit, then you need a holiday.

Posted: Wed Feb 09, 2005 4:10 pm

Lol David, lets at least get into Perspective.. You know nothing about code.. FPU's, CPU's, Memory Registers and all your doing is throwing out IEEE 32bit and "dword" as if thats the end all be all..
Processors/FPU's are not required to have more then a "standard.. if they follow one" of precision. That precision is not every possible decimal of the 32 bit register.

So, does using "up to" a specific precision, on a specific processor/fpu, etc mean your going to get the same value.. i've love to say guaranteed 100% yes but you just cant.

That being said you still cant control "what precision", order or conversions that each application uses/does.

So .. then are the programs using Single or Double, are they emulating MBF standards.. in either Single or Double Precision

Throwing out the Term IEEE 32 bit doesnt mean you will get the same numbers.

69.82! + 1 = Single precision, 70.82.
69.82# + 1 = Double precision 70.81999999999999. Thats just one stupid example in a program language

However they are NOT the same number, they will NEVER be the same number, but they are BoTH using IEEE standards.

Therefor.. can you come up with different results Yes.

Because the same compiler can do both, and since you dont realize that, you will stick with your "absolute mind" set.. Dont believe it.. You are more then welcome to call me at MS.. since you keep throwing out the name like you work there(and umm you dont).

As for not using 64 bit floats. err wow really. I guess we should toss out or 64 bit OS's and Intel/AMD should toss out their 64 bit processors lol.. not..

Anyhoo.. Point is your arguing something you truly dont understand, but your too stubborn to understand that.

Since you also dont seem to understand that YES processors make a difference.. WHY.. well lets see.. each of them has what is called an FPU built into them(at least the new computers since 486 usually do). You could get add ons for those back then too..

Is the precision always the same nope, could adding 1 + 1 in excel give you something different.. no but then your not talking about a float, your talking about a short(or a bit), but adding values in different programs who request("this much precision" versus "this program wanting this"), can have a difference.

just because something is in a 32 bit register doesnt mean it remotely has to have the same result.

But you seem like you always will think that Smile

so please, go for that and please for the love of God, dont ever try to get a programming job at MS... at least not next to me.

As for "Gods Sake" perspective.. actually believing that all programs will always come out with the same mathematical outcome(or in this case result) because "you" say they will... lol.. please..

Posted: Wed Feb 09, 2005 4:14 pm

Ohhh and just for "perspectives sake"

http://www.scit.wlv.ac.uk/cbook/chap4.fp.accuracy.html

is a clear example of why floating point math is NOT 100% accurate on all machines, processors or applications.

I dunno maybe david can fix it..

and also this is "not" c++ the inference is 100% the same.. you can also find exact things such as this on the MS site and more so internally. We dont control the cpu/fpu's the precision requirement of an application.

I also want to state that although I do work for MS, I am in no way representing them here or now and these are my own opinions etc etc.

If you can show me that they not only do everything in the same order, have the same CPU/FPU precision and then they also request the same precision and dont sample down(or convert) then yes.. ill agree in that scenario you should get the same information.. none of which you can guarantee..

You want real issues with Floats.. I write graphics programs(games) and have my own 3d engine.. there is NO difference in the sound use of floats and the graphics use of floats.. and they are the biggest pain.. as each machine/cpu etc can have a difference on them, especially if you randomly generate them. ugh

You can also go to msdn.microsoft.com and look up float(there will be tons of information on it), in which case you will see(yes from Microsoft) statements such as the below excerpt talking about singles/doubles and the issues with the inaccuracy warnings of use of float points numbers

Quote:

Because of these limitations to floating-point mathematics, you might encounter rounding errors when you perform operations on floating-point numbers. If you do not require absolute accuracy the floating-point data types are ideal for representing very small or very large values. On the other hand, if your values must be accurate — for example, if you are working with money values — you should consider one of the scaled integer data types

Wow.. sure sounds like you can get different information to me.. esecially since if one program says " i only want 100 digits past the decimal" and another says "i want 10" and another says "i want 1000".. it changes the outcome... especially once it is finally converted down to the final forat.
anyhoo.. Smile

happy vocalizing.

Posted: Wed Feb 09, 2005 5:43 pm

Firing up VS2003 Ent on my desktop, cause I write code during the day... and typing this in and running it ....

sub Main
dim sngNumber1 as single
dim sngNumber2 as single

dim dblNumber1 as double
dim dblNumber2 as double

sngNumber1 = 1.0
sngNumber2 = 69.82

dblNumber1 = 1.0
dblNumber2 = 69.82

console.WriteLine (sngNumber1+sngNumber2)
console.WriteLine (dblNumber1+dblNumber2)
console.ReadLine()

end sub

Gives

70.82
70.82

So I am not sure what CPU/compiler you are using, but its broken. A clue to its broken state was given to you when your double precision result was less accurate than your single precision result. Perhaps a support call to MS might help. Wink

Posted: Wed Feb 09, 2005 6:04 pm

Hey david

firstly at least "read" what people write.
secondly. know your code. your using Visual Basic .Net not even Visual C++..wow. masterful.

singles and doubles with the values you are adding(which btw.. you arent even coming close to specifying any scalar precision) your letting the compiler do auto defaults.

you have all of what 2. decimal places.

Since Microsoft Clearly states that Floats are not mathematically guaranteed to be accruate, just the opposite.. I see you decided to ty to pick on the "single" thing you could try to..

At least use and understand how the language you are working with works.

Microsoft Visual Basic doesnt use the same underlying engine as Microsoft VC++ even in .Net.. Especially between managed/unmanaged code.

Gosh.. i would have figured a genius like you knew that.

Final point is.. since floats, as you have so "blindly" showed, can have an unlimited number of decimal places and then can be rounded later, or converted. you are never guaranteed to get the same outcome..

So adding two floats at different precision wont give you that same number.. eww so close though..

now just to be even more goofy i decided to go your route.. heres some VB Code

Dim a As Single
Dim b As Double

a = 1.1234523452345235
b = 1.1234523452345235

Debug.WriteLine(CStr(a * 0.29387409287340827))
Debug.WriteLine(CStr(b * 0.29387409287340827))

know what though? The answers are
0.330153527251681
0.330153538842299

Guess what those numbers arent.. the same..

But wait.. i know you will say.. but you arent adding.

oh okies lets add them
Dim a As Single
Dim b As Double

a = 1.1234523452345235
b = 1.1234523452345235

Debug.WriteLine(CStr(a + 0.29387409287340827))
Debug.WriteLine(CStr(b + 0.29387409287340827))

Guess what.
1.41732639866717
1.41732643810793

They still arent the same..

Please.. next time at least do some testing.. like you keep telling everyone else..

and learn to code.

Posted: Wed Feb 09, 2005 6:07 pm

Wow and I forgot..(that info i gave you on the floats not being equal was also from a Microsoft compiler)

but.. from MSDN again.

http://support.microsoft.com/default.aspx?scid=kb;en-us;145889

The article talks about how the CPU affects floating point precision..

Wow.. again Im right.. your wrong.. that seems to be a standard though.

Oh and btw genius.. the reason the Double is what YOU are calling not as precise is between double doesnt automatically round the same way as single.. Therefor double would give you exactly what this would(with the Microsoft QBasic Compiler and MSDN article that I copied the info from). Again it was just an example.

Again, please understand how the numbers work.. Double is more precise(meaning MORE decimal places) it doesnt mean the darn number closest to the decimal place is more accurate.. at least not in the term you are associating it..

Sheesh.. "have perspective", your not a coder, your wrong just admit it Smile

.. I can go at this all day and youll still be wrong.

Posted: Wed Feb 09, 2005 6:08 pm

After reading your link, I also did this.

sub Main
dim sngN1 as single '32bit floats
dim sngN2 as single

dim dblN1 as double '64bit floats
dim dblN2 as double

sngN1 = 1.0
sngN2 = 1/3

dblN1 = 1.0
dblN2 = 1/3

console.WriteLine(sngN1-sngN2-sngN2-sngN2)
console.WriteLine(sngN1-3*sngN2)

console.WriteLine(dblN1-dblN2-dblN2-dblN2)
console.WriteLine(dblN1-3*dblN2)

'Convert back to 32bit ints
console.WriteLine(cint(sngN1-sngN2-sngN2-sngN2))
console.WriteLine(cint(sngN1-3*sngN2))

console.WriteLine(cint(dblN1-dblN2-dblN2-dblN2))
console.WriteLine(cint(dblN1-3*dblN2))

Console.ReadLine()

and got

-2.980232E-08
-2.980232E-08
1.11022302462516E-16
0
0
0
0
0

So if all DAW's use 32bit float they will get the same answers if their compilers aren't broken.

Posted: Wed Feb 09, 2005 6:13 pm

Quote:

Hey david firstly at least "read" what people write.
secondly. know your code. your using Visual Basic .Net not even Visual C++..wow. masterful.

singles and doubles with the values you are adding(which btw.. you arent even coming close to specifying any scalar precision) your letting the compiler do auto defaults.

you have all of what 2. decimal places.

I just used your example.

Posted: Wed Feb 09, 2005 6:16 pm

How exactly does using the cint function on a double/single that FORCES integer scalar precision.. prove that adding TWO floats.. is always the same.

Lol.. what a joke

Posted: Wed Feb 09, 2005 6:21 pm

But I am not interested in comparing the addition or mult precision results between a single and a double, this thread is talking about a single in one DAW and a single in another DAW. Your example proves nothing as well.

Posted: Wed Feb 09, 2005 6:28 pm

The reason you are still incorrect is because EVEN a single to single can have different values based on the CPU, the precision the person asks for. This is not meant as Double/Single precision

But if you take 1.555555555
If you round it becomes 1.5555556 (im not actually counting spaces here so bear with me)

That automatically makes the single different. Since its BITS we are talking then the ONE bit at a minimum is DIFFERENT making the output DIFFERENT..

Holy sheesh is it really that difficult?

Lets now say you have TWO wavs(which you plan to add) as you said.

Is 1.5555555 + 1.55555555 with a precision of (lets be stupid as again im not counting how much i type) to 9 digits
The same as
1.5555556 + 1.5555556 (lets say they rounded first).
No they arent the darn same thing and I dont care if you use singles, doubles or anything else.

And certainly you arent going to tell me that
1.5555
+ 1.5555
is the same as
1.55555555555
1.55555555555
or are you?

since Singles can easily have this sort of precision, WHICH one are all the programs using.. how do you know? what precision is guaranteed on the processor(again YES it has an affect).

Im not saying programs ARE or should be modifying bits etc.. but sheesh to say without reguard, that they cant be different..

Common.. your just being inflexible on purpose.. and your still wrong Smile

I did want to add, that I totally and happily conceed that if you just take two singles and absolutely did the same thing in both programs you SHOULD get the same outcome.. However your argument is that each program WILL produce the same outcome(for sure) and this is totally illogical as you cant possibly know what order they do things, how they convert, truncate, for each program, and knowing they use "single" doesnt mean squat else.

Posted: Wed Feb 09, 2005 6:41 pm

Tenor2B wrote:

But if you take 1.555555555
If you round it becomes 1.5555556 (im not actually counting spaces here so bear with me)

But we are always taking less precise numbers, 24bit ints and making them into more precise numbers, 32 bit floats before doing any math. There is no rounding, so I cannot understand the point of your posts. Then we are using 32bit float throughout and will get 32 bit float answers. I am saying these answers will be the same between different DAW's. If they are not then the differences are orders of magnitude less than we can detect or they are completely removed when the final WAV is rendered.

Sorry to be so thick, you are obviously a well mannered genius, so I am out of place here.

This topic sponsored by: