[flac-dev] Autocorrelation precision insufficient

[David Willmore]

If we're worried about machine compatibility of SSE2, it may be helpful to
note that it was introduced with the Pentium4 in 2000 and the Athlon64 in
2003.  With the exception of the Quark line of processors, no important x86
processor in recent years has lacked SSE2 support.

On Mon, Jun 28, 2021 at 5:59 AM Martijn van Beurden <mvanb1 at gmail.com>
wrote:

> Op ma 28 jun. 2021 om 09:45 schreef Brian Willoughby <
> brianw at audiobanshee.com>:
> > 1) What would affect the ability of an embedded FLAC firmware to decode
> certain files?
> >
> > Is it possible that the SD702 is not capable of processing complex
> predictors of higher orders?
>
> I cannot say for this specific case. If you would encode a file with
> all settings -0 through -8 and try playing them, it would be possible
> to draw conclusions. Have you done this before? The manual of the
> product you mention does not seem to list any limitations, and
> according to several sources, for most embedded devices FLAC decoding
> is much easier than MP3 decoding. See
> https://www.rockbox.org/wiki/CodecPerformanceComparison
>
> If only setting -0 and -3 play, the unit does not do mid-side
> decoding. If only -0, -1 and -2 play, the unit does only fixed
> predictor decoding. If only -0, -1, -2 and -3 play, the unit does not
> support predictor order larger than 6. If only -0, -1, -2, -3, -4, -5
> and -6 play, the unit does not support predictor orders larger than 8.
> If none of these work, perhaps the unit only plays files it made
> itself.
>
> > 2) Is there a strict definition of the 9 levels of FLAC coding such that
> the level would
> > precisely determine the predictor?
> >
> > I haven't looked at the source in ages, but it seems like you're saying
> that the compression
> > level might map to exact choices for model/predictor.
>
> There is no definition of the levels in the format specification, it
> just hasn't changed in all these years for the reference encoder. The
> *only* change the last 20 years was that level 7 went from max order 8
> to max order 12 in version 1.3.1. However, other FLAC encoders like
> Flake and FLACCL define levels differently.
>
> > 3) Can you explain why the encoded file should be exactly the same
> across different
> > processors or implementations? I'm still fuzzy on the details, but it
> seems like the
> > exact bits could still vary even with the same model - i.e. "exhaustive"
> implies that
> > different implementations might stop at different points along the way.
>
> The change I propose is changing autocorrelation calculation from
> single-precision floats to double precisions floats. However, it is
> impossible to implement this change in the current SSE code, because
> SSE cannot work with double precision floats. To use double precision,
> SSE2 is needed. My question was: should I replace the SSE routines
> with SSE2 routines, or should I keep the SSE routines as well? The
> choice for platforms with SSE but without SSE2 is between speed and
> compression. If the SSE routines are kept, the speed will stay the
> same but there won't be a compression improvement. If the SSE routines
> are dropped, the regular code that doesn't use any special extensions
> is used, so doubles can be used. This results in a large speed
> decrease but compression improves.
>
> If the SSE code is kept around and the VSX code is updated as well,
> all platforms (ARM, PPC, x86, etc.) will produce almost the exact same
> result when compressing a file with a certain setting, except those
> with SSE but without SSE2.
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20210628/e71dc433/attachment.htm>