[RESOLVED] Bad delay values for audio demuxed from bluray with a range set

Support forum for DGDecNV
DAE avatar
Guest

[RESOLVED] Bad delay values for audio demuxed from bluray with a range set

Post by Guest »

When using this new feature I tried using the range ability of DGIndexNV, i.e. trim
I demux the audio and subs and save project
The delay that is written in the audio name is off by approximately 500ms, tried two BDs
I read about the offsets but I don't see where the PTS values are or how to use them.
DGIndexNV reports the offset as bytes but the audio delay is reported in ms.
Can someone point me in the right direction
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

Forget about the range numbers in the DGI file. They are not intended to be useful for any aspect of a workflow. They exist only to allow the range configured in the GUI to be re-established when you load a DGI file into DGIndexNV. It simply stores the locations on the navigation bar where the [ and ] have been set. You cannot relate them to PTS values, etc. If you are interested in PTS values, then look into the Log Timestamps setting.

Let's go directly at this. I assume you are loading an MPLS, enabling demuxing of audio and subs, setting a range with [ and ], and then doing Save Project. Then you say that the audio delay of a demuxed audio file is off by 500ms. It's surprising that it would be off by that much, so we should look into it.

First, please explain in detail how are you establishing that it is off by 500ms.

Second, since we are talking about audio, best would be for you to just load the first M2TS (the playlist may contain several). Then set your range, etc. If you can create the issue that way, I will ask you to upload the M2TS to my FTP along with the DGI file (which I can use to recreate your [ and ]).

I am breaking this out to a new thread as it is not a feature request.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

I tested the process of setting a range, etc., with the bluray Ultraviolet. The following 64-bit script plays with acceptable audio sync with MPC-HC:

loadplugin("dgdecodenv.dll")
loadplugin("nicaudio.dll")
vid=dgsource("H:\ULTRAVIOLET\FullDisc\00000086_ULTRAVIOLET\BDMV\STREAM\00012.dgi")
aud=nicac3source("00012 PID 1100 3_2ch 48KHz 640Kbps DELAY -82ms.ac3",2).delayaudio(-0.082)
audiodub(vid,aud)

Note that 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. But it shouldn't be off by 500ms! 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. Then you adjust the DelayAudio() call appropriately and off you go with your encoding. Or you can just blindly try small adjustments until you are happy.

Finally, 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.
DAE avatar
Guest

Re: Bad delay values for audio demuxed from bluray with a range set

Post by Guest »

Thanks for splitting it off
You have my procedure right
After the Save Project I encode the audio and video and remux into MKV
I believe that the audio delay is off by about 500ms because when I watch the final remux the sync is off by about half a second
Note that if I don't use the range [] feature there is no problem
Let me try a straight demux / remux to see if it still happens
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

What is your script and how did you encode, etc? What was the reported delay and how did you correct for it?
Let me try a straight demux / remux to see if it still happens
I don't see how that can help. If you just give me the stream so I can reproduce it, it will be a lot faster than you running experiments with limited knowledge of the internals.
DAE avatar
Guest

Re: Bad delay values for audio demuxed from bluray with a range set

Post by Guest »

Ok, I'll start copying the m2ts to the HDD
Do you want the full M2TS?
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

Yes, please. And the DGI file you made.

Do you still have my FTP details?

I also ask again "What is your script and how did you encode, etc? What was the reported delay and how did you correct for it?"
DAE avatar
Guest

Re: Bad delay values for audio demuxed from bluray with a range set

Post by Guest »

I looked up the FTP details from the PM
The reported delay is -573ms
Encoded using NVEncC
Cmd line is

Code: Select all

"C:\Program Files (Portable)\StaxRip\Apps\NVEnc\NVEncC64.exe" --vbrhq 17500 --codec h265 --preset quality --level 4.1 --gop-len 24 --lookahead 32 --qp-init 1 --vbr-quality 25 --aq --cuda-schedule auto --colormatrix bt709 --colorprim bt709 --transfer bt709 --mv-precision q-pel --cabac -i  -o T:\TEMP\%source_name%_temp\_out.h265
Script is

Code: Select all

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin("C:/Program Files (Portable)/dgdecnv/x64 Binaries/DGDecodeNV.dll")
clip = core.dgdecodenv.DGSource(r'T:\TEMP\00042.dgi', fieldop=0)
clip.set_output()
Audio need not be encoded, just remuxed with the video, encoded or not, into a MKV
00042.dgi
(3.24 MiB) Downloaded 520 times
I'll upload the file first thing in the morning
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

You did not correct for the reported delay!

Normally you do it in your script as I showed using DelayAudio(). If you are not re-encoding the audio then you have to correct it with a tool such as DelayCut. I believe that you may be able to set a delay in MKVMerge when muxing the MKV also, but wouldn't swear to it.

The reported delay is telling you that the two streams will be off by that much if you simply remux them. That's the whole purpose of it. Now you will ask why don't I cut the audio when demuxing it. It's too late this evening to get into that. Suffice to say you MUST correct for the reported delay.
DAE avatar
Guest

