#382 closed defect (outdated)
ALL: mp3 bug when loading a save game
| Reported by: | SF/logicdeluxe | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | Audio |
| Version: | Keywords: | ||
| Cc: | Game: | Zak McKracken |
Description
Built on Aug 2 2002 00:07:18 win When ever I load a save game, endless lines saying: "WARNING: Error in MP3 decoding!" appear until a new track is playing.
Ticket imported from: #590069. Ticket imported from: bugs/382.
Change History (14)
comment:1 by , 22 years ago
comment:2 by , 22 years ago
| Component: | Engine: SCUMM → --Unset-- |
|---|---|
| Game: | Zak McKracken |
| Summary: | ZAK256: mp3 bug when loading a save game → ALL: mp3 bug when loading a save game |
comment:3 by , 22 years ago
Hmm... saveOrLoad() may call _mixer->stop_all(), but I guess that doesn't automagically set _mp3_cd_playing to false. Could that be the problem?
comment:4 by , 22 years ago
Better yet we should actually store the track information in the save game, so it can restart playing the music. That means a savegame file format change, of course.
Someone really needs to rewrite the saveload code so compatability doesn't break so easily :)
comment:5 by , 22 years ago
bug number 634028 (insert cool looking bugzilla strikethrough here) has been marked a duplicate of this bug and as such closed
comment:6 by , 22 years ago
Can't we put in a workaround for this, at least for now? Better to have that (marked with FIXME and explanation in the source of course) than to wait till the new save game format is finally there :-)
comment:7 by , 22 years ago
I think it'd be enough to just add a call to _sound->stopCD() to loadState() (along with the _sound->stopBundleMusic() and _sound->pauseSounds(true) that are already there).
The problem, as far as I can see, isn't restoring the music after loading a game (although that would be nice too), it's getting ScummVM to realize that it should no longer play what it was playing *before* the savegame was loaded.
comment:8 by , 22 years ago
He's right, you know. That workaround does work, but of course the music doesn't restart when you load until it's triggered (eg. by re-entering the room). Perhaps I will have a look round the source when I have time :)
comment:9 by , 22 years ago
Since I did rewrite the savegame format to allow easy extensions, we should now be able to store any track information we might need to store.
comment:10 by , 22 years ago
Well more generally speaking, this is about saving the currently playing CD tracke, then. I don't see a way to query the OSystem interface which one is playing, but I guess it should be possible to store this information in the Sound class (which already does this for MP3/Vorbis "CD" tracks). Then we could put that into the savegame, and upon a load, resume CD track playing using the stored parameters.
comment:11 by , 22 years ago
OK this is not quite that trivial I guess... if we save during e.g. the LoomCD intro, we also want to save the current position on the track, since music & animation are correlated. In other places, the position may not be so important, esp. if it's just a music track which is looped infiintly. Oh yes, the looping part is another thing, of course when saving we also have to safe how often the track should be looped, etc.
comment:12 by , 21 years ago
| Resolution: | → outdated |
|---|---|
| Status: | new → closed |
comment:13 by , 21 years ago
The issue reported in this bug has been fixed long ago. Also some of the other issues mentioned in comments have since then be fixed. If there are remaining issues regarding MP3 behaviour, they should be files in seperate bug reports.
comment:14 by , 6 years ago
| Component: | --Unset-- → Audio |
|---|---|
| Game: | → Zak McKracken |
I first noticed this in ZAK256, but I just noticed the same behavior in Monkey1. Seems to be a general savegame/mp3 bug.