2,051
edits
Difference between revisions of "SCI/Specifications/Sound/SCI0 Resource Format"
Jump to navigation
Jump to search
m
SCI/Specifications/Sound/SCI0 Resource Format (view source)
Revision as of 18:31, 2 May 2010
, 18:31, 2 May 2010→Sound Devices: close <tt> tag properly
(Merging of the SCI documentation) |
m (→Sound Devices: close <tt> tag properly) |
||
| (9 intermediate revisions by 5 users not shown) | |||
| Line 3: | Line 3: | ||
==Preface== | ==Preface== | ||
Sierra’s SCI0 sound resources contain the music and sound effects played during the game. With the introduction of SCI, the company took advantage of new sound hardware which allowed for far better music than the traditional PC speaker could ever create. Sierra chose two devices to specifically target: the MT-32, and the | Sierra’s SCI0 sound resources contain the music and sound effects played during the game. With the introduction of SCI, the company took advantage of new sound hardware which allowed for far better music than the traditional PC speaker could ever create. Sierra chose two devices to specifically target: the MT-32, and the AdLib. The MT-32 is a MIDI synth while the AdLib is a less expensive card based around the OPL2, a non-MIDI chip. Anyone interested in Sierra music and its history can find information at the [http://www.queststudios.com Sierra Soundtrack Series]. | ||
Music is stored as a series of MIDI events, and the sound resource is basically just a MIDI file. The MIDI standard and device implementations are not covered here in detail, but specifications should be readily available elsewhere. | Music is stored as a series of MIDI events, and the sound resource is basically just a MIDI file. The MIDI standard and device implementations are not covered here in detail, but specifications should be readily available elsewhere. | ||
| Line 20: | Line 20: | ||
;Non-MIDI Synths | ;Non-MIDI Synths | ||
:Generally not as good as MIDI synths, but also less expensive. The OPLx family of chips are still very common among home PC users thanks to the | :Generally not as good as MIDI synths, but also less expensive. The OPLx family of chips are still very common among home PC users thanks to the AdLib and SoundBlaster cards. Synths are polyphonic with definable instruments through patch files, but drivers must be written to interpret MIDI events and turn them into commands the hardware will recognize. Support for most sound controls gets lost in the process. Furthermore, drivers must map logical, polyphonic MIDI channels to physical, monophonic hardware channels. A control (<tt>4Bh</tt>) was introduced for this purpose and will be discussed later. | ||
;Beepers | ;Beepers | ||
| Line 28: | Line 28: | ||
:Wave devices play digital sound data. They could be used in conjunction with one of the above devices to add special sound effects to a game. The Amiga port of SCI uses a wave device to play music.<br>With such a diverse group of devices to support, Sierra put a lot of the work on the shoulders of the drivers. Functions for loading patch files, handling events, pausing, etc. are all in the drivers. The interpreter calls them as needed but does not concern itself at all with how they get implemented.<br>Listed here are devices supported by the SCI0 interpreter with a little information about each. There could very well be other hardware not listed here, so please send in any missing information. | :Wave devices play digital sound data. They could be used in conjunction with one of the above devices to add special sound effects to a game. The Amiga port of SCI uses a wave device to play music.<br>With such a diverse group of devices to support, Sierra put a lot of the work on the shoulders of the drivers. Functions for loading patch files, handling events, pausing, etc. are all in the drivers. The interpreter calls them as needed but does not concern itself at all with how they get implemented.<br>Listed here are devices supported by the SCI0 interpreter with a little information about each. There could very well be other hardware not listed here, so please send in any missing information. | ||
{| border="1" | {| border="1" cellspacing="0" cellpadding="5" | ||
|+ | |||
|'''Device Name''' | |'''Device Name''' | ||
|'''Driver''' | |'''Driver''' | ||
| Line 41: | Line 42: | ||
|01h | |01h | ||
|---- | |---- | ||
| | |AdLib | ||
|adl | |adl | ||
|003 | |003 | ||
| Line 123: | Line 124: | ||
;<nowiki>+</nowiki> | ;<nowiki>+</nowiki> | ||
:The imf driver almost certainly uses <tt>02h<tt> for the play flag, but I haven’t confirmed this. | :The imf driver almost certainly uses <tt>02h</tt> for the play flag, but I haven’t confirmed this. | ||
The driver column holds the file name of each driver without the <tt>.drv</tt> extension. The patch column specifies which patch resource each driver requests. The poly column is the maximum number of voices which can be played at once according to the driver. The flag column gives each device’s play flag. Play flags, explained in the header section, determine which channels a device will play. | The driver column holds the file name of each driver without the <tt>.drv</tt> extension. The patch column specifies which patch resource each driver requests. The poly column is the maximum number of voices which can be played at once according to the driver. The flag column gives each device’s play flag. Play flags, explained in the [[#Header|header section]], determine which channels a device will play. | ||
==File Format== | ==File Format== | ||
There are 2 formats used in SCI0 games. One is an early format used in a version of kq4 and 1988 xmas card. The other one is used in all other SCI0 titles. | |||
The first two bytes of the file contain a magic number identifying the resource type. The rest of the file contains a dump of the uncompressed data. The identifier is the resource type (<tt>04h</tt> for sound) OR-ed with <tt>80h</tt> and stored as a word. The result will be <tt>84h 00h</tt> in extracted sound files. | |||
The sound resource data itself is a header with channel initialization followed by a series of MIDI events. | The sound resource data itself is a header with channel initialization followed by a series of MIDI events. | ||
The header provides the sound driver with 2 pieces of information about each channel. | |||
==Header (kq4, 1988 xmas card)== | |||
The first byte is a digital sample flag. Afterwards 1 byte follows for each channel (totals in 17 bytes). | |||
The upper 4 bits of that byte specify how many voices each logical MIDI channel will be playing. The lower 4 bits specify which drivers should react on that channel. Bit 0 set means AdLib shall react. Bit 1 set means PCjr shall react. MT32 will react on all channels. Bit 3 signals the control channel. | |||
The original sierra driver needs bit 3 set and bit 0 unset to find the control channel. Also the AdLib driver needs bit 3 to be unset, otherwise the driver will ignore the channel even if bit 0 is set. | |||
Currently its not known if the digital sample flag behaves the same as in the SCI0 header. | |||
==Header (all other SCI0 titles)== | |||
The first byte is a digital sample flag. Afterwards 2 bytes follow for each channel (totals in 33 bytes). | |||
The first of those bytes specifies how many voices each logical MIDI channel will be playing. For MIDI synths, this information is not really necessary and is probably ignored. The same goes for beepers. This byte is only useful for non-MIDI synths which must know how many hardware channels each logical MIDI channel will need. This value is only an initial setting. Sound files can request changes to the mapping later with control changes. Requesting more hardware channels than are actually available can cause errors on some drivers. | |||
The | |||
The second byte describes how the user's sound hardware should treat the channel. It is the combination of bit flags which may be OR-ed together. If the appropriate bit is set for the currently selected sound device, the channel will be played. If it is not, the channel will be silent. The driver decides which bit it will use as the play flag, and the table under Sound Devices lists the flag used by each driver. Drivers ignore the first byte (used to request hardware channels) on MIDI channels they don't play. | The second byte describes how the user's sound hardware should treat the channel. It is the combination of bit flags which may be OR-ed together. If the appropriate bit is set for the currently selected sound device, the channel will be played. If it is not, the channel will be silent. The driver decides which bit it will use as the play flag, and the table under Sound Devices lists the flag used by each driver. Drivers ignore the first byte (used to request hardware channels) on MIDI channels they don't play. | ||
| Line 201: | Line 216: | ||
;Cx p | ;Cx p | ||
:Program change: Set program (patch / instrument / ect.) to p for channel x. This is a simple instrument change.< | :Program change: Set program (patch / instrument / ect.) to p for channel x. This is a simple instrument change.<br>Channel 15, however, includes two special cases of this status. The first relates to communication with the game interpreter. If p is less than 127 then the signal property for the game interpreter's Sound object gets set to p, triggering a non-cumulative cue.<br>If p is equal to 127, then the current position within the sound resource is remembered as the loop point. Normally the driver loops to the beginning of the sound when the sequence ends. If an explicit loop point is set, the sound will be replayed from the marked point instead.<br>The actual time of the loop point is better explained with a short diagram:<br><br><tt>0x10 0x91 0x20 0x20 play a note on channel 1<br>0x05 0x91 0x20 0x00 stop the previous note<br>0x00 0x92 0x30 0x10 play a note on channel 2<br> [restart here]<br>0x00 0xCF 0x7F set loop point<br>0x00 0xC8 0x05 change to program 5 on channel 8<br>0x00 0xCF 0x13 set signal to 19<br>0x20 0xFC end of file, loop to marked location</tt><br><br>In both situations (p < 127 and p = 127), no actual program change takes place. Channel 15 is used for control, not playing music. | ||
;Dx p | ;Dx p | ||
| Line 217: | Line 232: | ||
;FC | ;FC | ||
:Stop Sequence: This is a system real-time message which tells the sound driver to stop the current sound. The sound object's signal property gets set to <tt>FFFFh</tt> and the position moves to the loop point, which defaults to the beginning. Drivers allow this message to occur without a delta time, but I haven't seen any examples. | :Stop Sequence: This is a system real-time message which tells the sound driver to stop the current sound. The sound object's signal property gets set to <tt>FFFFh</tt> and the position moves to the loop point, which defaults to the beginning. Drivers allow this message to occur without a delta time, but I haven't seen any examples. | ||
==Digital samples== | ==Digital samples== | ||
| Line 292: | Line 306: | ||
==Amiga Sound (SCI1)== | ==Amiga Sound (SCI1)/Macintosh Sound (SCI1/1.1)== | ||
The SCI1 Amiga sound driver adds several features: multiple samples per instrument, variable samplerates and pitch bend support. | The SCI1 Amiga sound driver adds several features: multiple samples per instrument, variable samplerates and pitch bend support. SCI1/1.1 Macintosh games use the same format in the 7.pat file. | ||
The sound bank header contains pointers to the 128 instruments (NULL indicates instrument not used): | The sound bank header contains pointers to the 128 instruments (NULL indicates instrument not used): | ||
| Line 315: | Line 329: | ||
*[02][03] (int16) End note number (inclusive) [0-127] | *[02][03] (int16) End note number (inclusive) [0-127] | ||
*[04]..[07] (uint32) pointer to sample data | *[04]..[07] (uint32) pointer to sample data | ||
*[08][09] (int16) Transpose value [0a] | *[08][09] (int16) Transpose value | ||
*[0a] Attack speed [0-31] | |||
*[0b] Attack target velocity [0-64] | *[0b] Attack target velocity [0-64] | ||
*[0c] Decay speed [0-31] | *[0c] Decay speed [0-31] | ||
| Line 322: | Line 337: | ||
*[0f] Unknown (always 0) | *[0f] Unknown (always 0) | ||
*[10][11] (int16) Fixed note number for this instrument, or -1 | *[10][11] (int16) Fixed note number for this instrument, or -1 | ||
*[12][13] (int16) 0 = looping on, | *[12][13] (int16) 0 = looping on, <>0 = looping off | ||
| Line 330: | Line 345: | ||
*[00]..[07] Sample name | *[00]..[07] Sample name | ||
*[08][09] (int16) 0 = unsigned samples, | *[08][09] (int16) 0 = unsigned samples, <>0 = signed samples | ||
*[0a][0b] ( | *[0a][0b] (uint16) Start offset of phase 1 | ||
*[0c][0d] ( | *[0c][0d] (uint16) End offset (inclusive) of phase 1 | ||
*[0e][0f] ( | *[0e][0f] (uint16) Start offset of phase 2 | ||
*[10][11] ( | *[10][11] (uint16) End offset (inclusive) of phase 2 | ||
*[12][13] (int16) Native MIDI note for this sample | *[12][13] (int16) Native MIDI note for this sample | ||
*[14][17] (uint32) Pointer to period table | *[14][17] (uint32) Pointer to period table | ||
| Line 352: | Line 367: | ||
MIDI notes are not used directly when doing table lookups. Every sample has a native MIDI note that needs to be taken as a base. If the sample is played back at the native MIDI note, the period length is obtained from the 8th semitone in the table (cent 800) at the 11th octave, i.e. the value at offset <tt>0x0080</tt> in the table, divided by two 10 times. This period length will also correspond to the samplerate at the end of the table. | MIDI notes are not used directly when doing table lookups. Every sample has a native MIDI note that needs to be taken as a base. If the sample is played back at the native MIDI note, the period length is obtained from the 8th semitone in the table (cent 800) at the 11th octave, i.e. the value at offset <tt>0x0080</tt> in the table, divided by two 10 times. This period length will also correspond to the samplerate at the end of the table. | ||
==General MIDI and MT-32 (SCI1)== | ==General MIDI and MT-32 (SCI1)== | ||
| Line 362: | Line 376: | ||
*[100]..[17f] patchVolumeAdjust | *[100]..[17f] patchVolumeAdjust | ||
*[180]..[1ff] percMap | *[180]..[1ff] percMap | ||
*[200] percVolumeAdjust | *[200] percVolumeAdjust | ||
*[201]..[280] velocityMapIndex | *[201]..[280] velocityMapIndex | ||
*[281]..[300] velocityMap 0 | *[281]..[300] velocityMap 0 | ||
| Line 371: | Line 385: | ||
*[483].. #i bytes of MIDI data | *[483].. #i bytes of MIDI data | ||
* patchMap[ | * <tt>patchMap[i]</tt>: Native patch number for patch <tt>i</tt> , or <tt>-1</tt> for unused entries. | ||
* patchKeyShift[ | * <tt>patchKeyShift[i]</tt>: Key shift value for patch <tt>i</tt>. This value should be added to every non-rhythm key that is played. If the key goes out of bounds <tt>[0,127]</tt>, it should be clipped by a multiple of 12 semitones. | ||
* patchVolumeAdjust[ | * <tt>patchVolumeAdjust[i]</tt>: Volume adjust value for patch <tt>i</tt>. This value should be added to the volume (when setting controller <tt>07h</tt>) ''before'' scaling it by the master volume. | ||
* percMap[ | * <tt>percMap[i]</tt>: Native key for key <tt>i</tt> of the percussion channel, or <tt>-1</tt> for unused entries. | ||
* percVolumeAdjust: Volume adjust value for percussion. | * <tt>percVolumeAdjust</tt>: Volume adjust value for percussion. | ||
* velocityMapIndex[ | * <tt>velocityMapIndex[i]</tt>: Specifies which <tt>velocityMap</tt> to use for patch <tt>i</tt>. | ||
* velocityMap[ | * <tt>velocityMap[i]</tt>: Native velocity for velocity <tt>i</tt>. | ||
* MIDI data: MIDI data to initialize the device. Note that this data can contain sysex commands, after which an appropriate delay should be executed. | * <tt>MIDI data</tt>: MIDI data to initialize the device. Note that this data can contain sysex commands, after which an appropriate delay should be executed. | ||