Opened 22 years ago

Closed 21 years ago

Last modified 5 years ago

#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 SF/logicdeluxe, 22 years ago

I first noticed this in ZAK256, but I just noticed the same behavior in Monkey1. Seems to be a general savegame/mp3 bug.

comment:2 by SF/logicdeluxe, 22 years ago

Component: Engine: SCUMM--Unset--
Game: Zak McKracken
Summary: ZAK256: mp3 bug when loading a save gameALL: mp3 bug when loading a save game

comment:3 by eriktorbjorn, 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 SF/ender, 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 SF/khalek, 21 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 fingolfin, 21 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 eriktorbjorn, 21 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 SF/tom_newton, 21 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 fingolfin, 21 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 fingolfin, 21 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 fingolfin, 21 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 fingolfin, 21 years ago

Resolution: outdated
Status: newclosed

comment:13 by fingolfin, 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 digitall, 5 years ago

Component: --Unset--Audio
Game: Zak McKracken
Note: See TracTickets for help on using tickets.