Audio delay and playback time

[CoNS]

Two questions for the experts around here: :)

I'm adding custom subs to a disc. It has 1 VTS and 1 PGC inside the VTS. I use PgcDemux latest version to demux. It tells me the PGC has an audio delay of -92. I usually use IfoEdit DVD author function to remux. I specified -92 ms as audio delay, but when I later loaded the output in PgcDemux again, it had a much higher audio delay, something like -179.

I then downloaded MuxMan and tried this neat proggy. This time, the specified audio delay of -92 became -79 in the outout disc. No errors were encountered during any of the remuxing processes. What can be causing the incorrect audio delay? :confused:

The second question: When I load this disc into my software player (Media Player Classic), the player gives me a different overall playback time depending on which .ifo is loaded, even though there're no menus at all and only 1 VTS with 1 PGC as mentioned above. If I load VIDEO_TS.IFO, the playback time is 8 seconds shorter than if I load VTS_01_0.IFO. How come?

[jsoto]

I hope pgcDemux is not the culprit....
Could you double check with other prog, i.e. DVD2AVI?. Or may be you can check the PTSs with VOBedit and do the maths..

About the duration, I really do not know why, but I've seen some SW that uses the Cell durations instead of the PGC duration, so ..
- Check with pgcEdit (it does it automatically when opens the PGC)if the duration of the cells is the same than the PGC
I have no more ideas.

jsoto

[CoNS]

Originally posted by jsoto
I hope pgcDemux is not the culprit....Could you double check with other prog, i.e. DVD2AVI?. Or may be you can check the PTSs with VOBedit and do the maths..Hmmm, I don't have DVD2AVI and I'm not sure what you mean with the PTS in VobEdit. Sorry, I'm a nOOb you know. :)

In order to determine whether the problem is the authoring tool or PgcDemux, can you recommend any other tool to easily check the audio delay on my original disc and my output disc? If the error is in the authoring tool, then both IfoEdit and MuxMan has an error as they both give me results which differ from the value PgcDemux tells me.[/B][/QUOTE]

Originally posted by jsoto
Check with pgcEdit (it does it automatically when opens the PGC)if the duration of the cells is the same than the PGCI'm at work now and don't have the disc with me, but as far as I remember, PgcEdit says the duration is the same as the duration when I load the VIDEO_TS.IFO in MPC. Is this good or bad?

[frank]

You can download DVD2AVI from DOOM9 :)

Load the vob into DVDAVI and save a project demuxing the audio as AC3. The name of the audio track includes the delay time.

Be sure there are no cells with stills at the beginning of the stream (SCR discontinuity flag is set).

[mpucoder]

DVD2AVI is notorious for getting the audio delay wrong unless you use the new version by neuron2.
Here is how to determine the audio delay of the first vob in a title, others are more difficult.
In VobEdit open the vob, look at the first NAV pack and take note of the vobu_s_ptm(location 0039 "Vobu Start Presentation Time (90KHz clk)") - this is the time, in 90KHz clocks, that the first video frame is presented - ie it is time 0 of the movie.
Now look at the first pack of audio for the stream you are interested in, find its pts value.
delay (in ms) = (audio_pts - vobu_s_ptm)/90

Just wanted to add that the whole audio delay thing was started by DVD2AVI because of an error in the program that caused it to drop video frames. The other cause is demuxing by vobid incorrectly. Most DVDs have a delay of zero.

[jsoto]

Well, pgcDemx (and also Vobblanker in info dialogs) calculates the delay between audio and video stream, not versus audio and VOBU presentation times. I did it in this way, because I've checked the results with DVDAVI ones.

So.., do I have to check the delay versus VOBU presentation times?

Other point is that I'm using PTS, not DTS in video stream...

EDIT: Note VOBU start presentation time usually has the same value than video stream PTS [/EDIT]

Most DVDs have a delay of zero. I disagree with "Most". There are many with 0 delay, but, in my experience (only PAL, BTW) there are also a lot with negative delay. Positive is very rare..

jsoto

[jsoto]

@mpucoder
Seems to me there is something wrong in Muxman with negative delays. I've done the following tests:
Muxing with 80 msec (positive)--> pgcDemux reports 80 msecs
Muxing with 40 msec (positive)--> pgcDemux reports 40 msecs
But
Muxing with -80 msec (negative)--> pgcDemux reports 16 msecs (positive!)
Muxing with -40 msec (negative)--> pgcDemux reports -8 msecs (negative)

Muxman seems to use the same value for VOBU start presentation time as in video PTS. In the last case:
VideoPTS=VOBU startPTM= 25257
AudioPTS= 24537
which, doing the maths gives you a delay of -8 msec.

May be I am doing something wrong?

More tests:
Ifoedit (0.96 & 0.971) gives me good results in all the cases I tested
0 msec.
80msec
-92 msec
In all cases pgcDemux reports the value used when muxing.

BTW, Muxman using -92 msec, produces a VOB with 4 msec (positive!)

Always using the same ESs, PAL video and a 6 channels ac3 448kbit/s
Muxman 0.12c

jsoto

[CoNS]

Ok guys, thanks for taking the time to dig into this interesting problem. :)

Now, I might be doing something wrong but here's my test results following mpucoder's instructions:

