ATMOS Audio Drop Outs - Details thread


have you only tried an mkv?

wondering if the raw m2ts also has this issue directly played back on the oppo.

@jmone1 has at least confirmed m2ts has the issue with jriver.


Yup - as posted on the JRiver forum, I rip to folder and found:

  • The 3:16 Drop out Only happens when Bitstreaming and happens in both Title (uses LAV Splitter) and Menu mode (uses Libbluray). Note: Both modes use LAV Audio Renderer.
  • There is No 3:16 Drop out in either Title or Menu mode when Decoding.
  • There is No 3:16 Drop out when using a XBoxOne S to the same Yami AVR
  • Drop outs occurred with both a Yami and Pio AVR.

Given the feedback from others with the issue, the commonality seems to be LAV Audio Renderer (not the Splitter or Decoder). It could also be the HDMI Audio Driver. Seems most of us are nvidia, any AMD/Intel users able to confirm if they have the drop out? (I can test on one of my Intel NUCs)… Anyway, given Hendrik rewrote this no long ago I think we just need to wait to see what he says.


well his reply over at JRiver is a bit discouraging, unless i missed the sarcasm in his response

beyond Incredibles 2 and The Predator, any other movies have this issue?


Run into an interesting correlation with titles experiencing audio dropouts. I recently decided to convert my 4K HDR discs to 1080p SDR as an alternative copy for my media server. I am processing my discs using RipBot264. While running in batch mode I am finding discs being rejected by RipBot as having no audio track (despite the fact that they do). What’s interesting is that the discs being flagged as rejected are ones identified as having dropouts. Thus far I have Baywatch, Cars 3, and Coco as being rejected, but I only recently started this endeavor so I am confident I will find more. Is this a sign of a mastering issue?

UPDATE: So I decided to try a different approach. I did a complete folder rip with DeUHD and then process the files with MKVtoolnix to create a resulting MKV. RipBot did not throw up a flag and encoded the file. So, there must be some issue with MakeMKV causing this. I am going to try and process Pirates which is a notorious offender with this method and see what happens.

UPDATE: Pirates didn’t flag it. So the only correlation I can find so far is that it has something to do with seamless branching titles. I will continue to investigate.


On the discs with issues
have you tried to create a full folder structure with MakeMKV and then extract the movie with MKVToolNix


just out of curiosity, has anyone done a diff comparing the resulting folder rip of makemkv to deuhd? i think we did a long time ago with at least resulting mkv files, but how about the folder rip (excluding the files that each tool creates)?


I haven’t tried from a MakeMKV folder dump yet. I wanted to completely eliminate MakeMKV from the process to see what the result would be. So far, I have processed the three problematic discs using the DeUHD folder and MKVtoolnix trick and it has worked. I’ll give MakeMKV a shot on my next problematic disc.


I tested the following configs last night:

  1. Folder rip with AnyDvdHd
  2. Remux to a single M2ts with DVDFab
  3. Remux to mkv with mkvtoolnix

In all cases I got the same audio drop at the same exact spot when playing with MPC-HC and lav. The same mkv plays with no audio drop via Shield. So I don’t see any issue with Makemkv. The problem seems to be with LAV or another piece of the pipeline used to play it in Windows.


Ripping the entire folder and playing that way will work correctly with problematic Dolby Atmos titles. This has been my workaround to solve the MKV issue with playback on my Oppo 203. Oppo tech support says that they think the issue is how the file is handling seamless branching. The same audio codecs are used regardless of where the source is…disc, USB, network, it’s all the same to the Oppo.

Given that many of these utilities are using the same open source libraries, I wouldn’t be surprised if there was a common piece of code that is causing the problem between MakeMKV, mkvtoolnix and others.


Except, according to Balthazar2k4, DeUHD folder and a MKVToolNIX remux works on the discs he tested.
Also, in past I found that some apps would create a MKV that was practically unusable. Remux with MKVToolNIX solved the issue, this was 1080p sources


To many remuxes


perhaps a red herring but using mkvtosnix i dont ever recall seeing it report audio sync errors and dropping frames. makemkv often reports this

wonder if that combined with seamless branching might play a role

in any case above seems to implicate lav. folder rips also have this issue through jriver media center (lav) based on @jmone1’s experience. given hendrick’s reponse, he does not think he can do anything about it


See my comments above. I removed MakeMKV from the chain and still got exactly the same audio drops on the Incredibles 2. My approach was to rip the full disk via AnyDVDHd and use Mkvtosnix to build the MKV file.

Also @Sevenfeet, looks like there is a difference on behavior between Windows and Oppo when playing with the original folder structure. Using MPC-HC + Lav I still got the same audio drops, even when opening the 800.mpls file directly.


Removed MakeMKV and introduced DVDFab
Rip to folder with AnyDVD, if you must, and then extract with MKVToolNIX to mkv


I did some more testing. Same results regardless of the Ripper (makeMKV, DeUHD, Anydvd). Drop seems to be at some of the Seemless branching points (eg 3:16). Had a look using ffmpeg (as this is the basis of LAV) to remux and it just the main Video & Atmos track. Same Drop out at 3:16 and interstly it thew a bunch of these errors:

3586523. This may result in incorrect timestamps in the output file.
[matroska @ 000002434ebee200] Non-monotonous DTS in output stream 0:1; previous: 3586523, current: 3586515; changing to 3586523. This may result in incorrect timestamps in the output file.


That’s exactly what I did. Ripped to folder with AnyDvdHd. Then, I played with the results in three different ways:

  1. Played it straight from there, by opening the mpls file with MPC-HC. This step eliminates any mixing issues with MKV ir M2ts.

  2. Used Mkvtoolnix to create one MKV using the rip from step #1 above

  3. Used DVDFab to create a M2ts using the rip from #1 above as well. This is to answer the question if MKV was the problem.

In all cases I got the same audio drop. I hope this is clear now.


Interesting @jmone1. Do you know if Exoplayer 2 uses Ffmpeg? Because I can’t reproduce it using Plex on ShieldTv, which is calling Exoplayer 2.


I don’t sorry - I also just tried demuxing with madshi’s eac3to (then remuxing to MKV) - same issue… and then again, eac3to uses libav/ffmpeg as well.


someone at the Lav Doom9 forum reported that the drops stopped after reverting Lav to version 0.71, which is the version before the Atmos fixes for Pirates of the Caribbean and other titles. I haven’t checked it myself yet, but this could mean that the original fix messed up something else.


Hendrik has a new build of lav and says he may have possibly fixed it but will need someone to try lav 0.73.1-1

since i am at the moment in the land down under i won’t have a chance till i am back home later this week.

hopefully someone in this thread can test it