Opened 17 years ago

Closed 16 years ago

Last modified 11 months ago

#382 closed defect (outdated)

ALL: mp3 bug when loading a save game

Reported by: SF/logicdeluxe Owned by:
Priority: normal Component: Audio
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, 17 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, 17 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, 17 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, 17 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, 17 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, 17 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, 17 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, 17 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, 17 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, 17 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, 17 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, 16 years ago

Resolution: outdated
Status: newclosed

comment:13 by fingolfin, 16 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, 11 months ago

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