Audio delay after demuxing AC3 from DVD

[alexVS]

I'm demuxing AC3 audio from DVD. What program correctly shows audio delay: PGCDemux or DGIndex ?

My DVD disk is in NTSC.
PGCDemux shows delay = 67ms
DGIndex shows delay = 200ms

Which one is correct? Is there any other program that can do demuxing and show audio delay just to be sure that everything is correct?

[manolito]

Is there any other program that can do demuxing and show audio delay just to be sure that everything is correct?
Rejig can do this.

Cheers
manolito

[Inspector.Gadget]

They may show different delays because the PGC may not begin on the first cell of the first VOB that you indexed with DGIndex.

[Guest]

Delay is always determined by the starting points of the demuxed video and audio. If the programs don't start the demuxed streams at the same points (e.g., one may just dump all video it sees while another may discard stuff before the first sequence header) they can both report valid but different delays. So in general it's not valid to compare different programs like that.

[newstd]

in the spirit of having a better understanding of this answer :

- DGIndex can analyze delay at every I frame boundaries.
Does that mean the A/V delay should be determined only by the 1st delay indicated in the .txt file supplied by DGIndex analysis (supposing that streams start at 1st cell of the PGC) ?

- than Rejig (using the 'AC3 delay corrector' tool) and PGCdemux (delay estimation tool ?) should indicate the same value ?

[Guest]

- DGIndex can analyze delay at every I frame boundaries.
Does that mean the A/V delay should be determined only by the 1st delay indicated in the .txt file supplied by DGIndex analysis If that is the start of the project, yes.

- than Rejig (using the 'AC3 delay corrector' tool) and PGCdemux (delay estimation tool ?) should indicate the same value ? Not necessarily. As I described, it depends on how the demuxer decides to start demuxing the streams. For streams that start cleanly at a closed I frame, they are all likely to be the same, but not all streams are so clean.

[newstd]

Thanks for this clarification.

I also found this article which may correspond to our thread.
http://www.mpucoder.com/guides/delaymyth.html
It may explain why, sometimes, some typical values like 67 or 176 ms appear in programs.

Doesn't solve if Rejig and PGCdemux are correctly estimating the delays, but DGIndex looks to be.

Also didn't find this topic in the Audio FAQ.
Maybe, would be an idea to insert in ?

[Inspector.Gadget]

For what it's worth, newstd, I've NEVER had a desynchronization problem when processing with DGIndex.