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 linear there. 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.