What MT-32 model was used at s-island.mixnmojo.com?

[LogicDeLuxe]

I noticed that those sound slightly different to my own recorded tracks.

I'm curious, what MT-32 revision or compatible device was used to record the Monkey Island 2 tracks there?

What hardware was used to digitize them?

What was done to them? Noise reduction maybe?

 

Mine is done with an MT-32 first revision through an M-Audio Delta-44. MT-32 modules are known to suffer from quantization noise, which the Delta's ADC perfectly capture along with the music.

 

Beside the somewhat lower noise level in those Ogg's, I also notice that the reverb sounds slightly different in places. Are there difference which could produce those between MT-32 revisions?

 

If someone is interested, I did my recording for a best of Monkey Island 2 soundtrack CD, which features most of the tracks. It has no spaces between the tracks in most cases, as they are edited and cross faded. All are recorded from my MT-32, except for Jojo playing the piano, which is the piano patch from my Sound Canvas SC-155 and I also included the 192 kbps version of Highland Productions' "Underground Orchestral Remix", which fits the scene just perfect, imho.

[s-island]

All the tracks available today are recorded from a CM-64 with the left and right audio cable swapped because the game reverses the panpot upon playback and I'm using ripped MIDIs without the panpot reversed. It also seems to be how they were made because the built-in pan of the MT-32 is not reversed and you get some weird pans later, like Guybrush's falling sound is in the left speaker when he falls on the right side of the screen into LeChuck's bunker.

 

I used the external breakout box of an Audigy 2 ZS to record the files. I lowered the noise floor by creating a noise profile in Adobe Audition and applied that to the files. The noise is constant so the profile removes it pretty well without messing up the music. It also gets rid of the quantization noise, which is a nice side-effect. You notice that mostly in the pads and swells.

 

