64bit N-Track?

Is there an advantage?

I’m wondering if there is any performance advantage to upgrading to Windows XPx64 and using 64 bit N-Track?

My guess is yes, since n-Track now uses a 64-bit internal data path. However, most plugins currently only support 32-bit format, so you would get no performance benefit for them. I’m curious to know whether n-Track’s built-in pluts support 64-bit format; if they do – especially for EQ – the benefit might amount to something noticeable. Otherwise, probably not.

You see, the DAW itself doesn’t do much number crunching or even data movement of the floating-point signals, it’s the EQ and FX that do that. And it’s only the 64-bit floating point signals that would benefit. (I think.)

I’m curious about what other folks think, and especially any comparisons anyone has done.

<!–QuoteBegin>

Quote
I’m curious to know whether n-Track’s built-in pluts support 64-bit format; if they do – especially for EQ – the benefit might amount to something noticeable.


I think it does now. See below

<!–QuoteBegin>
Quote
n-Track Studio changes log
n-Track Studio changes build by build

n-Track Studio version 4.2.1 Beta Build 2095 Released - Wednesday, April 19, 2006 2:41:00 PM EDT
Support for VST 2.4 specification
Support 64 bit processing in VST plugins
64 bit processing in n-Track Tempo Delay, Graphic EQ and Multiband Compressor effects

What about the standard EQ? That’s the one I was referring to. Hopefully it’s 64-bit too, from this point of view.

I doubt there’s much advantage in a 64-bit signal path, sonically.

<!–QuoteBegin>

Quote
What about the standard EQ?

I guess that is something only Flavio can answer.

But would going to 64 bit mean that it would require more horsepower (CPU, RAM, etc) to be able to process it, like going from 16 bit to 24 bit?

Going from 16 bits to 24 bits doesn’t require more CPU power or memory. (It does require more disk space.) Those are file or soundcard formats. When n-Track runs, it converts either of those formats to its internal format (which used to be 32-bit floating point, but is now 64-bit floating point).

On 32-bit Windows, it takes more CPU power to handle the 64-bit data path. Probably not much more, though. Also, I suspect the 64-bit floating point multiply takes longer than the 32-bit multiply – if anyone knows the instruction times please pipe up. (Note that even a 32-bit chip has 64-bit floating point operations. The main difference is the data paths in the “integer” processor, which does logic and data manipulation, not the floating point unit.) You see, on a 32-bit machine, it takes two instructions to move 64-bit values between memory and registers. On a 64-bit machine, it only takes one – but only if the program is compiled for 64-bit operation. I don’t know whether this is available for n-Track.

Clear as mud, right? It’s confusing, because there are all these issues:

- data path width used by software
- CPU’s “integer” operation data width
- floating point unit (FPU, part of the CPU)
- whether software is compiled to take advantage of 64-bit CPUs

Now the FPU always supported 64-bit operations, but it might do them faster on a 64-bit chip.

These are the obvious issues, and they’re all I’m aware of, but I’d be flabbergasted if there weren’t a few less obvious ones. (That would be just about the first time.)

Oh, RAM: You can pretty much bet on Windows and programs all taking more memory. Have you ever seen any “enhancement” where that didn’t happen? Specifically, though, many variables that used to sit in 32 bits take 64 bits, so yes more memory. Probably not a gross order of magnitude. I’d be more worried about the size of Windows and .NET than n-Track itself. Oh, though – the compiler might need to use more space for objects; virtual function pointers are probably 64 bits (anyone know?) There’s no end to details in these kinds of things! I rely on nerds – er, co-workers – who live & breathe this stuff when I need serious answers in these areas.

Yes I follow your explanation, learjeff, and greatly appreciate it. And you are probably right regarding all the different elements required to process the next platform coming our way (64 bit). I just know that when I migrated from 2 track 16 bit to 8 track 24 bit, it was very evident that my PIII 1Ghz machine didn’t have what it took. I ended up biting the bullet and getting a new unit (AMD 64 dual core 2Ghz, etc.) and never looked back.

I guess my question revolves around my concern whether I jumped too soon in getting a 64 bit processor, when Vista and .net and n-Track finally comes out of beta, I will realize that I only have an entry level machine.

Thanks for the explanation, learjeff. I hope you’re right.

Paul

I sure don’t know why your P3 1GHz machine didn’t cut it. I used a much slower machine with my MOTU 828. Might have been your MOBO rather than the processor. No matter; you’re better off now, with a machine that should serve you well for quite some time. I wouldn’t call it an entry level machine. Those Athlons have a great rep for screaming, and dual core means you can run about half again as many effects before running out of CPU.

The 64 bit processor won’t ever slow you down, and I bet it will speed things up when you get all the software ducks in a row. If not, you can always back down to 32-bit operation.

My suspicion is the biggest price we pay is disk space, but that’s pretty darn cheap. (Not for wave files, just for Windows, programs, DLLs & such.)

Thanks for the encouraging word. And you may be right about that PIII. It was an IBM Netvista and I don’t think it had what it needed. Even with a fresh install of Win98SE, nothing else running, it would drop bits n bites like a drunken sailor.

<!–QuoteBegin>

Quote
If not, you can always back down to 32-bit operation.

I hope I can. I went to try your suggestion a few threads ago - to be able play 24 bit files on a 16 bit setup, by trying a 4.x (24 bit) .sng on another one of my machines with 3.3 and a CL Live (16 bit) - it didn’t like the .sng file. So I’ve learned that 4.x .sng files are not downward compatible to 3.x. So I’m hesitant to move to a new platform only to find out I can’t go backwards.

Paul

Quote (learjeff @ July 10 2006,17:51)
I doubt there’s much advantage in a 64-bit signal path, sonically.

Hate to do this… but…

