#3766 closed defect (wontfix)
LOOM: Compressed audio seek takes really long
| Reported by: | m-kiewitz | Owned by: | sev- |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Loom |
Description
Hi,
First I want to thank you very much for ScummVM. I'm finally able to play my favourite games again via Wii.
Anyway, I ripped my original Loom Talkie CD to one big Track1.mp3. Now when using ScummVM, normally one would hear "Welcome to...", but this is skipped, then the first frame of the intro plays and ScummVM halts for around 10-15 seconds, then audio starts to play but audio is much too late, so animation and audio don't match.
Also if I look at any object in the game, audio loading/seeking halts the engine for several seconds, which results in jerky gameplay.
I guess both glitches appear because of the big track1.mp3 and possibly seeking. I would need to take a look at the source, but I guess the seeking is what results in such big delays. This glitch happens on Win32 and Wii, so I guess it's an platform-indepedant problem. Other games like Sam'n Max Talkie or Maniac Mansion 2 that also use compressed sound don't have this problem.
I'm using fixed bitrate, so it should be possible to calculate seek destination within the MP3 w/o much reading. Perhaps an index into the MP3 could also help.
Regards M. Kiewitz
Ticket imported from: #1991847. Ticket imported from: bugs/3766.
Change History (9)
comment:1 by , 16 years ago
| Summary: | Compressed audio seek takes really long → LOOM: Compressed audio seek takes really long |
|---|
comment:2 by , 16 years ago
comment:3 by , 16 years ago
I used Tonigy (virtual fs that mounts audio cds as virtual wave files), never had any problems with it - and I used Frauenhofer DOS-Codec for conversion to MP3.
Will try again with EAC and respond to this track afterwards.
Do you also hear the introduction line after selecting the skill level?
comment:4 by , 16 years ago
I'm experiencing the exact same problem. I can also report it occurs on my copy of Lost In Time as well. In both cases, I ripped the music using iTunes, using the same settings: MPEG Audio Layer 3 44100Hz stereo 128Kbps.
comment:5 by , 16 years ago
Oh, just for completeness' sake, I'm running rev 32565 of the Wii port of ScummVM, downloaded through WiiBrew.org. I have 2 types of SD memory cards I tested this on, each had a delay of 12 secs between starting playing the sound and actually having it audible. In this period, the cursor can't move and it seems ScummVM is experiencing a freeze.
Ironically, this is what initially led me to believe support for Lost in Time was broken, as the game seems to 'freeze' 2x at the start, before showing an interface. ;)
The Monster.so3 compressed audio variations of the other games [i.e. Sam 'n' Max, Maniac Mansion 2/DoTT, Indy Fate of Atlantis] seem to work fine, would it perhaps be possible to create a Monster.so3 for Loom/Lost in Time to counter this mp3 issue? Or doesn't the game look for those files in these cases?
comment:6 by , 16 years ago
No, you can't just use a game format from a completely different game in another -- it wouldn't help either.
I can't talk about Lost in Time, but for Loom, this is the situation: Loom stores all its audio in one single gigantic audio track. When a script then wants to play a certain sound, it invokes a function of the interpreter (i.e. ScummVM in this case, the original .EXE back under DOS) telling it an offset and a duration. The interpreter then has to play the part of the big single audio track starting at that offset, for the specified duration. Since those offsets and durations vary for the various variants of Loom, and are not available as some kind of list anywhere, but rather only implicitly occur in the scripts, there is not much we can do to change this.
In addition, our MP3 code currently has no way to distinguish CBR and VBR files, so it can't just calculate file offsets based on time offsets. In general, the MP3 format is very bad when it comes to things like time based seeking, BTW, and a real PITA to program (it requires non-standard extensions to tack on seek tables, for example, and there are various for that) -- with Ogg Vorbis, it is so much easier and cleaner (thanks to a good standard library and API). As a first measure, I would recommend switching to Ogg encoded data files. You get better quality at the same file size, too (or smaller files at the same quality).
However, we *did* spend quite some effort to implement good and quick general seeking for MP3 files. CPU-wise, the result is pretty much optimal if you want to support both CBR and VBR file w/o relying on non-standard metadata extensions.
The only explanation for the problem you are seeing which I can think of right now, is super-slow data reading speed (the file has to be read completely up to the spot it wants to seek to). That might explain it on the Wii -- but you say it happens on Windows, too, but if you play from HD, then it shouldn't... Weird.
Hm, only other idea: The MP3 files you get are in some way not as libMAD (the MP3 decoding lib we use) expects them, hence breaking seeking.
(and yeah, we could generate a seek table, e.g. by reading the whole file once during startup, but so far that wasn't necessary, so we didn't bother :).
comment:7 by , 16 years ago
hi again,
sorry this took quite a while. I encoded the cd wave track using oggenc and the problem is now gone. Anyway fixing mp3 should be possible by calculating offset when cbr is used. i guess decoding the whole file everytime is a bit overkill. it would also be possible to create a util like the ones for dott etc. and split the samples, encode them and put them in a monster.sou style container.
anyway im now able to play loom again, thank you very much
regards
comment:8 by , 16 years ago
This is apparently caused by badly encoded file. libMAD supports seeking within VBR MP3s rather poorly. Closing this bug as Won't Fix.
comment:9 by , 16 years ago
| Owner: | set to |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
That's strange, I don't experience any of the problems you mentioned
What program did you use to rip and compress the game's audio track? Some music rippers add silence to each track. Try ripping the audio track again with EAC or CDEx http://www.exactaudiocopy.de/ http://cdexos.sourceforge.net/