¶Bad audio formats and hangs at frame 0 on save
One of the bitter lessons I've learned while working on VirtualDub is that for every single field in a file format, there's at least one program out there that writes a bogus value into it. Usually it's just due to unintended bugs; occasionally it's due to some moron who reads "denominator of a fraction" in the docs and decides it's a good idea to write zero. In the case of audio in the Microsoft AVI and WAV formats, there are several fields which make more or less sense depending on the specific audio encoding you're working with, and that means that sometimes you find programs writing values in files that are... less than optimal.
A user recently reported to me that a specific video file that he had wouldn't process in VirtualDub, sticking on frame 0. The app wasn't hung, and he could abort the operation, but the pipeline simply wouldn't advance. It turned out that he had been using a WAV file with an incorrect nAvgBytesPerSec field that was far too low -- it came out to something like 0.216 kbps for an MP3 stream, when in reality it was actually more like 96 kbps. This field normally indicates the data rate of the audio stream in bytes per second, but in his case it was so small that it was causing VirtualDub to allocate a zero byte audio buffer, which then caused the pipeline to immediately stall. Soon afterward, another user gave me a sample that was even worse in that it had zero for this field, which not only was invalid, but also caused the Fraunhofer-IIS codec to crash with a divide-by-zero error when the format was handed off to the waveOut API. These were no doubt the result of works-for-me syndrome, caused primarily by decoders that don't validate or even check all of the fields, which then causes people to ship applications that don't write correct values. nBlockAlign=0 is another oddball that I've seen in the wild and already had to put in workarounds for.
I've queued a sort of fix for this issue for the next 1.8.4 release, which is to ensure that the audio buffer can always hold at least one sample and that it's at least 64K in size. It's not a great fix by any means, but it'll at least get things working until I get a better one in. In the meantime, if you're suffering with this issue with an MP3-encoded WAV file, your best bet is to change the file type in the "audio from other file" open dialog from the default to MPEG audio; this will force the MPEG audio parser to be used, which will do a full scan of the stream and compute the data rate instead. For AVI-sourced audio, I might try to correct with dwRate/dwScale of the stream, which has to be reasonable for seeking to work. For WAV audio, it might be a bit tougher, although it might be possible to estimate a reasonable value based on the 'fact' chunk, which is supposed to holds the uncompressed length of the audio stream... assuming it's correct. I'll probably make the program apply this correction only if the value is obviously bogus (i.e., zero), and emit a warning when it does so.