ALL: MT-32 to GM key velocity conversion
|Reported by:||SF/logicdeluxe||Owned by:||SF/jamieson630|
I experimented with the key velocity, which definately
is different between GM and MT-32 so it needs to be
converted as well in case a MIDI track is converted.
For my tests I used my three GM wavetables and compared
them to the MT-32 output. These are a Yamaha MU5, a
Terratec wavetable professional, and a SB-Live with the
standard sound font.
I measured the output levels of the notes in order to
figure out the relation to the velocity. (I didn't
found that information in any documentation. Seems
they'd forgotten that in the GM proposal back than.)
What I found out is, that GM wavetables in fact have
quite wide spreaded different velocity behavior. Here
are the results given in the difference between a
velocity 127 note compared to a velocity 1 note.
MT-32: -30 dB
Yamaha MU5: -35 dB
Terratec: -40 dB
SB-Live: -54 dB
The ranges between those do not differ that extremly,
so a linear translation would do, I guess. And even the
MU5 looks less dynamically at first sight, the result
sound similar dynamically to SB-Live after my
corrections formula, since the curve is slightly more
So obviously the MT-32 is less dynamically than average
GM wavetables. This is why some tunes don't sound that
well in current ScummVM with MT-32 to GM conversion.
Some quiter melodies are almost not audible. For
instance listen to the Monkey2 Woodtick's outdoor
music, where the slow background melody are almost not
audible without velocity correction.
In conclusion I would suggest the following formula,
which sounds pretty close to the original MT-32 dynamic
with all my three wavetables (which sounds in deed a
lot better than without it):
GM velocity = MT-32 velocity * 3/4 + 32.
A check would be required, so it only would be
translated when the source is MT-32 MIDI, ie. it is a
'ROL ' resource, AND native MT-32 is NOT selected.
This is not to be confused with the expression
controller which exist on many MIDI devices, and in
fact it works completely different as I figured out. To
be exact, it usually scales down the dynamic fixed at
the quite end of the range which wouldn't solve the
conversion problem. So better leave that one alone and
implement that formula.
Ticket imported from: #817242. Ticket imported from: feature-requests/141.