LSL1 VGA (Russian) freezes when hailing cab

[oprion]

In the Russian-language version of the game (lsl1sci-ru) when hailing
a cab the game freezes with the following error in the console:

Access violation seeking sound.205: 0 + > 5 (abs: 0 + 6 > 5)!

ScummVM version: 2.1.0
Settings: MT32-Emulator (also tried PC-Speaker with the same result)

It works correctly in DosBox, with all the sounds in the right place
and no crashes, with SoundDrv set to mt32.drv and emulated through
MUNT.

[sluicebox]

Thank you reporting this. There is something odd about that version of sound 205, it's using 0xFE as a track terminator instead of 0xFF, which our SoundResource code expects. I don't know if that was a legal value or if it's a corrupt sound. SCI Companion can't load this sound either, but it loads the others, so it looks like it's just this sound that's weird.

In the meantime you can work around this if you have the English version of the game:

1. Load the English version in ScummVM
2. Bring up the debugger with CTRL+SHIFT+D (or maybe CTRL+ALT+D, it was recently changed)
3. Enter the command: diskdump sound 205
4. Move the file sound.205 from your ScummVM directory to your Russian LSL1 directory

[sev-]

Probably we could do patching on load?

[oprion]

This actually works! Yay!

Replying to sluicebox:

Thank you reporting this. There is something odd about that version of sound 205, it's using 0xFE as a track terminator instead of 0xFF, which our SoundResource code expects. I don't know if that was a legal value or if it's a corrupt sound. SCI Companion can't load this sound either, but it loads the others, so it looks like it's just this sound that's weird.

In the meantime you can work around this if you have the English version of the game:

1. Load the English version in ScummVM
2. Bring up the debugger with CTRL+SHIFT+D (or maybe CTRL+ALT+D, it was recently changed)
3. Enter the command: diskdump sound 205
4. Move the file sound.205 from your ScummVM directory to your Russian LSL1 directory

[sluicebox]

Great! I've since tried loading this with SCI Resource Viewer and it is able to parse and understand this alternate sound resource just fine. That implies that this sound is okay but that our parser isn't taking this rarely used track terminator into account. I think the SCI Companion code is based on ours so it's not surprising it can't read this either.

We should leave this open until we've figured this out and updated our SoundResource code.

[sluicebox]

Fixed in: 93b634fe7ca3995a40bc63325513bcbd682c8ade

After further investigation, this is indeed a corrupt sound resource. As sev said, this is a great candidate for our resource patcher to fix the two broken bytes.

The reason this didn't crash the original is that it would find a matching track entry earlier in the list, one that used the correct 0xFF terminator, and so it wouldn't get this far. Patching all the terminators in this sound to use 0xFE locks up the original. I was wrong about SCI Resource Viewer, it only parses the tracks before the broken bytes.

Thanks again for the report!