Reaper 64 bit engine...

[Geert van den Berg]

Nice to have you here Justin! I hope more developers will follow.

A thread in Music Computer forum questions the 64 bit engine in Sonar.

Does 64 bit Sonar really sound better?

In one reply it's mentioned Reaper has a 64 bit engine as well.

Can you explain what its advantages are? And if there are any benefits to the sound of a DAW or if it's just a way to make the application work more efficient with the hardware.

[Justin Frankel]

Originally Posted by Geert van den Berg

Nice to have you here Justin! I hope more developers will follow.

A thread in Music Computer forum questions the 64 bit engine in Sonar.

Does 64 bit Sonar really sound better?

In one reply it's mentioned Reaper has a 64 bit engine as well.

Can you explain what its advantages are? And if there are any benefits to the sound of a DAW or if it's just a way to make the application work more efficient with the hardware.

For the purposes of this post I'll compare 64 bit floating point with 32 bit floating point. Integer samples have their own advantages and disadvantages compared to floating point.

As a bit of background, floating point numbers are capable of representing a range of numbers that is MUCH larger than an integer sample of the same number of bits, which is useful, but the drawback is that they can't represent EXACTLY many numbers in that range.

Both 32 bit and 64 bit floating point numbers can exactly represent any normalized 24 bit integer sample.

However when processing audio (applying FX, summing signals, etc), there are operations that can end up with results that will not be exactly represented by the floating point numbers. So tiny errors are introduced.

These errors are arguably not a big deal, as they are very small and should typically be well below the precision of any ADC or DAC anyway, but they can also add up. Using 64 bit floating point keeps these errors many orders of magnitude smaller.

The chief disadvantages that I can see for 64 bit floating point are increased memory use, increased memory bandwidth use (which also leads to increased CPU use, though less and less on the newer Athlon64 and Core2s), and more chance of denormalization related slowdown.

We chose at the start to use 64 bit throughout, planning on newer faster machines with more memory and memory bandwidth, and so that we wouldn't have to deal with upgrading everything if it became important later.

[sam c]

Yes, can you further explain denormalization as it relates to 64 bit floats?

[Justin Frankel]

Originally Posted by sam c

Yes, can you further explain denormalization as it relates to 64 bit floats?

Actually I'm still trying to sort some of this out.. oops

[trock]

Hi Justin

i may be mis stating this but i own reaper and am enjoying it, i also have sonar PE 6 and cubase sx 3

however for the past 2 years i have used SAWstudio, and IF i remember this correctly and maybe Sam C can help me out here, bob lentini uses 64 bit fixed for his audio engine and has for a long time. just wondering what the differences really are with this vs your floating point in reaper or PT 48 bit fixed etc etc

i mean so many people say they "hear" differences but so many tests null??


just curious what this really means

thanks

[dawhead]

Originally Posted by Justin Frankel

For the purposes of this post I'll compare 64 bit floating point with 32 bit floating point. Integer samples have their own advantages and disadvantages compared to floating point.

small problem justin ... there are no 64 bit floats on any processor architecture in wide use today. there are 80 bit double precision floats, and there are 32 bit single precision floats. both formats are available on 32 and 64 bit processors.

[Justin Frankel]

Originally Posted by trock

Hi Justin

i may be mis stating this but i own reaper and am enjoying it, i also have sonar PE 6 and cubase sx 3

however for the past 2 years i have used SAWstudio, and IF i remember this correctly and maybe Sam C can help me out here, bob lentini uses 64 bit fixed for his audio engine and has for a long time. just wondering what the differences really are with this vs your floating point in reaper or PT 48 bit fixed etc etc

i mean so many people say they "hear" differences but so many tests null??


just curious what this really means

thanks

It's tough to say.. but a big factor for us is that processing samples as floating point is a lot easier and more efficient...

and for the most part should produce the same results

[Justin Frankel]

Originally Posted by dawhead

small problem justin ... there are no 64 bit floats on any processor architecture in wide use today. there are 80 bit double precision floats, and there are 32 bit single precision floats. both formats are available on 32 and 64 bit processors.

Actually 80 bit floats are usually "long doubles"... the x86 FPU apparently internally uses an 80 bit format, but can load/store 32/64 bit floats as well..


As far as other architectures that support 64 bit floats, I know PPC does too...

[orange]

Originally Posted by trock

i mean so many people say they "hear" differences but so many tests null??


just curious what this really means

