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

Support forum for DGDecNV
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.
DAE avatar
Guest

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

Post by Guest »

If I may, another approach
Index and demux from very beginning (start 0)
Do what has to be done (in my case encode)
Remux
Then use MKVToolNix to trim the beginning part
Only needs one quick index (on encoded file, which is quick) to obtain start point for range.

I am good with letting go of delay reporting for transport streams

P.S.
Delay reporting works great for MKV since that is one "big" file, no surprises
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, that can be an alternative as long as you know that your file begins with 0 delay. Not everything does.
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 »

gonca wrote:
Sun Jun 17, 2018 10:45 am
Delay reporting works great for MKV since that is one "big" file, no surprises
Yes, but it's valid only if the MKV file is in sync.

I'm probably going to ditch delay reporting for everything. I want people to use perceptual alignment, not a hacky heuristic with possibly invalid assumptions and prerequisites. Then I can't be blamed for audio desyncs. ;)
DAE avatar
Guest

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

Post by Guest »

Good point
But at the beginning delay reporting is good, no range to bring up the weird stuff
Maybe leave delay reporting in with a note about it in the docs
EDIT
Just read your last post
Yeah, why shoot yourself in the foot?
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 »

Some files do not start with 0 delay! For example, off-air TS captures, or just trimmed TS files.

Someone will have to make a strong case to get me to keep any delay reporting at all. In the modern world there are just too many ways to go wrong with the old DVD-era heuristic. And what developer wouldn't want to simplify his code?
DAE avatar
Guest

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

Post by Guest »

Don't think this is a strong case but MKV delay reporting has worked perfectly fine so far
Either way. I support your decision
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 »

Possibly, but of what use is it?
DAE avatar
Guest

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

Post by Guest »

Until now I extract the mpls as a MKV then trim and index, and demux
Possible future, index and demux and at end remux to MKV and use DGIndexNV to give me the start/end points for trimming
Not a strong argument
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, I see.

With the recent addition of PGS demuxing, I am trying to eliminate the need for going through MakeMKV, but I acknowledge that many people use it, especially as it is (currently) a free solution for ripping.

I'll think through all the ramifications before deciding. Thanks for your valuable input, and for reporting this issue. :salute:
DAE avatar
Guest

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

Post by Guest »

Actually I use MKVToolNix

Take your time to think about it, see if other users have any input, and then its your decision, it is your software that you maintain and improve at no additional costs to the users.
Again, I support whatever your decision will be
Post Reply