[sdlsound] mpglib in SDL_sound
Ryan C. Gordon
icculus at clutteredmind.org
Fri Feb 22 03:39:57 EST 2002
> The files decode_i386.c and dct64_i386.c would seem to indicate that
> it's only tested on Intel-based platforms. Perhaps it's making
> assumptions about byte ordering and/or alignment? Can anyone here verify
> that? If so, that would seem like a good place (for someone else :-) to
> start tinkering.
My list of known bugs for mpglib is currently:
1) Completely intolerant of corruption. I had an MP3 with two bad frames
(according to mp3_check), and the decoder aborts with an error upon
hitting it (and as such, the SDL_sound interface throws up
SOUND_SAMPLEFLAG_ERROR). I've been playing this song through SMPEG for
weeks, and never noticed. XMMS (which uses mpg123's more robust engine
for MP3 decoding) doesn't puke, either.
2) Lots of stderr chatter. Easy enough to fix.
3) Doesn't seem to like looping very much. This one is probably my bug,
4) Decoding uses a global variable (look for "gmp" in the mpglib
sources), which needs to be removed to prevent race conditions.
5) I have the sample properties hardcoded, but a lot of files seem to
play as a single channel, or < 44100Hz or something, and sound awful.
How to get this information from mpglib wasn't immediately obvious, or
it is SUPPOSED to play at that format, but doesn't recognize those
formats (or perhaps it chokes on variable bitrate files?
6) Probably other things.
I can't check the byte ordering thing, since I don't have a decent setup
on the iMac at the moment. Max? Darrell? Want to see if this thing even
builds on MacOS?
More information about the sdlsound