Video/Audio Sync Problems With Anything Other Than MPEG-1

[BishounenStalker]

Already searched the forums, didn't really get an answer, and I've been playing with this for a while.

Background info: I've dispensed with the old temperamental bait-and-switch maneuver in favor of just converting my source to MJPEG with the quality set very high (usually 18, because there is no noticeable difference at high values and the filesize is ginormous). I have serials and reg-codes for it so the watermark is disabled. I then use that converted source for both editing and final export, and I make sure that project and export settings agree with each other.

The problem is that TMPGEnc is the only final compressor that keeps the audio and video synched. Both AutoGK and VDub for some reason have the audio lagging significantly behind the video. Which is weird because I have no issues at all converting the .VOB files with AutoGK. Can anyone shed some light on why this is? Because I would very much like to encode for distro in something that is not MPEG-1.

For the record, I'm using NTSC 23.98fps because that's what AutoGK converted the .VOB files to.

[Qyot27]

How are you compressing the audio, and into what container? If AVI, and the audio is [VBR or even ABR] MP3, that's the issue. AVI only works well when the audio stream is CBR. Often the problem goes deeper than that even and has to do with the way audio is encoded through ACM and gets compressed at the same time the video is. The best solution in such cases is to encode the audio externally (with LAME or iTunes for example) and then mux it with the video later using VirtualDubMod or the particular tool for the container you're using (MP4Box, MKVToolNix, etc.).

If it's another container and audio format, it could have to do with the way the script (if it is a script) is getting loaded into the conversion app. There was a recent post about this concerning Zarx264gui - DirectShowSource desyncs, AVISource works fine. My guess is that DirectShowSource would work fine as well if the 'convertfps=true' parameter was used, as that is meant to ensure audio sync is kept when processing variable framerate streams. Even if the video wasn't actually VFR, it was still getting treated that way and the audio sync was screwing up because the framerate wasn't declared nor was the convertfps parameter used.



The other, non-encoding angle, is that maybe the computer isn't strong enough to play back the end products well, but MPEG-1 is still well within its abilities. Or maybe the decoders being used are the ones to blame. Make sure that if you're using ffdshow, that you're using a new build from ffdshow-tryouts, not the outdated original branch that hasn't been updated since, what, 2006? If you try playing the new files through VLC or SMPlayer, are they still problematic? If so, then it's not a decoding issue (unless the comp is too slow).

[BishounenStalker]

Thanks. I doubt it's the computer because I can play other MPEG-4 files fine. I'm going to try encoding the audio separately as CBR and then mux it with VDub, because I'm 99% positive that's the problem. Thanks, again.

[BishounenStalker]

Would compressing the video first without audio, and then running it through VirtualDubMod as Direct Stream Copy while muxing and compressing the audio using LAME work?

[Qyot27]

Would compressing the video first without audio, and then running it through VirtualDubMod as Direct Stream Copy while muxing and compressing the audio using LAME work?

That would still use ACM to do the audio encoding, and if it's messing up there, then no it probably wouldn't. Also it might help to keep the bitrate under 256kbps, or even under 224kbps. I remember things could be tricky on playback even if CBR was used but the bitrate was too high. Most of the time all that extra bitrate's not even necessary anyway, as LAME can often hit transparency under 192kbps.

And generally I meant encoding video separately (in VDubMod, for instance), audio separately (using LAME - personally I use either the CLI version or an old version of dBPowerAMP that still allowed you to use the drop-in LAME executable and do MP3 encoding for free; you could probably do it through foobar2000 or something similar*, too), and then loading them both back into VDubMod and using Direct Stream Copy.



*like LameDrop:
http://www.rarewares.org/mp3-lamedrop.php

[BishounenStalker]

After playing with it all morning, I finally found a happy medium in using XviD single-pass encoding in VirtualDubMod (for some reason VDubMod can never find the statsfile for the second pass). Now it's just a matter of fiddling with settings and filters to make the results look better. The only real problem I'm getting is the darker areas of the video being not as clear as the brighter ones.

[mirkosp]

The only real problem I'm getting is the darker areas of the video being not as clear as the brighter ones.

Try disabling the adaptive quantization (if it is enabled).

[BishounenStalker]

Thanks a million, guys. Got it running like a charm. The video isn't done yet, but I decided to experiment with final encoding techniques on a small, manageable segment to avoid throwing away hours of rendering time. Again, thank you all for the tips.

[Bakadeshi]

you can also try my AMVbe app (front end to mencoder)and see if mencoder will solve your audiosync issues. (You can also try handbrake, wich is an opensource fronteend for mencoder that I;ve heard is also very good) Mencoder has xvid, x264, and various other codecs built into it, so it does not rely on the vfw codec system, and has some builtin functions in its demuxer specifically for audio sync issues like this. maybe worth a try instead of relying solely on xvid single pass ;p

[BishounenStalker]

I finally figured out how to get XviD 2-pass to behave in VDub (I completely forgot about Job Control; DOH!), but I'll keep it in mind if I run into any other issues. Thanks!