Re: [mpg123-devel] fixed point decoders

[Thomas O. <tho...@or...>]

Am Sat, 30 May 2009 16:18:32 +0900
schrieb Taihei Monma <tm...@ma...>: 

> Now fixes are on the trunk. Layer 1/2 decoder (was totally broken) is  
> also fixed.

I had a look ... nice work!
Considering the accuracy, I modified the compliance test to recognize "limited" accuracy, as defined per ISO.
The maxdiff does not matter in that case, so the integer code qualifies mostly as ISO conformant decoder of limited accuracy:

==== Layer 1 ====
--> 16 bit signed integer output
fl1.bit:	RMS=9.631689e-05 (LIMITED) maxdiff=3.705621e-04 (FAIL)
fl2.bit:	RMS=9.817009e-05 (LIMITED) maxdiff=4.396439e-04 (FAIL)
fl3.bit:	RMS=9.903067e-05 (LIMITED) maxdiff=3.730059e-04 (FAIL)
fl4.bit:	RMS=7.792110e-05 (LIMITED) maxdiff=3.411770e-04 (FAIL)
fl5.bit:	RMS=1.143484e-04 (LIMITED) maxdiff=4.230142e-04 (FAIL)
fl6.bit:	RMS=1.292823e-04 (LIMITED) maxdiff=5.022287e-04 (FAIL)
fl7.bit:	RMS=9.130958e-05 (LIMITED) maxdiff=3.955364e-04 (FAIL)
fl8.bit:	RMS=1.030841e-04 (LIMITED) maxdiff=4.748702e-04 (FAIL)

==== Layer 2 ====
--> 16 bit signed integer output
fl10.bit:	RMS=1.202552e-04 (LIMITED) maxdiff=4.733205e-04 (FAIL)
fl11.bit:	RMS=1.186685e-04 (LIMITED) maxdiff=4.780293e-04 (FAIL)
fl12.bit:	RMS=1.175201e-04 (LIMITED) maxdiff=4.945397e-04 (FAIL)
fl13.bit:	RMS=1.109616e-04 (LIMITED) maxdiff=3.585219e-04 (FAIL)
fl14.bit:	RMS=1.256545e-04 (LIMITED) maxdiff=3.849864e-03 (FAIL)
fl15.bit:	RMS=5.289808e-02 (FAIL) maxdiff=3.792340e-01 (FAIL)
fl16.bit:	RMS=1.226452e-04 (LIMITED) maxdiff=8.984208e-04 (FAIL)

==== Layer 3 ====
--> 16 bit signed integer output
compl.bit:	RMS=1.673918e-04 (FAIL) maxdiff=1.907170e-03 (FAIL)

A notable exception is the layer3 test... there we barely scratch over the limit (around 1.4e-4).
And another notable exception is that one layer2 test that gets around 5e-2 RMS error.
It falls out of the usual pattern... I somehow hope that this means we can fix this one.

I compared to output from a madplay installation I have...

Computing RMS full scale for double float data (thus, full scale is 2).
ISO limit values: RMS=8.80967e-06 maxdiff=6.10352e-05; limited accuracy RMS=0.000140955
RMS=3.853300e-05 (LIMITED) maxdiff=2.242923e-04 (FAIL)

Obviously that build is not using the high-quality tuned MAD library, but the fast setup with limited accuracy.
What disturbs me about that: This code is faster than the generic mpg123 code, be it with floats or integers!
Granted, the floating point output of mpg123 is of higher quality, but MAD kicks our ass on the quick-and-dirty track.

Seems like we'd need to add fixed point assembler optimizations to catch up (MAD has some assembler stuff, particulary for ARM, too).

So, I am a bit weary on the future of mpg123's integer mode. It started life as a hack on the make it work on ARM (I guess) and now we got it nearly to a state where we can call it an MPEG decoder... but if MAD offers the same quality with more speed, plus the better quality as option... then we are shipping something inferior and somehow that doesn't fit into the "mpg123 way".
On the other hand, if it performs about as well regarding performance (actually, that is a matter of time and effort we want to spent on this, not any impossibilities...), we still have the edge on the smoother API (if one likes the abstraction) and some features like gapless decoding, RVA, ID3 parsing ... 

On a technical point, one could just merge in the integer math code from MAD, since they already put effort in it and it works, but the result would need a change of license from LGPL to GPL...


Alrighty then,

Thomas.