Which is why I have an issue open with CloneBD to look at because I TRULY believe it's a problem with shoving the seamless branching streams into an MKV container. All the ripping tools show the same issue when putting it in an MKV.

Which is why I have an issue open with CloneBD to look at because I TRULY believe it's a problem with shoving the seamless branching streams into an MKV container. All the ripping tools show the same issue when putting it in an MKV.

chapterEditor can mux seamless branching Blu-rays to mkv, with the help of eac3to.

Seems to work fine here. What version of LAV are you using? Are you using both LAV Splitter and LAV Video? Are you using software or hardware decoding? If hardware: what GPU/OS, what kind of hardware decoding?

Make sure you watch from the beginning. Most of us see an audio drop around the 3:17 mark, but not if you just skip to somewhere close to it (which could give a clue to what is causing it - a buffer issue?)

chapterEditor can mux seamless branching Blu-rays to mkv, with the help of eac3to.

Sure, all the tools can handle seamless branching. That isn't what I meant. I'm saying that for the Incredibles 2 UHD, there seems to be an issue with any of the tools muxing that into an MKV container where the ATMOS audio track gets corrupted. It seems like an issue with how the seamless branching is handled with that particular title.

I want to update here as I've already posted on the JRiver MC forum. The ripping tool I use updated today with a fix for ATMOS sub-types. So I re-ripped Incredibles 2 MKV. LAV is still having audio drops and eventually the audio completely drops out. Playing the same file on my SHIELD shows no audio drops at all. Hopefully Nev can nail this one down and find the issue.

I want to update here as I've already posted on the JRiver MC forum. The ripping tool I use updated today with a fix for ATMOS sub-types. So I re-ripped Incredibles 2 MKV. LAV is still having audio drops and eventually the audio completely drops out. Playing the same file on my SHIELD shows no audio drops at all. Hopefully Nev can nail this one down and find the issue.

---------------------------
Audio Detection Mismatch
---------------------------
The audio type determined from reading the PAT/PMT program information (AC3)
does not match the detected audio (MPA). In many cases, this is caused by emulation
of audio headers (false detection) and the PAT/PMT type is the correct type.
Hit Yes to use the PAT/PMT type. Hit No to use the detected type. Hit Cancel to disable this stream.
---------------------------

Sounds like there is in fact MPEG Audio in a stream multiplexed as if it was AC-3. But neither mode produces a sensible demultiplexed audio stream.

This would be very weird and uncommon:
I have never heard of any SAT broadcasts transmitting AVC video with MPA (MP2) audio. FOR SD broadcasts it is MPEG2 video with either MPA or AC3 audio, for HD broadcasts it is AVC video with AC3 audio.