Audio Delay Not Being Written

[EpheMeroN]

How can I determine the AC3 audio delay when demuxing in DGIndex when it's not being automatically written to the filename?

[nautilus7]

Why it isn't written automatically?

[Guest]

Did you demux or decode to WAV? If you decode AC3 to WAV you won't get a delay because DGIndex tries to make a zero delay WAV file.

Earlier versions of DGIndex did not put the delay in the filename if it exceeded 5 seconds. Try with the latest 1.5.0 RC2.

[EpheMeroN]

I demuxed, and tested with v1.4.9 and the latest v1.5.0 RC2. Both are not writing the delay in the filename.

I'm trying to manually guess the delay but having problems with that.

[EpheMeroN]

Just for testing purposes, I tried demuxing the audio with PgcDemux, and it remuxed just fine with perfect sync to the movie. There actually was no delay in the AC3 file, but for whatever reason DGIndex was causing it to be out of sync.

[Guest]

Can you give me the first 20 MBytes of the stream? You can use DGSplit to split it off. Set the size to 20 and then close the program after it finishes writing the first segment.

[Inventive Software]

Same sorta thing, but when saving the project file and checking "Demux All Streams", the delay is written. Only when you select "Demux Audio Only" is the delay not written.

[EpheMeroN]

Can you give me the first 20 MBytes of the stream? You can use DGSplit to split it off. Set the size to 20 and then close the program after it finishes writing the first segment.
I wasn't sure if you meant 20MB from the first VOB or just the AC3 file so I sent the VOB.

http://rapidshare.com/files/84780198/hocus_pocus_20mb_segment.html

[Guest]

I'm stuck behind my corporate firewall for the next two weeks and can't get file sharing sites. I'll PM you my ftp details and ask you to upload it to my FTP. Thanks.

[EpheMeroN]

Just uploaded the 20mb sample to your FTP.

[Guest]

Have you checked that sample? I cannot see good video in any application. I tried DGIndex, VLC, Media Player Classic. All give garbage and then crash.

[EpheMeroN]

Hmmm. Maybe because it strips the .vob extension?

I'll make another sample using a VOB cutter of some sort.

[Guest]

The VOB extension is unimportant. How did you cut that sample?

[EpheMeroN]

Exactly like you said using your DGSplit application...

[Guest]

Then either the original file is hosed or your upload hosed it.

[EpheMeroN]

Cut a new 20mb sample "VTS_01_1.VOB" and uploaded it to your FTP. I cut it this time using a tool called VobSplitter, and I tested it locally after I cut it in VLC and DGIndex, and also re-downloaded it after upload and VLC and DGIndex both still played it back fine so you shouldn't encounter issues this time :)

[Guest]

I downloaded the new one.

I opened it in DGIndex and did Save Project. The audio was demuxed and the delay value 0ms was written in the filename.

VTS_01_1 T80 3_2ch 384Kbps DELAY 0ms.ac3

So what gives?

[EpheMeroN]

I wish I knew. I found it all very odd to begin with when this whole ordeal started. I ran the cut vob through DGIndex here as well and it wrote the 0ms delay too.

[josey_wells]

I have not seen a time where the audio value was not written with DGIndex V1.5.0 RC2. However, I have seen it write an incorrect value.

If the audio is leading the video as shown in this timestamp log of License To Kill Special Edition:

DGIndex Timestamps Dump

frame rate = 29.970030
SCR 0, [0ms]
SCR 43885, [1ms]
V PTS 26142 [290ms]
V DTS 17133 [190ms]
GOP start
Decode picture: temporal reference 2[I]
SCR 87771, [3ms]
SCR 131657, [4ms]
SCR 175542, [6ms]
SCR 219428, [8ms]
Decode picture: temporal reference 0[B]
SCR 263314, [9ms]
SCR 307199, [11ms]
Decode picture: temporal reference 1[B]
SCR 351085, [13ms]
Decode picture: temporal reference 5[P]
SCR 394971, [14ms]
SCR 438857, [16ms]
SCR 482742, [17ms]
SCR 526628, [19ms]
SCR 570514, [21ms]
SCR 614399, [22ms]
SCR 658285, [24ms]
SCR 702171, [26ms]
Decode picture: temporal reference 3[B]
SCR 746057, [27ms]
Decode picture: temporal reference 4[B]
SCR 789942, [29ms]
SCR 833828, [30ms]
SCR 877714, [32ms]
Decode picture: temporal reference 8[P]
SCR 921599, [34ms]
SCR 965485, [35ms]
SCR 1009371, [37ms]
SCR 1053257, [39ms]
SCR 1097142, [40ms]
SCR 1141028, [42ms]
SCR 1184914, [43ms]
SCR 1228799, [45ms]
SCR 1272685, [47ms]
SCR 1316571, [48ms]
SCR 1360457, [50ms]
Decode picture: temporal reference 6[B]
SCR 1404342, [52ms]
SCR 1448228, [53ms]
SCR 1492114, [55ms]
SCR 1536000, [56ms]
SCR 1579885, [58ms]
Decode picture: temporal reference 7[B]
SCR 1623771, [60ms]
SCR 1667657, [61ms]
SCR 1711542, [63ms]
SCR 1755428, [65ms]
SCR 1799314, [66ms]
Decode picture: temporal reference 11[P]
SCR 1843200, [68ms]
SCR 1887085, [69ms]
SCR 1930971, [71ms]
SCR 1974857, [73ms]
SCR 2018742, [74ms]
SCR 2062628, [76ms]
SCR 2106514, [78ms]
SCR 2150400, [79ms]
Decode picture: temporal reference 9[B]
SCR 2194285, [81ms]
SCR 2238171, [82ms]
SCR 2282057, [84ms]
Decode picture: temporal reference 10[B]
SCR 2325942, [86ms]
SCR 2369828, [87ms]
SCR 2413714, [89ms]
SCR 2457600, [91ms]
SCR 4344685, [160ms]
A0 PTS 20136 [223ms]

then according to the PTS time stamps a delay value of -67ms should be written but DGIndex will record a 0ms. I have had several movies where a - delay value was reported as 0.

[Guest]

then according to the PTS time stamps a delay value of -67ms should be written but DGIndex will record a 0ms. I have had several movies where a - delay value was reported as 0. You have to take into account frame re-ordering if the I frame is not the first display frame, as would be the case for GOPs like this:

I B B P ....

Note that 67ms is two frames, so likely you have this case. The spec says that the PTS applies to the first access unit in encode order, but it is not the first unit in display order.

[josey_wells]

OK, this peaked my curiousity so I dug into the ISO 13818-1 standard to try to understand this.

The data in the video stream is in the following order:

I B1 B2 P1 B3 B4

But it is presented to the user in this order

B1 B2 I B3 B4 P1

Frame rate is about 33.36 ms.

According the 2.7.5 of the spec the PTS is for the I frame at 290 ms which is the first AU.

The DTS is 100 ms earlier since a total of 3 frames I B1 B2 need to be decoded before I is shown.

so the actual time display of the frames to the user is as follows:

B1 B2 I B3
223ms 257ms 290ms 323ms

The audio starts at 223ms which is coincident with the first displayed frame so when splitting them apart the delay would be 0 ms with the start of the video and not -67 ms.

Is this correct?

[Guest]

That's what I told you in my last post. Now you're asking me if I was correct?! :)