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

But bro...... huh...... do you really think the Xiph.Org Foundation and Mega Nerd can really afford patent royalty fee of POW-R dither and truncate inside LibFlac/LIBSNDFILE? Do you really understand what I really mean guys?

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.
 

that's what izotope ozone limiter does.

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?

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?

Sonar Preference has only one "Driver settings" section.
 
PS. so far could not reproduce under Platinum as well. I have tried several settings, but it will be simpler in case you specify exact settings with which you observe the effect.

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.

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.

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:
 

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

 

azslow3

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?

Sonar Preference has only one "Driver settings" section.
 
PS. so far could not reproduce under Platinum as well. I have tried several settings, but it will be simpler in case you specify exact settings with which you observe the effect.

OK, here're for you:
 
The one second crackle sample:
https://1drv.ms/u/s!ANdgTSeq042ThFk
 
The driver settings:

 
 
 
The project settings:

 
 
The Export settings:

 
 
 
And the subformat:

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.

 
Just sent you a PM message, please check.

So, my observations. All settings as in your dialogs, except specified explicitly:
1) Original signal mixed heavily over 0dB
1.a) "Export audio" dialog "Bit depth" 24  : FLAC has not digitally clipped the signal (also over 0db), heavy digital "bugs" in the waveform, of 2(!) types:
 I) one is already mentioned big +-
 II) DC shift of sample groups (like to +6dB, so completely out of +-0 region).
 
1.b) "Export audio" dialog "Bit depth" 16 : FLAC IS digitally clipped (no signals over 0db), but no bugs in the waveform
 
2) Original signal mixed in general under 0db, but one time it is over 0 db : the same is 1.a, so the waveform is buggy
 
3) Original signal mixed strict under 0db, no problems.
 
Note: when analyzing previously posted screenshots or reproduce that in Sonar, keep in mind that Sonar is drawing strain line on the border of visible area (f.e. 0db). Zoom our dB scale to check that the signal is really clipped there or in fact cross the border.
 
My conclusion: with 16bit setting, exported material is digitally clipped at 0db. With 24bit setting the signal is somewhere (Sonar, libsnd, flac?) normalized to allow saving over 0db and something in this procedure is buggy (the signal is destroyed not only on limit).
 
For the "usefulness" discussion: since in 24bit mode the signal is not clipped but scaled, even when the bug is found and fixes there will be no sense to use that approach. I mean the effect is the same as just lowering master output volume and than write in the file header "maximum level is thought to be +5dB instead of 0".

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