(i486 clipping) Right channel decoding issue on clip with 32-bit build
Brought to you by:
sobukus
Menu
▾
▴
1 Attachments
#209 (i486 clipping) Right channel decoding issue on clip with 32-bit build
x86 (32-bit) build of 1.18.0, 1.19.0, 1.20.0, svn snapshot seems to incorrectly decode the attached mp3 snippet. At the point where the right channel is expected to clip (typical), the output waveform seems to jump back to 0(?) instead, and it sounds like static. configure --with-cpu=i486. Noticed originally with 1.18.0-1 in Debian sid. On my amd64 machines, and with other decoders (exculding mplayer), everything is fine.
Am Fri, 13 Jun 2014 22:51:37 +0000
schrieb "Simon Kirby" sim@users.sf.net:
To clarify: This only happens with --with-cpu=i486, right? Choosing
--with-cpu=i386 is fine? Point being, i486 is special code for the
Intel 486 CPU. It is different from all other decoders. It is not for
any x86 CPU. It's a special hack to get the best out of that class of
CPU. Nevertheless, it still should work correctly, but I admit I'll
have to check if there is any attempt at proper clipping at all in that
code path. It's a bonus over basic decoding, after all.
Alrighty then,
Thomas
Confirmed that the problem only happens with --with-cpu=i486. --with-cpu=i386 seems to decode properly. The bug may not be exactly as I describe -- I'm just guessing -- but it sure is easy to hear from that snippet. Cheers!
Just a note that I'm still there ... I must admit that the bug went under for some time. I still need to check if hacking in proper clipping (not jumping around) sensible with the i486 code. Actually ... I'd have to dig out a real 486 CPU to check implications of any change. One point for current use is really that you are not supposed to use the 486 decoder unless you really intend to run it on a 486 CPU.
I finally verified that the decoding from the i486 decoder does not sound nice. It is not just clipping, it is the whole point that somehow the channel is driven into the volume range that causes clipping. There is some deepter breakage in the decoding.
But the i486 code is a special beast that largely is there as an example for trying to optimise for a certain cpu with plain C a long time ago. It is a nice student project to look into this and fix the decoder, but I do not see any practical relevance today.
My solution is to make it clear that you do not want the i486 decoder for regular duty. It is a relic. I am pondering how to best reach that. I am not yet convinced that I should just delete it. Maybe you'll need an extra configure switch with mpg123-1.25 to activate that decoder.
Of course, if someone took up the student assignment to have a look and fix it, a patch is still welcome.
My solution is to discourage use of the i486 decoder. I don't see a fix for that relic coming our way, unless someone wants to do it for the fun of it.