PGCDemux and DVD-Decrypt: audio delay question

[StephenChow]

Hello,

it looks strange,
When I use DVD-Decrypt to rip a VTS in IFO Mode
VTS_01
I see log file
0x80 - Audio - AC3 / 6ch / 48kHz / DRC / Chinese / LBA: 8 / PTS: 00:00:00.233 / Delay: -66ms
0x81 - Audio - AC3 / 2ch / 48kHz / DRC / Chinese / LBA: 9 / PTS: 00:00:00.233 / Delay: -66ms

When I use PGCDemux to demux movie, subpicture and audio from that VTS_01 ripped by DVD-Decrypt, check audio delay, I see:
0x80 ---> 0ms
0x81 ---> 0ms

If I use PGCDemux to demux that movie from DVD source (VTS_01_00.IFO) I see audio delays for both audios are 0ms

If I remux them after demux VTS_01 that ripped by DVD-Decrypt and demuxed by PGCEdit, which audio delay value should I use? -66ms or 0ms?

:thanks:

[bigotti5]

Use 0ms

DVD Decrypter is incorrect if there are backward prediction B-frames on the beginning of a track (as many hardware encoders do).

[StephenChow]

Use 0ms

DVD Decrypter is incorrect if there are backward prediction B-frames on the beginning of a track (as many hardware encoders do).

Thank you very much

[Dr.Khron]

Wow, great explanation!

DVD Decrypter is incorrect if there are backward prediction B-frames on the beginning of a track (as many hardware encoders do).

I never understood that, delays and how there are stored is sort of Voodoo to me... thanks for clearing that up.

[jsoto]

The audio video delay in a VOBU can be calculated using the PTS of the first video pack and PTS of the first audio pack, but, in this case, the MPEG-2 video has to be checked not only for B-frames, (usually two) but also for other complex NTSC stuff.

Fortunately, for the video you can trust the VOBU presentation time, stored in the NAV, and take it as the first frame of video PTS. That's what pgcDemux does.

jsoto

[yamyam]

Hello, just a quick question concerning delays, i demux video stream, all audio streams & all subpicture streams, so if theres any delay does pgcdemux automatically correct this during demux, because i end up with the audio just named Audiofile_80 when pgcdemux has finished, forgive the dumb question guess im used to rejig telling me the delay in the filename & then correcting it later but like stephenchow i get different audio delays from different programs (rejig will tell me one delay & checking the same file ill get a different delay from vobedit then a different one from pgcdemux), just doing a search for delays in this forum & pgcdemux seems like its the most reliable.

Thanks

[jsoto]

No, the naming in pgcDemux means to the ac3 stream number in hexa (80, 81, 82, etc). Nothing to do with delay.

pgcDemux does not correct any delay. It only reports it. (if exists)

jsoto

[yamyam]

Sorry my post wasnt clear enough, i know that 80,81etc stands for the hex number in streams, but you answered my question that pgcdemux does not correct delays, im in the uk & 99% of dvds i deal with are pal format (if it makes any difference), can i rely on pgcdemux to report the correct delays on pal dvds.

Cheers

[jsoto]

Remember, the audio/video delay in a DVD is a myth.
If you're dealing with a good DVD (without the new protection schemes, or with them well removed) demuxing properly will give you 0 msec a/v delay, if not in all cases, in the very most of them

jsoto