DGDemux development

domy
Moose Approved
Posts: 28
Joined: Fri Mar 20, 2020 10:50 am

Re: DGDemux development

Post by domy » Sat Mar 21, 2020 7:42 am

The software is called Audacity, it's free.

I suppose that begs the question how we define out of sync. I consider "in sync" to be each segment's (.m2ts) raw audio stream, concatenated together with duplicated frames at the tips overlapping, regardless of the video signal. This only holds if we assume that .m2ts files are in sync and that there aren't any duplicated video frames (I'm not sure how to verify the latter). In that case the total length is 1:47:12.635. DGDemux's TrueHD stream duration is 1:47:12.6367. Both are perfectly in sync up until the end of segment #1. By the third segment, DGDemux's output (top track) is 80 samples late - this is 8 seconds before the film ends:

moana-dgdemux-total-sync-annotated.png
moana-dgdemux-total-sync-annotated.png (77.72 KiB) Viewed 1132 times

By that definition, I'd say this is out of sync.

Sidenote: If I count the video frames of the movie, I get a total length of 1:47:12.6345: 154,229 * (24000 / 1001):

Code: Select all

$ ffmpeg -i "Moana.mkv" -map 0:v:0 -c copy -f null -
154,229
If you already have any Disney/Pixar UHD blu-ray, tell me which and I'll most likely find the same issue. I chose Moana for this example because it's only three segments and you can quite easily see the duplicated waveforms. I can also try this with a disc that has many more segments and see how much it accumulates, if you want.

Oh and since I forgot to mention it before, I used DGDemux 1.0.0.20.

User avatar
Rocky
Moose Approved
Posts: 841
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Sat Mar 21, 2020 7:57 am

I define it as audio within 50 ms of the video at all points in the movie. There should be no perceptible async at any point. The desync you show appears to be 1ms if I read the app correctly.

Let's continue with CARS_2 for now (I will buy Moana). I also have TOY_STORY_4_3D. I will get Audacity.

I do not currently do any gaps processing for THD but only for the embedded AC3 (when it is demuxed to a separate file). That is because the THD frames are so short that they do not accumulate to an out of sync condition (per my definition), even for a large number of M2TS files. Nevertheless, I do not rule out doing processing for THD. It may also be possible to combine methods 1 and 2 for gaps correction, and achieve what you call perfect sync.

domy
Moose Approved
Posts: 28
Joined: Fri Mar 20, 2020 10:50 am

Re: DGDemux development

Post by domy » Sun Mar 22, 2020 9:46 am

So I just took a look at Toy Story 4 (US, UHD)'s THD situation. It's a ridiculous disc with 61 segments for the 00800 playlist. All but three segment boundaries have duplicated audio frames. (segments #76-77, #81-82 and #109-110 did not overlap)

Movie length: 143,939 video frames, 1:40:03.4557916666...
THD tracks end-to-end aligned: 288,168,120 samples, 1:40:03.5025
THD tracks aligned with dupe frames overlapping: 288,165,840 samples, 1:40:03.455

So by the end, the audio is 47.5 ms late. That meets your goal of <50 ms, and Toy Story 4 is one of the most segmented UHD blu-rays out there that I know of, so this is definitely an extreme case ...

Until I discovered that Monsters University (US, UHD) has 135 segments, wow. It appears that it suffers from the same issue: the movie is 1:43:48.389, but DGDemux's THD track of that disc is 109ms longer, coming in at 1:43:48.498. After muxing DGDemux's THD and HEVC stream back together, I've measured a 92ms delay (+/- 20ms or so*) at the very end (the pixar lamp scene) against the reference 00160.m2ts. It is noticeable if you know what to look/listen for. This one exceeds the 50ms threshold around midway through the film.

Aside from that:
  • I don't get any pops/cracks during THD playback, unlike with MakeMKV, which is great :)
  • The GUI crashes when selecting a playlist if the disc's path contains a ] (closing square bracket).
(* It's a comparison of 120fps slow-motion recordings taken of the movie overlayed with Windows's volume mixer - kinda jank but works).

User avatar
Rocky
Moose Approved
Posts: 841
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Sun Mar 22, 2020 11:16 am

Thank you, domy, for your test results. That Monsters University is pretty insane with 135 segments. I'm going to have to implement gaps processing for THD. I'll buy the disk and get on it when I finish up HEVC seeking.

Let's calculate: 135 x 0.8ms (size of a THD frame) = 108 milliseconds. That is close to your 92ms and 109ms, so this is theoretically understood and thus fixable.

I have the ] bug fixed locally and will include it in the next slipstream.

Stay safe and well, my friend!

User avatar
Rocky
Moose Approved
Posts: 841
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Tue Mar 24, 2020 10:52 pm

zqslzwzw wrote:
Sat Mar 21, 2020 7:37 am
I would like to report two minor issues of the latest DGDemux 1.0.0.20 with regard to the option 'Do not split THD'.
1) With the latest DGDemux, no matter whether the option is checked, the THD stream(s) will be demuxed.
2) If the option is checked, the language property of the generated .thd file is missed, such as '00800 PID 1100.thd'.
I just noticed this as it got scrolled off. I'll look into it tomorrow. Thank you for your report.

