DGDemux development

User avatar
Rocky
Posts: 335
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Tue Dec 03, 2019 11:30 am

Here is version 1.0.0.10:

* Fixed demuxing of DTS-HDHR streams.

* Fixed GUI corruption after canceling 'browse output' operation.

http://rationalqm.us/dgdemux/DGDemux_1.0.0.10.rar

User avatar
redbtn
Posts: 40
Joined: Sat Nov 16, 2019 3:35 pm

Re: DGDemux development

Post by redbtn » Tue Dec 03, 2019 12:47 pm

Rocky wrote:
Tue Dec 03, 2019 9:43 am
Thanks, redbtn, for pointing that out.

I really need to know which MPLS you used for that 10ms thing.
00847.mpls. Sorry for late reply, I was afk

User avatar
Rocky
Posts: 335
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Tue Dec 03, 2019 1:18 pm

redbtn wrote:
Tue Dec 03, 2019 12:47 pm
00847.mpls. Sorry for late reply, I was afk
Please say disk title, MPLS, and your problem description in one post. There's no time to go searching back across multiple forums to try to piece things together. Thank you for your understanding.

User avatar
Bullwinkle
Posts: 67
Joined: Thu Sep 05, 2019 6:37 pm

Re: DGDemux development

Post by Bullwinkle » Tue Dec 03, 2019 1:19 pm

Even Rocky has limits!

User avatar
redbtn
Posts: 40
Joined: Sat Nov 16, 2019 3:35 pm

Re: DGDemux development

Post by redbtn » Tue Dec 03, 2019 6:32 pm

Rocky wrote:
Tue Dec 03, 2019 1:18 pm
redbtn wrote:
Tue Dec 03, 2019 12:47 pm
00847.mpls. Sorry for late reply, I was afk
Please say disk title, MPLS, and your problem description in one post. There's no time to go searching back across multiple forums to try to piece things together. Thank you for your understanding.
Iron man 2, mpls 00847. DTS-MA track.
Before 1.54.34.500 it perfect, after has shift +10ms. I guess there is place where last m2ts starts. Maybe there are 2 identical frames and 1 should be deleted, but for some reason it wasn't.I fail to find duplicate frame, but there starts difference +10ms (vs eac3to), and stream length is +10ms vs BDInfo information. I'm not 100% sure that it's issue, but if you look at it, it will be great.

User avatar
Rocky
Posts: 335
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Tue Dec 03, 2019 9:03 pm

Great report, redbtn. Thank you. Now I can get on it tomorrow.

zqslzwzw
Posts: 17
Joined: Fri Nov 29, 2019 9:35 am

Re: DGDemux development

Post by zqslzwzw » Wed Dec 04, 2019 3:41 am

redbtn wrote:
Tue Dec 03, 2019 6:32 pm
Iron man 2, mpls 00847. DTS-MA track.
Before 1.54.34.500 it perfect, after has shift +10ms. I guess there is place where last m2ts starts. Maybe there are 2 identical frames and 1 should be deleted, but for some reason it wasn't.I fail to find duplicate frame, but there starts difference +10ms (vs eac3to), and stream length is +10ms vs BDInfo information. I'm not 100% sure that it's issue, but if you look at it, it will be great.
How to get the duration of a BD disk so precisely by BDInfo or other tools? I also tried BDInfo 0.7.5.5 (GUI), however it reports the duration as hh:mm:ss without the precision of milliseconds.

User avatar
Rocky
Posts: 335
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Wed Dec 04, 2019 10:55 am

redbtn wrote:
Tue Dec 03, 2019 6:32 pm
Iron man 2, mpls 00847. DTS-MA track.
Before 1.54.34.500 it perfect, after has shift +10ms. I guess there is place where last m2ts starts. Maybe there are 2 identical frames and 1 should be deleted, but for some reason it wasn't.I fail to find duplicate frame, but there starts difference +10ms (vs eac3to), and stream length is +10ms vs BDInfo information. I'm not 100% sure that it's issue, but if you look at it, it will be great.
1.54.34.500 is the time at which the gap between the last two M2TS files occurs. At each gap, processing is done to see what adjustments are necessary. In this case at that gap, DGDemux sees an accumulated desync that is below the threshold (approx. 5ms for DTS HDMA) for requiring correction. Therefore, no audio frames are deleted or added at this gap. AV sync during the last M2TS appears spot on to me when playing an MKV made from the demuxed files in MPC-HC.

So, it appears that eac3to deletes a frame at this point and DGDemux does not. As I have mentioned several times, DGDemux and eac3to use completely different algorithms to decide when to delete audio frames. The decision at each gap will depend on what has been done at all the previous gaps.

Bottom line is I don't see a problem here.

User avatar
redbtn
Posts: 40
Joined: Sat Nov 16, 2019 3:35 pm

Re: DGDemux development

Post by redbtn » Wed Dec 04, 2019 11:23 am

Rocky wrote:
Wed Dec 04, 2019 10:55 am
1.54.34.500 is the time at which the gap between the last two M2TS files occurs. At each gap, processing is done to see what adjustments are necessary. In this case at that gap, DGDemux sees an accumulated desync that is below the threshold (approx. 5ms for DTS HDMA) for requiring correction. Therefore, no audio frames are deleted or added at this gap. AV sync during the last M2TS appears spot on to me when playing an MKV made from the demuxed files in MPC-HC.

So, it appears that eac3to deletes a frame at this point and DGDemux does not. As I have mentioned several times, DGDemux and eac3to use completely different algorithms to decide when to delete audio frames. The decision at each gap will depend on what has been done at all the previous gaps.

Bottom line is I don't see a problem here.
Thanks for investigating! DGDemux is smarter than eac3to, even on non UHD BDs, it's good! So, it seems I have no issues for now anymore. I'll check UHD seamless disks if I find them. But it will be much harder to find bugs.
Thank you for your hard work!
zqslzwzw wrote:
Wed Dec 04, 2019 3:41 am
How to get the duration of a BD disk so precisely by BDInfo or other tools? I also tried BDInfo 0.7.5.5 (GUI), however it reports the duration as hh:mm:ss without the precision of milliseconds.
Image

User avatar
Rocky
Posts: 335
Joined: Fri Sep 06, 2019 12:57 pm

Re: DGDemux development

Post by Rocky » Wed Dec 04, 2019 11:35 am

Great to hear, redbtn. You've been really helpful in DGDemux development.

Ah, that BDInfo report feature. I never noticed that before. Cool!

Post Reply