Difference between revisions of "SCI/Specifications/Sound/Mapping instruments in FreeSCI"

From ScummVM :: Wiki
Jump to navigation Jump to search
(Merging of the SCI documentation)
 
m (consistency change)
 
Line 6: Line 6:
Unfortunately, almost every SCI0 game uses an individual instrument mapping scheme. This means that there are only two options to generate GM music from the original SCI sound resources: Either create a manual mapping for each game, or abuse existing data from the game for this purpose. Obviously, the latter way would be either impossible or much easier.
Unfortunately, almost every SCI0 game uses an individual instrument mapping scheme. This means that there are only two options to generate GM music from the original SCI sound resources: Either create a manual mapping for each game, or abuse existing data from the game for this purpose. Obviously, the latter way would be either impossible or much easier.


So, the solution would be to use an existing instrument mapping scheme. Those mapping schemes are stored in the patch resources, and, as such, easily accessible to an SCI engine. As those patch files are driver dependent (which, in turn, are hardware dependent), most of the patch data is unusable. The Adlib data, for example, will only work for an OPL-2 FM synthesizer chip or one of its successors, the MT-32 data (which consists of one massive sysex block) won't help anyone without an MT-32 or LAPC-1, and so on. So, to recycle this hardware-dependent data, two new possibilities remain: Either extract and interpret the patch data using a portable software synthesizer (such as timidity), or extract instrument names and map those to GM instruments. The first approach would, of course, yield the better results (at the cost of computation power); but the only software emulator for a specific sound system I've seen so far was an OPL-2 emulator. So the alternative, extracting a text ID of each instrument and using it to map this instrument to a GM instrument, looks much more promising.
So, the solution would be to use an existing instrument mapping scheme. Those mapping schemes are stored in the patch resources, and, as such, easily accessible to an SCI engine. As those patch files are driver dependent (which, in turn, are hardware dependent), most of the patch data is unusable. The AdLib data, for example, will only work for an OPL-2 FM synthesizer chip or one of its successors, the MT-32 data (which consists of one massive sysex block) won't help anyone without an MT-32 or LAPC-1, and so on. So, to recycle this hardware-dependent data, two new possibilities remain: Either extract and interpret the patch data using a portable software synthesizer (such as timidity), or extract instrument names and map those to GM instruments. The first approach would, of course, yield the better results (at the cost of computation power); but the only software emulator for a specific sound system I've seen so far was an OPL-2 emulator. So the alternative, extracting a text ID of each instrument and using it to map this instrument to a GM instrument, looks much more promising.


Now, most SCI0 games come with a <tt>patch.002</tt> resource, which is used by the IBM Music Feature card and Yamaha FM-01 sound synthesizers (both of which appear to use frequency modulation). This is the only patch file that includes text descriptions of most of its instruments. Note this, not all instruments have name representation. This means that some of them can't be mapped and have to be silenced; but those instruments are either used for sound effects only or not used at all, so this isn't critical.
Now, most SCI0 games come with a <tt>patch.002</tt> resource, which is used by the IBM Music Feature card and Yamaha FM-01 sound synthesizers (both of which appear to use frequency modulation). This is the only patch file that includes text descriptions of most of its instruments. Note this, not all instruments have name representation. This means that some of them can't be mapped and have to be silenced; but those instruments are either used for sound effects only or not used at all, so this isn't critical.

Latest revision as of 00:28, 25 January 2010

Mapping instruments in FreeSCI

The Patch.002 resource

As Ravi describes in his description of the patch resources (which have not been included here), one of the major problems with SCI sound support is the lack of General Midi (GM) support in the earlier games. Since those were written before GM was conceived, this can hardly be considered to be Sierra's fault; but this fact doesn't help when it comes to supporting the games in a portable manner.

Unfortunately, almost every SCI0 game uses an individual instrument mapping scheme. This means that there are only two options to generate GM music from the original SCI sound resources: Either create a manual mapping for each game, or abuse existing data from the game for this purpose. Obviously, the latter way would be either impossible or much easier.

So, the solution would be to use an existing instrument mapping scheme. Those mapping schemes are stored in the patch resources, and, as such, easily accessible to an SCI engine. As those patch files are driver dependent (which, in turn, are hardware dependent), most of the patch data is unusable. The AdLib data, for example, will only work for an OPL-2 FM synthesizer chip or one of its successors, the MT-32 data (which consists of one massive sysex block) won't help anyone without an MT-32 or LAPC-1, and so on. So, to recycle this hardware-dependent data, two new possibilities remain: Either extract and interpret the patch data using a portable software synthesizer (such as timidity), or extract instrument names and map those to GM instruments. The first approach would, of course, yield the better results (at the cost of computation power); but the only software emulator for a specific sound system I've seen so far was an OPL-2 emulator. So the alternative, extracting a text ID of each instrument and using it to map this instrument to a GM instrument, looks much more promising.

Now, most SCI0 games come with a patch.002 resource, which is used by the IBM Music Feature card and Yamaha FM-01 sound synthesizers (both of which appear to use frequency modulation). This is the only patch file that includes text descriptions of most of its instruments. Note this, not all instruments have name representation. This means that some of them can't be mapped and have to be silenced; but those instruments are either used for sound effects only or not used at all, so this isn't critical.

Using those 7-letter instrument names, it is now possible to build a small database of instruments, which, subsequently, can be mapped to GM instruments.

The file structure is relatively simple (for this purpose): Every patch.002 consists of either one or two instrument banks carrying 48 instruments each. Every instrument has a fixed block size of 0x40 bytes; each block starts with the 7-letter description of the instrument or seven blanks if none is available.

If two banks are present, the second bank is separated from the first one by a two-byte sequence (0xab, 0xcd). Keeping this in mind, it is trivial to extract the instrument names of the 48 or 96 instruments.


Percussion instruments

Percussion instruments are treated specially in the MIDI standard. MIDI channel 10 (or 9, if you count from 0 to 15 like most people do) is reserved for percussions and some special effects; each key for this channel represents either nothing or one fixed percussion instrument.

At first glance, this might lead to an additional problem of mapping those percussion instruments. Fortunately, the General Midi standard extends on the MT-32 percussion mappings, which are used in SCI0, so that channel 9 can be left completely untouched in the process of instrument mapping.