Different delays with DVD2AVI and DVDDecrypter

[zehner]

I use rip4robot to rip a DVD, and DVD2AVI to demux audio and video. If the original file has no delay, DVD2AVI and DVDDecrypter say both the delay is 0ms. But if it has a delay, there is always a difference of 80ms. I have a file with -8ms (DVD2AVI) or -88ms(DVDDecrypter) and another movie has -23ms or -103ms. The other language tracks on both movies have the same problem.
What is the right delay-value for my resulting .ogm file? Is it better to demux with DVD2AVI or with DVDDecrypter?

The next version after 0.28.5 should be able to create .ogm-files. Now I use 0.28.6.3 and I don't find the option. Comes this feature in the next version or am I blind?

Thanks in advance and Happy Halloween from Germany

[Tuning]

I don't know what is causing the difference,but I would suggest DVD2AVI to use for demuxing.
The next version after 0.28.5 should be able to create .ogm-files. Now I use 0.28.6.3 and I don't find the option. Comes this feature in the next version or am I blind?

I think the support to OGM files will be available in 0.29 version.len0x has already mentioned that.

:) -Tuning

[manono]

Hi and welcome to the forum-

The latest GKnots are now using DVD2AVIdg which fixes some problems with other versions, problems that (I guess) DVDDecrypter also has. The upshot is that you should now do all of your demuxing using DVD2AVIdg to prevent audio asynch. If you still prefer to demux the audio using DVDDecrypter, then you should use DVD2AVI 1.76 or 1.77.3 (available in older GKnot versions or at the link coming up). Please see questions 11 and (particularly) 17 of the DVD2AVI FAQ (http://forum.doom9.org/showthread.php?s=&threadid=59272) for more information.

[RealityIsAnOpinion]

I have noticed the same thing, actually. I've never noticed this discrepency before I started using dvd2avi 1.77.3dg1.0.0 and dvd decrypter 3.1.7.0. Dvd decrypter was reporting a delay of -84ms and dvd2avi reported -1ms. I decided to keep with dvd2avi's -1 delay, because I used it to demux, and the resulting avi was fine. I noticed no async, although I'm not sure that 83ms difference can really be noticed with human eyes and ears... perhaps I'll mux a second time using -84ms and see...

I read the faqs kindly referenced by Manono, but with the dg1.0.0 version of dvd2avi it looks like the the dropped frames problem has been solved? If that accounts for the difference, then does that mean that dvd decrypter is wrong or dropping frames? Incidentally, I tried demuxing the same track with version 1.76 (well, it said save project 1.76 in the file menu, but it was actually dg1.0.0) and the delay was unchanged.

EDIT:

I muxed the audio again using a -84ms delay, and it looks to me that dvd2avi had the correct delay, but I had to watch VERY closely to see the difference. Without the scrutiny of looking at the same clip over and over, watching specifically for any async, there is no way I would have noticed. Even now I'm not 100% sure... 95% yes. ;)

[manono]

Hi-

You must have good eye-ear coordination (:)) if you can spot the asynch. It's usually said that you can't tell if it's less than about 100 .ms.

...then does that mean that dvd decrypter is wrong or dropping frames?

Beats me. It probably has to do with that GOP stuff, none of which I understand. But I think the answer to your question is yes. This is a job for hakko504. That's his specialty.

[len0x]

Originally posted by RealityIsAnOpinion
If that accounts for the difference, then does that mean that dvd decrypter is wrong or dropping frames?

dvd decrypter is not wrong and doesn't drop frames on it's own. it sipmly reports what has been stored in the VOB (i.e. delay of the audio to the first decodable frame). But it doesn't take into account that some of the tools (like new DVD2AVIdg) may adjust video stream and start with not first decodable, but first reported. In this case only those tools aware of the new delay they introducing.