Difference between revisions of "SCI/Specifications/Sound/SCI0 Resource Format"

Jump to navigation Jump to search
m
→‎Sound Devices: close <tt> tag properly
(added information about kq4/1988 xmas sound header)
m (→‎Sound Devices: close <tt> tag properly)
 
(5 intermediate revisions by 3 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 bet­ter 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].
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 bet­ter 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 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.
: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 42: Line 42:
|01h
|01h
|----
|----
|Adlib
|AdLib
|adl
|adl
|003
|003
Line 124: 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|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.
Line 139: Line 139:
The first byte is a digital sample flag. Afterwards 1 byte follows for each channel (totals in 17 bytes).
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 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.
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.
Currently its not known if the digital sample flag behaves the same as in the SCI0 header.
Line 306: 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 329: 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 336: 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, 11#11 = looping off
*[12][13] (int16) 0 = looping on, <>0 = looping off




Line 344: Line 345:


*[00]..[07] Sample name
*[00]..[07] Sample name
*[08][09] (int16) 0 = unsigned samples, 11#11 = signed samples
*[08][09] (int16) 0 = unsigned samples, <>0 = signed samples
*[0a][0b] (int16) Start offset of phase 1
*[0a][0b] (uint16) Start offset of phase 1
*[0c][0d] (int16) End offset (inclusive) of phase 1
*[0c][0d] (uint16) End offset (inclusive) of phase 1
*[0e][0f] (int16) Start offset of phase 2
*[0e][0f] (uint16) Start offset of phase 2
*[10][11] (int16) End offset (inclusive) of phase 2
*[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 366: 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 376: Line 376:
*[100]..[17f] patchVolumeAdjust
*[100]..[17f] patchVolumeAdjust
*[180]..[1ff] percMap
*[180]..[1ff] percMap
*[200] percVolumeAdjust (not used)
*[200] percVolumeAdjust
*[201]..[280] velocityMapIndex
*[201]..[280] velocityMapIndex
*[281]..[300] velocityMap 0
*[281]..[300] velocityMap 0
2,051

edits

Navigation menu