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.

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.

You have 64 bit Double Precision Engine checked? Try unchecking that and see what happens.

Just testet with +12dB clipped.
With 64 Bit Double Precision I get a lot of artefacts in The FLAC-file.
Without 64 Bit Double Precision I see no difference between Source and FLAC.

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.

"FLAC does not support floating point samples..." Source: https://xiph.org/flac/faq.html
 
Perhaps the floating point information is being replaced by anomalies because of that.
 I read somewhere that even the best converters will give you up to +/- 0.05dB  dBFS headroom between the quietest and maximum volume.
 

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.

As noted above, FLAC is integer data only. Any overflow values, when converted to integer data, will fold over - positive values become negative values and vice versa. This is exactly what your screenshot illustrates. Those abrupt transitions from positive-going to negative-going sound like loud pops or crackles (depending on their duration).
 
This is not a bug in the FLAC encoder. It's basic binary arithmetic. 
 
Always check for overs before you export to any integer format, including 16- or 24-bit wave, MP3 or FLAC. Overs should be considered a technical fault that needs to be fixed before exporting.

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

Noel Borthwick [Cakewalk]

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.

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?