Thanks. I should probably start a new subject, but I have related questions. Please don't feel obligated to answer ... I'm just curious. 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? Could it be as simple as absence (or requirement?) of mid-side encoding? (this doesn't seem that likely) 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. 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. Brian On Jun 27, 2021, at 23:34, Martijn van Beurden <mvanb1 at gmail.com> wrote:> 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.
Martijn van Beurden
2021-Jun-28 09:59 UTC
[flac-dev] Autocorrelation precision insufficient
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.