A serious bug from FLAC encoder of SONAR Platinum when dithering out 24bit audio output...

There are so many terrible crackle noises when I tried to dither and export a 64bit floating point processed master audio into 24bit and encoded into FLAC file from SONAR. I thought that's because my audio gears, so I'd tried to clean all of them, but nothing helps....
 
So I decided to look into that flac file then I found those crackle sounds inside:

 
 
 
 
But when I tried to dither into 16bit and encode into FLAC from SONAR, no any crackle problems.
 
And so next, I tried to export the dithered 24bit result into wav file, and then encoded into FLAC by my own FLAC 1.3.2 codec downloaded from FLAC official website, all things are alright and no more crackle sounds finally!!

 
 
So you guys can compare about the crackle sounds from waveforms above at the exactly same sample positions....
 
And I found those crackle sounds appear only when I encode a 24bit result with final master clippings into FLAC.
When I encode a 24bit result with absolutely no any clippings or even no samples are all 1, all things are alright and absolutely no more any crackle sounds from the FLAC output.
 
So let me make a simple conclusion here:
Dithering 64bit into 24bit FLAC with clippings in SONAR: so many terrible crackle sounds.
Dithering 64bit into 24bit FLAC with all sounds below 0dB in SONAR: no crackle sounds.
Dithering 64bit into 16bit FLAC with clippings in SONAR: no crackle sounds.
Dithering 64bit into 24bit wav file with clippings in SONAR, and then encoded into FLAC with my own FLAC 1.3.2 codec: no crackle sounds.
 
So...... would it be the time for SONAR to stop using its "libFLAC 1.0.26pre5 20141125" and upgrade its FLAC codec into the latest up-to-date verison 1.3.2? 
 
 
My config:
SONAR platinum 23.4.0.38
Magix (Sony) sound forge 11 build 345
Windows 10 pro 1703 x64
Echo AudioFire 4
Nectar Impact GX61
Intel 2600

If the master bus is clipping then you are going to get crackling because the clipping gets converted/output along with everything else.

The master bus should never be allowed to go over 0dB.

There are a lot of problems if you do the final stage to CD with clipped audio.
In the second graphic there is a broken waveform by 01:22.170 and a distortion by 01:22.180
We have 15 years experience with digitazing tapes and vinyl. Also with mastering AudioCDs for a lot of clients.
OK - there is no crackle - but THIS waveforms will result as crackles by a lot of CD-players. You should also never reach 0 dB, because a lot of CD-Player crackle by reaching 0dB.
Our company has also ripped over 50.000 CDs to harddrive for a lot of consumers for example for the German National Library. We know the specifications. But I'm limited in writing and reading, because I must translate german into english.
 

The fact that you get unwanted artifacts ONLY when dithering from 24 bit into the same encoder seems to point to a code error...it is obviously a math issue because dithering the same clips 16 versus 24 gets different results...

My guess is you are correct and Sonar probably needs to pay more attention to FLAC than they have in the past, typically home studios do not really do the majority of their work in FLAC but it is becoming a defacto standard in future proof studio environments...24 bit lossless high Khz recordings are becoming standard sub genres in almost all the places I work with...so a little bit of code tweaking might be in order here.

Frankly it seems a little odd to me that you would get crackles at 24 and NOT 16, that seems backwards dithering at 16 bit give you LESS headroom than dithering at 24 bit...I am not convinced its a code issue unless you can replicate it on another project...anomalies happen.

By the way, there is absolutely no reason to have clipping in a DAW, its just bad form...Sonar (and about a hundred other vendors) offers a decent limiter...it's there for a reason...

I thought every sound engineers should know how to read waveforms but it seems like I was wrong......... 
For clippings leading to other troubles than flac encoding, they are another matters. I will deal with but not now this stage. I can fade down the level of Izotope limiters, change the limiting rules or make them soft-clipping (round-angle clippings) or more and more other ways. So it's not necessary to worry about that for me, I know the Pope is Catholic and Paris is in France of course. 
 
Only Psychobillybob here is the smart one and really understand what's the problem I described. the same clipping track is completely alright when bouncing into 16bit flac or 24bit wav file, and encoding by FLAC 1.3.2 is completely alright as well. I can't imagine how complicated would the topic be.......
 
 
And I can't understand why today 2017 SONAR is still using the testing version "pre5" of FLAC (or something like beta/alpha versions) and not any stable versions of FLAC like 1.3.2, 1.3.1 or previous.........
I think v.1.0.26 of 25th Nov 2014 is an antique FLAC version.........

