Messages

16

SCI Development Tools / "Sounder" tool - alpha version is ready

« on: August 01, 2022, 07:34:13 AM »

Sounder tool is ready for alpha testing...



It should be able to do (more or less) almost anything you can think of with sound formats of SCI1+, SCI0 and SC0-Early.
Few features are planned to be added in the near future (most interesting one IMO - ability to add digital sample from any file, like MP3).

It even has a Graphical User Interface (I still prefer the command line, but I know that many people disklike such things...)

The installer can be downloaded from https://github.com/adventurebrew/re-quest/releases/download/sounder_0.1/Sounder.Installer.exe
In order to access the command line just run 'sounder.exe --help'.

If anyone prefers without installer: https://github.com/adventurebrew/re-quest/blob/master/tools/sci/sounder.py
(the beginning of the file has notes how to set up a Conda environment with anything needed to run it)

Important notes:

• This is really an Alpha version, it probably has bugs
• I like to code, but hate to test, so, I haven't found those bugs
• The good news - please report bugs that you found, and I will try to fix 'em
• You can report here, or at https://github.com/adventurebrew/re-quest/issues (please prefix the issue with 'sounder')
• If anyone wants to run in Linux, and needs help - just say
• Feature requests, or any other comments, are also welcomed

EDIT
====
I just discovered that with the installer the command line isn't working. I have an idea how to fix it. Meanwhile, in order to run the command line, use the Python file directly from GitHub, and not the installer.

EDIT2
====
CLI is working now, with a different shortcut pointing to a .bat file, with the exact path.

17

SCI Development Tools / Re: SCI1 Sound Resource Format

« 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

18

