SCUMM: IMUSE: Inaccurate fades in INDY4

[GermanTribun]

System: Windows 10 Pro
ScummVM: 2.7.1
Game: Indy 4 CD

The iMuse engine of Indy4 seems to have troubles, at least when using MT-32 (I didn't yet test other sound options).

I first noticed the problem due to the lost dialogue and the cutscene where Sophia reads it in the office, since after closing the book, the music started again from the beginning. I then noticed that while in the original interpreter reading the book anywhere else is not supposed to influence music at all, in ScummVM it seems to confuse iMuse when opening and closing the book, which I especially noticed in the dig site after turning on the light. It results in terruptions in the music or the music jumping back several seconds.

I checked further and there were numerous instances where the fades between music tracks didn't work (for example, the travel music just cuts off instead of fading out, when you visit Iceland or Monte Carlo in team mode for the first time).

I honestly don't know if it is an iMuse problem or an MT-32 problem, but the music behavior is not correct compared to the original.

EDIT: After using other music options, where the problems remain (though a bit less noticable), it indeed seems to be an iMuse problem.

[eriktorbjorn]

I can reproduce the music glitch when reading the Dialog, though it doesn't seem to happen quite every time for me.

One possible lead may be that when you open the Dialog, the game makes a temporary save that gets reloaded when the Dialog is closed. But it's supposed to leave the music alone when loading a temporary save state, and as far as I can see it does. So I still don't know exactly where the glitch happens. (My hunch is that you have to let the music play for a while to trigger the bug reliability. The music changes after a while, and that may have something to do with it perhaps?)

I have no theories about the fade-outs, or lack thereof. At least not yet.

[eriktorbjorn]

I think I'm on to something when it comes to the Dialog glitch. The ScummEngine::showMainMenu() function will set _saveSound to 1, perhaps to ensure that sound is loaded when using the original save/load GUI. But unless that's then cleared (I don't think it is), the subsequent temporary savegames will restore the music state, even though they should not.

That could be why it's not been noticed before. The original GUI is a fairly new addition to ScummVM.

It seems that even when _saveSound is 0, there's an audible glitch that may be related to the sound being paused/unpaused. So that will probably have to be looked at as well.

[eriktorbjorn]

Come to think of it, I'm not sure the menu even has to set _saveSound, because sound should always be included in regular savegames. Only temporary savegames are affected by that, I thought. But there could easily be subtleties that I'm not aware of here.

Edit: It may still have to make sure that _saveTemporaryState gets set to false somewhere, though.

[eriktorbjorn]

Savegame with the Dialog, outside Indy's office

[eriktorbjorn]

Possible fix for the Dialog glitch

[eriktorbjorn]

I've attached a possible fix. What it does is:

• After the main menu is done, restore the old values for _saveSound and _saveTemporaryState. This may be overkill.
• During save, when saving a temporary state (without sound), do not pause the music. I don't know if this completely fixes audio glitches during the save, though.

So this is just proof-of-concept.

[eriktorbjorn]

By the way, note that nothing of what I've written so far has anything to do with the fades between tracks. I haven't even looked for that - I don't know if I'm capable of diagnosing it - and I assume it's an unrelated problem.

[AndywinXp]

There you go, the main issue is solved. We might need an iMUSE expert for the fading issues though.

[AndywinXp]

Could you please provide savegames for the original DOS executable and ScummVM before the aforementioned fade issue arises?

[eriktorbjorn]

Something still seems to be wrong. Here's what I did:

1. I loaded the savegame (_saveSound = 1, _saveTemporaryState = 0)
2. I entered the office. The Dialog was opened, and a temporary save was made (_saveSound = 0, _saveTemporaryState = 1)
3. I closed the Dialog. The temporary save was loaded (_saveSound = 0, _saveTemporaryState = 1)
4. I loaded my savegame again (_saveSound = 1, _saveTemporaryState = 1)

Everything works fine until I get to step 4. After step 4, the music is no longer playing. Probably because _saveTemporaryState is still 1.

(Oddly enough, on the first attempt I made while writing this bug report the music was playing correctly after step 4. But _saveTemporaryState was still 1.)

[AndywinXp]

Okay, using _saveTemporaryState as part of the condition in loadState() is really unreliable. I'm committing a change in which I use the "compat" parameter.

[AndywinXp]

Done, it should be fixed now.

[eriktorbjorn]

Edit: Oops, I didn't see that a fix had already been committed. This table may be out of date.

The behavior depends on if you're using the original GUI or the ScummVM GUI:

	ScummVM GUI		Original GUI
Step	_saveSound	_saveTemporaryState	_saveSound	_saveTemporaryState
Manually load savegame	0	0	1	0
Open Dialog	0	1	0	1
Close Dialog	0	1	0	1
Manually load savegame	0	0	1	1

So with the ScummVM GUI it works. With the original GUI, it doesn't. At least in this particular case.

[AndywinXp]

Let me know if with the latest fix the issues are gone :)

[eriktorbjorn]

The issue seems to be gone, but the discrepancy illustrated by the table above is still there. To clarify this was captured at the "Save/load the iMuse status" point in the code. I guess it makes no difference to (_saveSound || !_saveTemporaryState), but I still find it worrying that _saveTemporaryState is true when manually loading a save state.

[AndywinXp]

Okay, I'll check that one out later...

[AndywinXp]

Actually, now that I think about it, this is a non-issue: the original GUI doesn't use _saveTemporaryState at all, it uses the saveState() and loadState() functions setting the "compat" parameter as false.

Truth to be told, _saveTemporaryState is only an auxiliary variable which was needed for ScummVM in particular, to let save states work properly on all fronts. But we don't really need that when following the original code path.

[eriktorbjorn]

Good enough for me then. The music around the Dialog sounds seamless to me, loading the savegame afterwards (or before) works, and I haven't found any other ways of breaking it. The only disappointment was that I misdiagnosed the source of the problem, but at least I got a simple test case from it. :-)

Thanks for taking care of it!

[GermanTribun]

Ah, so that leaves the problems with the fades, and that means create saves for comparison. I could create saveral, though I hope it's no problem that the original interpreter is the German floppy version, while ScummVM is the German CD version. (that's due to technical reasons)

