Quote:
Originally Posted by UnderTow This is why I say he is being vague. If a multiply or divide operation returns a 32 bit word it is effectively a 32 bit operation. It is even truncated which means you lose any additional precision that might occur. (Not that there really is any). |
Well not really. If in two cases where you return a 32bit figure - but in one you only have 32 bits of precision for the calculation while in the other you have 64bits - then the result can indeed be different!! - with the calculation being done at higher precision obviously having the potential for less errors.
Again - I'd say it's important to find out what's really going on "under the hood" as I'd say a lot if not most apps (such as PT HD) are doing the same thing of returning a lower precision figure after doing the calculations at a higher precision.
As far as truncating after the 64bit operation to 32bit - in the case of SAWStudio first off we're talking about a full 32bit DWORD here - which means true 32bits, not just 24bits+8bit mantissa that you get with a 32bit IEEE file - so then the question now that you have so much headroom above the noise floor of even the most accurate 24-bit DAC's how many operations can you perform before low level distortion from truncation accumulates to a point that is even approaching a point audible above the noise floor? My ear says in the case of SAW - you'd need a heckuva lot more of them than I've gotten from even huge multitrack sessions for them to create a difference. I'm sure other people will find it as a reason to condemn it without ever hearing it or analyzing it though.
Quote:
Anything in between is irrelevant.
That is the resolution available and nothing more.
|
For some operations this might be true. For multiples and divides - sorry, but having the greater precision even when returning even a lower precision figure will still lead to less errors.
Quote:
|
This is exactly what I was alluding to before. To me this is similar to saying a 32 bit float calculation has 80 bit resolution when using the CPU float units. It is stretching the truth too far for my taste.
|
Well again, I'd say Bob Lentini has been really forthcoming, and there's no truth stretching going on. He doesn't really ever use the word "64bit" in his marketing for SAW as far as I've ever seen - he's just used it when providing answers as far as what is going on "under the hood".
Quote:
|
Or Cakewalk. The devs have repeatedly discussed the details of the audio engine on the forum. Sonar has full 64 bit float throughout. There are a few legacy plugins but any of the new ones are 64 bit float. Any 3rd party VST 2.4 plugins will also communicate at 64 bit float. The limitation is the audio I/O and/or file bit depth if the user chooses less than 64 bit. (Which you usually will of course but if you want to use 64 bit, you can).
|
Sonar definitely seems to have some really good things going for it. I've never checked it out in person but the lack of direct Red Book master PQ creation/editing (unless they've added this in recently without me knowing) kind of makes it not really great for my needs, so I've just stuck with what I have (which was paid for very long ago and which I'm super quick at working with, and which still gets feature enhancements issued for it, including a free one that just came out last week).
Quote:
If it works for you and sounds good, what else can you ask for? |
Bingo.
And even more importantly, getting quick reference approvals! So the clients have been liking the sound of the results as well.
Again in the case of DAW apps I think folks should just use what they like that gets the job done for them. I happen to have a personal preference for one in particular - but when folks want to use something eles it's all good by me!
Best regards,
Steve Berson