Okay, that particular problem is fixed (new file link in the 1st post. I forgot to include a little error routine.
However, it would only be causing the error because it's finding something wrong with the file, at least according to the standard specs for wavefiles. With the proper error routine in there now, it should at least tell you what the specific problem is. Also, if you want to email me one of WAV files you're having a problem with (hopefully not too huge) I'll take a look inside it. Who knows, maybe Microsoft is doing something dopey with their own format. If so, I can at least tweak the script so that it recognizes it.
Okay, I threw in a kludge for some microsoft dumbness.
I fixed the bit with the missing error function. Then I was told it was still throwing an error, but at least it would tell me what the problem was.
I'm gonna wax very slightly techie bits in here. WAV (and AVI, actually, their both variations of the RIFF format) files are broken up into "chunks" that contain information about all the different things that might be in there, and they have the name of the chunk right at the start of the chunk. The only 2 I'm concerned about for this script are the FMT (format) and DATA chunks, which in a standard uncompressed WAV file are all there are supposed to be. The FMT chunk tells you all the stuff like mono or stereo, if it's compressed, samplerate, all that stuff. Also, the length of the audio data, and where that DATA starts. Normally, it's all pretty easy to find.
So in rides the stupidity. A few users were using the basic, builtin Sound Recorder in Windows. The first problem was that it seemed to be recording in a compressed format without making that clear. When I fixed the missing error function bit, somebody emailed me saying they got a "compressed file" error, and then when they converted the file (again in Sound Recorder) to uncompressed, they got a "bad DATA tag" error. Hmmm. Turns out that there is another chunk type, the FACT chunk, which contains compression specific info about compressed WAV files. And what do you know, but when sound recorder converts the file to uncompressed, it doesn't get rid of this danged FACT chunk the way its supposed to, and bolloxes up the works.
So I threw a little workaround in to get through this little windows faux pas.
7feet wrote:Okay, I threw in a kludge for some microsoft dumbness.
I fixed the bit with the missing error function. Then I was told it was still throwing an error, but at least it would tell me what the problem was.
I'm gonna wax very slightly techie bits in here. WAV (and AVI, actually, their both variations of the RIFF format) files are broken up into "chunks" that contain information about all the different things that might be in there, and they have the name of the chunk right at the start of the chunk. The only 2 I'm concerned about for this script are the FMT (format) and DATA chunks, which in a standard uncompressed WAV file are all there are supposed to be. The FMT chunk tells you all the stuff like mono or stereo, if it's compressed, samplerate, all that stuff. Also, the length of the audio data, and where that DATA starts. Normally, it's all pretty easy to find.
So in rides the stupidity. A few users were using the basic, builtin Sound Recorder in Windows. The first problem was that it seemed to be recording in a compressed format without making that clear. When I fixed the missing error function bit, somebody emailed me saying they got a "compressed file" error, and then when they converted the file (again in Sound Recorder) to uncompressed, they got a "bad DATA tag" error. Hmmm. Turns out that there is another chunk type, the FACT chunk, which contains compression specific info about compressed WAV files. And what do you know, but when sound recorder converts the file to uncompressed, it doesn't get rid of this danged FACT chunk the way its supposed to, and bolloxes up the works.
So I threw a little workaround in to get through this little windows faux pas.
Really thx for trying to fix it, and fixing it, and by the way i was emailing you
I'm not sure if you're still around, but if you are I have a small bug report for you.
The script assumes all scenes start at frame 1 so if you pad sounds in scenes with different starting frames the sound will be off sync.
If you have a scene starting at #10 and want to pad the sound to start at frame 15 then the script won't add 5 frames as it should but 15 frames, as it assumes the existing sound starts at #1 and not #10, so the sound in the end will start at frame 25.