It all comes down to ExoPlayer. I haven’t seen a fix for this issue, but nevertheless, we are once again 4 versions behind.
The seamless branching exoplayer ticket (MKVs from seamless branching blu-rays cause atmos audio drop outs and/or sync loss · Issue #10520 · google/ExoPlayer · GitHub) is still open. It doesn’t appear to be a priority right now.
3 Likes
OK, I just recently bought M3gan on Bluray and used MakeMKV to put on PLEX server as usual. Ripped the extended uncut/extended version.
I was expecting problems given previous comments about this movie so I saved the log from MakeMKV where it does all the frame dropping and audio correction.
I have to say this is the worst movie with the audio problem I have seen so far… terrible to try and watch… after the first audio dropout mentioned after dog fight, there are at least another 7 or 8 dropouts throughout the rest of movie after that.
And the only way I could figure to get audio back in sync was stopping and resuming the entire movie in PLEX… a complete PITA… totally unusable if there was actually anyone else but me alone watching it.
So in summary this Bluray is the “poster-boy” if needed for this issue.
Interesting though that the points corrected in MakeMKV log appear to coincide with the dropouts in movie (eg around 35.33 for dog fight).
2 Likes
Please post on the github posted in this thread, I am not a programmer and dont use git, but the person assigned to this just said we dont consider this an issue with our player, its a problem with the media and looks like they are closing the ticket…
Someone also posted how to fix a title using some obscure remuxer I have never heard of, which was a very bad idea even though they are trying to be helpful, posting a random workaround for a title usually means the programmer assumes there are ways around it and decide not to fix it, I think it was for apocalypse now. He quoted that comment and basically said we dont have any plans to address this problem…
Please note, the ticket has been re-opened. So let’s stay chill. 
After posting there twice, I was working on a third but decided to check on its current status. Glad I did. The third was going to be a bit more. . . stern. 
I see we have that rogue person also following up mentioning to try this and that as work arounds, I know they are trying to be helpful, but having worked for a software company developers see that and think theres a work around, not my problem. I dont know if hes reading this or can private message rather then posting in that github.
They already quoted him as a way to pass the buck. At my old job the ceo got really upset at the developers and that type of attitude, eventually the CEO said customers should not have to jump through hoops to use our software especially when they dont with competing software.
I think thats valid here, unfortunately it looks like its just other dev’s looking at this issue and a user suggesting work arounds. As hurin posted though that program hes suggesting mentions this was fixed in a makemkv version (most of us use that) from 2020…
Yes, only they (who wrote the player) can analyse and tell if a given MKV file has some structural problems or not when being parsed by their player… so its up to them to find out if its
a) a problem with their own player code
b) a problem with MKV produced by MakeMKV itself
But if it was a problem with MKV produced by MakeMKV itself, it would make sense that other players would have similar problem with file also.
To be honest I have no idea why MakeMKV has to do so much fiddling with the audio - a lot of overlapping frames, skews and dropping frames going on, but I’m sure author “mike” knew what he was doing, and this appears to do this with a lot of Bluray rips without causing problems, but its possible it may damage it somehow in this case.
But anyway I just tried playing back the M3gan MKV locally on my Windows 10 PC from the server on some local players…
KMPlayer 2021.02.23.57
Using LAV Filters 0.70.2.0
SMPlayer 22.7.0 rev10091
Using MPV 0.34.0
VLC Player 3.0.18 Vetinari
Windows Media Player 12.0.19041.2788
All were able to get past the first problem point at dog attack around 35mins without audio dropouts. The only program that went out of sync a bit was Windows Media Player when I tried to seek up to just before problem, but when I went back to start and then seeked to a bit further back there was no problem.
Here is details of M3gan MKV in case anyone is interested:
General
Unique ID : xxx
Complete name : \\xxxx\Media 2\Video\MKVs\Bluray\Movie\Individual\M3GAN\M3GAN (2022).mkv
Format : Matroska
Format version : Version 2
File size : 21.8 GiB
Duration : 1 h 41 min
Overall bit rate mode : Variable
Overall bit rate : 30.7 Mb/s
Movie name : M3GAN
Encoded date : UTC 2023-05-07 18:41:53
Writing application : MakeMKV v1.17.3 win(x64-release)
Writing library : libmakemkv v1.17.3 (1.3.10/1.5.2) win(x64-release)
Cover : Yes
Attachments : cover.jpg
Video
ID : 1
ID in the original source medium : 4113 (0x1011)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 2 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 2 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 41 min
Bit rate mode : Variable
Bit rate : 27.7 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.556
Stream size : 19.7 GiB (90%)
Language : English
Default : No
Forced : No
Original source medium : Blu-ray
Audio #1
ID : 2
ID in the original source medium : 4352 (0x1100)
Format : MLP FBA 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Codec ID : A_TRUEHD
Duration : 1 h 41 min
Bit rate mode : Variable
Bit rate : 2 516 kb/s
Maximum bit rate : 3 501 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Stream size : 1.79 GiB (8%)
Title : Surround 7.1
Language : English
Default : Yes
Forced : No
Original source medium : Blu-ray
Number of dynamic objects : 11
Bed channel count : 1 channel
Bed channel configuration : LFE
Audio #2
ID : 3
ID in the original source medium : 4352 (0x1100)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 1 h 41 min
Bit rate mode : Constant
Bit rate : 448 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 326 MiB (1%)
Title : Surround 5.1
Language : English
Service kind : Complete Main
Default : No
Forced : No
Original source medium : Blu-ray
Text
ID : 4
ID in the original source medium : 4608 (0x1200)
Format : PGS
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 1 h 32 min
Bit rate : 54.0 kb/s
Count of elements : 3008
Stream size : 35.8 MiB (0%)
Language : English
Default : No
Forced : No
Original source medium : Blu-ray
Menu
00:00:00.000 : en:Chapter 01
00:03:55.193 : en:Chapter 02
00:10:43.184 : en:Chapter 03
00:14:50.890 : en:Chapter 04
00:19:45.058 : en:Chapter 05
00:24:06.862 : en:Chapter 06
00:28:18.196 : en:Chapter 07
00:33:20.623 : en:Chapter 08
00:39:21.150 : en:Chapter 09
00:45:10.374 : en:Chapter 10
00:50:49.046 : en:Chapter 11
00:57:40.748 : en:Chapter 12
01:01:09.248 : en:Chapter 13
01:05:39.226 : en:Chapter 14
01:09:43.762 : en:Chapter 15
01:15:52.965 : en:Chapter 16
01:18:28.286 : en:Chapter 17
01:21:25.797 : en:Chapter 18
01:29:00.918 : en:Chapter 19
01:33:45.745 : en:Chapter 20
His “workaround” is just an entirely different way of producing the video file from original Bluray disc - decrypt the disc image somehow and then write entire disk file structure to PC, then use this demuxer program to parse it and create a final video file… it basically bypasses MakeMKV completely, but is completely useless here for existing MKVs. This program does not take MKV as source format, it needs original unencrypted disc files.
Just posted this on the github ticket, I hope he takes me up on the invitation!
@dastardo, as you just put it, “unless we can find a player that can deal with the output from MakeMKV”. . . Kodi was apparently modified so that it can play back the cited mkvs without issue (which I intend to test with renewed urgency).
Is it your contention that there is no issue with exoplayer and that the fault lies entirely in “malformed” MKVs? If so, fair enough, nobody can stop you from making that case. However, I’m not sure it’s possible, from (y)our vantage point, to determine which demuxer/transcoder/ripper is doing things correctly vs which ones are simply doing things in such a way that it doesn’t happen to trigger this unfortunate behavior in exoplayer.
If that is not your contention, and you allow for the possibility that exoplayer needs to be improved so that it can play back MKVs ripped from seamless branching blu-rays without issue, may I kindly invite you to join us on the Plex forums where I’m sure many of us would welcome any guides you would like to post to help us work around the issue (ie., rip our blu-rays in such a way that does not trigger this issue) while the investigation over here continues.
It doesn’t seem like this is the proper venue to work around the issue on a disc-by-disc basis using multiple different de/remuxers. And I’m not sure it’s helpful in determining whether the issue is with exoplayer itself or with media that we’re told has been demonstrably mangled.
Well it seems Google/Exoplayer has passed the buck and now blame Dolby code for the problem!
I wouldn’t be surprised if Exoplayer is just calling some Dolby supplied Atmos playback code library (functions or API), and they don’t know how it works or how to fix it either!
But as a programmer, if I wrote a program which only has one job - stream audio and stream video correctly… and it didn’t do one of these right for a major common file format i would be interested to try and figure out why and fix it… but it appears they don’t have pride or ownership of the code over there… or maybe as I said its in Dolby supplied player code and they know nothing about it… seems that way from their reply and closing ticket again.
2 Likes
Thanks for pushing this battle ahead!
After reading the Github issue page, and that dolby forums post, it does sound like they are yet again trying to latch onto anything that lets them not deal with the issue. How can anyone claim Atmos is not supported in mkv? It clearly works when seamless branching is not in play.
Posted on ticket. I fear that we will soon be petitioning plex to swap out their media player for android devices.
@icbaker I can’t find any official specs or documents from Dolby either, as a layperson, describing how to mux Dolby TrueHD Atmos into any containers. Perhaps, as a dev, you can. But in any case, I fail to see the point because a lack of evidence is not evidence of lack.
We know MKV containers can work with Dolby TrueHD, flawlessly. Thousands of people mux Dolby TrueHD into their MKVs daily for playback on their home theater devices. Only exoplayer has trouble with some of them (MKVs derived from seamlessly branched blu-rays).
I hope you will change your mind about your interpretation of an ambiguous forum post by a Dolby rep. While I can appreciate your desire to keep exoplayer "clean"and not modify it to play media that is not “spec-compliant,” we have yet to see any compelling evidence that there is any problem with MKV containers that would render them non-“spec-compliant.”
The number of affected blu-rays is already large (and it is growing). It would be a shame if exoplayer were consigned to a permanent status as an inferior player that will never play those movies back correctly on the best home theater playback device (nvidia shield) for the most popular home theater media player (Plex). Our only hope then would be that Plex would abandon exoplayer.
I regret that the tone of this thread has grown contentious. But I hope you can appreciate that, from our perspective as users (who are helpless to fix this ourselves), all efforts evident from here seems to have been directed at rationalizing why this readily evident issue should not be fixed. Shouldn’t it be demonstrated conclusively that MKV containers are materially non-compliant in some way before it is asserted/assumed that exoplayer is therefore faultless and the issue can be igored?
And, finally, thank you for taking the time to test and reproduce the issue! That does represent progress! I hope you will reconsider your interpretation of the dolby rep’s forum post and help us get this issue resolved.
Thanks!
Thanks everyone.
I might be asking alot even though its not asking much, but is there anyway a plex employee could put some pressure on them to fix this? This no doubt will hurt both companies. I had to switch to another player to play these 4k blu rays.
Considering this was noted more than a year ago and all we’ve gotten is crickets chirping, I don’t think they care too much. I still keep a Plex server up for other devices, but my mainstay device is Plex free and free from this issue. I have more and more extended versions of movies in my collection so the problem with Plex would grow and grow. Damn shame where Plex has headed…
That tool mentioned as a workaround (DGDemux) has the same issue as MakeMKV and tsMuxeR created remuxes when played on Plex’s exoplayer. This isn’t an MKV muxing issue, it’s a TrueHD muxing/demuxing issue.
If you convert a muxed seamless-branched TrueHD track in ffmpeg, you’ll get warnings at the branch points that it’s not lossless at those frames. This sounds like a possible cause of the player mishandling lossless passthrough.
1 Like
Interesting… if the actual audio has format changes in these areas for some reason (buggy metadata?), it could explain why AVRs attempting to play back the stream drop out the audio as they attempt to switch from one audio format to another mid stream.
Posted to exoplayer bug report
Hooked up my kid’s XBox Series X to my home theater receiver in audio passthrough mode, installed Plex on the XBox, and. . . TrueHD/Atmos plays back flawless via MKV files served from the Plex server. Yet another player that does not have this issue.
@icbaker, with respect, please reconsider your opinion that this has something to do with MKV containers. Its only basis appears to be that one post by a Dolby rep stating that their player application won’t play MKV files. That’s not the same thing as stating that Dolby Atmos won’t work in MKV files. And there is lots of circumstantial evidence and examples of other players handling TrueHD/atmos within MKV containers absolutely flawlessly.
Please, there are many people heavily invested in Plex, their Blu-rays, and their home theater that they envisioned being able to playback their files without issue on the Shield. Which is the only device currently out there that will do audio passthrough and playback Dolby Vision without issue (XBox won’t do Dolby Vision reliably).
Again, with respect. exoplayer should be able to play back TrueHD/Atmos from within MKV conatiners, like every other player in its class. It is so close, there’s just this glitch that is within your power to fix.
Thank you for your time and patience!
I’ve been following this topic for a while now and decided to watch The Martian extended edition with Plex HTPC tonight… From beginning to end.
I noticed a tiny glitch in the audio at every seamless branch, like just a tiny drop in audio, but it continued every time and stayed in sync… I didn’t have to correct it once!
I believe Plex HTPC uses mpv…
Although it wasn’t faultless playback, it was more than good enough to not take me out of the movie or force me to make any corrections, and the only reason I noticed it is because I was looking for it.
So yet another confirmation that it is exoplayer that is at fault here.
There is one distinction that needs to be made, IMO. If you “obtained” your copy of a seamless branch movie from one of the major groups, you should not really encounter this anyway. The release notes for those usually say something like “fixed seamless branching by using eac3to” or similar.
1 Like
