DGDemux development

[Boris]

Rookie mistake, Rocky mistake. Wake up!

[renols]

Hi.

Just did a search on the makemkv forum, and it sounds like 1.15.1 may indeed have some issues.

Like this: https://www.makemkv.com/forum/viewtopic ... ehd#p88167

Having pops at every m2ts change is much worse than maybe being 20 ms out of sync!

Guess we are not the only ones strugling to get this right.

Eventhough I have no technocal knowledge about audio files, I do appreciate you sharing your findings with us.

renols

[Rocky]

I have no technocal knowledge about audio files

You're doing fine, keep it up. And the thread says AC3 tracks are affected too. Doesn't sound good.

I'll know more when my new rip finishes.

Bottom line: I don't think compressed domain processing is going to succeed. But as always, keeping an open mind.

[Rocky]

I confirm the THD does not crash ffmpeg. Here are the truehd.exe outputs.

Raw THD from DGDemux:
59914 major, 7590349 minor, 7650263 total, 6375.219167 duration

THD from MakeMKV:
59884 major, 7590310 minor, 7650194 total, 6375.161667 duration

So far so good. According to the counts, Mike is removing both major and minor frames. But looking at the binary diff I see that sometimes he just deletes a major frame cleanly, but sometimes a major frame is edited by shortening it's length (effectively removing samples) and revising its timestamp and checksum. I haven't looked at what he is doing to minor frames. The changes seem haphazard to me, no rhyme or reason to them. Perhaps he stumbled on something heuristically that satisfies ffmpeg but which is still not kosher with the buffering model. Hence the reported dropouts. I don't have time to play the movie looking for issues, but I trust the reports and they have not been responded to or addressed thus far.

What to do? In the absence of any kind of theoretical understanding or justification for what he is doing, and the reported issues, this doesn't give me warm and fuzzy feelings about this attempt to edit in the compressed domain. So I'm going to keep to my position that compressed domain editing is a non-starter and press on with our solution. It's always good to have options.

Speaking of which, we might as well expand option 3 to allow choice of the following synced formats:

W64
RF64
FLAC

[renols]

Hi.

Having playback with pops in the audio is defenately a no go.

What ffmpeg seems to complain about is some checksum error, but maybe it still wouldn't work if that checksum was somehow
recalculated when the gap fixed thd file was written. eac3to seems to be expecting 00 every time, and receives other numbers and doesn't like it.

The error that eac3to throws, may not even be acurate, because why would the expected checksum be 00 all the time.

So, yeah. The three options one seems to be the safe route to go. Don't think I have used dgindexnv with gap proccessing on anything with seamless branching yet. But of course we must make sure that no audio issues occur at the splits between m2ts files. THD and AC3.

Sorry I pointed to tsmuxer. Looked like it did something during the demuxing, but clearly it doesn't.

renols

[Rocky]

But of course we must make sure that no audio issues occur at the splits between m2ts files. THD and AC3.

That's the key question. domy has mentioned he hasn't seen any issues with our Bresenham-like algorithm in that regard but we'll get it out there and let people bang on it.

I may do some experiments in Audacity to see how many samples need to be lost at once for it to be perceptible. If needed, we can reduce our threshold and thereby get more but smaller cuts. CMD accepts 32000 character command lines.

[Guest]

We could make a stand-alone demuxer that doesn't require an nVidia card.

Your statement on Oct 28, 2019, and 3 days shy of six months later you have the best demuxer going.
Happy 6 month anniversary

[Rocky]

Thanks, but we better wait for feedback and until we get it released before claiming victory.

[domy]

