when to use 64 bit engine?

[sadicus]

I notice some of the audio export has 64bit engine off by default. When to Export Audio with 64bit engine?
 

[DeeringAmps]

14 minutes ago, sadicus said:

When to Export Audio with 64bit engine?

This is a good question!

Occasionally in the past, some had issues; right?

[Starship Krupa]

From The Cakewalk Reference Guide: "You can also render at 64 bits for greatest precision."

Now as to what precisely is meant by "greatest precision," the documentation seems to be silent. ?

Also, from the online documentation, "If you don’t usually run Cakewalk in 64-bit mode in order to save CPU, you can turn 64-bit mode on when you export audio by enabling this check box. Remember to turn it off after you export your audio, if you don’t want to use it during tracking or mixing."

No hint as to why you would want to do this.

I usually select the option because, hey, it's free and it doesn't seem to affect anything in a negative way. If the feature didn't exist I wouldn't miss it, because I have to trust my ears that my mixes sound like I want them to. If I heard aliasing distortion in my mix, I'd do something to get rid of it at that point (like enabling oversampling in the plug-in itself), not rely on oversampling in the rendering engine to clean it up.

There's the possibility to consider that a plug-in might not function the same way if you feed it 88.2KHz. I've only run into one that didn't behave, and it was obvious.

[Clovis Ramsay]

14 hours ago, sadicus said:

I notice some of the audio export has 64bit engine off by default. When to Export Audio with 64bit engine?
 

I always have a hard time remembering that a 64bit engine is not the same as a 64 bit CPU.   The difference being, 64 bit audio processing and rendering is far cleaner than 32 bit simply because of math.   But I am not a smart person with all this math hocus pocus so simply is not something one should describe this situation,,,,,,,,,

I may or may not understand the subject in question but it goes a little something like this....ahem!;   When recording/rendering/processing in 32 bits there is a problem with  the length of the repeating integers that occur in the division of 32 bits.  So the long repeating string of numbers that translate back into audio has to be blunted or truncated which introduces artifacts and sample distortion.  64 bit does not have this issue as it divides down into whole numbers so there should or could be faster processing times due to less rounding and blunting a string of repeating integers.  The trade off would come in the form of larger audio files which would offset any of the performance gains picked up from 64 bit.  

But I predict in the near future things will just be and do  and math will never need to happen again!

[tulamide]

1 hour ago, Clovis Ramsay said:

I always have a hard time remembering that a 64bit engine is not the same as a 64 bit CPU.

That's the point. A 64-bit CPU communicates based on the length of 64 bits (or multiples thereof). Be it busses or address registers. Everything can be done on 64-bit wide communication. But that's the hardware side of things.

On the software side of things, apps at all times use data types, that are totally detached from a processor's architecture. We wouldn't have seen the game Elite, which used 32-bit data types although running on a 16-bit processor architecture.

Cakewalk internally uses certain data types to represent audio samples. A sample in dsp is the smallest slice of data in audio streams, a sample point. Because recording audio is done by getting a sample of the original every x seconds, where x is usually very small, like 44100 times per second. The value of a sample is a representation of how strong it makes the membrane of your speaker/headphone/etc deflect outwards or inwards, which is why it is considered to be in the range of -1 and +1, and so naturally such a number will have quite a few digits at times. In the past, for example when working with 16-bit data types, this was less of an issue, because the number was actually stored as a so called 16-bit signed integer, in the range -32768 to +32767. But that means, you only have 65536 descrete steps to represent a sound wave's "curviness". And so DAWs soon switched to using what's called a single-precision floating point format, or single float in short. This is a format that instructs the CPU about the actual value, instead of really being a value by itself. It is 32-bits wide, and this range is divided into 3 fields, the sign, exponent and mantissa. The CPU uses a single to do this calculation: -1^sign * 2^(exponent-127) * 1.mantissa
the sign is 1 bit, the exponent 8 bits, and the mantissa 23 bits. To pass this scary part, let's just say, both exponent and mantissa are limiting. This format can't represent every possible value. And so the cpu rounds numbers to nearest neighbor, if the exact value can't be reached. This makes things imprecise on edge cases. For example, a sound wave's value could become a very small number instead of 0. And many more unwanted effects.
When using "64-bit engine", Cakewalk switches the whole audio stream pipelines to so called double-precision floating point format, or double float in short. A double is 64-bits wide and its exponent is 11 bits wide and its mantissa 53 bits wide. This is still error-prone, but now there is way more headroom, before inaccuracies appear.

