[Scummvm-devel] Idea: IndexedMp3AudioStream

Max Horn max at quendi.de
Fri Oct 8 14:44:37 CEST 2010


Hi,

to put things in perspective: The biggest MP3 I have which is used in a ScummVM game is a track for GOB2, which is 47 MB. For GOB3 & GOB1  I have two more with 31 MB and 28 MB; all my other MP3 files are less than 5 MB. Clearly these numbers can vary depending on what encoder you  use, and which settings.

A seek table with N entries points means that for a file with M bytes, we need to scan on average (M/N)/2 bytes for a random seek, if we use a simply linear search from the closest seek table entry *before* the target frame.

Using M = 50 MB and N = 100 (for XING), that means roughly 50/100/2 ~ 256 KB have to be scanned on average for a seek. That might still be too slow for a low end device, but it *might* just be small enough to make it usable.

Of course, for a 5 MB file, only 25 KB need to be scanned.

Regarding using a binary search: That would be doable, of course, but with VBR data and just 100 entry points, can lead to quite a big discrepancy between request target frame, and actually computed target frame. For games like Loom, which play e.g. voice samples by seeking to a specific part of a huge track, that could lead to very noticeable and annoying problems, so I'd advice against it, at least for VBR data (even for CBR you need to be careful).

Finally, according to what I find on the web, XING is more widespread than VBRI... however, I am not sure how accurate and up-to-date those numbers are. It would be interesting to know whether any popular encoders and decoders support any of these (be it for writing or reading). Maybe we should investigate this a bit, and e.g. look at FFmpeg/mplayer/gstreamer/lame/... To my big irritation, it seems to be quite difficult to find definite information about these things on the internet. Maybe I just didn't search well enough yet, though...


Cheers,
Max



More information about the Scummvm-devel mailing list