flac dev - Jun 2021 - Autocorrelation precision insufficient

Playing Devil's Advocate here, but isn't the point of compression
standards like FLAC that encoders can vary quite a bit, so long as decompression
always produces the correct results? In other words, I think it might be taking
it too far to require that the encoder produce identical results on every
processor, at least if the decompressed audio is correct.

To counter myself on this topic, I do think it's important to maintain any
distinction between levels (and I'm not sure how that's defined). I have
the Sound Device 702 recorder, and it can only play back FLAC files with low to
moderate compression. The recorder itself can only compress moderately -
certainly nowhere near --best -9

I'd say that it's important to maintain compatibility with players that
have limited capabilities. I don't actually know which levels of compression
the SD702 supports, and which levels are too extreme, but whatever the threshold
is, then I would expect that future versions of FLAC would not stop being
compatible with the SD702 when the same compression level is used.

My apologies that I do not have more details on player limitations, but my point
is that compatibility with players should be required, while producing identical
compressed bit streams might not necessarily be required.

I've also never understood the mathematics behind a compression format where
the encoder can vary immensely in quality - even to the point of exceeding
original compression ratios - but the decoder remains compatible. Witness MP3,
where they improved the algorithm of the encoder and produced smaller files, all
without requiring an update to the decoder. I'm assuming that FLAC fits that
same model.

Brian Willoughby


On Jun 25, 2021, at 14:15, Robert Kausch <robert.kausch at freac.org>
wrote:
> I concur with David that compression should work the same on all platforms.
There can be SIMD optimizations for some routines, but they should produce the
same result as the non-SIMD versions. If outdated optimizations cannot be
updated, better drop them instead of keeping versions that produce different
results than the new reference code.
> 
> Regarding VSX, you could try to contact Anton Blanchard to ask whether he
can update the routines. Otherwise, it should be possible to emulate VSX with
QEMU. You won't be able to verify performance that way, of course, but
should be able to verify correctness.
> 
> Best,
> Robert
> 
> Am 25.06.2021 um 19:55 schrieb David Willmore:
>> Martijn,
>> 
>> Just a lone voice here, but I would opt for the best compression on the
most platforms.  As I am one of the people who always run FLAC at the placebo
max compression, my vote will always be for best compression over any other
resource use.
>> 
>> I also can make ARMv7 hardware available to you or I can do any testing
you want on a number of machines.
>> 
>> Thank you for your work!
>> 
>> Cheers,
>> David
>> 
>> On Fri, Jun 25, 2021 at 3:48 AM Martijn van Beurden <mvanb1 at
gmail.com> wrote:
>>>    Op do 24 jun. 2021 om 09:17 schreef Martijn van Beurden
>>>    <mvanb1 at gmail.com>:
>>>    > - Switch to autoc[] as doubles, but remove current SSE and
>>>    disable VSX
>>>    > intrinsics for someone to update them later (I don't
have any POWER8
>>>    > or POWER9 hardware to test). This means all platforms will
get the
>>>    > same compression, but some (with only SSE but not SSE2 or
with VSX)
>>>    > will see a large slowdown.
>>> 
>>>    I see now that besides routines with SSE intrinsics (which I
rewrote
>>>    into SSE2) and with VSX intrinsics (which I don't have
hardware for)
>>>    there is also a open pull request for routines with ARM
intrinsics. I
>>>    am willing and able to rewrite those if this change is accepted
and
>>>    merged. I have access to ARMv8 with 32-bit OS, ARMv8 with 64-bit
OS,
>>>    ARMv6 and I might be able to get hold of ARMv7 hardware.
>

Op ma 28 jun. 2021 om 04:59 schreef Brian Willoughby <brianw at
audiobanshee.com>:
> I'd say that it's important to maintain compatibility with players
that have
> limited capabilities. I don't actually know which levels of compression
the
> SD702 supports, and which levels are too extreme, but whatever the
> threshold is, then I would expect that future versions of FLAC would not
stop
> being compatible with the SD702 when the same compression level is used.
No worries, this change does not affect decoding complexity.
> I've also never understood the mathematics behind a compression format
> where the encoder can vary immensely in quality - even to the point of
> exceeding original compression ratios - but the decoder remains compatible.
> Witness MP3, where they improved the algorithm of the encoder and produced
> smaller files, all without requiring an update to the decoder. I'm
assuming that
> FLAC fits that same model.
FLACs inner workings are not very difficult, I will explain. FLAC does
encoding in
two steps. First, it tries to find a model to fit the audio data. As a
model is never
exact, the second step involves storing the difference between the input and the
model (called the residual) in an efficient way.

How this model and residual are stored and decoded is part of the FLAC
specification, this doesn't change. The only change to the specification
after FLAC version 1.0 concerned 24-bit files and was the introduction of a
different residual encoding method in version 1.2.0, in 2007. No other
changes to the format and thus decoding were introduced after 1.0.

The different compression levels increase one of two things: how much
effort to spend finding the best model, and how complex a predictor to use.
The first, the effort finding the best predictor, slows down the
encoding but not
decoding. These are options like adding apodizations and exhaustive model order
and precision search. With these settings, the encoder tries various models and
picks the one that fits best. The second, how complex of a predictor
to use, does
affect decoding performance. There are only three parameters here:
whether to use
a fixed or non-fixed predictor, how large the maximum model order is and whether
mid-side encoding is used.

The change I propose is a change in the way the encoder does the modelling.
When this modelling is done with more precision, this slows down encoding,
but it does not change anything in the way decoding is done. It just changes the
'representation' that needs to be decoded, but this decoding process
does not
become more complex.