I'm writing here a draft of SCI1 Sounder Resource Format description.
I will be more than happy to hear any comments, feedback, or pointing out mistakes.
Hopefully, later, I will write it in ScummVM wiki (just because I have writing permissions over there, and I think this should be documented. I'd be glad to have it other relevant Wikis as well).
The file starts with Sierra Sound magic number: 84h 00h. Those bytes aren't taken into account when calculating offsets, etc.
Then comes a header, which describes for each device (1) what channels it's using.
Each device starts with one byte, describing its type. This is SCICompanion's list:
Adlib, Sound Blaster ($00)
Amiga/Mac ($06)
General Midi ($07)
Unknown ($08)
Game Blaster ($09)
Unknown ($0b)
Roland MT-32, GM ($0c)
PC Speaker ($12)
Tandy 3v / IBM PS1 ($13)
(2)
I also encountered $16 (Eco Quest 1, at 185.snd).
If FFh is encountered, it means that there are no more devices, and the header ends immediately.
If F0h is encountered, it's called by ScummVM and SCICompanion "Digital track" (3); they both don't support it (according to the comments in the code). In that case, there are 6 bytes (first of them might be priority), then FFh.
Any other value means regular device, according to the devices type table.
For each device, after its type, comes the supported channels list.
Each supported channel starts with a byte that is either FFh, marking end of channels list (and end of device). Don't confuse end-of-channels FFh with end-of-devices FFh. If that byte is not FFh, its meaning is unknown.
The following byte has also unknown meaning.
Next 2 bytes are channel's data offset (from beginning of file [ignoring the magic id]).
Next 2 bytes are channel's data size.
That concludes the header.
The channel data referred to from the header is as following:
If the first byte is FEh, this is a digital channel, described later. Otherwise:
4 lower bits of that byte are channel number
4 higher bits of that byte are flags. According to SCICompanion's code:
// Flag 0x1: Channel offset start is 0 instead of 10 (?) (haven't encountered this yet)
// Flag 0x2: Prevent re-mapping (commonly set on 9)
// Flag 0x4: Start muted (?)
, and channel 9 is treated as if flag 2 is set even if it's not.
Next byte, 4 lower bits are 'poly', and 4 higher bits are 'priority'. 4
All the following bytes until end of channel data (according to its size in header; note that this size includes the 2 previous bytes) are midi messages.
If the channel is digital, it start with the following header:
first byte is prio
next 2 bytes are frequency
next 2 bytes are sample length
next 2 bytes are offset from end of header
next 2 bytes are end of sample
then, after 'offset' bytes, comes the PCM sample itself.
Note:
Theoretically, this mechanism could allow each device to have completely different channels; i.e., ADLIB might use some "channel 1" which is different than MT-32's "channel 1". However, in practice it seems to not be the case in few files I have examined. Furthermore, SCICompanion has an assertion that if I understand correctly makes sure that if channel X is mentioned by device Y, it will be the same channel X when mentioned by device Z.
Therefore, my claim that it's better to call it "device" rather than "track", and that it's similar to SCI0 mechanism.
Footnotes:
(1) SciCompanion and ScummVM code call it 'track'. I prefer to call it 'device' in order to use the same terminology used by SCI0 spec, and because I find it less confusing, as using the term 'track' suggests that it has something to do with 'MIDI track' (it doesn't), and it also suggests that it's a different concept than SCI0 'device' (it's not).
(2) I wander where is this list from? Decompilation? If so, why are there unknowns?
(3) I'm really curios where did this term comes from. And how come it's not supported, and no one seems to care?
(4) I have no idea what is their effect.
