Thanks for detailing your method! I've updated the OP in light of your findings.

(2020-09-16, 01:36 AM)schorman Wrote: There's never more than one duplicated frame, and the ripping software should simply drop the first audio frame of each new .m2ts file. 

Ah! In that case, there should be no need for a second pass.  It used to puzzle me that MKVToolNix could handle branching titles successfully in a single pass with no loss of sync.  Now it's clear.  I suppose that a second pass has its place if a stream has gaps (by which, of course, I mean actual gaps (missing information), rather than branch-points).

Thanks for the explanation schorman!

Would you be able to check the output from DGdemux and MPL to evaluate how and if they indeed do it right?

I'll check MPL, but I'm not going to pay for DGdemux just to test it. Am I missing something amazing that it does that other software doesn't?

Edit:

Can DGdemux extract the .thd+ac3 stream, rather than just the thd?

(2020-09-16, 05:39 AM)schorman Wrote: Am I missing something amazing that it does that other software doesn't?

It's intended to be more robust when it comes to branching discs and to handle UHD better than eac3to.  I've had problems with the latter, but I didn't know about the second-pass problems at the time.  When DGDemux was at an early stage of development, the author was kindly giving out free licenses upon request to those offering to test it.  It might be worth sending an e-mail explaining your findings and requesting a license; it never hurts to have options.

I checked the output from mlp.exe with that from CloneBD and they're bit for bit identical. mlp.exe has the speed advantage, because you can demux directly from the .mpls, whereas CloneBD has to be ripped to mkv, then demuxed.


I couldn't get identical output when using the new Useac3to version 1.3. I'm not sure exactly how to integrate and use mlp.exe from within the GUI. Any help with that would be appreciated.

Despite the fact that it was I who posted about MLP and UsEac3to, I haven't yet used either.

schorman,

just to add on what Chewtobacca has already said, I'm no comissioned salesman, but from a user/customer standpoint, it's an effective, simple, frequently updated/upgraded tool with user feedback usually taken into account and incorporated (I've had one of my own incorporated).

What really got me on, was that when seamless branched UHDs like Toy Story 4 and Onward came out, it was the only tool to correctly demux them (video, audio and subtitles included).

Furthermore, you get access to all the other tools from the develper and it's just $15 bucks for lifetime updates (of course, you can also try Chewie's suggeston).

I just decided to donate. I probably would have done it a long time ago, but since I don't have an nvidia graphics card, I never felt the need to. I'll give it a shot once I hear back with the license.
Hopefully it can demux the thd+ac3 streams correctly.

(2020-09-16, 04:09 PM)schorman Wrote: Hopefully it can demux the thd+ac3 streams correctly.

I believe that it does. Is there a particular problem with the thd+ac3 combination in other applications? I thought that eac3to's problem with extracting TrueHD tracks from branching discs affects both thd+ac3 and thd-only streams alike.

Only TSMuxer will do it, but it doesn’t remove overlapping audio. Eac3to can demux either the .thd or the ac3 core, but if you output as .thd+ac3, it reencodes the ac3 part from the lossless track, which is slow, and IMO, not ideal.

I should be able to test DGdecode this evening.