I can confirm that MakeMKV 1.15.1 doesn't exhibit any of the audio pop issues that previous versions did. I filed an issue on that a few months ago, and the Finding Nemo disc doesn't have the audible pop anymore (haven't tested the other discs, but I'm guessing they're good too).

[Rocky]

domy, did you see the discussion above? People are saying the problem is still there. And that it affects other track types as well, not just THD.

https://www.makemkv.com/forum/viewtopic ... ehd#p88167

Also, any comments on the extensive analysis we did over the last two days? Speaking of which, I am tapped out. See y'all tomorrow.

[Bullwinkle]

Ah, yes, Rocky, run along now. I'll take care of business.

[Rocky]

Move over Bullwinkle. I'm back. Wheee.

And I have to tell you, I am back with some exciting new information! It seems that compressed domain deletions will be possible after all. It's a bit of a long story so let me walk y'all through it.

Obviously we are interested in what MakeMKV is doing under the hood. My methodology for doing that until this morning was to binary compare the raw THD file (no deletions) against the MakeMKV THD file. I had made some erroneous conclusions earlier about what the binary diff was showing. That's because a binary diff is not always intelligent about what it shows as diff blocks. For example, consider 3 frames:

A
B
C

and one file has B cleanly removed. When we diff them we want to see one diff block with B removed. However, if there is some common content between A and C, then instead of showing a clean deletion of B it will show all the little diffs between A and C. Pain in the ass! I could not find a diff tool that minimizes the number of diff blocks, which would show clean frame deletions. Hope that's clear. The file binary diff method is not useful for reverse engineering here, strange as that sounds. We need a new method to reverse engineer.

So I revised my truehd tool to print some stuff at each frame. It prints +/- for major or minor frame, the input_time, and a * if the frame is major and the previous frame was major (a double major). Here is an example from the raw THD:

...
- 33241
- 33267
- 33293
- 33320
- 33360
+ 35159
+ 35200 *
- 35240
- 35280
- 35320
- 35360
- 35400
- 35440
- 35480
...

It's clear this will be very useful if we compare the listing for raw versus MakeMKV. Before discussing what that shows, first an important preliminary point. For this disk there are 74 M2TS files and thus 73 gaps. Looking at the trace for the raw THD I see that there is a one-to-one correspondence between a gap and a double major. Nice. This suggests that we might want to delete one of the majors at each double (note that this is different from both EAC3TO's strategy of looking for duplicate frames, and our Bresenham algorithm). What is MakeMKV actually doing here? Instead of having 73 simple one-frame deletions, one of three things is done at each gap=double:

1. Nothing is done, i.e., no deletion is made.

2. The first major of the double is deleted together with the previous minor.

3. Just the minor preceding the double is removed.

It's not clear why MakeMKV doesn't just delete the first major of every double. I'm looking to see if there is a pattern to that, possibly based on the times of the two majors and the preceding minor. Nothing screams out to me as I look that over
but further study may reveal something. Nevertheless, even before concluding on that we see that MakeMKV's behavior does offer two keys about how to delete frames without slagging off ffmpeg.

A. If a minor is deleted it must be the last minor in the "GOP", i.e., the one just before a major.

B. If a major is deleted it must be one of the majors in a double. MakeMKV always deletes the first one in the double.

A poster at the MakeMKV forum (thread linked earlier) had pointed out that MakeMKV seemed to sometimes not delete a frame at some gaps and then delete 2 at others. So this analysis confirms that but I add that sometimes it deletes 1 frame at a gap (the minor before the double, number 3 above).

Finally, I verified that MakeMKV is simply deleting frames. It does not modify frames in any way, such as changing timestamps.

Sweet! Now I will fly off and experiment with this. I am extremely hopeful that this effort will yield an in-sync stream that satisfies ffmpeg. And hopefully others trying to solve the seamless branching puzzle will find the information useful.

Wheee.

[Bullwinkle]

[Rocky]

When domy didn't reply I knew there must be something wrong with my previous analysis. It is crucial to keep domy happy.

[renols]

Hi.

Thanks you very much for the detailed explanation.

As written earlier I don't know much about the technical stuff when it comes to audio, but I have found the thd spec and looked at it a bit.

