Audio Delay with DVD2AVIdg

[fritzdis]

First, let me preface my question with two statements:
1. I believe I understand why DVD2AVIdg and DVD2AVI 1.76/1.77.3 can give different delays. This question is not about that.
2. I posted this question here (http://forum.doom9.org/showthread.php?s=&postid=421426#post421426), but because there has been no response for 5 days, I wonder if people are actually seeing my question (it's at the end of an 18-page post, so people might assume that they already read it all). If posting this as a separate thread is out of line, just let me know.

Now, on to my question (pasted from the other thread):

I'm a little confused about the question of audio delay. Most particularly, I'm confused about why the delay reported by DVDDecryptor is different from that of DVD2AVIdg. I understand why DVD2AVI and DVD2AVIdg may return different delays, but I don't understand why DVDDecryptor's delay will always correspond to DVD2AVI's (old). In this thread there have been references to DVD2AVIdg "adding delay" when it had to "add frames" at the beginning. Isn't that the wrong way to look at it? As far as I can tell from this thread, DVD2AVIdg doesn't "add" frames when compared to the original .m2v. Rather, it simply avoids "removing" the frames that the old DVD2AVI removes. Assuming then that the delay from DVDDecryptor is correct for the original .m2v, shouldn't it also be correct for the .d2v produced by DVD2AVIdg?

In case I've worded any of this poorly, let me try to say it another way: The point of DVD2AVIdg (as I understand it) is that with the exception of possibly the first few frames, frames in a DVD2AVIdg .d2v should match those in the original .m2v. That is, if a scene change occurs at frame #100 in the original .m2v, then it occurs at frame #100 in the DVD2AVIdg .d2v rather than (possibly) at frame #98 in the DVD2AVI .d2v. The audio that is in sync with the .m2v would therefore be in sync with the DVD2AVIdg .d2v and not with the DVD2AVI .d2v. This seems to contradict at least part of the answer to Q19 of the DVD2AVI FAQ: Demuxing audio with DVDDecryptor and creating a .d2v with v1.76, etc. would create async files if B frames were dropped by DVD2AVI at the beginning of the video.

Another thing related to this issue that is not entirely clear to me is whether the ac3 files created by DVD2AVIdg, DVD2AVI (old), and DVDDecryptor are actually ever different. Do any of the versions of DVD2AVI actually remove or add audio? When testing on a file that seems to start with IBBP (5 frames more in the DVD2AVIdg .d2v than the DVDAVI 1.76 .d2v), the ac3 files from DVD2AVIdg, DVD2AVI 1.76, and DVDDecryptor were identical. Of course, there may be other cases (I only tested one where the frame count was at least 5 different) in which the files are different.

I understand that a lot of thought has been given to these issues, and my confusion may result from misinterpretation, but I haven't seen an explanation that makes sense to me yet.

[Chatwalker]

Hi fritzdis

This is exactly what i want to know too!!!!!
Nobody an idea????

Regards
Chatwalker

[Matthew]

First up, I've never used DVD2AVIdg (edit: before today), although I came in this forum with a view to start using it, given it does support command line now. I've instead been using a couple of lines in my avs to substitute dropped frames with black, as the missing frames are always black anyway (I always encode full films). And adjusting the audio delay in the AC3 filenames accordingly, of course.

"I don't understand why DVDDecryptor's delay will always correspond to DVD2AVI's (old)."

It's quite simple - for whatever reason it uses the same mechanism to calculate the audio delay. I believe this is to find the presentation time stamp for the first I-frame and then subtract the presentation timestamp for the first audio frame. The problem being that in these special cases the first I-frame is interpreted as the 3rd frame in the stream. So the video is interpreted as starting 2 frames later than it actually does. Now this description may be technically flawed, I don't know, but all that really matters is that DVD Decrypter exhibits the same delay-reporting mechanism as DVD2AVI. (Note: vobedit reports the correct delay)

"In this thread there have been references to DVD2AVIdg "adding delay" when it had to "add frames" at the beginning. Isn't that the wrong way to look at it? As far as I can tell from this thread, DVD2AVIdg doesn't "add" frames when compared to the original .m2v. Rather, it simply avoids "removing" the frames that the old DVD2AVI removes."

I originally wrote something else here and have junked that as I was mistaken.

After testing a retail DVD and actually bothering to read the FAQ properly, the first 2 frames are decoded properly provided the first GOP is closed. The retail DVD I tried was fine, and that's the norm I'm sure. You'll know if you'll get junked frames because DVD2AVIdg will give that pop-up warning box (on account of an open first GOP). Bleh I really should read properly before posting...

"Another thing related to this issue that is not entirely clear to me is whether the ac3 files created by DVD2AVIdg, DVD2AVI (old), and DVDDecryptor are actually ever different."

They are always the same, only the reported delay is different.

The bits I've left unresponded to are, I believe, dealt with in other bits of my post.

Hope this helps to clear things up.

[fritzdis]

Matthew,

Thanks very much for your reply. It has helped me realize that the question I really wanted to ask is:

Is the audio delay reported by DVD2AVIdg correct?

The reason that your reply does not answer that specific question for me (which I hadn't asked and so didn't expect to be answered) is that I have a file that gives me the Open GOP warning, and the audio delay in VOBEdit matches that of DVD2AVI 1.76 and does not match that of DVD2AVIdg. Since the dg .d2v has 5 more frames than the 1.76 .d2v, VOBEdit's reported delay can only be correct for one of the .d2vs. Are you sure that VOBEdit always gives the correct delay? I also have a file where the dg delay, the 1.76 delay, and the VOBEdit delay are all different, so if VOBEdit is always right then I'm really confused (that one didn't even give me the Open GOP warning, so I'm already confused about it).

Another question that still bugs me is whether the delay reported by DVDDecrypter is correct for the original .m2v. If it is, then that delay must also be correct for the dg .d2v, right?

I think getting to the bottom of the "correct" delay requires knowledge of just how each of these applications calculates delay, and I don't have that knowledge. Hopefully, someone who does have that kind of knowledge can help me understand this question better.

[Matthew]

Well the audio delay of DVD2AVIdg is obviously correct when dealing with closed first GOPs, and that's easily testable anyway if you don't trust it...compare with vobedit's delay with each DVD rip if you like, it takes less than half a min.

If you are dealing with cut vobs (open gops seems to indicate that) I wouldn't necessarily rely on vobedit, e.g. when I've tried to get the delay of a demuxed cell it's given very weird values. But I've always found it accurate and consistent with complete vobs ripped off DVDs. In these cut/demuxed vob circumstances I have instead relied on DVD2AVI and found it accurate (adjusting the delay if required of course, e.g. adding back adding back 80 ms if using the original m2v without re-encoding).

"I also have a file where the dg delay, the 1.76 delay, and the VOBEdit delay are all different, so if VOBEdit is always right then I'm really confused (that one didn't even give me the Open GOP warning, so I'm already confused about it)."

Sounds like vobedit is incorrect (this a demuxed vob or something?)and as long as DVD2AVI and DVD2AVIdg exhibit a 2 frame difference in audio delay and 2 video frame loss at start is there then DVD2AVIdg is correct.

So in summary, if dealing with open gops, or cut/demuxed vobs, as long as DVD2AVIdg has a delay 2 frames less negative than DVD2AVI, then yes I'd rely on its delay figures.

"Another question that still bugs me is whether the delay reported by DVDDecrypter is correct for the original .m2v. If it is, then that delay must also be correct for the dg .d2v, right?"

No, the delay reported by DVD Decrypter is not correct for the original m2v. If I take one of these PAL DVDs with odd first gop structure a stream with -80ms delay reported by DD but 0 by vobedit and remux the m2v/ac3 in Maestro without inserting any delay, DVD Decryptor will still report a delay of -80ms even though the delay is 0. I know - I've tried it, before DVD2AVIdg was even conceived.

I told you, DVD Decrypter mnakes the same mistake as DVD2AVI (unfixed), I've noticed this in the past and haven't give it a moment's more thought, why is it so hard to understand? The conclusion from this is not to rely on DVD Decrypter's delay unless you are using DVD2AVI (unfixed).

As for how delay is calculated, http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/doc/issue.html
says how DVD2AVI calculates delay.

For some reason the odd structure of the first GOP on some DVDs leads DVD2AVI to interpret the first I-frame as the third frame in the stream, leading to the PTS value for video being 2 frames larger (80ms in the case of PAL). So when video PTS is taken away from audio PTS, the delay is 2 frames smaller than what it should be (typically -80ms instead of 0ms, in the case of PAL releases).

[fritzdis]

Matthew, thanks again. Your response addressed everything that concerned me.

[begu]

Well a few questions related to AV delay / synch considering DVD2AVIdg:

1: If I create stereo wav sound file using DVD2AVIdg (surround downmix), will it be in sync with video, when using simple .avs script to serve the video frames to virtual dub and using virtualdub's stream list to import the generated audio (wav)?

2: When extracting the audio to AC3, will the delay info be in the extracted audiotrack's filename?

2b: Is there any other way to find out audio track delay info using DVD2AVIdg program?

Thanks for very nice program, and for any information in advance ! :)

[neuron2]

AV synch issues give me a headache.

I posted my complete analysis and conclusions in a thread here somewhere.