This higher precision of course means, that everything takes a tiny bit longer to calculate  and the memory usage of course is higher. Both is of no concern if your PC is a rather recent one, say, 5 years old. You also get a higher dynamic range (but of course only inside Cakewalk). As soon as you render to anything other than 64-bit, you will raise the noise floor again.

So just use 64-bit engine mode, whenever you want (best, by activating it via Edit > Settings > Audio > Driver settings, I'm on the German version, so the path might be named a bit differently in English), the downside is neglectable and the higher precision will yield more accurate results (even if often we won't notice them).

[bitflipper]

In practical terms of audible fidelity, it doesn't really matter whether you use it or not. Leave it on if doubling your memory usage isn't an issue and you just feel better knowing that any cumulative math imprecision is going to be buried so far below the noise floor that it can never matter. But I can think of no real-world use-case where it would be a necessity.

Sure, you can go off into the weeds with the math and convince yourself there's a benefit, and an abstract case can be made that there truly is. But I'd challenge anyone to actually discern a difference in a blind A/B test. It's certainly easy enough to test for yourself: just export the exact same mix with it on and again with it off, then ask someone to randomly select one and then the other while you listen.

 

[tulamide]

1 hour ago, bitflipper said:

In practical terms of audible fidelity, it doesn't really matter whether you use it or not. Leave it on if doubling your memory usage isn't an issue and you just feel better knowing that any cumulative math imprecision is going to be buried so far below the noise floor that it can never matter. But I can think of no real-world use-case where it would be a necessity.

Sure, you can go off into the weeds with the math and convince yourself there's a benefit, and an abstract case can be made that there truly is. But I'd challenge anyone to actually discern a difference in a blind A/B test. It's certainly easy enough to test for yourself: just export the exact same mix with it on and again with it off, then ask someone to randomly select one and then the other while you listen.

 

I agree. My contribution was just to explain what is actually meant with a rather non-explaining term like "64-bit engine". Wether you see a need to use it or not, is everyone's personal decision.

If you don't mind dc-offsets, denormals and other symptoms caused by it, leave double precision off.

It of course is not doubling your memory usage, as it's just the engine that uses a 64-bit value instead of a 32-bit. I doubt you will even notice a memory difference, since apps are dynamically allocating and releasing memory. But yes, if concerned about some bytes of memory, while loading your 60 GB string library, don't use it.

Yes, 32 bit is just fine with audio streams. If all audio streams had 32-bit each. Unfortunately, you're mixing like 40 tracks to just one stereo track, which would benefit so much from double precision while mixing. But if you're frightened of 64-bit data types, you better don't use it.

Yes, do the blind A/B test. Erm, wait a second, you do this on your hardware, don't you? The hardware, that never gets in touch with 64-bit precision, but gets down-rendered audio, like 24-bit @ 44.1 kHz? Maybe even dithered? So you don't listen to 64-bit audio, but 24-bit or maybe even 16-bit audio, which says nothing about the 64-bit precision within your DAW. So what's the test then for? Ah, probably to see if your hardware really doesn't make a difference between 24-bit and 24-bit! Yes, that makes sense. In other words, using an apple to judge the quality of a banana.

And of course, let's not forget that some years ago, it was 16 bit @ 44.1 kHz, that was considered the best possible audio. Yet, most studios expect you to deliver 24-bit @ 48 kHz nowadays. How strange that we have to work with formats that are better than the best possible audio format. Don't progress, I say, let's keep things, where they were. Like 40 years ago, when OS developers stated "640 kB of RAM is enough". And it was. For like half a year. Then things progressed.

With bitflipper and my remarks, you now have a lot of personal opinions, which you can either use or not, to decide wether to use 64-bit precision or 32-bit precision, when calculating numbers.

Edited September 20, 2021 by tulamide
spelling

[Glenn Stanton]

