DGDemux development
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Re: DGDemux development
Miss Natasha said never to take any crap from anybody. Offense is the best defense. Sharp chick!!
Re: DGDemux development
Bullwinkle, if you want to be a moderator you can't threaten to stomp the site admin. That vampire is making you stupid. Look what happened to Prince Harry. Wake up!
Sherman Peabody
Director of Linux Development
Director of Linux Development
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Re: DGDemux development
Good thinking Sherman! Now watch me put a pancake on a bunny's head...
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Re: DGDemux development
And Rock, don't forget to make the 'M2TS list' and 'Command line' fields multiline so the whole lines are visible. And change the Error field to Status and use it to talk to the user. Could have speech and sound. Moose snorting, what's not to like?
Re: DGDemux development
Wheee!!!
Re: DGDemux development
Build 18 is nice. You are fine squirrel. Will put peanuts out for you. Stay warm!
Re: DGDemux development
18 is nice, but i cant find changelog. (maybe is it possible to make changelog.txt file?) And a little bug there. Left click on empty Playlist area reloads playlists.
- Attachments
-
- Video_2020-01-22_231333-2020-01-22.zip
- (533.93 KiB) Downloaded 630 times
Re: DGDemux development
We've transitioned to using the Binaries Notification thread to document changes.
viewtopic.php?f=5&t=463&p=10696#p10696
Your bug...is it so terrible?
viewtopic.php?f=5&t=463&p=10696#p10696
Your bug...is it so terrible?
Re: DGDemux development
I'll see if it is easy to fix.
Re: DGDemux development
It was easy. Next build.
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Re: DGDemux development
Rocky, Sherman told me Natasha is like a mosquito. It's not her fault.
- Mr. Peabody
- Posts: 46
- Joined: Tue Dec 24, 2019 9:20 am
Re: DGDemux development
Give a little, get a little, but do not give away your soul.
Re: DGDemux development
You guys are too deep for me.
Re: DGDemux development
DGDemux works fine for me on Wine stable (installed after adding the WineHQ and Wine OBS repos) on Debian 10. Both GUI...
...and CLI (following the example given in DGDemux.txt)...
...versions work fine. I didn't have to use winepath or anything like that. So far, I have tested one UHD BD and one standard BD. Thanks for making this tool!
Code: Select all
wine DGDemuxGUI.exe
Code: Select all
wine DGDemux.exe -i filepath/BDMV/PLAYLIST/filename.mpls -o ~/Videos/whatever
Re: DGDemux development
Thank you RGB! It's great to hear that things are working under Wine. Takes a little pressure off to make a native Linux version.
Re: DGDemux development
Hi,
I've noticed an issue with duplicated audio frames in the Dolby TrueHD stream. This is the Moana US UHD blu-ray, and playlist 00800 consists of the segments 55,59,61. The TrueHD audio frames between segments 55 and 59 are duplicated: (same between 59 and 61, but this one's easier to see)
There's two issues I see with that: (1) This introduces a +40 samples (.083ms) delay on every such boundary, and (2) in some situations this could result in an audible crack/pop/whatever. Of course the delay itself isn't noticeable at all on its own, but with movies like Toy Story 4 (which has 60-some segments) it could be significantly out-of-sync by the end of it. I'd also argue that in the pursuit of perfection, there should be a 0ms delay throughout
Every Disney/Pixar film I've analyzed so far (Brave, Frozen, Frozen II, Moana, and more) has these overlapping audio frames at the segment boundaries.
MakeMKV has the same issue and CloneBD does too (among other things), which makes me wonder if this is even fixable. But I thought you should know about it.
I've noticed an issue with duplicated audio frames in the Dolby TrueHD stream. This is the Moana US UHD blu-ray, and playlist 00800 consists of the segments 55,59,61. The TrueHD audio frames between segments 55 and 59 are duplicated: (same between 59 and 61, but this one's easier to see)
- The top track is remuxed with DGDemux from the BD.
Code: Select all
DGDemux -i "BDMV\PLAYLIST\00800.mpls" -o "moana-dgdemux-00800" -demux 1100 eac3to moana-dgdemux-00800.thd moana-dgdemux-00800.flac -mono
- The second track is the TrueHD stream from 55.m2ts, which is the first segment of the film.
Code: Select all
eac3to "BDMV\STREAM\00055.m2ts" 2: 1_55.flac -mono
- The third track is the TrueHD stream from 59.m2ts, which is the second segment of the film.
Code: Select all
eac3to "BDMV\STREAM\00059.m2ts" 2: 2_59.flac -mono
There's two issues I see with that: (1) This introduces a +40 samples (.083ms) delay on every such boundary, and (2) in some situations this could result in an audible crack/pop/whatever. Of course the delay itself isn't noticeable at all on its own, but with movies like Toy Story 4 (which has 60-some segments) it could be significantly out-of-sync by the end of it. I'd also argue that in the pursuit of perfection, there should be a 0ms delay throughout
Every Disney/Pixar film I've analyzed so far (Brave, Frozen, Frozen II, Moana, and more) has these overlapping audio frames at the segment boundaries.
MakeMKV has the same issue and CloneBD does too (among other things), which makes me wonder if this is even fixable. But I thought you should know about it.
Re: DGDemux development
Thank you for your report, domy, and welcome to the forum!
There are two approaches for dealing with file gaps: 1) delete duplicate frames at the gaps, and 2) do a Bresenham-like algorithm just deleting frames as needed. Method 1 was working for most blurays but is now failing for UHD titles. Method 2 was working correctly for the UHD titles. Yes, the duplicates are not touched but there should be good audio sync throughout. DGDemux uses method 2. You speculate that audio sync could be off but have you actually tested it? If you report any audio sync issue I will buy the disk and investigate, but I am not planning to do anything regarding duplicate frames (could change depending on what we see in the wild).
There are two approaches for dealing with file gaps: 1) delete duplicate frames at the gaps, and 2) do a Bresenham-like algorithm just deleting frames as needed. Method 1 was working for most blurays but is now failing for UHD titles. Method 2 was working correctly for the UHD titles. Yes, the duplicates are not touched but there should be good audio sync throughout. DGDemux uses method 2. You speculate that audio sync could be off but have you actually tested it? If you report any audio sync issue I will buy the disk and investigate, but I am not planning to do anything regarding duplicate frames (could change depending on what we see in the wild).
Re: DGDemux development
Hey domy, what application did you use for the screenshot above? I'm going to look deeper into all this.
Re: DGDemux development
Hi,
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 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'.
Re: DGDemux development
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:
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):
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.
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:
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
Oh and since I forgot to mention it before, I used DGDemux 1.0.0.20.
Re: DGDemux development
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.
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.
Re: DGDemux development
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:
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).
Re: DGDemux development
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!
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!
Re: DGDemux development
I just noticed this as it got scrolled off. I'll look into it tomorrow. Thank you for your report.zqslzwzw wrote: ↑Sat Mar 21, 2020 7:37 amI 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'.