gswitz
I suppose with floats you could dither the least significant bit, but the variance of level of this dither would significantly complicate quantifying the benefit of that dither. Also, with thirty two bit bounces where every available bit is used at the loudest moments, humans could never detect the precision on any system.

I believe that what Noel is saying is that dither is never applied to floats. That would mean that internal bounces never get dither, regardless of your settings, since the files created are floats. Noel?

Corollary: changing the setting for dither between internal bounce and export is not necessary.

Actually dither gets applied when you convert from 64 to 32. I believe POWR supports that.
For internal bounces it will only dither if the render bit depth is set to < 32.

azslow3
Sorry people, I am noob and probably not getting something right about dithering and the difference in the bit depth.
 
* the first question is theoretical pure: if someone want dithering when moving from 32 to 24 bit, how he/she can test it is really working? I mean for that, that someone need at least 32bit (real DAC bits!) interface.
 
* the second is simple test inside Sonar: export some peace as 24bit WAV and the same peace as 16bit WAV. Import both into 2 tracks (24 bit project and audio drivers) and add Channel tool with flipped phase. Start playback. Can you see or hear SOMETHING? I mean my master bus show -96dB and my speakers/phones keep absolute silence.

I can hear something from my H|H (BHC caps inside) + Wharfedale passive monitors but can't tell what's that sound...........

parco
I can hear something from my H|H (BHC caps inside) + Wharfedale passive monitors but can't tell what's that sound...........

I can be wrong with some fine details of the following, I am not sound expert (but I have worked with ADC/TDC/DAC hardware).

That is "digitization" noise, so the difference between 24bit shaped signal and 16bit shaped signal. By itself is should not sound like anything in the original material (that will indicate misalignment of both clips). And it is quite by definition (on the level of least significant bit from 16). The whole "dithering" is on the level of that "noise". You can think about it "reversed" way: that is the signal which should be added to 16bit data to receive original 24bit data (exact).
 
To check what you hear is really this signal (and not the noise generated some other way), instead of 24bit and 16bit clips use 2 instances of 24bit clip. Since the phase inversion produce perfect digital mirror, resulting signal is absolute zero. So you should get absolute silence on output.
 
For more deep explanation, https://xiph.org/~xiphmont/demo/neil-young.html gives the overview which sounds reasonable for be, from technical, mathematical as well as practical points of view.

Noel Borthwick [Cakewalk]

gswitz
I suppose with floats you could dither the least significant bit, but the variance of level of this dither would significantly complicate quantifying the benefit of that dither. Also, with thirty two bit bounces where every available bit is used at the loudest moments, humans could never detect the precision on any system.

I believe that what Noel is saying is that dither is never applied to floats. That would mean that internal bounces never get dither, regardless of your settings, since the files created are floats. Noel?

Corollary: changing the setting for dither between internal bounce and export is not necessary.

Actually dither gets applied when you convert from 64 to 32. I believe POWR supports that.
For internal bounces it will only dither if the render bit depth is set to < 32.

Cakewalk guys, I think your technical staffs should have a look on this thread from the github of Libsndfile:
https://github.com/erikd/libsndfile/issues/294
 
So now you may have 2 ways, 2 choices to solve this crackle problem:
 
Way 1:
You should set the sf_command() interface with SFC_SET_NORM_DOUBLE = SF_FALSE and SFC_SET_NORM_FLOAT = SF_FALSE, and also SFC_SET_CLIPPING = SF_TRUE
or just simply look into every floating point sample, with something like

IF sample > 1 then sample = 1

or

If sample >= 1 then sample = 0.9999999999...........

 
Way 2 (Preferred):
Export 24bit results like 16bit results, dithering in SONAR with POW-R, rectangular or triangular, inside SONAR, not inside libsndfile, then truncate into 24bit integer, in SONAR as well, not inside libsndfile.
Finally, to send 24bit integer samples to libsndfile, just use "int" functions/interfaces like sf_write_int, add 8 zeros on the right hand side (the 8 least significant bits) of the 24bit number and store as a int variable for sending to libsndfile, mark the preferred destination as a 24bit file.
Then libsndfile is going to auto truncate those 8 zeros on the right hand side (the 8 least significant bits) away when writing into a 24bit audio files.
 
So the way 2 is the best way! just solved all problems perfectly!

and truncate before sending to libsndfile, not letting the libsndfile truncate inside.... huh.........

I haven't had any issues with the encoder, using 24 bits at export rather than 32.