Could it be that each m2ts file actually contains its own thd file?

According to the spec it shouldn't really be allowed to have two Majors after each other, other than at the start of the thd file.

See point 5.1 of the spec.

It also states that the maximum access units between Majors is 128, and the minimum is 8 access units.

I guess this means that each time you have two Majors after each other, that actually represents the start of a new thd file (since that is only allowed at the start of a thd file)?

Since we create a new thd file, I guess removing one of the Majors actually makes it within spec, since having two Majors following each other will break the spec.

Maybe I am way off in deep water here, since it is nothing I work with normally. But chapter 5.1 seems pretty clear, as to how many and how often Majors are allowed.

Seems to me like we actually have 74 seperate thd files, and when we stich them together into one file, we actually break the spec, by having two Majors following each other.

Just a thought. Maybe a stupid one, but still a thought

renols

[Rocky]

Yes, I also have the spec and am aware of these things. You're doing pretty good for someone that doesn't know much about the technical stuff.

Obviously, as I suggested, the first thing I will try is simply removing the first major of each double.

[domy]

That's a very insightful look into MakeMKV's behavior, Rocky. Thanks for that! I've got a couple clarifications/questions:

• What disc was that, with the 74 segments?
• Each THD bitstream ends with a major sync? I would not have expected that, since it makes very little sense to me - players don't need to start decoding at the end of a THD bitstream ...
• If the answer to the previous question is yes: The final major sync of bitstream A and the first major sync of bitstream B (where B.m2ts follows A.m2ts) don't have the same input_timing value? Does B's first major sync's input_timing not start at 0?

[Rocky]

What disc was that, with the 74 segments?

CARS_2 00800.mpls.

Each THD bitstream ends with a major sync?

Each stream meaning each M2TS. The doubles come at the gaps, so presumably there is a major at the start and end of each M2TS, although I didn't check that. So I suppose the answer is yes. I could verify it if needed.

If the answer to the previous question is yes: The final major sync of bitstream A and the first major sync of bitstream B (where B.m2ts follows A.m2ts) don't have the same input_timing value? Does B's first major sync's input_timing not start at 0?

For all double majors, they have different timestamps and not 0. Even the first M2TS does not start with a 0.

[Rocky]

First experiment completed. It was easier to delete the second major frame of each double because lookahead is not required. Sadly, this crashes ffmpeg even though the stream plays in sync in the players.

Next experiment, delete the first major frame of each double. Then try the last minor before each double.

Hmm, I wonder if Mike had to go through this same process.

[Rocky]

Oh Happy Day!

My second experiment was completely successful. If I delete the first of the majors in a double then the result is an in-sync THD file that can be transcoded to FLAC by ffmpeg without errors. It makes sense that it would work for two reasons:

1. It's just clipping off the last frame (a major) in the M2TS.

2. The buffering in a GOP will be associated with the first major of the GOP, which is the second major of the double.

I do not know why MakeMKV is doing the strange deletions that it does. Perhaps that accounts for the remaining issues that have been reported.

Next step is to implement this strategy in DGDemux/DGIndexNV (testing was done with a modified truehd.exe). We're not going to need any options at all. Tomorrow is another day. domy will be happy. When domy is happy, I am happy.

[Natasha]

Even a blind squirrel occasionally finds an acorn. Hopefully, it's a rotten one.

[Curly]

You're such a douche, Natasha. Or maybe you need one. Nyuk nyuk.

Bravo, Rocky!

[Bullwinkle]

Jeez Louise. Step away for a while to help Sherman and look what happens. My brilliant uncompressed domain editing is superfluous? Horrors!

Way to go, Rock!

[Rocky]

Thanks, guys. Gonna lie in bed with some Absolut and watch Matilda again (haven't seen it for a long time). Been a long day.

[Natasha]

Boris! Where are you? Forget moose and squirrel for now. We have to off this curly guy.