Re: [mpg123-devel] fixed point decoders

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

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

> > OK, now I've finished investigation, and integer decoder (for  
> > layer3, no work for layer 1/2) works better. The problems are:
> > - The current double-to-real scalefactor (32768.0) is too small for  
> > gainpow2 table. This causes a corruption (truncated to zero) of  
> > dequantized samples in some cases.

Ah, that matches the picture I got when first digging into this... at some point, zeroes appeared.
I suspected something like this... and indeed...

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

... I am very interested in looking into what you did there to work with different scale factors at the places!
I am not too surprised that layer 1/2 code has been broken ... the whole integer decoding must be some quick hack to get mp3 going on ARM machines and the like. layer 1/2 is a bit off mainstream, so people did't bother.

When you get 10^-4 RMS on compliance data, that does not look too nice on paper, compared to a "proper" decoder like MAD.
But, hm, lemme look... that's about 13 bits accuracy, right?
Given that the (badly broken, depending on you POV) version of code we had before was kindof OK for non-audiophile listening of (not too quiet) music already, such a number is really not bad.
We won't achieve 16 bits accuracy with 32bit integers and multiplying around like we do... 13 bits may be "good enough" as the fast alternative to the high quality stuff.
And for high quality, you can also use mpg123 floating point output on a machine that emulates floating point math in software...

But in any case, you again proved that the mpg123 is very lucky having you with the ability, time and will to fix those issues!
Since especially the second of these is very much lacking for me, the 1.8 release being planned not before next weekend at least, we could consider putting the improved integer code into that release.
The nofpu decoding is marked experimental in any case, so we don't fail a code stability criterion there.

I'll finish up fixing that buffer bug that I started investigating on a train ride yesterday, then have a look over what you did with the integers... enjoy the view and then, sadly, move on to my real life work, that really needs attention:-/

Thank you again... and let's all look forward to releasing a big firecrackin' mpg123 1.8.0 in June 2009 -- the best mpg123 EVAR!


Alrighty then,

Thomas.


PS: After the buffer issue is solved, too... that leaves us mainly with some platform-specific issues:
- crashes of 64bit windows DLL ... still? The tester is silent...
- output performance on OS/2 (initial stuttering, then smooth... not sure if this is regression, I am happy that mpg123 works there at all)
Perhaps we get some news on these, too, during the next week.