I'd be interested in how the 'null' test are being conducted. It seems to me that it's entirely possible that an 'export wav / offline' test could null and the actual 'real' audio out of the D/A not null (clocks not consistant etc etc). I'm not saying that this is the case here, but I'd be interested in knowing more.

[Justin Frankel]

Originally Posted by orange

I'd be interested in how the 'null' test are being conducted. It seems to me that it's entirely possible that an 'export wav / offline' test could null and the actual 'real' audio out of the D/A not null (clocks not consistant etc etc). I'm not saying that this is the case here, but I'd be interested in knowing more.

This isn't something I'd be concerned with, at least if assuming that other DAWs function similarly to REAPER.. the clock is dependent on the hardware (if playing back), and REAPER just follows along, doing the same thing whether sending to hardware or direct to disk.

-Justin

[living sounds]

I've done mixes in Saw for comparison and found them to sound less harsh and more musical than what I normally get out of a DAW (even Samplitude). I've also heard comparisons of Waves plugins in native and TDM (24 bit fixed) and found the TDM-ones to sound better (better definition in attacks for instance, float sounded slightly more muddy; bass sounded more defined as well). Is this really due to the fixed-vs-floating point calculation? How does 64bit float compare to 24bit integer?

[dawhead]

Originally Posted by Justin Frankel

Actually 80 bit floats are usually "long doubles"... the x86 FPU apparently internally uses an 80 bit format, but can load/store 32/64 bit floats as well..


As far as other architectures that support 64 bit floats, I know PPC does too...

my mistake, sorry. i forgot that both architectures "prefer/preferred" the 80bit double-extended format, but also support the standard ieee-754 64 bit double precision one too. AFAIK, SSE(2) still is built around the 80 bit format.

[Justin Frankel]

Originally Posted by living sounds

I've done mixes in Saw for comparison and found them to sound less harsh and more musical than what I normally get out of a DAW (even Samplitude). I've also heard comparisons of Waves plugins in native and TDM (24 bit fixed) and found the TDM-ones to sound better (better definition in attacks for instance, float sounded slightly more muddy; bass sounded more defined as well). Is this really due to the fixed-vs-floating point calculation? How does 64bit float compare to 24bit integer?

This is hard to answer without knowing about the internals of the Waves plugins, etc... I'd be interested to see side by side .wav files, too, so you could do some analysis to figure out why one sounds more harsh or musicial...

[sam c]

Originally Posted by living sounds

I've done mixes in Saw for comparison and found them to sound less harsh and more musical than what I normally get out of a DAW (even Samplitude).

Justin, I can never substantiate this harsh vs musical thing and I own and use 4 DAW's, one of which until recently was SAW which always gets accolades for its sound and stability. I have A/B'd all of my DAW's finished products. Mostly trying to hear this difference that I read about, but I never can hear the difference. I believe it is something other than the DAW. Do you have a strong opinion about differences people think they hear?

[Justin Frankel]

Originally Posted by sam c

Justin, I can never substantiate this harsh vs musical thing and I own and use 4 DAW's, one of which until recently was SAW which always gets accolades for its sound and stability. I have A/B'd all of my DAW's finished products. Mostly trying to hear this difference that I read about, but I never can hear the difference. I believe it is something other than the DAW. Do you have a strong opinion about differences people think they hear?

Well, I'm a big believer in placebo effects, and I know when things are slightly louder they often do sound "better"..

When people are comparing mixes, little things like getting the pan laws the same end up mattering a lot--otherwise one mix may end up significantly louder than another...

At the end of the day, having a reliable method of really comparing quality of mixes between different DAWs/machines is a very difficult problem.

[orange]

Originally Posted by Justin Frankel

Well, I'm a big believer in placebo effects, and I know when things are slightly louder they often do sound "better"..

When people are comparing mixes, little things like getting the pan laws the same end up mattering a lot--otherwise one mix may end up significantly louder than another...

At the end of the day, having a reliable method of really comparing quality of mixes between different DAWs/machines is a very difficult problem.

I totally agree. So many threads on Gearslutz break down into unsubstantiated bickering about things sounding better, check out any thread regarding cables to see what I mean.

I think IT IS possible to do reasonably accurate tests on audio equipment. They just need to be double blind and REPEATABLE. I think if people took the time to do this I think many would discover that placebo can do more for a mix than most of the highend items we discuss on Gearslutz.

[Bill Lorentzen]

