I think this has become a bit overly convoluted. Essentially the lower bit depth the more quantisation (squaring) of analogue signals will happen. 0dB is silence or your reference point from what we determine is louder and quieter. 
 
With 0dB in digital is essentially a limit of the equipment or process you are using, so if you are using an "analogue process/algorithm" . 24-bit is essentially that and 8-bit of floating point information. Some DAC use double-precision floating point to counteract aliasing and clipping.
 
24-bit is a a good resolution however as most consumer equipment is 20-bit sound/4-bit noise does it really matter.
 

Noel Borthwick [Cakewalk]
As I mentioned above we don't normalize inside SONAR - were passing the raw float data to Libsndfile which handles all the encoding tasks.

I also do not produce any music... I just send it to SONAR and wonder why most of the time it produce very strange sounding result
 
Back to serious. How libsndfile is going to work is controlled by "sf_command", including clipping processing, normalization, etc. And that should be set by Sonar.

Where is the dithering done when sending float to libsndfile? I.e. the objective is to write 24 bits after dithering from float. So is dithering done in the float-to-24-bit conversion? Therefore inside libsndfile? Or some other way? Seems dithering was not implemented in some earlier versions of libsndfile.

bvideo
Where is the dithering done when sending float to libsndfile? I.e. the objective is to write 24 bits after dithering from float. So is dithering done in the float-to-24-bit conversion? Therefore inside libsndfile? Or some other way? Seems dithering was not implemented in some earlier versions of libsndfile.

Really good question... Pow-R is "Platinum only" feature, I also do not think that happens in the libsndfile.
 
Also "Bit depth" influence the export, unclear which part of the software is using this setting (and how).
 
PS. I am almost sure that I will never be able to recognize dithering effect when converting from 32bit project  to 24bit, especially from material recorded at 24bit and processed by 64bit engine  

The only time SONAR's dithering will kick in for FLAC export is when you pick 16 bits as SONAR's export bit depth.
This is because all other formats are treated as float. For 24 bit export via LIBSNDFILE we pass through 32 bit float to libsndfile since it doesn't handle 24 bit input.
IOW in all the OP's use cases no dithering is being done in SONAR at all. I just checked it and it doesn't execute the dither code.
In the case of LIBSNDFILE encoders, the bit depth and other bounce settings from SONAR's export dialog are applied prior to the audio being sent for encoding. In most cases you will want to set those to match the project settings. i.e float, stereo and same sample rate as project. That way you leave it to LIBSNDFILE to do the final conversion to the destination format once.

azslow3
Back to serious. How libsndfile is going to work is controlled by "sf_command", including clipping processing, normalization, etc. And that should be set by Sonar.

We don't use sf_command to set any of the obscure LIBSNDFILE options today. We only use it to query properties.
They apparently have a SFC_SET_DITHER_ON_WRITE now for which there is zero documentation :)
The params for it show some rudimentary dither support.
 
Today most likely the default LIBSNDFILE behavior is to truncate data which is likely whats causing the noise.

Noel Borthwick [Cakewalk]

azslow3
Back to serious. How libsndfile is going to work is controlled by "sf_command", including clipping processing, normalization, etc. And that should be set by Sonar.

We don't use sf_command to set any of the obscure LIBSNDFILE options today. We only use it to query properties.
They apparently have a SFC_SET_DITHER_ON_WRITE now for which there is zero documentation :)
The params for it show some rudimentary dither support.
 
Today most likely the default LIBSNDFILE behavior is to truncate data which is likely whats causing the noise.

I put the latest libsndfile into platinum, no changes.
 
From my observations, the problem is that it does not truncate data by default. At least not for FLAC. So:
* export to WAV 24 bit - digital cliping
* export to FLAC 16bit (in dialog) - probably cliped in Sonar during dithering
* export to FLAC 24bit (in dialog) - no digital cliping but destroyed waveform at random (but reproducible) places
 
May be SFC_SET_NORM and/or SGC_SET_CLIPPING explicitly can solve that?
 
PS I want repeat that the effect is always reproducible for me. Not that I am ever going to export clipping projects into FLAC, but it is better to solve that to avoid confusion
 
PSPS exporting to 24 WAV, so truncated data, is as I understand "desired" OP effect. The noise produced by the bug is completely different kind...

Noel Borthwick [Cakewalk]
 
Actually SONAR does pass raw floating point data to LIBSNDFILE (when the export bit depth is 24, 32 or 64).
Internally libsndfile would be doing the conversion to integer before passing it to the FLAC encoder.
Based on the OP's observations it would appear that something is going wrong when LIBSNDFILE converts the float data to integer before doing the FLAC encoding.
 
From SONAR's point of view the code looks like this:
 
[code]long CLibsndFile::Write( char* pSamples, long cSamples )
{
 // Figure out the sample width and call the appropriate API to write the samples
 DWORD dwSampWidth = m_pwfx->wBitsPerSample / 8;
 switch (dwSampWidth)
 {
  case 2: // short
   return (long)sf_writef_short( (SNDFILE*)m_hf, (short*)pSamples, cSamples );

  case 3:
   // The assert below shouldn't fire because the caller should have disallowed a 24 bit source format
   // and upconverted to 32 bit instead - libsndfile doesn't support 24 bit as a source to encode from
   ASSERT(FALSE);
   return 0;

  case 4: // float
   return (long)sf_writef_float( (SNDFILE*)m_hf, (float*)pSamples, cSamples );

  case 8: // double
   return (long)sf_writef_double( (SNDFILE*)m_hf, (double*)pSamples, cSamples );
 }

  return 0;
}

Thanks for the clarification, Noel. It would appear that the standalone FLAC encoder does not itself use LIBSNDFILE, thus depriving itself of the ability to accept floating point data directly. I guess the author wanted to minimize external dependencies - even though libsndfile is universal, free under the GPL and can handle just about any data type you can throw at it.
 
A look at the code (flac.c in libsndfile) reveals some interesting math (e.g. multiplying by 0x7FFF to convert float to int and then calling lrint() to round it.), but I don't understand it well enough to say if it could result in overflows and misplaced sign bits (the code is almost completely devoid of comments). 

azslow3
I put the latest libsndfile into platinum, no changes.
 
From my observations, the problem is that it does not truncate data by default. At least not for FLAC. So:
* export to WAV 24 bit - digital cliping
* export to FLAC 16bit (in dialog) - probably cliped in Sonar during dithering
* export to FLAC 24bit (in dialog) - no digital cliping but destroyed waveform at random (but reproducible) places
 
May be SFC_SET_NORM and/or SGC_SET_CLIPPING explicitly can solve that?
 
PS I want repeat that the effect is always reproducible for me. Not that I am ever going to export clipping projects into FLAC, but it is better to solve that to avoid confusion
 
PSPS exporting to 24 WAV, so truncated data, is as I understand "desired" OP effect. The noise produced by the bug is completely different kind...

I can try SET_CLIPPING and see if it improves the results with the OP's file. 

Then I wonder that...... where does the POW-R dither be done? inside SONAR or libsndfile? As what I know....... the patent user license fee of POW-R is not cheap so far...........