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
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.
aud=nicac3source("00012 PID 1100 3_2ch 48KHz 640Kbps DELAY -82ms.ac3",2).delayaudio(-0.082)
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.
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
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.Let me try a straight demux / remux to see if it still happens
Do you want the full M2TS?
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?"
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
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()
I'll upload the file first thing in the morning
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.
I check for that in "Delay (ms)" box with the audio selected
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
If you want me to continue with this please provide the stream, etc.
The half second was an estimate from watching, not actually measured
I'll try cutting and see if the issue persists
As long as you leave the start intact it should behave the same. Cut a few GB with DGSplit.
Already split, tested and uploading, it produces the same negative delay
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()
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.
But it does it with any or all streams
Something fishy going on. Investigating...
Shouldn't that beSomething fishy going on
Something nutty going on
For sure.Something nutty going on
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. DGIndexNV assumes that the PCR is monotonic with no jumps. I do not think it is a simple sign change on the delay value.
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]
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]
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.