Download the trial version of Sonar 5 - it’s got a 64-bit internal path…

load a few tracks into Sonar, then minimize it… load the same tracks into n-Track… Don’t EQ anything, just adjust the pans and levels indentically in both programs… now A/B between the two… Sonar has a much more detailed image. Even without EQ my mixes sound better.

Is this a result of the 64-bit path in Sonar? Or is it some “trick” they are using? Or is it due to some limitation in the n-Track mixing engine?

OTH… Sonar 5 PE is $500 vs n-Track at $70 or so.

-John
:cool:

OK, John, but unless you’re using n-Track V4.1 or earlier, you’re comparing 64-bit to 64-bit. According to n-Track site, it has 64-bit sig path since V4.2. Do you hear a difference between V4.1 and V4.2 (without using any EQ or FX)?

Are you really sure you hear a difference? It sure is easy to fool oneself – a blind study is really necessary. I’ve fooled myself many times.

Frankly, what n-Track does is the best that can be done for summing: deferring all fader actions to the last possible moment and then applying them with a single multiply/add rather than two (for track and master fader). Furthermore, given that two DAWs both use this ideal technique (minimizing multiplies), and given no FX or EQ – just fader, pan, master fader, the results should be bit-identical. Because it’s just multiply and add, and math is math. (Of course, they might use slightly different roundoff values for “1 dB” or whatever, so this isn’t as easy to verify as it sounds.)

But, there is a difference between summing to 64 bits and summing to 32 bits. With older versions of n-Track, I don’t know whether the accumulator was 32 or 64 bits. (You don’t have to carry signals 64-bit all the way through for this difference to be significant. In fact, with no FX or EQ, there is zero difference between a 64-bit signal path and a 32-bit signal path – only a difference between 64-bit and 32-bit accumulation (summing)). That’s because, if you take a 42-bit signal and never modify it, it has exactly 24 bits of significance just before summing. Regardless of signal path (as long as it’s big enough to hold those 24 bits).

Tell ya what: send me two short wave files, identical mixes from 32-bit and 64-bit (without any EQ). I’ll send 'em back to you with different names. You tell me which is which. OK? (If you’re really interested, we can start a new thread: “64-bit shootout”.)

Quote (vanclan @ July 11 2006,10:46)
Thanks for the encouraging word. And you may be right about that PIII. It was an IBM Netvista and I don’t think it had what it needed. Even with a fresh install of Win98SE, nothing else running, it would drop bits n bites like a drunken sailor.

<!–QuoteBegin>
Quote
If not, you can always back down to 32-bit operation.

I hope I can. I went to try your suggestion a few threads ago - to be able play 24 bit files on a 16 bit setup, by trying a 4.x (24 bit) .sng on another one of my machines with 3.3 and a CL Live (16 bit) - it didn’t like the .sng file. So I’ve learned that 4.x .sng files are not downward compatible to 3.x. So I’m hesitant to move to a new platform only to find out I can’t go backwards.

Paul

First, note that I THINK you can revert back to 32-bit operation – but I was talking about CPU operation, not n-Track signal path.

And no, n-Track song files are not backwards compatible. Unfortunately!!!

I do wish Flavio would adopt a mechanism that isn’t so version-sensitive. It’s not rocket science; simpler than a lot of things n-Track does very well. There would be little hope of making it backwards compatible to CURRENT earlier versions, but it could be backwards compatible to FUTURE earlier versions (versions starting with the rework of the file format). Of course, any data for features not supported or substantially changed between versions would be ignored by the earlier version.

Quote (learjeff @ July 11 2006,15:35)
Are you really sure you hear a difference? It sure is easy to fool oneself – a blind study is really necessary. I’ve fooled myself many times.


I quit upgrading with each new build due to the fact that every time a new feature got added, something else broke. Sorry, but that’s my experience… I went back to using what was considered to be the most reliable build which was 1846 - this is what I did the comparison with. Since that build was only 32 bit and Sonar was 64 bit, I suppose that’s what I was hearing. I even had my girlfriend listen… I just gave her an A/B and asked her if she heard any difference, Sonar won hands down - but that was against build 1846…

I haven’t abandoned nTrack at all… I still use it with my laptop when I go to my drummer’s house to track drums (10-tracks at a time) because I know it works. For now. I did spend the $$ on Sonar and have been taking my time exploring the thing - even messed around with midi for the first time.

FWIW, I’m not attacking; I still think nTrack is a great value.


:cool:
-John

I’ve been thinking of going with a version of Sonar. How do you like it? Is it about the same resource wise? What kind of computer are you running it on?

I’m trying going back to build 1846… my problem regarding CPU load went down alot but I’ll let you know if that changes. I would go back to 3.3 if 1) i had a registration key for it and 2) there was some kind of backwards compatibility.

Quote (Rocket Boy @ July 11 2006,20:27)
I've been thinking of going with a version of Sonar. How do you like it? Is it about the same resource wise? What kind of computer are you running it on?

Sonar 5 PE.

n-Track does everything it can do (as far as I can tell) in the audio department. I don't know enough about MIDI to make an honest comparison between the two.

Sonar is not crash proof. It's crashed on me several times, and is really quircky if you need to change sample rates.

I've got a P4 3.0G 1G RAM and a MOTU 828 mkII

n-Track is still a great value, and worthy tool. Like I said, I still use it on my laptop for location recording.


-John

<!–QuoteBegin>

Quote
I do wish Flavio would adopt a mechanism that isn’t so version-sensitive

I heartily agree. And I don’t understand why Flavio chose this route. MS Office (love it or hate it) is downward compatible. I can create an Excel or Word file in Office 2003 at work and be able to read it at home with Office 97 - and there’s a lot of versions in between those two. This should be the norm for any software. Flavio, if you are reading this thread, please take note.

Paul