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

Jump to navigation Jump to search
m
→‎Sound Devices: close <tt> tag properly
m (Improved table formatting, linkify section)
m (→‎Sound Devices: close <tt> tag properly)
 
(6 intermediate revisions by 4 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.


==File Format==
==File Format==
Sound files follow the same format as all extracted SCI0 resources. 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.
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.


=== Header ===
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 header provides the sound driver with 2 pieces of information about each channel. The first is a byte which 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.
 
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 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 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, 11#11 = looping off
*[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, 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 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 (not used)
*[200] percVolumeAdjust
*[201]..[280] velocityMapIndex
*[201]..[280] velocityMapIndex
*[281]..[300] velocityMap 0
*[281]..[300] velocityMap 0
2,051

edits

Navigation menu