SCI Development Tools / Re: SCI0 Sound Resource Format - few notes (Ravi's spec, SCI Resource Viewer)

« on: August 01, 2022, 04:22:33 AM »

According to SQ3 sound resources viewed in SCI Viewer, Bit 2 is indeed PC Speaker.

SQ3 is "SCI0", not "SCI0 - Early".

I'm referring to this section:

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.

19

SCI Development Tools / SCI0 sound: "The MT-32 always plays channel 9, the MIDI percussion channel" ??

« on: July 31, 2022, 06:21:21 AM »

The SCI0 sound spec says:

The MT-32 always plays channel 9, the MIDI percussion channel, regardless of whether or not the channel is flagged for the device. Other MIDI devices may also do this.

Are we sure that it's true?

This can be demonstrated by SQ3, sound.073
The MT-32 doesn't report using channel 9, but this channel exists, and is used by ADLIB and FB01.

SCICompanion and SCI Resource Viewer report that MT-32 is not using channel 9, as the header supposedly says - but unlike that comment I quoted from spec.

20

SCI Development Tools / SCI0 Sound Resource Format - few notes (Ravi's spec, SCI Resource Viewer)

« on: July 31, 2022, 03:13:48 AM »

1.
Ravi's SCI0 Sound Resource Format seems to have a small typo:

The fact that F8h waits F0h ticks makes me think that E9h is the largest technically allowable delta time.

Should be:

The fact that F8h waits F0h ticks makes me think that EFh is the largest technically allowable delta time.

The meaning of that value is F0h - 1, which is EFh, but can be easily mistaken for E9h.

Note: when I read this sentence (a few times...) it made perfectly sense for me. I only discovered it when some file failed with the assertion that I wrote that the value should be <= E9h.

2.
Ravi's spec states for SCI0 early - Header (kq4, 1988 xmas card):

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.

What does Bit 2 mean?
I think it's PC Speaker, because:

• It should be there somewhere...
• In a few files that I have checked, there was exactly one channel with Bit 2, which looks typical for the PC Speaker

3.
Regarding "SCI0 Early" - it seems that both SCI Resource Viewer and SCICompanion have problems with it.
When loading sound.001 from Kings Quest 4 1.000.111 (attached), SCI Resource Viewer thinks that it supports the following devices:
MT32, FB01, Adlib, Casio, Tandy1000, PC Speaker and "7".
That list seems to be too long, according to the possible devices in the SCI0-early spec.

Furthermore, it reports that PC Speaker uses channels 1, 9, 11, 13, 15 and 16; which of course, doesn't make sense as well.

However, when this file is loaded with Sounder (https://github.com/adventurebrew/re-quest/blob/master/tools/sci/sounder.py), it reports only PC_JR, SPEAKER, MT_32 (and CONTROL CHANNEL); and the PC SPEAKER is using only channel 1.

Note:
So far I had the impression that SCI Resource Viewer is a perfect tool. It's interesting to find a bug in it, even if minor

21

SCI Development Tools / Re: SCI1 Sound Resource Format

« 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.

22

SCI Development Tools / 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 ⁽¹⁾ 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)
⁽²⁾
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" ⁽³⁾; 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'. ⁴
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.

23

SCI Development Tools / Re: Anyone knows of a SCI1+ game with sound channel?

« on: July 30, 2022, 04:02:54 PM »

That has occurred to me, too, but are there any SCI1.0 games with a PCM sound embedded one of its sound resources?

Well, at least Eco Quest 1 has it.
It's interesting to check whether there are others as well.

24

SCI Development Tools / Re: Anyone knows of a SCI1+ game with sound channel?

« on: July 30, 2022, 04:02:19 PM »

This brings to mind that one tool we're still missing is something that amends a PCM audio sample to a SCI1.0 sound resource. NRS made one for SCI0 sounds, but that obviously doesn't help with SCI1.0.

Well, soon we'll have such a tool

25

SCI Development Tools / Re: Anyone knows of a SCI1+ game with sound channel?

« on: July 30, 2022, 04:01:43 PM »

You don't mean a PCM embedded in a SOUND/SND resource do you? AKA the SQ3 "Where am I?" That ended by the time that AUD became a separate resource from the SND. Digital sounds in SCI games were done a number of different ways from AUD to WAV to CDA to Audio36, etc.

I mean exactly that.
SQ3 is SCI0, I'm looking for SCI1.
It has support for it (apparently, in early versions), as demonstrated by Kawa's file aforementioned.

26

SCI Development Tools / Re: Anyone knows of a SCI1+ game with sound channel?

« on: July 30, 2022, 03:59:44 PM »

I'm not sure what the difference between a digital track and channel would be.

All I know is that later games (SCI11 and higher) use Audio resources to do non-speech digital sound effects, that may match IDs with Sound resources. That may be why you couldn't find anything in SQ6's sounds, all its digital effects would be in another resource type entirely.

In earlier games, these digital sounds are part of of the audio resource itself, like in the provided EcoQuest (disk ver.) example (*chomp* OUCH!). That's all I know.

Yes, indeed, that's exactly the file I was looking for, thanks.
Regarding digital track vs digital channel - I will explain in the sci1 snd spec I promised to write...

27

SCI Development Tools / Anyone knows of a SCI1+ game with sound channel?

« on: July 29, 2022, 05:45:30 AM »

Hi.
I'm working on my 'sounder' tool, and want to check my support for SCI1+ .snd digital channel.
(note, I'm talking about digital *channel*, not digital *track*, see https://github.com/icefallgames/SCICompanion/blob/f1a603b48b1aa7abf94f78574a8f69a653e2ca62/SCICompanionLib/Src/Resources/Sound.cpp#L1553)

I've searched all of SQ6, and couldn't find one (or maybe I'm having some mistake in my search...)

If anyone can refer me to such sound file in some game, it'd be great.

28

SCI Development Tools / Re: Convert SCI0 vocab to SCI1 vocab?

« on: July 25, 2022, 12:14:34 PM »

Well, thanks to Phil's code I managed to get around SCI1+ format. The header is quite different. The payload is also slightly different.
I will open a different thread to discuss that.

Anyway, I have a (basic) tool ready:
https://github.com/adventurebrew/re-quest/blob/master/tools/sci/sounder.py

It currently can:

• load SCI0 snd file (not early SCI0, but it's working for my GOG's KQ4 copy)
• load SCI1+ snd file
• load arbitrary MIDI file
• show file's info (for Sierra's formats)
• play the file
• save the file as MIDI
• save the file as SCI1+ snd file
• save the file as MIDI, and later read it and save as SND, and keep cues and loop points (they are saved as MIDI meta-message)

Missing features and limitations (will be hopefully addressed in the future):

• Digital samples are ignored
• Saving as .SCI0 file is missing
• SCI0: Playing only specific device (currently it plays all channels)
• SCI1: Selecting device to play and midi file save (currently it uses only GM or MT32 if GM doesn't exist
• Support early SCI0 (if anyone can lend me such a game, it will be easier )
• SCI1 flags, 'poly' and 'prio' are ignored, both on save and load
• Better support of saved file name

It's supposed to handle cue and loop points, but I haven't thoroughly verified it.
Generally speaking, it's not verified well enough, and probably has some bugs

As for number of voices, for adlib - there's no place to save it SCI1+ format (as far as I understand) - so, it's a problem...
It's interesting to check with ScummVM (I might do it...), or original interpreter (even better but I couldn't find it in OmerMor's files; maybe it's in the adlib driver itself) how is it handled.
Maybe the interpreter selects these values by itself?

As usual, run with '--help' to get detailed information, or ask here if something isn't clear.

And of course, I'll be happy to get bug reports or feature requests.

EDIT
====
For more details, see https://sciprogramming.com/community/index.php?topic=2075.0

29

SCI Development Tools / Re: Convert SCI0 vocab to SCI1 vocab?

« on: July 21, 2022, 11:37:51 AM »

I'm glad to hear that it worked!

Regarding the sound issue, I might give a hand here, to automate the manual work needed, but I don't really understand the problem definition.
I have done some work on ScummVM's sound code, but I never touched the sound format itself.

Can you refer me to specs, if any exists, of the old and new formats? Examples of game or two that uses each format?
And what happened to loop points in the new format?
And I didn't understand the comment regarding # of voices channels.

30

SCI Development Tools / Re: Convert SCI0 vocab to SCI1 vocab?

« on: July 21, 2022, 09:36:17 AM »

OK, I was wrong - those 2 'strange characters' were actually perfectly fine, it was a bug in my script.

Now everything is fixed, and should be working even with original Sierra interpreters (I hope...)
Please pull and check again.

Update how is it going.