Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ZvikaZ

Pages: 1 [2] 3 4 ... 14
16
SCI Development Tools / Re: "Sounder" tool - alpha version is ready
« on: August 04, 2022, 06:41:52 AM »
Great! Now I've just found that the sounds converted from SCI0 to SCI1 are not converted right, leading to notes playing in the wrong place!

To see what I'm talking about, I've put here a little program that tests SCI1 sounds. The menu has an option to play a sound, and you can input the resource number you want to play. I've included three sounds as an example. Please excuse the wrong instruments; that's just because the patch files are from the INN demo (at which point General MIDI was the standard).

I fixed few things.
Please take the updated release from the same link (https://github.com/adventurebrew/re-quest/releases/latest/download/Sounder.Installer.exe)

It still sounds a little bit weird in your program - maybe it's due to the patch files?

In sv.exe it sounds well. I checked in SCICompanion - it was very confusing - everything seemed messed up, and it didn't play. But then I realized that it recognized the game as SCI0 (and the sounds were saved as SCI1). When I forced it to change 'Sound format' to SCI1, it played fine.

So, maybe something is wrong with the test program? It seems to be based on SCI0 templates instead of SCI1.
Then I took sound.100 from SQ6 and tried to play it with sci1_sound_test, and it also didn't play well.

Lastly, just for fun, I tried taking sound files from SQ3 and play this sci1_sound_test, and it just got stuck.


17
SCI Development Tools / Re: "Sounder" tool - alpha version is ready
« on: August 03, 2022, 10:52:47 AM »
Okay, so I've tested it with LSL2 (1.002). The music tracks (those in the 100 range) all converted from SCI0 to SCI1 without error. However, some of the sounds would not convert.
For example: sound.005...
Code: [Select]
C:\SCICompanion\Sierra\LSL2\original_sounds\sound.005 SCI0
Device FB_01 uses [{'ch': 1, 'voices': 8}]
Device ADLIB uses [{'ch': 1, 'voices': 8}]
Device PC_JR uses [{'ch': 1, 'voices': 8}]
Device SPEAKER uses [{'ch': 1, 'voices': 8}]
Device MT_32 uses [{'ch': 2, 'voices': 0}]
Midi length: 1.9 seconds
SAVE SCI1: Ignoring device FB_01, doesn't have a SCI1 counterpart
SAVE SCI1+: Adding GM device, as duplication of MT-32
Traceback (most recent call last):
  File "sounder.py", line 873, in <module>
  File "gooey\python_bindings\gooey_decorator.py", line 134, in <lambda>
  File "sounder.py", line 860, in main
  File "sounder.py", line 617, in save_sci1
KeyError: 1
[12824] Failed to execute script 'sounder' due to unhandled exception!

Sounds 7 and 12 have the same issue.

And I tested the 1988 Christmas Card, for converting from early SCI0 to newer SCI0...

Code: [Select]
C:\SCICompanion\Sierra\demos\88xmas\original_sounds\sound.001 SCI0_EARLY
Device PC_JR uses [{'ch': 1, 'voices': 0}, {'ch': 11, 'voices': 0}, {'ch': 12, 'voices': 0}]
Device SPEAKER uses [{'ch': 1, 'voices': 0}]
Device MT_32 uses [{'ch': 1, 'voices': 0}, {'ch': 2, 'voices': 1}, {'ch': 3, 'voices': 1}, {'ch': 4, 'voices': 6}, {'ch': 10, 'voices': 0}, {'ch': 11, 'voices': 0}, {'ch': 12, 'voices': 0}]
Device ADLIB uses [{'ch': 2, 'voices': 1}, {'ch': 3, 'voices': 1}, {'ch': 4, 'voices': 6}]
Device CONTROL_CHANNEL uses [{'ch': 10, 'voices': 0}]
Midi length: 67.0 seconds
Traceback (most recent call last):
  File "sounder.py", line 873, in <module>
  File "gooey\python_bindings\gooey_decorator.py", line 134, in <lambda>
  File "sounder.py", line 857, in main
  File "sounder.py", line 450, in save_sci0
  File "sounder.py", line 450, in <listcomp>
TypeError: unsupported operand type(s) for -: 'dict' and 'int'
[4636] Failed to execute script 'sounder' due to unhandled exception!

None of the sounds would convert at all. However, all of them do convert to SCI1.

Then tested KQ4, converting the SCI0 sounds to SCI1...
Code: [Select]
C:\SCICompanion\Sierra\KQ4\original_sounds\sound.007 SCI0
Device PC_JR uses [{'ch': 1, 'voices': 0}, {'ch': 11, 'voices': 0}, {'ch': 12, 'voices': 0}]
Device SPEAKER uses [{'ch': 1, 'voices': 0}]
Device MT_32 uses [{'ch': 2, 'voices': 8}]
Device FB_01 uses [{'ch': 2, 'voices': 8}]
Device ADLIB uses [{'ch': 2, 'voices': 8}]
Midi length: 6.6 seconds
SAVE SCI1: Ignoring device FB_01, doesn't have a SCI1 counterpart
SAVE SCI1+: Adding GM device, as duplication of MT-32
Traceback (most recent call last):
  File "sounder.py", line 873, in <module>
  File "gooey\python_bindings\gooey_decorator.py", line 134, in <lambda>
  File "sounder.py", line 860, in main
  File "sounder.py", line 617, in save_sci1
KeyError: 10
[15684] Failed to execute script 'sounder' due to unhandled exception!

Sounds 12, 14, 20, 22, 34, 36, 38, 47, 50, 57, 64, 104, and 203 have similar issues.

Thanks for the detailed report!
I don't have LSL2, but thanks to your finding I've done several fixes, I assume they will help there as well.

Permanent link to the latest release: https://github.com/adventurebrew/re-quest/releases/latest/download/Sounder.Installer.exe

It also contains:
  • Internal converter, so digital sample can be in any file (even video - it will just take the audio stream)
  • The "Play device" selection is updated to show only the relevant devices every time "input files" or "input version" are changed

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

19
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 :)

20
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:

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

21
The SCI0 sound spec says:
Quote
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.

22
1.
Ravi's SCI0 Sound Resource Format seems to have a small typo:
Quote
The fact that F8h waits F0h ticks makes me think that E9h is the largest technically allowable delta time.
Should be:
Quote
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):
Quote
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 ;)

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

24
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 (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.

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

26
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 ;)

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

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

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

30
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


Pages: 1 [2] 3 4 ... 14

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

Page created in 0.046 seconds with 21 queries.