What do I do with the DELAY?

I'm trying to rip a DVD and re-encode it to fit on a DVD-R. I created a DVD2AVI project, which produced my D2V and AC3 files as required, and I went on to use the D2V file to re-encode the video fine, but what do I do with the delay setting that DVD2AVI produced? The guide said to make a note of it, but not what to actually do with it.

Tnx for the reply, but I'm just trying to rip a DVD. I used DVD2AVI to produce the aforementioned AC3 file, which reports a -80ms delay, and the D2V file which I then served to CCE using AviSynth. Now I have an MPV file and an AC3 file which I need to author back to DVD, but I don't know what to do about the delay. I also have another major problem in that the lengths of the MPV and AC3 files don't appear to match, but I've posted that in another forum :) Fun & games... :)

I was asking my self the same question when I read the guide. If you browse through the programs to download on doom9. First make sure you click where it says "all programs" or something like that since after clicking it will show all the programs and not some of them. Download AC3 Delay corrector, this will fix the delay on the AC3 file and ready for the authoring program.

Hmm... I'm still not convinced of the need to butcher the AC3 file. As far as I can tell, Scenarist syncs your audio automatically by using the time code embedded in the stream. I'm not sure how these delay correctors work, but I'm pretty sure they only chop frames off or add frames on - which of course would have no effect since the time code is still embedded. For the vast majority of cases, nothing needs to be done to the audio stream. However, some PAL users have reported problems with audio sync. My perception of the issue is that frames are being dropped in the d2v and hence mpv, which results in these audio sync problems. Rather than focussing on the audio, the video should be corrected instead. My understanding is that there is a problem with DVD2AVI or mpeg2dec or both. I'm awaiting Nic's word with baited breath :)

Thanks for the reply Aquabubble. I just did a test on one I have recently done, Aliens, PAL version. The .d2v file that I imported into TMPGEnc was reported by TMPGEnc to have 165309 frames, which equates to 1hr50mins12secs9frames. I then checked the m2v file created by TMPEnc (found the info in the Maestro project) and found that this file is 165310 frames, hence 1 frame longer than the original. So it may be that TMPGEnc is adding a frame at the begginning (or end) of the file. If at the beginning, then the audio would be ahead of the video by 40ms (which could be what I am seeing -video lags audio when I have corrected the AC3 delay). If that were the case, then the audio delay reported of -108ms, would need to be corrected to just -68ms (i.e. strip off 2 frames of audio, 80ms) for the audio and video to be nearly in synch. Can we just edit the resulting IFO file after authoring to give the AC3 delay and avoid all this hassle? If so what with?

There's nothing wrong with AC3 delay corrector, or DVD2AVI. They both work brilliantly. I think the problem lies in Tmpegenc. I also used to get sync errors when re-encoding with tmpeg..but since switching to CCE for encodes, I no longer have those problems. My video and audio is perfectly synced...i've tested this on countless DVD's now and they are all great!! I remember earlier someone started a thread where he noticed that if he encoded progressive with 3:2 pulldown in tmpegenc, he'd always end up with audio sync problems. But if I he did it in CCE and then used pulldown.exe to insert the RFF flags, the audio sync problem didn't happen.

TMPGEnc may be a problem for NTSC films requiring pulldown, but my problem is with PAL films that do not require pulldown. The same thing happens with progressive or interlaced material. Reasons why I do not think that TMPGEnc or DVD2AVI are the problem here: 1. If TMPEnc was the problem then I would expect the number of frames in the output file to differ widely from the input file, which is not the case. 2. The delay in the finished product is a fraction of a second, but still noticeable (you would be surprised at how many times we can open and close our mouths per second when we speak - 40 ms is noticeable). 3. The delay is consistent throughout the film 4. When you re-author the film with the original m2V file demuxed using SmartRipper (in other words not touched by TMPEnc or DVD2AVI) the delay is still a noticeable problem. So in my mind the problem is caused by either AC3 Delay Corrector or more likely, the reported delay in the VOB file is not an acurate delay. How do DVD players handle this info anyway. Do they actually have a delay circuit which adjusts the sound to the video? Do software players also have this?

Well that was the theory, but I'm sorry to have to report that the results were not good. The video was ahead of the audio this time. I think we're going to have to just try it out a few times until it's nearly right and then call it a day! Anyone tried out CCE?

thats right jinxed, all the vobs are part of the same PGC. When i remuxed the vobs seperately i did according to their specific delays and they were in synch (for sure). The first vob has a delay of 40ms. So yor idea that dvd2avi is only indicating the delay at the beginning is plausible. 40 definately couldn't have been an average of the delays from each vob but i cant believe the delay calculation is as simplistic as that it is referenced from the first vob only and all other vob delays are ignored.

The way I understand it DVD2AVI thinks that you are processing one continuous stream at a time, regardless of how many files it contains. So the audio and video should be the same length. It then just has to match them up at the beginning and they will stay matched. I remember someone in the Development forum explaining this process, where DVD2AVI would derive the delay factor somehow from the differences in the timestamps of the beginning of the respective audio and video streams. But I don't remember the details. - Tom