User avatar
Rocky
Moose Approved
Posts: 841
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Thu Mar 26, 2020 8:36 am

zqslzwzw wrote:
Sat Mar 21, 2020 7:37 am
1) With the latest DGDemux, no matter whether the option is checked, the THD stream(s) will be demuxed.
I have duplicated this for do_not_split and have it fixed locally. But I can't duplicate it for when do_not_split is not checked. Can you try that again please?
2) If the option is checked, the language property of the generated .thd file is missed, such as '00800 PID 1100.thd'.
The name should be rewritten after the file is closed (when demuxing finishes) with full info in the name. Is that not happening for you?

User avatar
Rocky
Moose Approved
Posts: 841
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Fri Mar 27, 2020 8:45 am

zqslzwzw hasn't been here for a while so I am going to release the fixes that I have:

* Opening MPLS with [] characters.

* Fix always demuxes THD even when disabled for do not split mode.

The second one also needs to be done for DGIndexNV.

After that, back to DGHDRtoSDR stuff.

User avatar
Bullwinkle
Moose Approved
Posts: 135
Joined: Thu Sep 05, 2019 6:37 pm

Re: DGDemux development

Post by Bullwinkle » Sun Mar 29, 2020 3:05 pm

Rocky wrote:
Sun Mar 22, 2020 11:16 am
That Monsters University is pretty insane with 135 segments.
Still waiting for the disk to arrive. Not an essential product? GTFOOH. STOMP!

User avatar
Rocky
Moose Approved
Posts: 841
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Tue Mar 31, 2020 6:30 am

Monsters disc is here and being ripped right now.

User avatar
Rocky
Moose Approved
Posts: 841
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Tue Mar 31, 2020 10:43 am

@domy

How did you get Audacity to open your thd file? I have Audacity 2.3.3 and ffmpeg 2.2.2, and I have set it in Preferences/Library. But still, when I try to open my thd file, it says cannot and suggests installing ffmpeg.

Audacity log:

11:32:08: File name is D:\tmp\DGDemuxGUI test\00801 PID 1100 48000 8ch eng DELAY 0ms.thd
11:32:08: Mime type is *
11:32:08: Opening with libsndfile
11:32:08: Opening with liboggvorbis
11:32:08: Opening with libflac
11:32:08: Opening with lof
11:32:08: Opening with libav
11:32:15: Error: FFmpeg: avformat_find_stream_info() failed for file D:\tmp\DGDemuxGUI test\00801 PID 1100 48000 8ch eng DELAY 0ms.thd
11:32:15: Error: can't flush file descriptor 5 (error 5: Access is denied.)
11:32:15: Error: Importer::Import: Opening failed.

Note that import of the separate embedded AC3 succeeds. Also, when opening Audacity it shows that ffmpeg was loaded.

Post Reply