Re: [flac-dev] Autocorrelation precision insufficient
On 06/28/21 08:39 AM, David Willmore wrote: 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. I was going to say the same. There are very few people even on OS/2 running PII or PIII chips that support SSE but not SSE2 and as long as there is a configure option to disable SSE/SSE2, it is easy enough to spin up 2 binaries if requested. Dave ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Autocorrelation precision insufficient
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 wrote: > Op ma 28 jun. 2021 om 09:45 schreef Brian Willoughby < > bri...@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@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Autocorrelation precision insufficient
Op ma 28 jun. 2021 om 09:45 schreef Brian Willoughby : > 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@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Autocorrelation precision insufficient
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 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. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
