SCUMM: Distorted speech on submarine in Indy4

[raziel-]

ScummVM 2.1.0git (May 29 2018 08:17:19)
Features compiled in: Vorbis FLAC MP3 RGB zLib MPEG2 Theora AAC FreeType2 JPEG PNG cloud (servers, local)

On the german submarine one can navigate into a game over screen.
One can order the man to either side of the ship and to tell them to go about their buisness.
In the save game, i did so.
I told them "Good work, Carry on".

In the savestate, if one goes down the ladder Indy will say "I have a bad feeling about this" and climbs down.
Once in the midship area the sailors will see him and start talking (what i don't know).
Instead of the talking there is a huge amount of noise played instead until the sailors go on and grab Indy.
Indys "Uh-Oh" is played fine again.

I have the MONSTER. SOU file and ATLANTIS.001 and ATLANTIS.002.
I have not tinkered with or crunched the sound file.

Playing the game directly from CD creates the same dissorted sound.
md5sums of both the games directory and the original CD file are the same.

Indiana Jones and the Fate of Atlantis (CD/DOS/English)

AmigaOS4 - PPC - SDL - BE
gcc (adtools build 5.4.0) 5.4.0

[raziel-]

Just go down the ladder

[bonki]

I dumped the VOC in question from my MONSTER.SOU (MD5 8f9ea0cfd03f6631c8072797192d1f0b) and playing the file directly results in the same noise so it would seem that the speech sample is broken in the game data so the original should behave the same, although I have not verified this. We should also rule out that it's simply a broken data block header which we could work around (I doubt it is, though).

If this is the case we should consider silencing this particular sound, it's quite unpleasant to listen to, especially with headphones :-)

[bonki]

A better workaround might be to replace the broken sample with another one which is working. It's not perfect because the same sentence will be used twice by two different characters in the game, but leaving the noise in place or disabling this sample altogether would be even more noticeable.

The supposedly broken sample is at offset 0x76ccbca, two working "Hey, you!" samples can also be found at offsets 0x6a3b232 and ‭0x69e5935‬ which can be played back instead of the broken one. I tried this locally with a workaround in engines/scumm/sound.cpp and it works nicely.

The remaining question is if the VOC payload really is irreparably broken and if there is more than one version out there.

[bonki]

Potential workaround in ​PR-1208. Does this work for you?

I'm a little hesitant to push this to master, can you confirm that this also occurs in the original? I don't have an original savegame handy, unfortunately.

[jepael]

Corrupted part shown at different sample formats

[jepael]

I examined the file with a hex editor and imported the file at various formats to Audacity.

The VOC header of the sample in question indicates it's in 8-bit unsigned PCM format, but it looks like it's playable when imported as 16-bit signed PCM.

As a workaround, can the format be forced to play that sample correctly?

[raziel-]

I can test with dos Box, nur mit instantly.

If you still Need it test I'll be able to play it in the middle of Next Week earliest

Thanks for taking a look

[bonki]

@jepael I cannot replicate this, can you describe what exactly you did? If I change the codec number in the sound data block from 0x00 (unsigned 8 bit) to 0x04 (signed 16 bit) and leave the frequency divisor alone (0xA6, aka 11111 Hz) the file still plays as garbage.

However, if I strip the VOC header and treat the data as PCM signed 16 bit, big endian at 44100 Hz it seems to play correctly.
This leads me to believe that this isn't really a proper VOC file to begin with because signed audio in VOC is always little endian (I think).

[bonki]

​PR-1208 updated.

@raziel-
Yes please, I'd be grateful if you could post an original savegame.

[jepael]

@bonki I re-checked and indeed the data seems to be big-endian (most significant byte first) for some reason (so your thinking is correct, 16-bit VOC files should be little-endian).

I just imported the monster.sou file into Audacity as raw data at various formats, but did not take offsets and endianess into account before. By looking at the .sou file again with hex editor the actual sample data starts at even offset and that's why it worked when importing to Audacity as big-endian.

I don't have an estimate about the sampling rate though.

[bonki]

This should now be fixed in commits scummvm@788d85d6b82400e0e6f7e68e4a343129e4d3052a and scummvm-tools@72655d828c4670afce37f5ab1c92486f48f461d8, respectively.

[raziel-]

Sorry for the long delay.

Confirmed working, "Hey you" can be heard.

Do you still need the original save state?

[bonki]

Yes, please :-)

[raziel-]

Same save state, but with DosBox - just go down the ladder

[raziel-]

Seems i found an original game bug, it disorts the same way in the original.

Maybe no one thought about while play testing?

[bonki]

Looks like it. Thanks a lot for reporting and providing an original savegame!