561
edits
Difference between revisions of "SCI/Specifications/Sound/Mapping instruments in FreeSCI"
SCI/Specifications/Sound/Mapping instruments in FreeSCI (view source)
Revision as of 00:28, 25 January 2010
, 00:28, 25 January 2010consistency change
(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 | 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. | ||