[AndywinXp]

Thanks! Sure, no problem about the different versions :)

[GermanTribun]

All right, here a Zip with seven saves each from the original interpreter (German Floppy iwth Adlib music) and ScummVM 2.7.1 (German CD with MT-32 music), please note that you most likely need to alter the names of the ScummVM-saves to use them. The saves for both platforms are labeled Test 1-7.

Test 1: Push the button to send the ghost onto the stage. The ghost music should start while Indy makes his comment, but doesn't in ScummVM until the ghost reaches Sophia.

Test 2: Advance the scene until the view skips to the close-up of the necklace. In the original interpreter there is a smooth transition, while ScummVM has a hard cut.

Test 3: Advance the scene until the travel to Iceland happens. When the scene changes to iceland the original interpreter quickly fades out the music while hanging on a note. In ScummVM, either the note hangs without fading, or there just is a hard cut in the music.

Test 4: Give Costar the eel figurine. Once the scene changes to the Nazi lab, the original interpreter has a smooth transition in the music, while ScummVM has a hard cut.

Test 5: Travel to Monte Carlo. Original has a smooth music transition at arrival while ScummVM has a hard cut.

Test 6: Walk in and out of the dig site. The music fades of the original are missing in ScummVM, which cuts hard.

Test 7: The same as Test 6, only with the other music.

[GermanTribun]

Btw., during the creation of the saves I made two obervations:

-The sound of Dr. Heimdall chisling the ice almost never syncs up with the animation. Was that already a problem in the original and and the any chance to fix that?
-When Omar leads Indy and Sophia through the marketplace, the food vendor for some reason is missing (also in the original). Is that an engine limitation since otherwise there would be too many actors on screen?

[AndywinXp]

Most of these have now been fixed in the daily (which is, all except for Test 1), can you confirm?

[GermanTribun]

Much smoother already. The problem with Plato's Dialogue was fixed and the transitions now mostly work as intended (with exception of the first test, I wonder what's going on there). Of course those instances were only the ones I used to demonstrate the problem, but considering the time you probably went through the whole game.

I can guess that iMuse is a very complicated engine?

[AndywinXp]

In tomorrow's daily, Test 1 should also be fixed. Please confirm if so.

[GermanTribun]

I had to use the branch master, since the stable release was still from the 15th. Yep, now the first scene has its music work as intended as well.