NDub, or VDub default option change in gknot?

[divx_encode]

I’m using Gknot .21b version for my dvd rip, divx encode process. While using Gknot and divx 4.11 codec, 2pass, I get nice results. The only thing I don’t like is during playback, on occasion the movie will suddenly fast forward for a couple milliseconds. It’s not that big of a deal because it only happens on occasion, but, sometimes it can get irritating because you’ll miss what the person said because of the fast forward.

I followed the Gknot guide to a tee which brings me to my question; are there any set values I should/could “CHANGE” in vdub and or ndub, that might alleviate this problem? Does anyone have some good set values that they can recommend I change too?

Just for the record, I convert the ac3 audio to 1 x vbr-mp3, and set that for about 192kbps while in gknot.

I guess I’m wondering if I should “change” any "key frame values" from the Gknot .21b default, perhaps in ndub or vdub progs?

[cofferscuffs]

READ THE FORUM RULES (in particuler no. 8) BEFORE YOU POST!!!
Taken from VirtualDub.org:

How many AVI parsers do you think Microsoft ships with Windows? One? Two?

Three, actually. The MCIAVI driver, AVIFile, and DirectShow's AVI splitter. And it turns out that all act slightly different.

I finally started attacking that sync problem that people have been reporting with VirtualDub for ages, and after several hours of reverse engineering, it turns out that it's actually caused by Nandub. Now, I've warned Nando repeatedly about the way in which vdub-mp3, and later Nandub, sets certain fields in the audio stream header when it uses an MP3 file as input. To put it bluntly, they're invalid. And it turns out that they sometimes work, and sometimes they don't. On the same file. It only happens if you use an MP3 file as input -- VBR or not -- and doesn't happen if you actually compress to MP3 in Nandub itself.

The way Nandub tries to set up (VBR) MP3 streams is as follows:


dwSampleSize = 0 (VBR samples)
dwRate/dwScale = sampling_rate/1152 (rate of compressed samples)
nBlockAlign = 1152 (block size)
dwSampleSize, as it turns out, is totally ignored by both the AVIFile and DirectShow AVI parsers for audio streams, so setting it to zero for VBR operation doesn't work at all -- the AVI parsers use the nBlockAlign value of 1152 regardless. The significance of the dwRate/dwScale fraction is that MPEG-1 audio frames decompress to 1152 samples each; it turns out that this is incorrect for MPEG-2 (16-24KHz) and MPEG-2.5 (8-12KHz) streams, but those are usually low bitrate and seldom used. Now, you'll notice that dwRate/dwScale is independent of bitrate here, so with a fixed blocksize and a compressed sample rate regardless of bitrate, the audio stream should be horribly desynchronized.

Except for the strange nBlockAlign value and the way that Nandub writes out audio samples.

Nandub writes each MPEG audio frame as a separate chunk in the file. Ordinarily, this is a bad idea because it causes multiple audio blocks to be written for each video frames and consumes a couple of additional % in the AVI for headers. The odd thing here is that this causes all of the audio chunks to be smaller than the nBlockAlign value. This ends up interacting with an interesting bug/feature in the DirectShow AVI parser, which, for seeking purposes, rounds up all of the chunk sizes. Since no MPEG frame created by the MP3 codec is 1152 bytes or larger, this causes DirectShow to seek as if every MPEG frame was a sample, which gives accurate seeking even with VBR streams. In actuality, any nBlockAlign value will work as long as it is as least as large as the biggest audio chunk in the file.

So everything is hunky dory and we can use VBR audio, right? Unfortunately, not really.

First, DirectShow's buffering does not seem to react very quickly to VBR audio, and if you have high variance in the audio stream, it can cause the video playback to suddenly speed up or slow down. Second, neither DirectShow nor AVIFile will write out an audio stream in this way, so nearly any other program will trash the AVI file when it's rewritten. DirectShow actually refuses to rewrite the stream with an "The data is invalid" error if you try using GraphEdit in a direct copy configuration (File reader -> AVI splitter -> AVI mux -> File writer), even though it works if you disconnect the audio stream or decompress it, or use a regular AVI file.

The killer, though, is that AVIFile's parser rounds down instead of up when it sees blocks that aren't a multiple of nBlockAlign. Thus, AVIFile sees zero samples where DirectShow sees one, and as a result AVIFile-based programs cannot read any audio samples at all from a Nandub MP3-based AVI file. Because AVIFile reports the dwLength header value when AVIStreamLength() is called, this generally results in some nice errors when AVIFile-based applications attempt to read the files and can't get any samples at all. The eventual point of all of this is that the AVI files are basically trashed. No offense to Nando, since it's a pretty neat trick, but the truth is that it just doesn't work for anything other than playing in Windows Media Player. (This also applies to the many DirectShow-based players out there, like Sasami2k, which are basically the same DirectShow engine with some add-ons.) The files are useless for editing. Tsunami MPEG Encoder 2.0's OpenDML parser doesn't like the files either and either reads no audio or badly broken audio when faced with odd-size chunks. You can get Tsunami to work, however, if you force it to use DirectShow to read the source AVI.

MCIAVI, as it turns out, seems to read almost anything correctly, and will even play Nandub MP3-compressed files even when nBlockAlign is lowered below the MPEG frame size, which neither AVIFile nor DirectShow will handle -- quite a testament to the original Video for Windows programmers. However, I seriously doubt that many of you will want to switch to mplay32.exe and Video for Windows to play your movies.

So what happened with VirtualDub?

V1.4c actually handled Nandub MP3 files ok, because it supported VBR operation for dwSampleSize=0. I changed this behavior in V1.4d when I discovered the Microsoft behavior, in order to fix the crash with Canopus AVI files. That turned out to cause the problem with VirtualDub destroying the audio sync on Nandub files, because it then acted similar to the way that AVIFile does. I am going to have to come up with a workaround for V1.4.8, but the truth of the matter is that there is still no reliable way to stick VBR audio in AVI files. Doh!

If anyone has comments or corrections to the above, I've love to hear them.

As a side note, someone finally explained how people are getting the Windows 98 version of the Asus ASV1 codec installed on Windows XP: apparently, it happens if you upgrade a 98/ME system with an Asus capture-capable video card to XP. Whoops. If you haven't figured it out yet, installing an upgrade of Windows over an older version is generally a bad idea, and you should always do a full install.

[divx_encode]

cofferscuffs,

Unfortunately the forum rules page cannot be found when I click the link. I’ll have to get back on that when it’s accessible.

I appreciate you taking the time to explain this situation, in a technical way I might add.

I would just like to clarify though, are you saying that there is currently no fix for this issue with the nandub program included with the gknot version .21b I am using? Can you recommend any suggestions?

[MaTTeR]

Originally posted by divx_encode

I would just like to clarify though, are you saying that there is currently no fix for this issue with the nandub program included with the gknot version .21b I am using? Can you recommend any suggestions?

I believe that's what he is saying. Typically this problem won't popup as you know, just occassionally.

The workaround you could try is to add the WAV header to the MP3 and then mux it as a WAV in Nandub or Vdub. Have a look in Doom9's audio download section.

[cofferscuffs]

Yep, there's no fix for it atm. Use CBR MP3 (via WaveMP3!)/OGG/Ac3 to get round it. Sorry if I seemed bossy about the double posting thing, but that was the second double post I've seen and replied to today.

[divx_encode]

Thanks for the suggestions!

cofferscuffs, no problem, rules are rules. Thanks for your help and for the explanations. Hopefully you can find a fix for this issue sometime soon. In the mean time I'll try to do as suggested.