Opened 17 years ago
Closed 16 years ago
#3005 closed defect (fixed)
COMI: Music fade-out broken for compressed audio
| Reported by: | eriktorbjorn | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Monkey Island 3 |
Description
Current ScummVM SVN snapshot. English version of the game.
I discussed this with aquadran a bit the other day, but just so that it won't be forgotten:
Usually (always?) when a piece of music ends and another one begins, the game fades down the first piece of music rather than stopping it abruptly. But when using compressed audio files, the music jumps to the beginning of the track just as it's beginning to fade out.
As far as I can tell, the bug does not happen with the original (uncompressed) audio files. Though even there, there might be a slight skip when the sound is "cloned" from one track to another. It's hard to hear for sure.
One good place to observe this is early in the game, after you've managed to get Wally away from the cannon. Both the indoors and outdoors music have fairly distinctive starts, so simply walk between the two rooms and listen carefully to what happens.
I think the reason for this is the rather unusual way Digital iMUSE handles fading out. Although there is code present to fade any track up or down, when a track is set to fade out and die, it is "cloned" to a completely different track. See the cloneToFadeOutTrack() function for details. I guess the new audio stream isn't re-positioned to the point the old one was.
Ticket imported from: #1635361. Ticket imported from: bugs/3005.
Change History (6)
comment:1 by , 17 years ago
| Summary: | CMI: Music fade-out broken for compressed audio → COMI: Music fade-out broken for compressed audio |
|---|
comment:2 by , 17 years ago
comment:3 by , 17 years ago
thebluegr: Be careful about making such guesses. We had various problems related to cloneToFadeOutTrack in the past, all of them totally different and not really related to each other. Just because two bugs occur in the same function does not mean they are the same bug.
Torbjörn, there are several ways to handle this I think:
* Get rid of cloneToFadeOutTrack -- not sure whether this is doable (depends really on why exactly we need it in the first place) * Add seeking (or at least skipping) to the compressed audio streams, then re-seek the clone streams * As a some what less intrusive variant to the first proposal, transfer ownership of the (compressed) audio stream when performing the fade out cloning, i.e. let the fade out track simply use the same stream (assumes that the original track has no need for the stream anymore).
comment:4 by , 17 years ago
I just noticed that cloneToFadeOutTrack did not properly setup the "compressed" flag of the new (fade) track. So I commited a fix for that. Not sure if that caused any problems, or is even related to this bug, but I thought I'd mention it just in case.
comment:5 by , 16 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Bugs #1624464 and #1527274 seem to be related with this one. The bug submissions don't contain information concerning the compression used on the game's audio files, both of them are related to cloneToFadeOutTrack() (which, by the looks of it, seems to be producing erratic behavior when dealing with compressed tracks).