So there you have it....
 



 
 

drewfx1

Goddard
Still, noteworthy that the processed 16-bit streams always nulled, even when using floats, whereas the 24-bit streams never nulled when floats were used. Hmm, maybe double precision does matter. Good to hear the bug's been squashed.

 
You crack me up. 
 
You just can't seem to comprehend the difference between an error being present and being audible or meaningful. Until you will admit that those are not the same thing, I will not waste anymore of my time on you.
 
But I will wish you good luck in your future endeavors.

Ha! And I didn't even put a smiley after my "Hmm, maybe double precision does matter" remark! (although obviously floats are not really "double precision" wrt 16-bit PCM, only "higher precision")
 
Be careful while you're cracking up that you don't fall off your high horse!
 
I comprehend the difference just fine, thank you. Have for a long time now. The question of the necessity vel non for double (or extended or, at least, higher than source) precision when performing dsp operations is hardly a new one. Been there, learned and practiced that already back when dedicated fixed point dsp was pretty much the only option, although some chips could also implement floating point, and things only became more critical as converters got better and  higher resolution formats like 20- and 24-bit and became more widely used. Fun times, experimenting with what other tricks could be coaxed out of the Moto 56K on a TB Tahiti.
 
So yes, I am very well able to comprehend (and mostly still hear) at just what point rounding/truncation errors may become so significant as to be meaningful. Just as I am well able to comprehend how and why rounding errors which may occur in stream data but not be significant enough to be audible/meaningful may in the course of downstream processing be compounded to such a degree as to become definitely audible in effect and undesirably manifest quite meaningfully above the relevant noise floor, as well as what measures may prevent or at least ameliorate such, including the use of higher processing precision. So yes I already grokked what these are all about:
 
http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
 
 
http://www.analog.com/en/content/relationship_data_word_size_dynamic_range/fca.html#4
 
(although, were I say, coding today for a native host-based DAW or DSP application, I might also look at the merit of implementing Kahan summation rather than relying upon naive)...
 
http://baumdevblog.blogspot.kr/2010/11/fast-kahan-summation-implementation-in.html
 
Anyway, it's been fun but as my time is becoming rather precious just now and it's apparent you're more interested in arguing about what is or isn't audible, perhaps your own time might better be spent arguing with Craig instead about "fuzziness" and "fizzing" and reverb tails:
 
http://www.harmonycentral.com/t5/Craig-Anderton-s-Sound-Studio/64-bit-sound-Are-you-using-it/m-p/36059653/highlight/true#M277140
 
or with Bob Katz about what a double precision digital mixer sounds like:
 
http://www.digido.com/articles-and-demos12/13-bob-katz/17-more-bits-please.html
 
as they seem to be able to hear things, and Bob's real big on null tests too.
 
 
Btw, even award-winning "null test" results which get published by AES can be off:
 
http://www.cirmmt.org/activities/newsletter/past/april2012
 
https://secure.aes.org/forum/pubs/ebriefs/?elib=16597
 
http://www.aes.org/e-lib/browse.cfm?elib=16518
 
oops...

Noel Borthwick [Cakewalk]
The interesting thing is on Intel X86 CPU's there is no significant difference computationally between 32 bit floats vs 64 bit double precision, since they use 80 bit registers for both types. IIRC they take the same number of clock cycles to process a float instruction. There is however a huge gain over integer arithmetic including fixed point math which is much slower. So for most software implementations its a no brainer to use either float or double precision. There is a very slight performance hit with double over 32 bit float when you consider the memory footprint since we're pushing twice the amount of data on the bus, and some potential cache issues. 
 
We switched to supporting 64 bit floats in 2003-2004 when we ported the app to a 64 bit architecture - besides the extra precision, it was the most logical thing to do. It had nothing to do with DirectX or anything like that. We could have done 64 bit in DirectX if we had chosen to do so at the time. It just turned out that the 64 bit revolution started around the time we decided to stop using DX in our engine.
There is no question that 64 bit gives you higher precision and is virtually lossless in terms of errors. Whether the extra accuracy is benefits a typical mix or is audible is obviously a loaded question depending on many factors as discussed in this thread already.

Ah, thanks for explaining all that, Noel.
 
I recall being surprised by the performance benchmark results given in that white paper at the time of the 64-bit rollout. I had the impression that SSE2 and x64 might have been a stimulus.
 
Anyhow, in the interest of precision (just in case you weren't aware):
 
http://baumdevblog.blogspot.kr/2010/11/fast-kahan-summation-implementation-in.html
 
http://baumdevblog.blogspot.kr/2010/11/high-precision-floating-point.html
 
 

BTW now my 64 bit engine is back, I completely agree, it sounds so much better. I'm actually busy decoding the differences by listening to my tracks several times, so far I detected 45 buzzes or so, came out in morse as "let me out".... not sure what that is about.... I'm amazed I didn't hear it the first time...

Yeah! My 64-bit engine sounds so much....
 
like it always did!
 

 

 

D K

Goddard

D K
 ^^^ Game, Set, Match ^^^ - That is.. for anyone whose primary concern is about performing,capturing, mixing and presenting...music

 
Seeing as how you feel compelled for some reason to keep score here, why don't you instead tell us all about how much improvement your heard in your Tango 24 after shelling out for that BLA mod?
 
Btw, we'll be expecting objective proof...

Son.. do you really think I give a rats A** about proving to you (or anyone else for that matter) what improvements BLA did or did not make to my Tango 24?

 
Hmm, appears your position changed from when you'd posted this earlier:

D K
Love when people put the time in and report facts..  Now.. Let's wait for the remainder of those who are going to say "facts be damned.. I hear it..and my ears are better than your stupid null test" :)

 
Not your son. But I do recall you from that GS thread about BLA mods a while back.
 

D K
Stick to posting unread links and mindnumbing pointless internet arguments... and just for relevance sake.. I'm betting my 20+ years of experience doing this.. that BLA's modification to my Frontier Designs Tango 24 did a metric ***t ton more for improving sound than whether or not I have checked the 64 bit engine box in my preferences..
 
I'll wait for the new link about metric tons....

Perhaps if you took the time to read what I'd linked to you might find some facts revealed in there too.
 
Not in the betting business, but if I were I might wager that wordclock likely made more difference than the upgrade.
 
Anyhow, glad you're happy with your Tango 24.

 
http://www.youtube.com/watch?v=smYQeWxa5wg