Opened 17 years ago

Closed 17 years ago

Last modified 23 months ago

#961 closed defect (fixed)

FOA: AdLib sound distortion

Reported by: eriktorbjorn Owned by: SF/jamieson630
Priority: normal Component: Engine: SCUMM
Keywords: Cc:
Game: Indiana Jones 4

Description

[Extracted from bug report #761637]

[FOA, English talkie version]

When using AdLib sound there are some places at the end of FOA where the instruments sound very distorted. Particularly during Dr. Ubermann's transformation - in this case all of the bad noises are coming from channel 5 by the way - but also during Kerner's transformation.

Maybe it has something to do with pitchbend? If I disable the pitchBend() function the bad noises go away. But why would it make some instruments sound horrible while most instruments sound just fine? Is it a bug in our AdLib driver, or in the fmopl code itself?

I'm attaching a savegame right before starting the machine at the end. (The stones are set to their correct positions already.)

Ticket imported from: #766984. Ticket imported from: bugs/961.

Attachments (1)

atlantis.s55.gz (16.0 KB ) - added by eriktorbjorn 17 years ago.
Savegame near the end of the game

Download all attachments as: .zip

Change History (7)

by eriktorbjorn, 17 years ago

Attachment: atlantis.s55.gz added

Savegame near the end of the game

comment:1 by eriktorbjorn, 17 years ago

Owner: set to SF/jamieson630

comment:2 by SF/jamieson630, 17 years ago

Okay, I was able to observe this, as well. Not only do pitch bends sound horrendous, the rest of the music sounded pretty broken up, like voices were continually dropping in and out abruptly.

I restored the following files to the 0.4.0 release revision, in order to test if this was related to the new YM3812 emulation code:

sound/fmopl.h sound/fmopl.cpp backends/midi/adlib.h * backends/midi/adlib.cpp *

* For the Adlib code, I put back in the new memory init code and restored the new timer-rate value required by the revamped iMuse.

The resulting music was perfectly clean -- a VERY NOTICEABLE improvement over the current CVS output. Since no significant changes have been made to the Adlib code since 0.4.0 (I only restored that code to reinstate the old emulator calls), my conclusion, is that this is a problem with the new YM3812 emulation code.

Since I'm not aware of ANY situation where the new code has IMPROVED the quality of Adlib emulation, my vote is to reinstate the old code indefinitely -- until we're able to understand exactly what would cause the new code to generate such lousy output.

Ender? Fingolfin? Comments?

comment:3 by eriktorbjorn, 17 years ago

I don't have any savegame for 0.4.x so I can't hear it for myself, but if it's as you say then I'm all for reverting to the old, proven code for 0.5.0 at least.

(Of course, for future versions it would be nice if we could use the newer code because in theory it *should* be better.)

Maybe we should bring this up on the ScummVM mailing list? Could you do that? Endy used to complain that the mails I sent there were unreadable to him, and you know more about the changes involved than I do anyway.

comment:4 by SF/jamieson630, 17 years ago

Eck.... I made an error in my tests. In the process of reverting to the old FMOPL code, I accidentally reversed a change Fingolfin had made to the Adlib driver, as well. It turns out THAT was the problem, not the FMOPL code.

It turns out that during the FOA musical passage in question, a large number of notes are passed in that are WAY out of range. The old code used a lookup table and happily looked up way outside the table's range -- getting, interestingly enough, 0's for the values it was looking up. Seems to sound right with 0's, so I just took Fingolfin's new code (which is based on computations rather than lookup tables) and made sure to return 0's if the note is out of range.

This phenomenon DOES warrant tracing backwards to figure out WHY these notes are so far out of range. (I mean, c'mon, note numbers in the 1,000's when the highest valid note number is 127?) This fix only makes the music sound like it used to, but there might be a more subtle bug that's been making the music sound not QUITE the way it did in the original.

Anyway, closing this one, and I'll look at the other potential problem separately.

comment:5 by SF/jamieson630, 17 years ago

Resolution: fixed
Status: newclosed

comment:6 by digitall, 23 months ago

Component: Engine: SCUMM
Game: Indiana Jones 4
Note: See TracTickets for help on using tickets.