Opened 16 years ago

Closed 16 years ago

Last modified 11 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 16 years ago.
Savegame near the end of the game

Download all attachments as: .zip

Change History (7)

by eriktorbjorn, 16 years ago

Attachment: atlantis.s55.gz added

Savegame near the end of the game

comment:1 by eriktorbjorn, 16 years ago

Owner: set to SF/jamieson630

comment:2 by SF/jamieson630, 16 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, 16 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, 16 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, 16 years ago

Resolution: fixed
Status: newclosed

comment:6 by digitall, 11 months ago

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