Audio quality comparison between 32bit and 64bit host

Has anyone done A/B comparison between 32bit and 64bit host. I know that by using 64bit host, we have lots of privileges in terms of using large sample libraries, plugins and so on. But what about the audio quality of the final product, is there any difference in terms of dynamics, wideness and loudness?

c’mon, its just zeroes and ones…

No…

I wouldn’t expect any sonic difference given the core sample format is 16,24 or 32bit FP) in both 32 and 64 bit versions, as I understand that internal processing is done in one of those 3 formats (which is why I use 32bit FP, lots of room for “overflow” and no clipping). I would hope/expect a slightly more stable system because of added phyiscal memory, but less core stability due to the sheer numbers of people using 32 bit (more real-world testing) vs 64 bit (which does have a few issues :slight_smile:

What I expect from 64 bit vs 32 bit the ability to play and record way more tracks, as more than 4GB of stuff (well really like 3G) can be kept in physical memory. And perhaps bouncing to disk might be faster if more stuff can go in memory… Generally, it’s the pulling stuff on and off disk in huge projects that overloads thing (well, presuming you’ve frozen your VSTi and are just running audio :slight_smile:

Sure, you can go 6000 db over digital 0 internally as opposed to just 1500db or so I guess. We all know how frustrating it can be when you have a 32-bit float track and you need it to be 1525db. :mrgreen:

Seriously though, I know some musical bats that mix in Cubase and Sonar and they say Sonar sounds much better. :laughing:

I never have popcorn ready when I need it…

64bit host != 64bit audio processing

32bit FP processing = 32bit FP processing

Not unless you have a tube amp warming up the bit rate between your hard drive and your screen. :wink:

No. The confusion here is the use of the term “64-bit” in relation to both CPU architecture and audio resolution.

Referring to CPU architecture, 64-bit is almost always a good thing as it allows the use of practically unlimited RAM, and even assists 32-bit applications running under a 64-bit OS; so for example, Cubase users who use large sample libraries which need to loaded into RAM will certainly benefit from the use of both a 64-bit OS and the 64-bit version of the application. Even the 32-bit version of Cubase can benefit from being run in a 64-bit OS, something which many of us are doing (usually in cases where there’s no 64-bit version of a favourite VST plugin, and the VSTBridge doesn’t work).

In the case of audio resolution, when audio is passed between VST plugins, it is done only after each sample is converted to what’s called a “floating point” number – think of this as mapping e.g. a 16-bit (integer) sample as it might exist in an audio file to a value between 0 and 1, but with all possible values between 0 and 1 available, thus giving infinitely more resolution during processing. Only when the result is converted back to integer samples (e.g. 16-bit, 24-bit) for playback via an audio interface or for burning to disk is the resolution decreased.

So, in summary, as far as audio processing is concerned, it does not matter whether the application is compiled for 32-bit or 64-bit CPU architecture, the audio processing would be identical because this happens in the floating-point domain.

There was a difference between ASIO 2.2 and 2.0 because higher precision was enabled, as there was quality improvements also between pre VST 2.4 and 3.0 plugins.

However since many people are still using older ASIO 2 hardware they don’t know the difference. :nerd: :ugeek:

Shhhhh!
{’-’}

Hi Cramar.

Can you provide a link or some info on this please as I’m interested, thanks.

Interesting, but not what the OP originally asked; “audio quality comparison between 32bit and 64bit host”. Given the same Cubase project, there’s no difference in audio quality between a mixdown from the 32-bit version and one from the 64-bit version.

Thats kind of what I’m asking, was the difference in timing and various other parameters like control, not audio.

It’s a good question - and one that I was asking myself a couple of months back.
After doing a little research (thanks Google) I came to the conclusion that any resulting files, whether created by 64bit or 32bit, would be identical.
I’ve since partitioned my drive and now dual boot Win 7 32bit & Win 7 64bit. Cubase is quite happy bouncing a project from 64bit to 32bit and vice versa. There’s no difference in audio quality.

Sorry to interrupt. Here is a link right at the steinberg site.
http://www.steinberg.net/en/company/press/archive/steinberg_press_room_archiv_2006/steinberg_asio_22_standard.html

The article was dated Sept. 13, 2006, so I believe there is already a good chance we are all using 2.2. (I have to investigate though cause now I’m paranoid).

Cheers!

I’d already seen that, I was wondering if this statement could be backed up, that’s all.

Although it does not state that the audio is passed at a higher precision, I think it’s implied?

Ahh… Maybe someone else has those answers. I personally am loathe to try it on my system.

You know the saying. “If it’s not broken, don’t fix it”. (Or something like that). :mrgreen:

People are still comparing apples with oranges. Please read my earlier post – I’ve tried my best to explain the difference between digital audio resolution (to do with things like integer/floating point formats and bit depth) and CPU architecture (8/16/32/64-bit).

ASIO has nothing to do with this, and ASIO 2.2 did not have increased audio resolution (“precision”). The article referred to is talking about 64-bit in relation to CPU architecture, not audio resolution. The ASIO 2.2 SDK enabled developers to create versions of their existing drivers that would function properly on 64-bit operating systems. If your interface deliveres 24-bit audio with it’s ASIO 2.0 driver on a 32-bit OS then it still delivers 24-bit audio with it’s ASIO 2.2 driver on both 32-bit and 64-bit OSs.

ASIO 2.2 and VST 2.4 enable double width integers to be used.