A 64-bit file won't change the sound, it will increase the size of it.
 

interpolated
A 64-bit file won't change the sound, it will increase the size of it.
 

converting 24bit into 64bit won't change the sound, but then process the 64bit with sth like mixing, faders, pans, EQ or other effects always change the sound of bits lower than the original 24bit, especially in the fraction bits on the right hand side of decimal point. Just search inside the Cakewalk bitmeter VST then you will know.
 
That's why Cakewalk provides you a 64bit audio engine, Avid and RME give you 48bit (56bit actually) engine. Because audio processing usually need some algorithms like divisions, root, log, sin, cos, tan, etc....... Try 2/3 or square root of 2, 3 or 5 then you will know what I'm talking about. And also floating point samples give you dynamic headroom by movable decimal point, so you don't need to worry about clipping in track, bus or any rendering stages before final master output.......

While I tend to agree with whatever algorithms Sonar apply, what is 1. should stay 1.,
but with all the knowledge you have about algorithms you still try to play the game 0.0000000000234 / 0.0000000000234 under different bit depths. I mean you try to achieve best possible audio quality intentionally making it worse possible by letting end user DA crashing on digital clipping. Is that smart?   

that's still fine, my users they tend to love a little bit well controller colored clippings of various drum sounds for dancing music, house, disco, hiphop, R&B, or even acoustic funk (of course no those clippings in orchestra-only music, so it has to depend on genres). They told me that they only care about how long is the "sound tails" of the dry sounds...... too short? they are not going to pay me.........
 
But anyway we are not going to discuss about this in this thread.....

The 64-bit DPE is for computational purposes, and has had known issues in the past as being the culprit behind certain processes going south (why that stuck out when you said you are using it).
 
As far as an audio file itself is concerned, a 64-bit audio file is overkill to the max... it has already gone far beyond the capability of human hearing at 32-bit. The computations associated with 24-bit files is why higher word lengths are used (to allow for higher precision math)... the end result is still dithered back down.
 
Unfortunately, as technology advances, everyone thinks "more is better" when the ultimate glass ceiling is the ears of the listener... Technology surpassed human hearing capabilities long ago, so many can only "hear" this difference when they are using visual tools as a crutch.
 
The digital clipping is sort of a "hard stop" issue to always keep in mind. Even though processing can be done to compensate/tolerate this, certain media forms, algorithms, and the like most certaintly cannot (and it is those that cannot that will bite you).

I guess the problem is that SONAR creates floating point samples with the 64-Bit Double Precision - and FLAC cannot convert floating point samples.
FLAC FAQ writes:
In some cases it is possible to losslessly transform samples from an incompatible range to a FLAC-compatible range before encoding.
So the FLAC converter generates crackles although SONAR generates accurate samples, but unfurtunately with floating point samples. Then it is possible that different versions of the FLAC encoder generates different results.
 

THambrecht
Then it is possible that different versions of the FLAC encoder generates different results.

Not likely. The encoder does not modify the samples it is given, they must already be integer data. You can illustrate this by attempting to use the standalone FLAC encoder on a floating-point file. The encoder aborts with an "unsupported format" error. SONAR knows this and converts the sample data accordingly into a temporary file that's then passed to the encoder.
 
Any samples exceeding 0dB simply cannot be converted to integers. They can exist within SONAR only because floating-point data allows bigger numbers than the number of bits would otherwise accommodate.
 
Trying to convert >0dB values to FLAC is an exercise in futility. Blaming it on the encoder is like pouring 12 oz. of water into an 8 oz. glass and saying it's the glass' fault for getting your feet wet.
 
 
 

pacor: this effect is not the same as letting analog hardware clip a signal for added color. For that, use a digital clipper. It will give you the desired distortion while assuring that individual sample values remain within the valid range.
 

Taking usefulness of such clipping apart (I do not think "a little bit well controller colored clippings" should look like digital overflow presented in the screen-shots, but as correctly commented that is not OP topic... I mean I agree we should separate possible processing bug from any particular content and its fidelity), could someone reproduce that?
 
I have tried with several settings in X2 without "success" (I mean the result was expected).
 
In case you can not publish an example (no one asked for copyrighted material, I think you could produce just one second of any clipping sound and in your environment buggy conversion should be reproducible), can you at least exactly specify:
* Driver settings. 64-bit precision check box.
* Project settings. Sample rate and BitDepth.
* Export audio: Sample rate, Bit depth, Dithering algorithm, Sub format.

mettelus
 the end result is still dithered back down.

but dithering and noise shaping nowadays still depend on the bits which will be truncated away, so the contents inside the bits will-be-truncated can still be kept in a certain extent inside the dither noise and the rest bits. so dithering from the different bit sizes will still give out different results, whatever how much the differences will be.