Re: Bad delay values for audio demuxed from bluray with a range set

Post by Guest »

Actually, I was going to say that when I use MKVToolNix to remux the streams it sees the delay in the name and corrects for it
I check for that in "Delay (ms)" box with the audio selected
DAE avatar
Guest

Re: Bad delay values for audio demuxed from bluray with a range set

Post by Guest »

It struck me that in both movies I tested the audio delay was stated as being negative.
I did another demux and then changed the reported delay from -573ms to 573ms in the name of the audio file
I then remuxed the video and the renamed audio and it appears to be in sync
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

It's possible I suppose that mkvtoolnix is using a different sign convention or interpretation for the delay value than DGIndexNV and Avisynth. But that would produce a delay of about a full second, not half a second, in your case.

If you want me to continue with this please provide the stream, etc.
DAE avatar
Guest

Re: Bad delay values for audio demuxed from bluray with a range set

Post by Guest »

File is uploading but it will take a while to do the full m2ts
The half second was an estimate from watching, not actually measured
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

OK, thank you.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

How big is that file? It's going very slowly, maybe you can cut it if it is very large. If you do, make sure you keep the beginning of the file intact.
DAE avatar
Guest

Re: Bad delay values for audio demuxed from bluray with a range set

Post by Guest »

About 31GB
I'll try cutting and see if the issue persists
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

OK, you may as well cancel that upload because it's going to take days.

As long as you leave the start intact it should behave the same. Cut a few GB with DGSplit.
DAE avatar
Guest

Re: Bad delay values for audio demuxed from bluray with a range set

Post by Guest »

Actually it would have been don tomorrow afternoon, maybe :wow: :oops:
Already split, tested and uploading, it produces the same negative delay

script

Code: Select all

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin("C:/Program Files (Portable)/dgdecnv/x64 Binaries/DGDecodeNV.dll")
clip = core.dgdecodenv.DGSource(r'I:\test.dgi', fieldop=0)
clip.set_output()
dgi
test.dgi
(167.38 KiB) Downloaded 479 times
If its just a naming convention I can take care of it on my side by renaming the audio file delay
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

Cool, thanks.
gonca wrote:
Sat Jun 16, 2018 11:40 am
If its just a naming convention I can take care of it on my side by renaming the audio file delay
Sure, but if the tools are using different interpretations then we should be really sure of it and document it well. I'd like to confirm your theory as a fact. ;)
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

Which audio stream are you using?
DAE avatar
Guest

Re: Bad delay values for audio demuxed from bluray with a range set

Post by Guest »

The thd one, the first one
But it does it with any or all streams
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

Back from flying from tree to tree.

Something fishy going on. Investigating...
DAE avatar
Guest

Re: Bad delay values for audio demuxed from bluray with a range set

Post by Guest »

Something fishy going on
Shouldn't that be
Something nutty going on
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

Something nutty going on
For sure.

I'm theorizing that the PCR is taking a jump but I have to verify it. I do have a foolproof way for you to get the right delay value but I don't want to tell you until I understand why DGIndexNV is not delivering that. :scratch: DGIndexNV assumes that the PCR is monotonic with no jumps. I do not think it is a simple sign change on the delay value.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: Bad delay values for audio demuxed from bluray with a range set

Post by admin »

I'm going to first explain how to reliably get the correct audio delay, using gonca's case as an example. Then I am going to explain why DGIndexNV can't reliably determine it and what we might do about that.

Here is the process I followed. The main thing to note is that the detection of the delay is done by human perception and not any kind of automated heuristic. gonca, please follow this and report if you get the same results. I'm using 64 bit for everything here.

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 VLC media player. Repeat play through a good section for assessing sync while using the j and k keys to adjust the sync (great feature of VLC). When you have good sync, write down the value displayed. For gonca's 00042.m2ts and the range given in his test.dgi, 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 will play in good sync. Note that the granularity of the VLC tweak is 50ms, so you may want to tweak it further if desired. Also, when I serve things through an Avisynth script, I also find that DelayAudio(-1.550) gives good sync.

Now, why can't DGIndexNV determine the correct value? First, be aware that this delay value reported in the filename is an old hack that derives from the days of DVD program streams (VOBs), where the things I list next were in most cases not applicable. Here are three ways things can go wrong for the delay heuristic (there may be 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. Here is an example from gonca's case. Here is the beginning of the timestamp dump from the full M2TS (not the range):

Code: Select all

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:

Code: Select all

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 because of player buffering).

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.

Now, what do we do about all this? My suggestion is to just ditch delay reporting in the filename for transport streams. We can keep it for program streams because they are usually VOBs where the heuristic is much more effective (although I would be happy to ditch it for everything). And of course add some good explanation in the user manual (or a new document) that explains how to achieve good audio sync for various use cases.

Your thoughts about this will be appreciated.
Post Reply