My experience on testing agrees that pan law is a big factor. At one time I tested Samplitude vs Cubase SX, setting levels and panning apparently the same from one to the other, and Samplitude's mix sounded significantly better. Then I tried exporting each track of a tune as a stereo file at the level it was originally mixed and then played them back panned center with faders at 0 and I could hear no difference. Ah hah!

[MarkusColeman]

Originally Posted by Justin Frankel

Well, I'm a big believer in placebo effects, and I know when things are slightly louder they often do sound "better"..

When people are comparing mixes, little things like getting the pan laws the same end up mattering a lot--otherwise one mix may end up significantly louder than another...

hey Justin,

please help me understand this.
audio engine tests should result in zero, null, silence.
BUT only when you render an EXISTING (read: "prerendered") AUDIO track.

now when you render a midi track using a VST, unless the VST has a sample accurate "internal" sync to the sample accurate midi engine of the sample accurate audio engine.............shouldn't every test with (midi) track rendering result in a slightly DIFFERENT AUDIO FILE, even if you render THE SAME midi file with the same host?

thanks,
MC

[h2000]

Originally Posted by Justin Frankel

The chief disadvantages that I can see for 64 bit floating point are increased memory use, increased memory bandwidth use (which also leads to increased CPU use, though less and less on the newer Athlon64 and Core2s), and more chance of denormalization related slowdown.

We chose at the start to use 64 bit throughout, planning on newer faster machines with more memory and memory bandwidth, and so that we wouldn't have to deal with upgrading everything if it became important later.

Hi Justin,

I have never been able to get low CPU consumption while only streaming audio in Reaper (no FX). Compared to Vegas, it is 2-3x the CPU consumption. I have tried all the various options in Reaper and have tried all the suggestions from the forum to no avail. After what you mentioned here, it struck me that my problem could be related to having older 32 bit processors (Athlon XP 2400+) and a relatively low amount of older style memory (768M PC133). Do you think that this the problem?

I understand your reasons for going with 64 bit...it makes a lot of sense. I will of course eventually upgrade my system. But for me now, 40-50 streaming tracks and a few plugins is all I need, as I use outboard FX too. I'd love to start using Reaper on some larger mixes, but it's not possible now. Would more memory help my current system or is it futile?

Chris

PS: sorry to bring my personal technical issues into this thread, but I felt it was related to the topic and may be of use to others with older systems.

[Justin Frankel]

Originally Posted by MarkusColeman

hey Justin,

please help me understand this.
audio engine tests should result in zero, null, silence.
BUT only when you render an EXISTING (read: "prerendered") AUDIO track.

now when you render a midi track using a VST, unless the VST has a sample accurate "internal" sync to the sample accurate midi engine of the sample accurate audio engine.............shouldn't every test with (midi) track rendering result in a slightly DIFFERENT AUDIO FILE, even if you render THE SAME midi file with the same host?

thanks,
MC

It depends on the VSTi.. Many VSTis will produce consistent sample-accurate output.. others will humanize things, or have some internal state that isn't reset the exact same way every time.. hard to say ;)

-Justin

[Justin Frankel]

Originally Posted by h2000

Hi Justin,

I have never been able to get low CPU consumption while only streaming audio in Reaper (no FX). Compared to Vegas, it is 2-3x the CPU consumption. I have tried all the various options in Reaper and have tried all the suggestions from the forum to no avail. After what you mentioned here, it struck me that my problem could be related to having older 32 bit processors (Athlon XP 2400+) and a relatively low amount of older style memory (768M PC133). Do you think that this the problem?

I understand your reasons for going with 64 bit...it makes a lot of sense. I will of course eventually upgrade my system. But for me now, 40-50 streaming tracks and a few plugins is all I need, as I use outboard FX too. I'd love to start using Reaper on some larger mixes, but it's not possible now. Would more memory help my current system or is it futile?

Chris

PS: sorry to bring my personal technical issues into this thread, but I felt it was related to the topic and may be of use to others with older systems.

Hi h2000,

I remember your issue.. I wish I knew how to help.. It's odd seeing this, as on similar systems I've seen it go both ways...

[jamesp]

Originally Posted by h2000

After what you mentioned here, it struck me that my problem could be related to having older 32 bit processors (Athlon XP 2400+) and a relatively low amount of older style memory (768M PC133). Do you think that this the problem?

I run a slower CPU (XP1700+) but with a similar size of DDR memory. Reaper doesn't seem to be using excessive amounts of processing power compared to other software that I've used. Maybe the faster memory helps here.

Cheers

James.