Author Topic: SCI1 Sound Resource Format  (Read 193 times)

0 Members and 1 Guest are viewing this topic.

Offline ZvikaZ

SCI1 Sound Resource Format
« on: July 30, 2022, 04:51:32 PM »
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:
Code: [Select]
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:
Code: [Select]
                        // 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.



Offline Collector

Re: SCI1 Sound Resource Format
« Reply #1 on: July 30, 2022, 04:57:26 PM »
How about adding it to the SCI Wiki? http://sciwiki.sierrahelp.com/index.php?title=Main_Page I can easily add an account for you.

ETA: This is our community's Wiki. Any regular SCI Community poster can request an account for editing privileges.
« Last Edit: July 30, 2022, 05:04:37 PM by Collector »
KQII Remake Pic

Offline ZvikaZ

Re: SCI1 Sound Resource Format
« Reply #2 on: July 31, 2022, 02:52:54 AM »
How about adding it to the SCI Wiki? http://sciwiki.sierrahelp.com/index.php?title=Main_Page I can easily add an account for you.

ETA: This is our community's Wiki. Any regular SCI Community poster can request an account for editing privileges.
Good idea, thanks.

Offline MusicallyInspired

Re: SCI1 Sound Resource Format
« Reply #3 on: July 31, 2022, 04:38:35 PM »
Technically, in SCI1+ sound resources there are tracks, channels, and devices. All three. Standard MID files support multiple tracks as well that can point to the same channel. But standard MID files don't support devices. I think that's what it's referring to. Tracks =/= channels and tracks =/= devices. They're all unique. SCI0 sounds don't support multiple tracks per channel so its tracks really are just channels.
« Last Edit: July 31, 2022, 04:50:41 PM by MusicallyInspired »
Brass Lantern Prop Competition

Offline ZvikaZ

Re: SCI1 Sound Resource Format
« Reply #4 on: August 01, 2022, 06:46:44 AM »
Technically, in SCI1+ sound resources there are tracks, channels, and devices. All three. Standard MID files support multiple tracks as well that can point to the same channel. But standard MID files don't support devices. I think that's what it's referring to. Tracks =/= channels and tracks =/= devices. They're all unique. SCI0 sounds don't support multiple tracks per channel so its tracks really are just channels.

How do you know that "in SCI1+ sound resources there are tracks, channels, and devices"?
I'm asking, because the evidence that I have, made me think that 'tracks == devices', for SCI1+.
But I'm ready to change my mind, if you'll show me that I'm wrong :)

Offline Kawa

Re: SCI1 Sound Resource Format
« Reply #5 on: August 01, 2022, 10:06:19 AM »
How do you know that "in SCI1+ sound resources there are tracks, channels, and devices"?
I'm asking, because the evidence that I have, made me think that 'tracks == devices', for SCI1+.
But I'm ready to change my mind, if you'll show me that I'm wrong :)
There's a many-to-many mapping of tracks to devices, with potentially impressive overlap. Think of a PC Speaker track also being used for the Tandy 3-Voice.

Compare and contrast that with Anvil Studio's many-to-one, where you can assign each track to only one device, and one channel.

On top of all that, track 4 does not necessarily use channel 4 -- tracks and channels are a one-to-one map, unless it's a Type 0 file where it's one big track driving all channels. But those are rare, so don't worry about 'em.


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.164 seconds with 23 queries.