Community
SCI Programming => SCI Development Tools => Topic started by: MusicallyInspired on June 19, 2015, 01:54:59 AM
-
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.
-
Drag a wav file into the resource view. Not very discoverable yet :P
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.
-
I figured it out, actually. Thought I deleted the thread. Sorry!
-
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.
-
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.
-
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 :P
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?).
-
Relevant discussion: https://trac.ffmpeg.org/ticket/1843 (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?)
-
Relevant discussion: https://trac.ffmpeg.org/ticket/1843 (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.
-
Relevant discussion: https://trac.ffmpeg.org/ticket/1843 (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.
-
According to http://ccrma.stanford.edu/courses/422/projects/WaveFormat/ (http://web.archive.org/web/20080603160754/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...
-
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.
-
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?
-
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.
-
Does it take it if you use Audacity?
-
That's what I am trying to find out before I start downloading and installing half a dozen pieces of software ;)
-
Or just wait for the next release of SCI Companion, which may happen today. It will handle the .wav created by your app (as long as it's PCM).
-
Cool Edit Pro here, the audio editor later known as Audition.
-
fyi, same issue here, it looks like:
https://forums.adobe.com/thread/1373344?start=0&tstart=0
Someone one there suggests using a hex editor to remove the offending two bytes.
Bad Adobe!
I use Sony Vegas, FWIW
-
Removing those bytes would invalidate the chunk. You should do that and adjust the length field, too.
Edit:hdr_frmt.sz 18 though indicates that it's used some sort of compressed format (although I can't figure out exactly which one 18 is at present).
That's... not even wrong. :o
-
Audacity is probably what most will use if they do not already own a commercial product. Any tutorials about adding sound should probably be done with it because of this reason. It is pretty complete and robust.
-
So have we all come to a consensus on the best audio set up yet...
I have found that the AUDDISNY driver doesn't seem to mind if the wav file is 8 or 16 bit, but does seem to play the sounds a bit crackily.
The AUDBLAST driver doesn't make the sound crackily, but it also doesn't seem to want to play 16 bit files.
-
The SQ5 audblast.drv plays 16 bit sounds. That's what the template game is set up to use by default now.
No driver that I've found plays 16 bit sounds smoothly if you want your sound effects to loop though.
-
Has anyone gotten around to trying (DoSound SETRATE) to see if this fixes the sound problems?
-
Never heard of a setrate command for DoSound. I don't see it in Scumm either, but maybe I'm not looking in the right place...
-
I would like to know more about SETRATE too.
I have usually resorted to the AUDTHUND.DRV when I have issues with the SB driver that I cannot resolve any other way. Seems to give better, more predictable results than the AUDDISNY.DRV, at least for a broader range of games.
Might be nice to enlist NRS to look at the SB driver. With a small demo SCI1.1 game with a 16 bit sound I could try to ask, but he has not been around much lately.
-
Sorry about that. I meant to say DoAudio. It's called kSciAudioRate in ScummVM (and maps to subfunction 7). LB2 uses it.
-
Just from a quick test, the following doesn't seem to have any effect with regards to the stuttering when looping a 16-bit 11025Hkz sound:
DoAudio(7 11025)
(I also tried 22050, just in case it wants the byte rate and not the sample rate).
At any rate, audio mostly works well with the SQ5 audblast.drv in DOSBox. The only problem is the brief pause when looping a 16-bit sound.
And of course you can't play more than one audio resource at a time, and you can't control the volume (neither DoSound or DoAudio's set volume function affects the volume).
[edit:] KQ6 uses this, I don't see it in LB2 (maybe there is a talkie version of that game that does use it? I don't have it). It seems like DoAudio seems to be related to the speech stuff - those use separate resources than .aud, right? I don't have any talkie SCI1.1 games to look at, maybe I should get one off of gog or something. If we got the talkie stuff working, is there any reason it couldn't be used for audio music tracks? (I'm assuming it supports greater resource sizes than .aud).