Quote from: bennetng on 2022-10-24 18:30:28

Did you really type "flatopp"?

Damn, only one way to find out, and that is not done in two minutes ...

Prediction order (the "-l" switch) makes for big time penalty somewhere above -l12.

Loops are only unrolled until order 12

That is something I need translated

repeat the following code for each sample {
     repeat the following code for each order {
          do multiplication
          do addition
     }
}

[...]
Use this code for order 2:
repeat the following code for each sample {
     do multiplication
     do addition
     do multiplication
     do addition
}

Use this code for order 3:
repeat the following code for each sample {
     do multiplication
     do addition
     do multiplication
     do addition
     do multiplication
     do addition
}

Use this code for order 4:
repeat the following code for each sample {
     do multiplication
     do addition
     do multiplication
     do addition
     do multiplication
     do addition
     do multiplication
     do addition
}

Here are compiles using a more generic CPU optimization x86-64-v3 instead of haswell while using similar capabilities up to AVX2 in the hope for better performance across more modern CPU types.
Inside are builds with Clang 16.0.1, GCC 12.2.0 and a "disable-asm-optimizations" version with faster 16bit performance but slower 24bit performance for apps like CUETools or EAC.

To the "showcases" division, a file downloaded from <stupidlyhi-rez site

The original sample rate is likely 96kHz. See how clean the upper spectrum is, it is impossible for anything originally recorded in 384kHz with an ADC.

Another thing is that the 24-bit file on the website is clipped (the vertical cyan lines). The website sells conversion software and it is a pretty pathetic way to sell the product with such a careless conversion.

It makes me wonder if it is possible to exploit without a brute-force -e.

So whoever did this went to lenghts to force libflac 1.3.1 to handle a 32-bit signal (I mean, flac.exe couldn't!) but the 24-bit signal behaves different ... what for? 32-bits rounding up the 24th to overflow? Anyway, foo_bitcompare reports peak difference of -20.48 dB, which is suspiciously high but not high enough for my ears to bother trying to ABX it out.

It may not be a flac issue

I don't know why -l32 makes no difference on the retune, perhaps it detects the bloat?

That is because the retune's "-8" does in fact select "-l 32" whenever the sampling rate is high enough for it to be subset-compliant. "-r 8" as well, since that part of it got a speedup.
But also, the retune did tweak the algorithm to select LPC order, with consequences you can find in that thread. Next test build is likely different.