audio sync lost when demuxing in dgindex...

[fidels]

hi everyone!

i've been using dgindex for quite a while now, basically to back up movies in xvid format. i usually demux the video and audio streams with dgindex, and then process them using soundforge, virtualdub and avisynth.

i've never experienced any audio sync problems in the past, but now i bought the first season of lost, and when i try to repeat the process i use with my movies, i end up with an out-of-sync audio (it lags between 2 and 4 seconds). it's really annoying, because i can correct the audio manually, but it takes time to get the sync right, and i have to do it separately for each episode.

so here's my question: how can this problem be avoided? can i correct it when demuxing in dgindex? is this problem due to the fact that i'm processing series episodes instead of full movies?

some data that may be useful:

- the video stream is MPEG-2, at 29.97 fps. dgindex shows it's 99% film, so i'm using the forced film option.
- the audio is AC3 (at 384 kbps, and sometimes at 448 kbps), and the audio files that dgindex creates have "DELAY 0ms" in the filename
- after demuxing in dgindex, i sometimes get a warning about incorrect field operations. in these cases i use the fix d2v tool to fix the d2v files
- the problem is NOT created by the rest of the processing: if i try to re-mux the demuxed streams (using virtualdubmod), i end up with the same sync problem
- the audio is fine both in wmp and a standalone player when played directly from the dvd (or its ripped image)
- i'm using the latest version of dgindex, 1.4.9
- i tried to load in dgindex the vob files starting from VTS_#_0 and starting from VTS_#_1 (the VTS_#_0 file contains a few seconds of black screen), but after demuxing the audio is out of sync in both cases

anyways, i hope someone knows what's happening here, or has some suggestions about things i should try... all your help is greatly appreciated!

regards

fidels

[Guest]

Log the timestamps and then post a link to the log file. No need to do the whole project. Just do a few minutes including the start.

[fidels]

ok, i've uploaded the (zipped) timestamps log file to rapidshare (i didn't really know where to upload it: if you're not comfortable with rapidshare, please tell me where i can upload the file again). as you suggested, i only saved the project with a few minutes of one episode, including its beggining. i also left all of dgindex's options as i've been using them...

the link is: http://rapidshare.com/files/48656731/VTS_02_0.timestamps.zip.html

thanks for your help!

[Guest]

Weird. Open the same thing in DGIndex and then step through the first 10 GOPs or so (> button). Is that proper video or some kind of lead-in? From the trace you provided, the first 10 or so GOPs are just hosed, timetamp-wise. There's not even one audio timestamp during that whole period.

Try stepping in 11 or 12 GOPs and starting your project from there. Is it better?

[fidels]

well, that's much better! when i save the project and demux the audio starting from 12 GOPs after the beggining of the file, i get a small delay value in the audio filenames . if i then use an avisynth script to frameserve the video to virtualdub, and load the audio with the specified delay, i get everything in sync (or at least up to where my ears can tell: i've been dealing with this problem for a few days now, so i'm going sort of sync-deaf). in any case, i think the problem's solved now, so my thanks go to you for all your help!

just as you said, the first few seconds of each episode are some sort of lead in (in some cases, just a black screen; in others it's more of a fade in). however, the lead in was not entirely eliminated by jumping the first GOPs (in fact, most of it is still there), so it seems that the problem was caused only by it's first part...

anyway, i'd really like to know how you can tell from the log files when a problem like this arises, just in case some of the other episodes i'll be processing don't have exactly 12 "bad" GOPs at the beggining. is there a good tutorial/article on these things?

well, i thank you again,

regards

fidels

[Guest]

I just found the first audio timestamp, i.e., a line beginning with " A", and then counted the number of "GOP start" lines leading up to it. The video and audio timestamps from that point on looked reasonable compared to the SCR. There are other possible pathologies, however; it may not always be hosed the same way.

There's no tutorial but understanding how timestamps work in MPEG2 will help a lot. You can read the spec or Google for information.

[fidels]

ok, i'll definately do that...

theanks again for all your help!