For my original disc the calculation is: (4095 - 3285) / 90 = -9. PgcDemux tells me the a/v delay is -92 (same value is written in the log file by PgcDemux when demuxing).

For my output disc with MuxMan, where I set the delay to -92, the calculation is: (25617 - 25257) / 90 = 4. Same result as jsoto got I can see.

Ok, I was a bit unsure about the part about getting the audio_pts value, but I figure it's the "PTS" value at offset 0017 under PES HeaderData, header data details?

EDIT:

Originally posted by jsoto
Ifoedit (0.96 & 0.971) gives me good results in all the cases I tested
0 msec.
80msec
-92 msec
In all cases pgcDemux reports the value used when muxing.Hmmm, when I muxed my files using IfoEdit 0.971 where I set the audio delay to -92, PgcDemux reported something like -179 for the output disc. I don't have the IfoEdit authored files anymore, but I'm positive the a/v value reported by PgcDemux wasn't -92 as I specified in IfoEdit.

[jsoto]

For my original disc the calculation is: (4095 - 3285) / 90 = -9. PgcDemux tells me the a/v delay is -92 (same value is written in the log file by PgcDemux when demuxing). Are you sure?.. Values usually are higher than these. In any case, could you check also the video PTS ?(in first video pack) is it also 3285? Well your maths seems wrong 4095-3285 is positive...

For my output disc with MuxMan, where I set the delay to -92, the calculation is: (25617 - 25257) / 90 = 4. Same result as jsoto got I can see. Good!.

Ok, I was a bit unsure about the part about getting the audio_pts value, but I figure it's the "PTS" value at offset 0017 under PES HeaderData, header data details?
Yes

Hmmm, when I muxed my files using IfoEdit 0.971 where I set the audio delay to -92, PgcDemux reported something like -179 for the output disc. I don't have the IfoEdit authored files anymore, but I'm positive the a/v value reported by PgcDemux wasn't -92 as I specified in IfoEdit. PAL or NTSC material?

EDIT: Be careful with VobEdit. Click twice (not double_click, but click twice) on the selected pack. IIRC, if you go backwards, VobEdit shows a wrong pack..[/EDIT]

jsoto

[mpucoder]

Let's clear a few things up. vobu_s_ptm IS the start of the video. When you see a video pts value that is different from vobu_s_ptm it is because the first encoded frame is not temporal sequence number 0. pts is the presentation time of the first encoded frame, not the first displayed frame. You can calculate video pts from vobu_s_ptm by looking at the I frame TSN and checking the B frames for rff - or you can trust the value in the NAV pack.

This is the exact same problem DVD2AVI had before neuron2 fixed it.

Muxman will not start audio more than 1200 ticks before video. This translates to -13ms, so the most negative value after muxing with Muxman is -13. If the initial delay is more negative than that audio frames are discarded, and the delay increased by the audio frame duration, until the delay is within range.

So, since ac3 frame duration is 32ms, if the delay is set to -92 Muxman will discard 3 frames and delay the audio by 4ms.

[jsoto]

Let's clear a few things up. vobu_s_ptm IS the start of the video. When you see a video pts value that is different from vobu_s_ptm it is because the first encoded frame is not temporal sequence number 0. pts is the presentation time of the first encoded frame, not the first displayed frame. You can calculate video pts from vobu_s_ptm by looking at the I frame TSN and checking the B frames for rff - or you can trust the value in the NAV pack. Thanks for the clarifications...So, I'll change it in pgcDemux and VobBlanker...


Muxman will not start audio more than 1200 ticks before video. This translates to -13ms, so the most negative value after muxing with Muxman is -13. If the initial delay is more negative than that audio frames are discarded, and the delay increased by the audio frame duration, until the delay is within range.I was suspecting something like this... In fact, I was going to compare the first ac3 frames.. ;)

jsoto

[CoNS]

Originally posted by jsoto
Are you sure?.. Values usually are higher than these. In any case, could you check also the video PTS ?(in first video pack) is it also 3285? Well your maths seems wrong 4095-3285 is positive...Oops, I switches the values when posting the calculation, it should ofcourse be (3285-4095)/90=-9. I double checked the values in VobEdit...

Originally posted by jsoto
PAL or NTSC material?NTSC...

[CoNS]

So, what's the conclusion to the delay issue? :)

[jsoto]

PgcDemux 1.2.0.1 (and before) is wrong (as DVD2AVI was, in fact I've checked my results with an old version of it). It fails in some cases, exactly when:
... a video pts value that is different from vobu_s_ptm it is because the first encoded frame is not temporal sequence number 0. pts is the presentation time of the first encoded frame, not the first displayed frame
For this reason, some DVDs where pgcDemux says -80 msec, in fact have 0 msec of delay. Note 80 msec are the two B frames lost (40 msec = 1 frame in PAL)

Muxman drops some audio frames because it will not start audio more than 1200 ticks before video. What Muxman does is absolutely correct, but the side effect is that the delay you read with pgcDemux (or with any other tool) in the remuxed VOB will not be the same than the original.

It is known IFOEdit had more than one problem with NTSC material. Not sure if all of them are fixed.. So I wouldn't trust in IFOEdit authored material (I only work with PAL).

jsoto