#2077 closed defect (fixed)
COMI: Failed assertion in Digital iMUSE
| Reported by: | eriktorbjorn | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Monkey Island 3 |
Description
The Curse of Monkey Island, English version Latest ScummVM CVS snapshot
I'm getting a failed assertion on line 579 of dimuse_codecs.cpp. The assertion is that "(firstWord & 3) == 0". It doesn't happen right away - not on the difficulty selection screen - but it does happen on the chapter screen right after the intro cutscene.
If I remove the assertion, everything seems to be working fine. But I don't quite dare to do that.
Ticket imported from: #1227778. Ticket imported from: bugs/2077.
Change History (5)
comment:1 by , 19 years ago
| Owner: | set to |
|---|
comment:2 by , 19 years ago
comment:3 by , 19 years ago
And since you asked for step-by-step instructions:
* Start COMI in ScummVM. * Pick a difficulty level. It doesn't matter which one. * Either wait for the intro to finish, or press Escape a few times.
When the assertion fails the screen is still blank, but it's where it would ordinarily show the "Part I" screen. It's the "Interlude 1" music, but the assertion also fails on the "Hold" music that comes next.
It probably only happens with the original (uncompressed) music files, since otherwise we wouldn't use these codecs at all, I guess.
comment:4 by , 19 years ago
I noticed the assertion has been changed to "(firstWord & 1) == 0" instead. I don't know enough about the code to see how even that is guaranteed, but it does fix my problem.
comment:5 by , 19 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
This appears to be the data it chokes on:
decompressCodec(15, 026547E0, 02734044, 1147) 000000: 00 8a 69 4d 55 53 00 0f c8 8a 4d 41 50 20 00 00 |..iMUS....MAP ..| 000010: 00 72 46 52 4d 54 00 00 00 14 00 00 00 8a 00 00 |.rFRMT..........| 000020: 00 00 00 00 00 10 00 00 56 22 00 00 00 02 54 45 |........V"....TE| 000030: 58 54 00 00 00 14 00 00 00 8a 32 31 30 35 2d 49 |XT........2105-I| 000040: 6e 74 65 72 6c 75 64 65 31 00 54 45 58 54 00 00 |nterlude1.TEXT..| 000050: 00 16 00 00 00 8a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a |......**********| 000060: 2a 2a 2a 2a 2a 2a 2a 00 52 45 47 4e 00 00 00 08 |*******.REGN....| 000070: 00 00 00 8a 00 0f c8 00 53 54 4f 50 00 00 00 04 |........STOP....| 000080: 00 0f c8 8a 44 41 54 41 00 0f c8 00 82 0c 88 80 |....DATA........| 000090: a2 20 a2 82 22 22 20 c8 82 08 a2 20 2a 20 a2 08 |. .."" .... * ..| 0000a0: a0 a2 22 80 2a 0a 20 a0 a2 22 20 a0 a2 82 22 0a |..".*. .." ...".|
In this case, firstWord would be 138 which will land it shortly after the DATA chunk. We may be able to make assertions about firstWord relative the beginning of the DATA chunk, since that's presumably where we begin to skip audio samples, but I don't see how we can make assumptions about it relative the beginning of the iMUS chunk.