flac dev - Jan 2014 - Why Rice order in "--best" switch is limited to 6?

No, FFMPEG uses its own FLAC encoder/decoder, based on Flake source
code, that based on FLAC reference encoder/decoder source code.

Yes, I agree that "optimal"? values for reference encoder/decoder may
differ "optimal"? values for FFMPEG's encoder/decoder.

But we're talking about the "highest reasonable" values, not
"optimal".
>>>>> BTW, you can also use -A=... options to increase
compression ratio.
Yes, using "-p" and "-A" or more than one "-A" (up
to 32) switches is
really unreasonable, because using them very greatly increase the
encoding time. But I did some tests and found that using "-r 8"
instead of "-r 6" NOT greatly increase the encoding time (one of my
tests: 24 sec instead of 18 sec for 10 min input on my machine).
Increasing value of Rice order is not exhaustive, and increasing
encoding time is predictable. IMHO 33% (for calculation sample of 100
tracks was used) is not critical for "best" compression preset. People
use "best" preset and expect to get
"best"/"highest" results. It is
basis of encode/decode time asymmetry! People who want to get
"optimal" ("quality"/speed compromise) use default
"--compression-level-5" or "--compression-level-7".

Finally, I suggest to increase Rice order parameter in "--best"
("--compression-level-8") preset from 6 to 8. (I'm not suggest to
increase Rice order in "--compression-level-7",
"--compression-level-6", etc.

> But FFMPEG uses flake encoder, not libFLAC. So their optimal values may
differ.
>> I think "-r 8" is "highest reasonable". E.g. from 5
to 12 values of
>> "-compression_level" switch in FFMPEG uses value 8 of Rice
order
>> parameter.
>>> IMHO it just means "highest reasonable", not
"highest theoretically possible".
>>>> "--best" preset is designed for highest compression,
not for faster
>>>> compression, isn't it?
>>>>> Because -r 8 is noticeable slower? The size difference is
0,0003%,
>>>>> the speed difference is 30...40%.
>>>>>
>>>>> BTW, you can also use -A=... options to increase
compression ratio.
>>>>>> The "--best" switch currently synonymous with
"-8" that synonymous
>>>>>> with "--compression-level-8" that synonymous
with "-l 12 -b 4096 -m -e
>>>>>> -r 6".
>>>>>>
>>>>>> Why value of "-r" switch in
"--best" is limited to 6?
>>>>>>
>>>>>> The maximum Rice order is 8 (not 6) for the stream to
be Subset compatible.
>>>>>>
>>>>>> "-r 8" ("-l 12 -b 4096 -m -e -r 8")
produces better results than "-r
>>>>>> 6" ("-l 12 -b 4096 -m -e -r 6") and and
also Subset compatible.

???? ?????? wrote:
> Yes, using "-p" and "-A" or more than one
"-A" (up to 32) switches is
> really unreasonable, because using them very greatly increase the
> encoding time. But I did some tests and found that using "-r 8"
> instead of "-r 6" NOT greatly increase the encoding time (one of
my
> tests: 24 sec instead of 18 sec for 10 min input on my machine).
> Increasing value of Rice order is not exhaustive, and increasing
> encoding time is predictable. IMHO 33% (for calculation sample of 100
> tracks was used) is not critical for "best" compression preset.
People
> use "best" preset and expect to get
"best"/"highest" results. It is
> basis of encode/decode time asymmetry! People who want to get
> "optimal" ("quality"/speed compromise) use default
> "--compression-level-5" or "--compression-level-7".
>
> Finally, I suggest to increase Rice order parameter in "--best"
> ("--compression-level-8") preset from 6 to 8. (I'm not
suggest to
> increase Rice order in "--compression-level-7",
> "--compression-level-6", etc.
>
I encoded several albums (44.1/stereo/16bit) using "-l 12 -b 4096 -m -e -r
6"
and "-l 12 -b 4096 -m -e -r 8" settings.

The total size of FLAC files:
-r 6: 2866669702 bytes
-r 8: 2866647652 bytes
The difference is 22050 bytes, or 0,00077%

So basically you suggest to trade 33% decrease in speed
for 0,00077% increase in compression.