Thought Sonar 5's 64-bit engine sounded "better?"

Audio Plugin Hosts and other audio software applications discussion
RELATED
PRODUCTS

Post

Turns out it was a integer conversion error introducing harmonic distortion and giving everyone that clearer, "analog" sound!

http://forum.cakewalk.com/tm.asp?m=708189&mpage=1&key=

:roll:

Post

But it's the song that matters?

Post

bonch wrote:Turns out it was a integer conversion error introducing harmonic distortion and giving everyone that clearer, "analog" sound!

http://forum.cakewalk.com/tm.asp?m=708189&mpage=1&key=

:roll:
Err, there is much much more that story.

If you do an A/B comparison of files rendered from the 32-bit engine vs. the 64-bit engine, they differ by much more than a single bit. IOW the integer conversion thing accounts for a miniscule part of why the 2 engines sound different, but doesn't come close to accounting to the whole story. The reason these 2 engines sound different is because 64-bit math is more precise when you start mixing many tracks of material at many different gains.

And before some of you snicker about the "bug", you be wise to check your own DAW's behavior. I've find a couple of popular ones have this exact same behavior even in their 32-bit floating point implementation.

The test (thanks to SONAR user bthompson) is: create a mono 1kHz tone in 32-bit float format. Load this file into your DAW, then export it out with dither to 16-bit. Load both the original float version, and the dithered/exported 16-bit version into an app that has an FFT, and compare the frequency response. You may be very surprised.

Post

any idea when the snapping and the vst automation will be fixed?

Post

Colonel Flashback wrote:any idea when the snapping and the vst automation will be fixed?
In the next update to 5.0, underway as we speak. By the way we've read reports about a snapping issue (do you mean, snap-to-clips doesn't always work), but none of us have been able to reproduce it? Can you please email me (ronkuper AT cakewalk DOT com) with more details about this, so we can get it fixed? Thanks.

Post

Sorry! I'm moving, resizing, cutting stuff like crazy right now and it all snaps perfectly. :oops:

I was playing with the Sonar demo recently and clips often snapped just a bit too far to the right or left of clip boundaries or measures. I searched the Cakewalk forum and found eg this thread (http://forum.cakewalk.com/tm.asp?m=657487) in which someone posted that Cakewalk had confirmed that there's a snapping bug.
It might have been user error on my part (wrong settings, Sonar newbie), dunno...

The vst automation bug was a show stopper (for me anyway), so i didn't dive into the program much further. But i might just switch from Ableton Live when that's fixed because the Sonar 5 Freeze functionality is just GREAT!

Post

Ron Kuper [Cakewalk] wrote:The test (thanks to SONAR user bthompson) is: create a mono 1kHz tone in 32-bit float format. Load this file into your DAW, then export it out with dither to 16-bit. Load both the original float version, and the dithered/exported 16-bit version into an app that has an FFT, and compare the frequency response. You may be very surprised.
Hey Ron - maybe I'm reading this wrong - but the process bthompson reported was to export/dither the -6dB@32bit sine file twice with the same setting - except that one pass is with the 64 bit option on, and one with it off. The result should be an apples-to-apples comparison of two 16-bit files.

I'd be curious to know if adding more than one file causes an accumlation of the errors - perhaps someone can do the test with several instances of the sine wave at a lower dB point to see how/if error accumulation occurs.
Houston Haynes

Post

HHaynes wrote:Hey Ron - maybe I'm reading this wrong - but the process bthompson reported was to export/dither the -6dB@32bit sine file twice with the same setting - except that one pass is with the 64 bit option on, and one with it off. The result should be an apples-to-apples comparison of two 16-bit files.
And it would, except that Bill's test uncovered a subtle yet measureable difference in how our 64-bit mix engine converts doubles to integers, versus how the 32-bit mix engine converts floats to integers. (Both engines need to convert their internal numerics to integer/PCM when playing back or when exporting to a PCM format.)

The difference was in the rounding mode. In the 64-bit engine, a floating point value of as 12345.6 was getting converted to 12345, whereas in the 32-bit engine it is converted to 12346. IOW, the 64-bit engine was programmed to use a "truncate" rounding mode, while the 32-bit engine uses a "round-to-nearest" mode. The difference, yielding at most 1 bit's worth of error, was measureable in the FFT of the exported sine wave.

Finally, since this float/double -> integer conversion only happens once, at the very output of the mix engine to the hardware or rendered file, it isn't a cumulative effect.

Post

Ron Kuper [Cakewalk] wrote: By the way we've read reports about a snapping issue (do you mean, snap-to-clips doesn't always work), but none of us have been able to reproduce it? Can you please email me (ronkuper AT cakewalk DOT com) with more details about this, so we can get it fixed? Thanks.
Hi Ron, nice to see you answering people's questions :)