it's likely that few people would notice single vs double float processing - i believe in the old forum someone had done some tests with reverb tails tapering more nicely on the double float but it was also specifically testing for it versus what it would be in normal material. since the 64-bit option has been there in SONAR and CbB, i always have it checked.

i'm perfectly comfortable using 64-bit processing ?. i just don't use any type of float when processing overnight fed fund currency swaps ? 

as a note,  i generally export either 48K or 44.1K @ 24-bit, no dither WAV. subsequent processing via Ozone 9 which may or may not use double float to render 44.1K 16-bit WAV and MP3.

[treesha]

IIRC  I have had it happen a few times that on export I didn’t notice the 64 was being used and when I went to import that exported file into something else I use (don’t recall which program) I got a message basically the other program couldn’t import it. So I went back to the cakewalk export box and changed from 64 to 32 or 24 (?) and it worked fine in the next program.

[tulamide]

33 minutes ago, treesha said:

IIRC  I have had it happen a few times that on export I didn’t notice the 64 was being used and when I went to import that exported file into something else I use (don’t recall which program) I got a message basically the other program couldn’t import it. So I went back to the cakewalk export box and changed from 64 to 32 or 24 (?) and it worked fine in the next program.

You might confuse the audio engine with an export format here. Wether the engine is set to 32-bit or 64-bit has no influence on the export formats you use. Those are seperate from the audio engine's inner workings. You can always render to a format, that other tools, distributers or hardware understands. Or make a mistake and choose a format that they don't understand.

[treesha]

I work in cakewalk at 64 bit but in the export box there is an option to export at 64 bit. I noticed a few times when the export box had 64 bit for some reason(?)  (i normally choose 24) that when i tried to use another program on the exported file that it was not acceptable to the next program. Cant recall which program didn’t like it. Just an aside to the subject. 

Edited September 20, 2021 by treesha

[tulamide]

1 hour ago, treesha said:

I work in cakewalk at 64 bit but in the export box there is an option to export at 64 bit. I noticed a few times when the export box had 64 bit for some reason(?)  (i normally choose 24) that when i tried to use another program on the exported file that it was not acceptable to the next program. Cant recall which program didn’t like it. Just an aside to the subject. 

Yes, that's what I mean. Exporting to 64-bit has nothing to do with the setting of your engine. You can export to 32-bit and 64-bit (among a lot of other formats). Those two options would be used, if you know beforehand that, say, the studio that does the mastering for you, uses a 32-bit or 64-bit engine in their DAW. It can than access the original data, without converting it. Any audio file you load into your DAW, is automatically converted to whatever format the engine is in. If you run your engine at 32-bit, the 16 bit audio file you load will be converted to 32-bit for use within Cakewalk. It gets out at whatever format you choose to export.

Under normal circumstances, you want to export in 16 or 24 bit most of the times, though.

[treesha]

I posted my experiences to say that if someone works in 64 bit and unknowingly or accidentally ( as happened to me somehow ?) exports a file at 64 bit it may not be acceptable to another program as happened to me. 

[azslow3]

Most discussions when it comes to 32 vs 64 bit (44.1 vs 96 kHz, etc.) ends discussing fidelity. While in practice the problem is in bugs/mistakes (sure they can influence fidelity up to destroying the sound or even crashing the DAW).

32bit floating point is sufficient to represent 24bit audio (fixed point) bit accurate. Really meaningful for the best audio interfaces are 20-21. Really meaningful for a human is even less (16-17 at most).  But people which write music software are way less careful then people calculating atom reactors, also checking that cranking all possible parameters will not produce crazy math calculation is almost impossible. As the end effect final numbers calculated using 64bits and 32bit can differ in the first 16  most significant bits. F.e. if you export audio as 16bit after 32bit and 64bit processing the result can be (up to significantly) different.
I repeat, that should not happened in case the author is careful in what he/she is doing, but all of us are not perfect.

