pwalpwal

parco

Noel Borthwick [Cakewalk]
Libsndfile is external to SONAR. Dithering is applied when SONAR converts from float to integer. Since in this case we do not convert to integer before sending the audio to libsndfile there is no dithering applied (at least at the SONAR level). So today the only case with libsndfile where dithering would apply would be when you pick 16 bit as the export bit depth in SONAR.

So are you telling me that there are totally no any dithering done but only truncation while exporting to 32bit or 24bit?

and to clarify, this is only when exporting to flac?

The general rule for when we apply dither within SONAR:
 
Source Depth                  Dest Depth
64                                  32/24/16
32                                  24/16
 
The exception is for any encoders like LIBSNDFILE that won't take 24 bit integer formats. For those dithering wont take place unless the engine format is 64 bit (double precision)

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.

Noel,
For me the nice lesson is I can set Dither and forget it. Cakewalk will apply it when appropriate. I don't have to worry about turning it on and off. It's like it's on an automatic setting.
 
It also means I don't have to set it for triangular for internal bounces and pow-r for exports. I used to do that thinking that internal shaped dither might stack up. This is not necessary.
 
It's a small thing but it saves me thought and clicks.
 
Thanks!

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...........

If you hear a difference going from 32- to 24-bit, it's not dither.
 
With 24 bits, dither noise is so low in volume (~ -120dB or lower) that there's literally no way you can hear it - other than intentionally isolating and amplifying it specifically so that you can hear it. For example, recording silence and then turning the silent track up by, say, 80 dB and placing your ear next to the speaker. 

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.

New status update here:
 
When I'm still not sure if Cakewalk have already started looking into and working on solving this problem on their own initiative, meanwhile, I've just sent this email to  erikd@mega-nerd.com to contact Mega Nerd, who is the author of Libsndfile:
 

Hi Mega Nerd,



I have some questions about writing 24bit PCM samples into libsndfile, as flac files and wav files.



1. What value type of numeric data should I use to input 24bit audio samples into libsndfile for writting audio files? Like sf_write_int or sf_write_float? And how should I do or anything should I take notice of?

2. Would there be any internal dithering auto-applied inside libsndfile when I give libsndfile larger size samples but require libsndfile to write an audio file with smaller sample size, e.g. giving 32bit FP, 64bit FP or 24bit integer samples to libsndfile to write into a 16bit file?

3. We are experiencing some random artificial crackles which destroying waveform in random places when we give floating point samples to libsndfile to write into a 24bit flac file, but we never experience the same crackle situation when we give FP samples to libsndfile to write into a 24bit wav file…. What’s wrong inside the libsndfile? And the crackles only appear when there are some clippings in the source audio, but crackles never appear when I encode the same clipping wav source by the official libflac encoder from xiph.org…… The complete detail of this bug is inside this thread here of Cakewalk forum: http://forum.cakewalk.com...o-output-m3607265.aspx



The libsndfile is v.1.0.28

I’m glad to waiting for your reply, thanks a lot.



Parco

 
I'm not sure if that is the only email address I can contact Mega Nerd, so please anyone tell if there are any email addresses I can contact them as well.
 
Besides, I've post that bug of flac as an issue in their libsndfile github.

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!

So you're saying the easy workaround is to select 24 as the bit depth before exporting to FLAC? If so, good catch!
 
 

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