Most decoders now report total sample play time, now. Technically, this breaks binary compatibility with the 1.0 branch, since it extends the Sound_Sample struct, but most (all?) programs are just passing pointers allocated by SDL_sound around, and might be okay. Source-level compatibility is not broken...yet! :) --ryan. -------- Original Message -------- Subject: SDL_sound patch: Finding total length of time of sound file. Date: Sun, 26 Jan 2003 09:31:17 -0800 (PST) Hi Ryan, I am working with Eric Wing and helping him modify SDL_sound. AS part of our efforts in improving and enhancing SDL_sound, we like to submit this patch. We modified the codecs to find the total time of a sound file. Below is the explanation of the patch. The patch is appended as an attachment to this email. * MOTIVATION: We needed the ability to get the total play time of a sample (And we noticed that we're not the only ones). Since SDL_sound blocks direct access to the specific decoders, there is no way for a user to know this information short of decoding the whole thing. Because of this, we believe this will be a useful addition, even though the accuracy may not be perfect (subject to each decoder) or the information may not always be available. * CONTRIBUTORS: Wesley Leong (modified the majority of the codecs and verified the results) Eric Wing (showed everyone how to do modify codec, modified mikmod) Wang Lam (modified a handful of codecs, researched into specs and int overflow) Ahilan Anantha (modified a few codecs and helped with integer math) * GENERAL ISSUES: We chose the value to be milliseconds as an Sint32. Milliseconds because that's what Sound_Seek takes as a parameter and -1 to allow for instances/codecs where the value could not be determined. We are not sure if this is the final convention you want, so we are willing to work with you on this. We also expect the total_time field to be set on open and never again modified by SDL_sound. Users may access it directly much like the sample buffer and buffer_size. We thought about recomputing the time on DecodeAll, but since users may seek or decode small chunks first, not all the data may be there. So this is better done by the user. This may be good information to document. Currently, all the main codecs are implemented except for QuickTime.

* 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?