Also audio processors (f.e. VSTs) use different code to process in 32 and in 64 bits (VSTs process audio in these 2 formats only, f.e. they can't process 16/24bit fixed audio). Normally one code calls another or one source is used to produce both codes, but that is not guarantied. I mean it can happened one code has a bug while other doesn't. May be not really a bug, just different result.

Based on written, I suggest to use the same engine all the time to avoid possible troubles. So after mixing in 64bit engine also export in 64bit engine (but not into 64bit file formats, that is not my suggestion).

I guess when computers was old, there was people who prefered mix in 32bit and export as 64bit, a kind of "online"/"offline" quality.

-----------------

Still OP question is valid and not yet answered: does the option in the Export dialog still switch the engine or just a historical artifact? F.e. in case 64bit is on in the preferences and that option is unchecked, does Cakewalk "downgrade" the engine to 32bit during export?

 

[tulamide]

3 hours ago, azslow3 said:

Still OP question is valid and not yet answered: does the option in the Export dialog still switch the engine or just a historical artifact? F.e. in case 64bit is on in the preferences and that option is unchecked, does Cakewalk "downgrade" the engine to 32bit during export?

Oh. I see! This slipped through.

According the the documentation, this option exists, in case you have your engine set to 32-bit, but want to export with the 64-bit engine. You don't need to tick it, if you already use the 64-bit engine (because you activated it in Edit > Settings > Audio > Driver settings).

 

Quote

If you don't normally run Cakewalk in 64-bit mode to conserve processor power, you can enable this mode for audio export by checking this box. Don't forget to switch off the mode again after exporting, unless you want to use it for composing or mixing.

 

[sadicus]

yes I do mind "mind dc-offsets, denormals and other symptoms" lol
Here are all the places I found "64-bitEngine" Thanks everyone for the explanations!

 

[tulamide]

1 hour ago, sadicus said:

yes I do mind "mind dc-offsets, denormals and other symptoms" lol
Here are all the places I found "64-bitEngine" Thanks everyone for the explanations!

 

Just a reminder, in case I explained it too complicated, and a picture says more than thousand words: If you have 64-bit engine ticked in the preferences, like in the first picture, there's no need to tick it in the third picture (it is already active). The second picture shows the export formats, that are detached from the 64-bit-engine. If you select 64-bit there, you don't change how Cakewalk works with audio, but export a 64-bit audio file (which will hardly be accepted by any application other than a DAW)

[sadicus]

It just happens to be on with some selected presets.
Workflow:
Export 48/24bit WAV no dithering
Import to Ozone

[Glenn Stanton]

21 hours ago, Milton Sica said:

This topic is discussed by many users without any input from the Cakewalk development team.

just to summarize - we're asking about the 64-bit engine - on or off - with regards to how it impacts the rendering of 1) the mixing process, 2) the export out file?

maybe @Noel Borthwick  can clarify but my understanding is the 64-bit engine processes using 64-bits versus 32-bits in-CPU/in-memory and then depending on your project word size, would store the results by either truncate? or dither? or as @Milton Sica notes - we don't really know what's going on ? 

[Noel Borthwick]

These links should help.

http://forum.cakewalk.com/64bit-Audio-engine-vs-double-precision-engine-and-a-dithering-question-Noel-please-m3804976.aspx

https://www.cakewalk.com/Press/Release/1047/White-Paper-Benifits-of-x64-for-Audio-Workstations

Essentially the 64 bit engine uses double precision floating point numbers from end to end assuming that plugins support it.
The main advantage of 64 bit computing is that its very tolerant of errors that build up over thousands or millions of computations and has a massive dynamic range. You can literally do multiple mixing gainstages that clip > 0dB or go to very low levels and then scale back up with no audible errors creeping in. In fact the original white paper had a test project that did something like that.
Not only is it advantageous for mixing, it is actually more efficient for modern CPUs to process. 

As far as the export settings go, its simply a way to control whether you want the export to use the 64 bit engine processing or not. I.e you can have it disabled in preferences and enabled in the export or vice versa, (If its disabled in export it will NOT use 64 bit processing even if it’s ON in preferences)

The delivery file format is independent of the engine precision. You can choose to export to 16, 24, 32 or 64 bits. Obviously 64 bits will retain the full resolution and integer formats will be dithered down. There are still advantages to mixing in 64 bit even if rendering to 16 bit because the conversion happens at the last stage. Whether you will hear a difference with 64 bit really depends on the processing in the project. In simpler projects without a ton of buses and processing its unlikely that it would be audible.