Mercurial > SDL_sound_CoreAudio
view decoders/timidity/TODO @ 562:7e08477b0fc1
MP3 decoder upgrade work.
Ripped out SMPEG and mpglib support, replaced it with "mpg123.c" and libmpg123.
libmpg123 is a much better version of mpglib, so it should solve all the
problems about MP3's not seeking, or most modern MP3's not playing at all,
etc. Since you no longer have to make a tradeoff with SMPEG for features, and
SMPEG is basically rotting, I removed it from the project.
There is still work to be done with libmpg123...there are MMX, 3DNow, SSE,
Altivec, etc decoders which we don't have enabled at the moment, and the
build system could use some work to make this compile more cleanly, etc.
Still: huge win.
| author | Ryan C. Gordon <icculus@icculus.org> |
|---|---|
| date | Fri, 30 Jan 2009 02:44:47 -0500 |
| parents | 2d887640d300 |
| children |
line wrap: on
line source
* I don't like the indentation style at all, but for the most part I've left it alone. * Much of the code looks ugly to me. * The return value from SDL_RWread() is checked inconsistenly. * Group the members of MidiSong into logical units, i.e. structs? * The debug messages are probably a bit too noisy. I've removed one particularly annoying one, but... Some of them should be turned into error messages instead. * Can the instrument handling be made more efficient? At the moment different MidiSongs may separately load the same instrument. Note that the MidiSong's audio format affects how the instrument is loaded, so it's not as easy as just letting all MidiSongs share tone and drum banks. At the moment they do share the data that is simply read from the config file, but that's just a quick hack to avoid having to read the config file every time a MIDI song is loaded. * Check if any of MidiStruct's members can safely be made into static globals again. * TiMidity++ adds a number of undocumented (?) extensions to the configuration syntax. These are not implemented here. In particular, the "map" keyword used by the "eawpats". * The other decoders generally only read as much of the file as is necessary. Could we do that in this decoder as well? (Currently it seems to convert the entire file into MIDI events first.) * Can it be optimized?