Thank you very much ktf for the good information you have given. I did not think that there could be such exceptional cases in stereo data. If this is the case, it can really be better efficiency in these special cases.  I can come up with a quick solution for this in the next releases.

Also, you can have quite nice stereo while remaining mono compatible. But truly great stereo usually needs phase differences as well. As you have noticed, one bit of audio HALAC underperformed was Armonia Di Flauti. Guess what: great, true stereo (I really enjoy it) but not achieved by only varying amplitude, but both amplitude and phase. HALAC isn't the only one though, as far as I know, WavPack does this as well: always converting L+R to M+S.

I found some time and did a quick test. I was a bit lazy to write the detailed results. So I'll summarize briefly.
The processor, memory and ssd I used for the test is not very fast. I did this to see compatibility with legacy systems. However, when I use a newer processor, HALAC's decode speed increases even more. And FLAC -5 has a faster decode time than FLAC -0.

16 bit, 48000 bps, stereo, 4 CD
Total size: 2,462,609,998 bytes

HALAC -normal	13.268s	17.114s	1,727,197,297 bytes
FLAC -5	34.249s	18.968s	1,729,332,719 bytes

How "bad" it would be to stick to L&R as only choice? I don't know. Too lazy to test, I would need to use other tools to convert first.

I have a question about HALAC's Rice Coder. Let all values ​​in a block of audio be 0 except one. The value that is different is 1000. And let the calculated Rice parameter be 0.
How many bits do you use to encode the value 1000 for k=0?

i7 3770K, 16gb, 240 gb. Single thread results
Busta Rhymes (829,962,880)
HALAC +   7.852  9.226  558,783,643
FLAC -8  33.128  7.113  558,662,099

Sean Paul (525,065,800)
HALAC +   5.259  5.952  373,657,717
FLAC -8  21.133  4.710  373,252,115

Globular (802,063,984)
HALAC +   7.342  8.699  473,432,182
FLAC -8  31.297  6.298  471,599,215

Sibel Can (504,822,048)
HALAC +   4.895  5.641  356,662,028
FLAC -8  20.455  4.489  356,997,976

Gubbology (671,670,372)
HALAC +   5.976  7.038  361,180,016
FLAC -8  26.233  5.244  360,222,227

HALAC +
I am publishing this trial version, especially for those who want to see a HALAC capable of compressing a little more. Actually, I certainly didn't want to do something like this. Because HALAC was not developed for this. However, I wanted to clarify that better compression rates can be obtained without compromising more than speed.
This work, which I call HALAC+, is not an official version and is only a experiment for now. The compression ratio is very close to FLAC -8. However, the Encoding speed is least 4x faster. I didn't hardly deal with the Decoder optimization. So it's a little slow for now. But new processors can be faster.

• HALAC 0.29 normal : 867 kbps on average
• HALAC 0.38 normal: 851 kbps on average (-16 kbps compared to 0.29)
• HALAC+ normal: 848 kbps (-3 kbps compared to HALAC 0.38)
• HALAC 0.29 fast: 909 kbps on average
• HALAC 0.38 fast: 869 kbps on average (-40 kbps compared to 0.29!)

According to my results, Halac+ is on average equivalent to Flac Level 8 as mentioned. Sometimes a little below, sometimes a little above. However, it compresses more than 4 times faster than the fastest thing known (Flac). And it is not even fully optimized.
But I think there is no need for such a thing. I can guess that Halac can offer better compression if desired, but it is not worth such a loss of speed for a small gain. Absolutely!

253 full albums to feed the comparison

• HALAC 0.29 normal : 867 kbps on average
• HALAC 0.38 normal: 851 kbps on average (-16 kbps compared to 0.29)
• HALAC+ normal: 848 kbps (-3 kbps compared to HALAC 0.38)
• HALAC 0.29 fast: 909 kbps on average
• HALAC 0.38 fast: 869 kbps on average (-40 kbps compared to 0.29!)

For comparison, FLAC 1.43 -8 end with 841 kbps (-7kbps compared to HALAC+)


Full and detailed results on my table:
https://docs.google.com/spreadsheets/d/1V-OwngNspELbkoRp-DQ34wMj2g7g-VMtvqaCqpqMAoU/edit?usp=sharing
(go to the FULL table tab, and all HALAC values are at the extreme end of the table)

On summary:
HALAC+ is on average 1 to 4 kbps smaller than HALAC 0.38 depending on musical genre
HALAC+ is bigger than FLAC -8 on all genres except AUDIOBOOKS corpus (-1 kbps). Biggest difference found on the ELECTRONIC MUSIC corpus (+13 kbps for HALAC+ compared to FLAC).

I can't comment speed encoding (bottlenecked by external drives/USB)

time ./flac --silent -5 file_01.wav

real	0m6.782s
user	0m6.114s
sys 	0m0.668s

time ./halac_enc file_01.wav file_01.halac -normal

real	0m4.965s
user	0m4.600s
sys	 0m0.365s

time ./flac --silent -5 file_02.wav

real	0m8.712s
user	0m7.816s
sys	 0m0.896s

time ./halac_enc file_02.wav file_02.halac -normal

real	0m6.317s
user	0m5.833s
sys 	0m0.484s

stat -c "%s %n" -- file_*
662438138 file_01.flac
662341661 file_01.halac
973741394 file_02.flac
973935321 file_02.halac

time ./flac --silent -d file_01.flac

real	0m5.597s
user	0m4.872s
sys 	0m0.725s

time ./halac_dec file_01.halac file_01.wav
The decoded file has a corruption in the frame 1373! (around byte 719847424)

real	0m6.887s
user	0m6.226s
sys	 0m0.661s

time ./flac --silent -d file_02.flac

real	0m7.112s
user	0m6.187s
sys 	0m0.924s

time ./halac_dec file_02.halac file_02.wav

real	0m9.118s
user	0m8.330s
sys	 0m0.788s

This work, which I call HALAC+, is not an official version and is only a experiment for now. The compression ratio is very close to FLAC -8. However, the Encoding speed is least 4x faster. I didn't hardly deal with the Decoder optimization. So it's a little slow for now. But new processors can be faster.

Basically, I tried Adaptive Rice Coding. And a simple error correction. Block costs are a bit more. I think I can reduce them. Of course, this is not perfect and better can be done.
In this version, "-fast", "-ufast" parameter and lossyWav support for the time being disabled.