[RESOLVED] Audio Delay

Support forum for DGDecNV
Post Reply
DAE avatar
Xunkar
Posts: 36
Joined: Sun Aug 18, 2019 5:17 am

[RESOLVED] Audio Delay

Post by Xunkar »

Hello. I'm new to DGDecNv, but I've been using the regular DGDec tools for a while. I've noticed that DGIndexNv doesn't output audio delay information when demuxing like DGIndex does. Is there a way to retrieve this information? When I check "Log Timestamps" in DGIndexNv it does nothing, the setting is not even saved.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Audio Delay

Post by admin »

Welcome to the forum Xunkar! Thank you for your post.

Regarding the audio delay in the demuxed filenames, I had removed it after running into some cases where it is inaccurate, and after spending inordinate time analyzing such cases. Perhaps I was hasty. I will look into bringing DELAY back, in conjunction with a warning that it is a heuristic and not always totally accurate for all streams, or when a project range is set, etc. The manual method is always available as a final arbiter for tricky cases.

See here for the history of this matter. The thread also describes ways to get the correct audio delay empirically.

viewtopic.php?f=8&t=658

Log Timestamps is operating as designed. Be aware that it works only for PS/TS, not ES/MKV/MP4.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Audio Delay

Post by admin »

For DGIndex compatibility, the DELAY value in the filenames is returning (thank you divine spirit for source control). Here is an appendix I will add to the DGIndexNV manual. Comments are welcome. It will be included in the next slipstream.

Appendix F: Notes on Audio Delay Reporting

When demuxing audio files, DGIndexNV includes a DELAY value in
the demuxed filenames. The method to obtain these values is a
heuristic (hack) deriving from the earliest days of DVD processing with
DVD2AVI. While the heuristic works pretty well for that use case,
it can occasionally fail dramatically for more modern containers
and video/audio types. Here are just three ways things can go wrong
for the delay heuristic (there are more):

1. There can be (intentionally) missing audio. An instance of this is
the case sometimes seen where there is some black video without audio
at the start and then when the real content starts with both video
and audio, we align the first audio PTS with the first video PTS
(one of the black frames), which is wrong. Following is an example from
one case I analyzed. Here is the beginning of the timestamp dump from
the full M2TS (not a selected project range):

PCR1001 289144383 [10709 ms]
V1011 PTS 1048560 [11650 ms]
V1011 DTS 1044806 [11608 ms]
[GOP started]
V1011 PTS 1056067 [11734 ms]
V1011 DTS 1048560 [11650 ms]
A1100 PTS 1048560 [11650 ms]
A1101 PTS 1048560 [11650 ms]
A1102 PTS 1048560 [11650 ms]
A1103 PTS 1048560 [11650 ms]
A1104 PTS 1048560 [11650 ms]

As you can see, the first video and first audio PTSs are both 11650, so
we would conclude that the delay is 0. Now here is a section later in
the dump:

V1011 PTS 1089851 [12109 ms]
V1011 DTS 1078590 [11984 ms]
V1011 PTS 1082343 [12026 ms]
PCR1001 301292097 [11158 ms]
V1011 PTS 1086097 [12067 ms]
V1011 PTS 1101112 [12234 ms]
V1011 DTS 1089851 [12109 ms]
PCR1001 303722655 [11248 ms]
V1011 PTS 1093605 [12151 ms]
V1011 PTS 1097358 [12192 ms]
V1011 PTS 1112373 [12359 ms]
V1011 DTS 1101112 [12234 ms]
PCR1001 306152367 [11338 ms]
V1011 PTS 1104866 [12276 ms]
V1011 PTS 1108620 [12318 ms]
PCR1001 308582079 [11428 ms]
V1011 PTS 1123635 [12484 ms]
V1011 DTS 1112373 [12359 ms]
V1011 PTS 1116127 [12401 ms]
PCR1001 311012637 [11518 ms]
V1011 PTS 1119881 [12443 ms]
V1011 PTS 1134896 [12609 ms]
V1011 DTS 1123635 [12484 ms]
PCR1001 313443195 [11609 ms]
V1011 PTS 1127388 [12526 ms]
A1100 PTS 1077360 [11970 ms]

We are getting a bunch of video without any audio frames. This can
happen because there really is no audio (as in the black frame case)
or just because it is muxed without expected alignment (the audio is
there but appears later in the stream; that's not a problem for a
player due to buffering). Starting a project range around this point
will be problematic.

2. The timestamps can arbitrarily reset anywhere in the stream. That
means the sync calculation can change and if we only do it at the start
of the stream it may not be valid later in the stream.

3. The stream may have interpolated timestamps, i.e., there is not a
transmitted PTS for every video frame. That means that when we see an
audio PTS, the last video PTS we saw may be from many frames previously,
instead of the last one before our audio PTS.

Note that even when these issues are not present, the delay value may not
be perfectly exact (due to the granularity of audio blocks) and in some
cases it may require tweaking by (for example) up to 16ms (half an AC3
audio block), depending on how sensitive you are to small desyncs.

So what can we do when we get an obviously wrong DELAY value reported? We
have to resort to an empirical process to get things right. For example,
using MPC-HC you can set an audio delay and you can use that feature to
determine the amount by which to tweak if necessary (NUM + [+] / [-] in
10ms steps). Then you adjust the DelayAudio() call appropriately
and off you go with your encoding/muxing. Or you
can just blindly try small adjustments until you are happy. Be aware that
assessing audio sync by observation can be tricky. If the desync is small
it's hard to even be sure whether the audio is late or early. There is an
Avisynth plugin that overlays the audio waveform on the video that you can
use to tweak things exactly by observing a frame with a sudden loud sound.

Following is an example process that uses MPC-HC to tweak and select the
delay. The main thing to note is that the
delay calibration is done by human perception and not any kind of
automated heuristic.

1. Using DGIndexNV demux the video and audio with the desired range. We'll
ignore the reported delay in the audio file. If you need to re-encode the
video, do so now and use that instead.

2. Using mkvtoolnix, mux the video and audio with delay 0 on both the video
and audio tracks.

3. Load the MKV into MPC-HC media player. Repeat play through a good section
for assessing sync while using the NUM + [+] / [-] to adjust the sync.
When you have good sync, write down the value displayed. For my stream
and the selected project range, I obtained a value of -1550.

4. Using mkvtoolnix, again mux the video and audio with delay -1550 on the
audio track. The resulting MKV should play in good sync. When serving
through an Avisynth script, DelayAudio(-1.550) gives good sync.

Note that VLC media player also can be used to tweak the delays, but its
granularity is only 50ms, so MPC-HC is preferred.
DAE avatar
Xunkar
Posts: 36
Joined: Sun Aug 18, 2019 5:17 am

Re: Audio Delay

Post by Xunkar »

That is very thorough, thank you!

Even if it's only informative I find this information useful, and most of the times it has been very accurate (when I was using DGIndex).
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Audio Delay

Post by admin »

:salute:
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: [RESOLVED] Audio Delay

Post by admin »

Released as slipstream 181.
Post Reply