parco
For clippings leading to other troubles than flac encoding, they are another matters. I will deal with but not now this stage. 

I'm confused. You concluded in your first post:
 
Dithering 64bit into 24bit FLAC with clippings in SONAR: so many terrible crackle sounds.
Dithering 64bit into 24bit FLAC with all sounds below 0dB in SONAR: no crackle sounds.
 
Wouldn't that imply that clipping is the source of the crackle sounds? 
 
Anyway, try Noel's suggestion of downloading the latest encoder and see if that helps. I tried a FLAC export using the existing encoder of three 64-bit files (one with peaks at -0.1, one with peaks at 0, and another where after normalizing I applied 3 dB of gain to cause intentional clipping) with Pow-R 3 dithering and there are no crackles in any of the exports. I used signed 24-bit PCM as the Sub-Format. To investigate any further, I would need a more precise recipe to reproduce because I cannot obtain the results you obtain, except for no crackles with signals under 0.

parco
but
 

Dithering 64bit into 16bit FLAC with clippings in SONAR: no crackle sounds.
Dithering 64bit into 24bit wav file with clippings in SONAR, and then encoded into FLAC with my own FLAC 1.3.2 codec: no crackle sounds.

 
I use 250ms buffer for fast bounce. and pow-r 2 dither, 64bit engine turned on, but all other checkboxes are unchecked except the 64bit and fast bounce.

If its still happening with the latest FLAC support in LIBSNDFILE its hard to say where the issue is.
You may need to provide a project file with the audio that exhibits this problem. Just upload it somewhere and provide a link.

https://xiph.org/flac/faq.html:
It's unlikely FLAC will ever support floating-point samples natively. The main application for floating-point is audio engineering, which demands easy editing and very high speed for both encoding and decoding above everything else.

FLAC is designed as a consumer audio format ... for playback.

But my master file is a 64bit wav file so I have to turn on 64bit engine, otherwise.... truncate to 32bit before dithering and noise shaping?
 
And then that's even more stranger........ should it process all things and truncate in internal PCM streams before sending to libsndfile/libflac? Can't imagine about doing dithering and truncation just inside libsndfile/libflac........
 
In common sense, that should be: 64bit file -> all pre-processes -> re-sampling if need -> dithering + noise shaping -> truncate to 24bit PCM -> send 24bit PCM samples into libsndfile/libflac module
I can't imagine if libsndfile/libflac or mega-nerd they get enough funds to pay the patent royalty of luxuriously expensive POW-R dither. Only Cakewalk and Avid Pro Tools and other large DAW systems paid. Even Sound Forge has not paid for POW-R.
 
So, if like what THambrecht said, there're something to do with 64bit engine, before truncation and sending into libsndfile/libflac, then there should be something wrong inside SONAR somewhere else, but totally nothing to do with libsndfile or libflac...... only 24bit samples are sent to libsndfile/libflac but not any 64bit FP samples.....

A 64-bit file won't change the sound, it will increase the size of it.
 

While I tend to agree with whatever algorithms Sonar apply, what is 1. should stay 1.,
but with all the knowledge you have about algorithms you still try to play the game 0.0000000000234 / 0.0000000000234 under different bit depths. I mean you try to achieve best possible audio quality intentionally making it worse possible by letting end user DA crashing on digital clipping. Is that smart?   

The 64-bit DPE is for computational purposes, and has had known issues in the past as being the culprit behind certain processes going south (why that stuck out when you said you are using it).
 
As far as an audio file itself is concerned, a 64-bit audio file is overkill to the max... it has already gone far beyond the capability of human hearing at 32-bit. The computations associated with 24-bit files is why higher word lengths are used (to allow for higher precision math)... the end result is still dithered back down.
 
Unfortunately, as technology advances, everyone thinks "more is better" when the ultimate glass ceiling is the ears of the listener... Technology surpassed human hearing capabilities long ago, so many can only "hear" this difference when they are using visual tools as a crutch.
 
The digital clipping is sort of a "hard stop" issue to always keep in mind. Even though processing can be done to compensate/tolerate this, certain media forms, algorithms, and the like most certaintly cannot (and it is those that cannot that will bite you).

THambrecht
Then it is possible that different versions of the FLAC encoder generates different results.

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.
 
 
 

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.