View Full Version : Extracted audio stream from VOBs goes out of sync
chipzoller
22nd November 2009, 06:40
I'm not sure the exact place for this question, but this forum seemed the best candidate although I don't think it's a newbie question.
I'm trying to make an MKV backup of one of my opera DVDs but am finding after muxing video and audio, the audio goes out of sync at a certain point. The original DVD plays fine, but when I extract the VOBs and start from the VOB which contains this point, it begins out of sync from the start, however if you seek anywhere in this VOB, the audio is in sync, even if you seek forward then backward in the same. But again, if this is played without seeking from the beginning, the audio arrives a second or more late from the beginning. So when the audio channel desired is demuxed with dgindex, it contains this same anomaly. My guess is that this is caused by an authoring error in the VOB in question, but since I'm unsure what I'm looking for and even how to fix it, I need to suggestions. It may or may not also be relevant to note that for this VOB in question, Windows 7 64-bit reports its length to be 25:34:57 in length versus the others 00:23:xx length.
This DVD was ripped to a disc image, mounted, then extracted both with AnyDVD and DVDDecrypter, both twice and both with the same result. The image file mounted in a virtual drive plays fine as does the disc as mentioned above. The VOB file before the problematic one has no sync issues nor does the one following.
Inspector.Gadget
22nd November 2009, 07:41
Don't demux by VOB. Use DGIndex or PGCDemux to demux an entire program chain, starting with VTS_0X_1.VOB (in the case of a multi-PGC titleset, use PGCDemux). Mux that with MKVMergeGUI and your encoded (or just demuxed) video, without renaming the demuxed file. If you demuxed with DGIndex, the delay is automatically applied by MKVMergeGUI; I think with PGCDemux you may have to enter it manually. If DVD playback is synced, then this procedure will produced a synced file.
Other possible causes: blank cells as a crude form of copy protection, some unique problem with your virtual drive/ripping setup.
Start from the original DVD, rip with a recently updated ripper (AnyDVD, DVDFab), demux as described above, and encode. You'll get a file that's 1:1 to the sync of the original DVD if you do everything correctly.
Out of curiosity, in what year was this disc produced? What do DVD Decrypter and AnyDVD say about copy protection?
chipzoller
22nd November 2009, 07:47
I should have clarified, I'm not demuxing by VOB but rather a PGC with dgindex. I was simply trying to describe where the sync issues happens. I also forgot to include that if I mux the encoded video stream and audio as extracted (to rule out any compressors), the sync problem still happens at the same point.
Re: encryption - This DVD is a Deutsche Grammophone release of Wagner's Die Walküre made in 2002 (recorded from a live Met performance in the 90s) and didn't have any encryption on it other than CSS. I'll also mention that the second volume of this title (disc 2/Act 3) encoded without issue, and the other 3 operas in the "Ring" also encoded without this problem anywhere.
Inspector.Gadget
22nd November 2009, 07:54
OK, sounds like there may be a PGC issue. If you're ripping with DVD Decrypter in FILE mode, pre-processing the relevant VTS with PGCDemux to (if necessary) create a new one containing only the relevant cells. If you're already ripping in IFO mode, check the DVD Decrypter log and make sure "Uncheck suspect cells" is selected in the IFO Options menu. Also, you really have to do this from the original DVD: it will eliminate a whole bunch of confounding factors and thus simplify the process of elimination.
chipzoller
22nd November 2009, 07:59
I ripped the PGC in IFO mode and yes, "Uncheck suspect cells" is selected. I tried ripping this both from my original DVD and the disc image, same result.
manono
22nd November 2009, 17:49
Check to see if there are multiple VOB IDs within that PGC. Open the DVD in PGCDemux and tick Mode->by VOB ID rather than 'by PGC'. If there are 2 or more VOB IDs, then most likely the desynch occurs at one of those places.
Edit: Fixed a spelling error.
chipzoller
22nd November 2009, 18:47
PGCDemux (was this what you meant?) reports that there are 4 VOB IDs for this PGC.
manono
22nd November 2009, 19:09
PGCDemux (was this what you meant?)...
Darn. Yes, and I apologize, and I'll fix the typo.
So, check out the various places in your output and see if the asynch occurs at one or more of those places. If so, I usually split the AC3 audio at those places and remove the delay. You can also push the 'Check A/V Delay' button in PGCDemux and check if a delay is listed. That might not work to find the delay, though, if it's caused by the audio in the VOB IDs being shorter than the video.
chipzoller
29th November 2009, 00:56
As far as I could tell, the desynch occurred only in the place I mentioned, but since this desynch occurs at audience applause, and it was out of synch for almost 2 seconds, it made it impossible if more desynch occurred later. What I ended up having to do since I couldn't fix it otherwise, was to extract the audio track, measure the delay amount and insert silence before that desynch occurred. It took a few tries to get it adjusted properly, but I managed to get it close enough where it isn't noticeable. Just for my future reference, had I not done this, what else could I have possibly done to fix this? I also pushed the 'Check A/V Delay' button, but PGCDemux didn't report a delay for the track in question. Thanks for your help so far.
manono
29th November 2009, 02:52
That's more or less what I do. I first find out the exact amount of the delay (or as close as my ears can tell) using Media Player Classic Home Cinema, split the audio into 2 pieces at the place the out-of-synch begins (HeadAC3he), fix the delay (DelayCut), and finally rejoin the 2 audios using Muxman.
chipzoller
29th November 2009, 02:54
Is there any way to tell why or how this happened? What could cause such a bizarre problem?
manono
29th November 2009, 03:15
I already speculated it was because of more than one VOB ID. You didn't yet say whether or not the out-of-synch occurred at one of the VOB ID boundaries. That's where I've seen it before. It can sometimes happen if it's a newish DVD with newish copy protection and it's not decrypted properly (unreferenced cells), but that's not what happened in your case.
Edit: fixed a typo.
chipzoller
29th November 2009, 03:17
Sorry, forgot to mention that the one and only desynch I noticed was at the first VOB ID boundary. This is not a new DVD and had no unique copy protection, which is what I don't understand.
manono
29th November 2009, 04:52
Darn, another typo. In my last post I meant to say, "but that's not what happened in your case". I'll go back and fix it.
Oh, so it did happen at the end of a VOB ID. Think of it this way. They assembled the DVD in pieces, each piece being a VOB ID. The audio for the first one is slightly shorter than the video. If you extract the audio in one piece for the whole thing, the audio for what was originally the beginning of the 2nd VOB ID and for the rest of the video is out of synch, because the audio "slides up against" the audio for the 1st VOB ID, where when playing the DVD that 2nd VOB ID starts fresh, with no reference to the first VOB ID. I don't know if that makes any sense, but out-of-synch audio like you're experiencing happens sometimes. When I get an unexplained audio asynch seemingly out of nowhere in the middle of a video, the first thing I check is if there is more than 1 VOB ID, and then if the asynch began at the end of one and the beginning of another.
You could extract the first VOB ID with PGCDemux, find the lengths of the audio and video, and then I'll bet the delay for the rest of your reencoded concert equals the difference between the lengths of the 2.
chipzoller
29th November 2009, 04:54
Understood. Thanks for the explanation and your help.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.