How do you record the music? Directly from the game or by playing back the MIDI files? The game changes the reverb on the MT-32 when you start it up (and also duplicates 12 of the percussion notes on empty notes, plus removing the duplicated notes' reverb). Depending on how you record, that could account for the difference in reverb.

[elTee]

The Audigy was a great sound card for recording audio. I found it to be almost flawless when I recorded audio from my Gamecube - a great sound card. Shame it broke! Lousy Creative - at least I don't have Vista.

[s-island]

Yeah, the breakout box of the Audigy 2 ZS has some good inputs. I'll be getting a professional card soon though because I want one with proper Gigastudio support.

[LogicDeLuxe]

All the tracks available today are recorded from a CM-64 with the left and right audio cable swapped because the game reverses the panpot upon playback...

I'm aware that the Roland MT series has the panning reversed in comparision to GM/GS. This fact is even stated in the Sound Canvas manual. I noticed your recording is opposite to mine and swapped channels for comparision.

It also gets rid of the quantization noise, which is a nice side-effect. You notice that mostly in the pads and swells.

In deed, I did notice. It is filtered a bit too much for my taste. It takes something which defines the sound of the MT-32, imho. It's a matter of taste, though. I personally just filter the mirror frequencies off above 16kHz on MT-32 and Sound Canvas recordings.

 

I'd like to know if the hardware differences are actually noticable. In order to make an accurate comparision, I need to know what MIDI files exactly you used. And I need to know the exact parameters you used for noise reduction. I use Adobe Audition myself, so I can do the same filtering.

How do you record the music? Directly from the game or by playing back the MIDI files?

I played through the game using ScummVM, so I got iMuse in action. I sometimes used the console to interrupt tracks and get clean beginnings of some in order to have more control when I edited the compilation for the CD.

The game changes the reverb on the MT-32 when you start it up (and also duplicates 12 of the percussion notes on empty notes, plus removing the duplicated notes' reverb). Depending on how you record, that could account for the difference in reverb.

I am aware of that too. I was the one who examined the SysEx of the original DOS executable so it can be reproduced in ScummVM. I also translated the reverb settings to GS, which is what the GS option is doing in ScummVM.

[s-island]

It takes something which defines the sound of the MT-32, imho.

Yeah, the annoying quantization noise. But as you said, it's a matter of taste.

 

As I said, I used the MIDI files from the game after transmitting the bootup sysex. I edit together the sequences that make up a tune, of course. Here's an unfiltered copy of track 2 and here's the MIDI I made for this track.

 

I should have specified about the noise profile. I don't use some preset values, I create it by recording some silence before I start playing a MIDI file. If I record 4-5 tracks at once, I use the same profile on all of them, but I don't bother to save it.

[LogicDeLuxe]

I recorded that MIDI and encoded it to Ogg Vorbis at the same volume as yours, thus best suited for comparison. largotestmt32.ogg

It sounds slightly different to your largotest.ogg, but really not by much. Hard to tell if this is related to the different DAC or even the ADC used to record this, or if the difference prior the DAC actually makes an audible difference. Reverb seems to be the same at least.

 

Anyways, there is a bigger difference between that MIDI file and ScummVM's output for some reason. Besides some slightly different reverb settings, the volume between the instruments to each other seems to be different for some reason. Maybe it's the way iMuse works.

[s-island]

The default settings of MI2, when not running it through ScummVM, sets max volume to 96 out of 127. All the other volume controllers are then lowered so that they're relatively the same. I see ScummVM uses 192 out of 256 as default volume. I assume that means it'll also lower the volume to 96 by default. My MIDI file is taken directly from the game's resource files and therefore uses the full 127 range.

 

Maybe that has something to do with why it sounds different. I've noticed that the instruments of the MT-32 don't all react the same way when the volume's changed.

 

The DAC of the CM-64 is the PCM54, the same the MT-32 uses.

 

Update: I tried changing the volume to 256 in ScummVM and now it sounds much closer to my recording.

[LogicDeLuxe]

...

Maybe that has something to do with why it sounds different.

Not really. I set the volume to 256 in ScummVM, which then plays at about the same overall loudness your MIDI file does. I also tried at 192, but I didn't notice a big change other than a worse noise ratio.

I've noticed that the instruments of the MT-32 don't all react the same way when the volume's changed.

Might be, but there seems to be more to it than this.

The DAC of the CM-64 is the PCM54, the same the MT-32 uses.

It's connected differently, though, according to this: http://en.wikipedia.org/wiki/MT-32

[s-island]

Well, ScummVM sends a lot of junk to the MT-32 compared to the game running in DOS....

[LogicDeLuxe]

Now this one really sounds different: http://www.sendspace.com/file/lcaz6j

In this one, my MT-32 got the MIDI from Monkey 2 running in DOSBox.

[s-island]

Heh, for some reason it's playing sax 4 instead of bassoon.

 

Proof that the imuse implementation still has a way to go before it's perfect, I guess.

[LogicDeLuxe]

I just hooked up my MT-32 to my old Pentium 200 mmx running Windows95 and installed Monkey 2 in order to check this out on the real thing.

 

Running that machine in full speed sounds much like your largotest.ogg.

But slowing it down (ie. CPU internal cache turned off in the BIOS setup), it suddenly plays just like DOSBox with that one instrument changed.

 

Could it be that an instrument change is sent corrupted on fast machines? After all, the game was made for a 386 at best.

Did you examine the MIDI's and could you see what is actually meant to be played?

Still strange since in too fast machines, usually a lot more problems like hanging notes arise. Nothing like this happens here, though.

[s-island]

Well, I did check the original MIDI file and I found the reason. At the beginning of each imuse MIDI file, at tick 1, there are typically a row of sysexes that are sent to the imuse engine that sets the instruments, volume, panning, and so on for each part. These sysexes are then decoded by the imuse engine, which then sends the resulting messages to the MT-32. Why it uses sysexes instead of regular controllers is so the engine can choose which parts of the MT-32 should be used in case another MIDI is already occupying some parts. This is especially important in cases where you have a cross-fade between two MIDIs or where there are multiple MIDIs making up the background music.

 

The MIDI file for Largo's theme also has a bunch of these and here's the one for the melody line, which is usually played by a bassoon, but in your latest recording, by sax 4:

 

F0 7D 00 06 00 03 00 00 07 0A 00 00 00 00 00 00 00 02 05 01 F7

 

Ok, the third byte specifies this as a "set part" sysex. The rest specifies which part on the MT-32 (6), volume (122), pan (64), reverb (on), and so on. Now the last two bytes, 05 01, specifies the patch for this part. Since the sysex only uses the first four bits of each byte, the hexadecimal number is 51. Hex 51 is 81 in the decimal system and patch 81 is sax 4.

 

Normally, this means the MIDI should play using sax 4 as the melody. However at tick 50 in the MIDI, that part is changed to patch 86, or bassoon, with a regular patch change. What I think happened here was that they originally intended to use sax 4 as the instrument playing the melody line, but then changed their minds later and simply added a patch change instead of changing the sysex. Then, on slow computers, it's possible that the imuse engine uses more time to decode the sysexes before passing the resulting messages to the MT-32. If the MIDI then is past tick 50 before the messages are sent, the wrong instrument will play.

 

Hope that clears it up.