SCI1.1 Audio?

[MusicallyInspired]

Err...I think I'm missing something. How does one add digital audio to the game again? I can't find where it was explained before.

[troflip]

Drag a wav file into the resource view. Not very discoverable yet

I guess I could have a "new audio resource" button that pops up a file dialog to let you browse for a wav or something.

[MusicallyInspired]

I figured it out, actually. Thought I deleted the thread. Sorry!

[Cloudee1]

So what's the criteria for a recognized wav file...

I am trying to drag this one in, but I get an error that it's not a recognized wave file

sample Type 48000Hz, Mono, 16-bit

have also tried a 32000Hz, Mono, 8-bit version with the same error.

[Kawa]

So what's the criteria for a recognized wav file...

I've had no trouble importing 22k 8bit mono, saved with no extra editor-specific junk.

Edit: the same sound in 32k was also found acceptable. But I haven't actually tried to play either of them in-engine...

Edit?: your main issue seems to be that your file does have extra junk at the end.
Edit?: both versions of my sound seem to play just fine in Sierra's terp. It's very probably just the junk at the end of yours.
Edit⁴: your sound at 48k 16-bit with the junk cut off didn't play, but 48k 8-bit did.

[troflip]

My validation code is expecting a header size of 16 bytes, and yours says 18 bytes (although it still appears to be just 16 bytes). I'm not sure if it matters or not, I'll need to do more research. Maybe I can be more lenient?

[edit:] Ok, I've modified my code to allow importing your sound, but it plays at half speed in the Sierra interpreter (ScummVM) is fine. So I think it's having trouble with the sample rate. The sounds in LSL6 are all 22kHz, so I think you should limit it to that. This is 1993, after all

As for a workaround to let you use your sound before I release the next SCI Companion update, see if you can play with the export settings of your audio app to see if you can generate a wave without the extra 2 bytes in the header (not sure what they're used for?).

[lskovlun]

Relevant discussion: https://trac.ffmpeg.org/ticket/1843
Some sources seem to say that the extra field is required when using 16-bit sound, which might explain why it doesn't work for you (wasn't there a problem related to this earlier?)

[Kawa]

Relevant discussion: https://trac.ffmpeg.org/ticket/1843
Some sources seem to say that the extra field is required when using 16-bit sound, which might explain why it doesn't work for you (wasn't there a problem related to this earlier?)

I dispute your sources. I just made a dumb test recording (me saying "bleugh") and saved it as 22k mono, one copy in 16-bit and one in 8-bit. Both open and play in Media Player Classic just fine, and a quick glance at a hex editor shows the fmt chunks being equal in length.

[troflip]

Relevant discussion: https://trac.ffmpeg.org/ticket/1843
Some sources seem to say that the extra field is required when using 16-bit sound, which might explain why it doesn't work for you (wasn't there a problem related to this earlier?)

From what I gather, the "bits per sample" field they are talking about being cut off on that page is actually the last two bytes of the 16 byte header (I think they are talking about the 14 byte header cutting that data off). It looks like the extra 2 bytes that can follow the 16 bytes are for extra "extensible" data, which I wouldn't care about (or know how to use). But I actually might need to skip past it if it's not zero, so I need to find a file that has this to verify (cloudee's file has 0 for this extra data).

As for any problems we had with the interpreter playing sounds before, I don't think this would be related - the WAVEFORMAT stuff is irrelevant when the resource is in the game, since Sierra has their own header format.

[Kawa]

According to http://ccrma.stanford.edu/courses/422/projects/WaveFormat/, the two extra bytes are the ExtraParamSize field, which apparently shouldn't be there for PCM-format sounds. ElevatorDing.wav has this set to zero, so there's no ExtraParams to follow. It is a PCM file, so technically there shouldn't be an ExtraParamSize if this document is correct, but on the other hand it seems safe to ignore everything past the BitsPerSample field and the RIFF length field has the right value...

[troflip]

Yeah, I was able to make an ADPCM format wav with my audio editor, and it stuffed a bunch of extra data in there. Even skipping past the data though, I can't reliably read the format.

cloudee's file works though, since the extra data size is zero.

[Kawa]

Yeah, I was able to make an ADPCM format wav with my audio editor, and it stuffed a bunch of extra data in there. Even skipping past the data though, I can't reliably read the format.

This agrees with the doc I found.

cloudee's file works though, since the extra data size is zero.

And the length field correctly said it was eighteen bytes, even though there's not supposed to be an ExtraParamSize field.

So yeah. Respect the length fields, detect and disallow non-PCM files? That'd cover most bases, I guess. The only pitfall that comes to mind is having another chunk inbetween fmt and data but who even does that?

[Cloudee1]

So what audio software is everyone using?

I've been using Adobe Audition CS6 and no matter how I try to save this file, I can't get the file into companion.

[Collector]

Does it take it if you use Audacity?

[Cloudee1]

That's what I am trying to find out before I start downloading and installing half a dozen pieces of software