Re the snapping thing: I'm not sure if it is what is in question, but I have noticed a weird thing with groove-clipped imported wav files. I noticed that sometimes, not all the time, if I copied the grooveclip by selecting it, holding down shift (or is it control, I can't remember without it being open in front of me - anyway the one you use to copy a highlighted grooveclip/audio clip etc), and dragging it to the new location, that the original grooveclip became 'damaged', in that the first few fractions of a second became a non-grooveclipped piece of audio lying on top of the groove clip, as a seperate entity, no longer in time with the bpm. It happened a few times but not consistently; in the end I reverted to using right click>copy>paste which seemed to be safer.

Post

Ron Kuper [Cakewalk] wrote:The difference, yielding at most 1 bit's worth of error, was measureable in the FFT of the exported sine wave.
'Measurable' in the case of 32bit rounding vs truncation error is still nearly 30dB away from 'audible'. :lol:

Post

I'm amazed people can even claim to hear a difference, just by pressing "play". I would think the real test would come if you could compare the same song, with tons of processing, duplicated on a 32-bit and a 64-bit machine. It's the lack of degradation from processing where I would think the audible difference lay, no? :shrug:

Post

bduffy wrote:I would think the real test would come if you could compare the same song, with tons of processing, duplicated on a 32-bit and a 64-bit machine. It's the lack of degradation from processing where I would think the audible difference lay, no? :shrug:
Just to clarify one common misconception: you don't need to be on a 64-bit machine to utilize the SONAR 64-bit mixing engine. The "64 bits" of the mixing engine refer the sample wordsize used for mixing and processing. The other "64 bit" story around SONAR 5 is that is available as a native x64 binary application.

Our customers who can hear a difference between the two engines are using real world songs, where IMO the difference is that 64-bit retains more accuracy with lots of processing.

Post

Ron Kuper [Cakewalk] wrote:
bduffy wrote:I would think the real test would come if you could compare the same song, with tons of processing, duplicated on a 32-bit and a 64-bit machine. It's the lack of degradation from processing where I would think the audible difference lay, no? :shrug:
Just to clarify one common misconception: you don't need to be on a 64-bit machine to utilize the SONAR 64-bit mixing engine. The "64 bits" of the mixing engine refer the sample wordsize used for mixing and processing. The other "64 bit" story around SONAR 5 is that is available as a native x64 binary application.

Our customers who can hear a difference between the two engines are using real world songs, where IMO the difference is that 64-bit retains more accuracy with lots of processing.
Sorry, Ron - actually, I didn't mean to use "Machine", I meant "version". I just wouldn't think that you would be able to open the same song on a 64-bit version of Sonar and be like "WHOA!!! MY LIFE HAS CHANGED!!!", but maybe I'm wrong.

Post

bduffy wrote:Sorry, Ron - actually, I didn't mean to use "Machine", I meant "version"
You don't need to run a different version of SONAR to enable 64-bit mixing. It's available as an option (a checkbox) in the Options | Audio settings in SONAR 5. IOW it's a setting just like pan law, dither, etc.

Post

Ron Kuper [Cakewalk] wrote:
bduffy wrote:Sorry, Ron - actually, I didn't mean to use "Machine", I meant "version"
You don't need to run a different version of SONAR to enable 64-bit mixing. It's available as an option (a checkbox) in the Options | Audio settings in SONAR 5. IOW it's a setting just like pan law, dither, etc.
Ah, OK, sorry again.

So do you think there is an audible difference in the sound quality, if one just opens an old mix with 64-bit enabled, say?

Post Reply

Return to “Hosts & Applications (Sequencers, DAWs, Audio Editors, etc.)”