Opened 6 months ago

Last modified 6 months ago

#14618 new defect

SCUMM: IMUSE: Inaccurate fades in INDY4

Reported by: GermanTribun Owned by:
Priority: normal Component: Engine: SCUMM
Version: Keywords:
Cc: Game: Indiana Jones 4

Description (last modified by 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.

Attachments (3)

atlantis.s04 (25.7 KB ) - added by eriktorbjorn 6 months ago.
Savegame with the Dialog, outside Indy's office
foa-dialog-fix.txt (1.9 KB ) - added by eriktorbjorn 6 months ago.
Possible fix for the Dialog glitch
Atlantissaves.zip (242.9 KB ) - added by GermanTribun 6 months ago.

Download all attachments as: .zip

Change History (25)

comment:1 by GermanTribun, 6 months ago

Description: modified (diff)

comment:2 by eriktorbjorn, 6 months ago

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.

Last edited 6 months ago by eriktorbjorn (previous) (diff)

comment:3 by eriktorbjorn, 6 months ago

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.

comment:4 by eriktorbjorn, 6 months ago

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.

Version 0, edited 6 months ago by eriktorbjorn (next)

by eriktorbjorn, 6 months ago

Attachment: atlantis.s04 added

Savegame with the Dialog, outside Indy's office

by eriktorbjorn, 6 months ago

Attachment: foa-dialog-fix.txt added

Possible fix for the Dialog glitch

comment:5 by eriktorbjorn, 6 months ago

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.

comment:6 by eriktorbjorn, 6 months ago

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.

comment:7 by AndywinXp, 6 months ago

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

comment:8 by AndywinXp, 6 months ago

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

comment:9 by eriktorbjorn, 6 months ago

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.)

comment:10 by AndywinXp, 6 months ago

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.

comment:11 by AndywinXp, 6 months ago

Done, it should be fixed now.

comment:12 by eriktorbjorn, 6 months ago

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.

Last edited 6 months ago by eriktorbjorn (previous) (diff)

comment:13 by AndywinXp, 6 months ago

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

comment:14 by eriktorbjorn, 6 months ago

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.

Last edited 6 months ago by eriktorbjorn (previous) (diff)

comment:15 by AndywinXp, 6 months ago

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

comment:16 by AndywinXp, 6 months ago

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.

comment:17 by eriktorbjorn, 6 months ago

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!

comment:18 by GermanTribun, 6 months ago

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)

comment:19 by AndywinXp, 6 months ago

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

comment:20 by GermanTribun, 6 months ago

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.

by GermanTribun, 6 months ago

Attachment: Atlantissaves.zip added

comment:21 by GermanTribun, 6 months ago

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?

comment:22 by AndywinXp, 6 months ago

Summary: SCUMM: iMuse trouble in INDY4SCUMM: IMUSE: Inaccurate fades in INDY4
Note: See TracTickets for help on using tickets.