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

parco

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

what driver do you mean?

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

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;
}

Noel Borthwick [Cakewalk]

parco
That is just a remastering work for a music with copyright already, so I just processed the most works in some single track softwares else and only decreased bit size in SONAR, and thus I didn't keep any SONAR project files for that.
 
I have that processed 44100Hz 64bit wav file in my hands, but due to the problem of copyright, I'm not allowed to post that file here. Would you mind if I send to you by PMs?

You should be able to repro the problem with any music content at similar gain levels. In any case if its hard to do, you can PM me a link to the original file that causes the problem with instructions on how to reproduce the problem.

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.

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.

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.

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;
}

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.

parco
So.......... does it count towards a lie to SONAR users while the export dialog shows us some dithering choices but actually not using them at all no matter what we've chosen........?