Ripping Dolby Atmos into MKV

[cipher]

@domy94 Do you know if this is still occuring in v 1.15.2?

It's still occuring in MakeMKV 1.15.3.

I'm surprised. It was greatly rewritten in 1.15.2 with some details being here - https://www.makemkv.com/forum/viewtopic ... 706#p98706
Also, I wonder if MakeMKV does the right job in remux mode (as it is supposed to do) - if you save the track as flac, you should get a sample-level overlap management.

EDIT: I've looked at your code. So,the major difference is that I rely on PES timestamps to figure the duration of audio gap, and you actually decode both segments and optimize on covariance. In a perfect world these should provide identical results, but apparently they are not. Do you have the sample case where 1.15.3 works differently to your tool (is it same MU file that was beaten to death?)

Ironically, even as of now, MakeMKV already fully decodes the frames at boundaries in order to get the exact length of a last short frame. I ought to steal your method...

Mike, it would be great if Domy94's MLP logic, or something similar, was integrated into the MakeMKV codebase as this would take care of those pops that pop up (sorry, couldn't help myself!) every once in a while on TrueHD tracks.

I had previously verified that all the following titles and timestamps posted by domy94 result in a pop/click sound on my UHD rips:

- Finding Nemo (2003) - 1:32:43.5
- Cars (2006) - 0:06:48 (with two minor ones later in the movie, but can't remember anymore)
- Ratatouille (2007) - 1:16:44
- Wreck-It Ralph (2012) - 1:25:27

[VarHD]

I can also confirm a pop on Disney's 4K release of the "Onward" movie. It has 7 sync issues:

AV sync issue in stream 1 at 0:03:18.240 with duration of 1.666ms : 2 frame(s) dropped to reduce audio skew to -0.019ms
AV sync issue in stream 1 at 0:08:14.327 with duration of 1.666ms : 2 frame(s) dropped to reduce audio skew to +0ms
AV sync issue in stream 1 at 0:09:34.991 with duration of 1.666ms : 2 frame(s) dropped to reduce audio skew to -0.016ms
AV sync issue in stream 1 at 0:12:38.800 with duration of 1.666ms : 2 frame(s) dropped to reduce audio skew to -0.019ms
AV sync issue in stream 1 at 0:16:42.001 with duration of 1.666ms : 2 frame(s) dropped to reduce audio skew to +0ms
AV sync issue in stream 1 at 0:22:33.602 with duration of 1.666ms : 2 frame(s) dropped to reduce audio skew to -0.016ms
AV sync issue in stream 1 at 0:26:47.690 with duration of 1.666ms : 2 frame(s) dropped to reduce audio skew to -0.016ms

and the pop happens in the first one at 0:03:18.240. it only happens in the TrueHD track.

[cipher]

Mike, it would be great if Domy94's MLP logic, or something similar, was integrated into the MakeMKV codebase as this would take care of those pops that pop up (sorry, couldn't help myself!) every once in a while on TrueHD tracks.

I had previously verified that all the following titles and timestamps posted by domy94 result in a pop/click sound on my UHD rips:

- Finding Nemo (2003) - 1:32:43.5
- Cars (2006) - 0:06:48 (with two minor ones later in the movie, but can't remember anymore)
- Ratatouille (2007) - 1:16:44
- Wreck-It Ralph (2012) - 1:25:27

I should add one other observation. When I listen to these MKV's on my laptop with headphones, the pop is very prevalent. Interestingly, when I listen to these same MKV's, with those same headphones, via my plex server, the pops are not as loud and sometimes sound more like audio dropouts.

I don't know if my Shield->Denon combo is masking some of the popping sound, but just though I'd mention it for others who come across the issue.

[domy94]

But new Blu-ray players and specifically UHD-Blu-ray players don't seem to have an issue with that anymore. Is there any indication of how they handle this problem? I can't imagine that they rely on heuristics internally?! Wouldn't it theoretically be possible to reverse-engineer e.g. PowerDVD for this specific issue?

That's the big question that is still puzzling me. My current theory is that Dolby's decoder somehow deals with this on the playback side. I also wonder why the disks even have these duplicate audio frames to begin with, like what's the point? Or is it just some quirk of the disk authoring software?

I ought to steal your method...

You're absolutely welcome to. In fact, you'd be doing me a favor; demuxing a disk twice and muxing it back together takes a helluva long time

[karbre]

My current theory is that Dolby's decoder somehow deals with this on the playback side.

You mean the Dolby decoder in, like, an AVR? But then they would be able to handle the MakeMKV-generated Dolby streams without problems as well, no? That's why I believe it must somehow be done within the Blu-ray player.

For instance, it could theoretically be the case that there is a proprietary algorithm that decides based on any bits within the Dolby streams of the single segments which audio frames to drop and which ones to keep. In this case, reverse-engineering an existing (Software-)Blu-ray player would probably be the only way to get it 100% correct.

Then again, what would be the point of such a secret algorithm? It would be a VERY quirky way of implementing copy protection / DRM...

[Krobar]

Has anyone else noticed the issues with the Extremely high bit rate Beatles Atmos in Kodi?
https://github.com/xbmc/xbmc/issues/16704

I wonder if the issue with variable size TrueHD packets will be come more common. Still hoping the Kodi team will fix DD+ 256SPF bitstreaming too but since this mostly affects HDDVDs it probably isn't shiny and new enough to get any attention.

[recordplay]

Has anyone else noticed the issues with the Extremely high bit rate Beatles Atmos in Kodi?
https://github.com/xbmc/xbmc/issues/16704

I wonder if the issue with variable size TrueHD packets will be come more common. Still hoping the Kodi team will fix DD+ 256SPF bitstreaming too but since this mostly affects HDDVDs it probably isn't shiny and new enough to get any attention.

This issue has to do with the way Kodi outputs Dolby TrueHD. Still get a lot of dropouts on movies like Maze Runner: The Death Cure

[jayper]

Folks in this thread might want to look at the release notes for 1.15.4

https://www.makemkv.com/download/

[dontknowjack]

Thanks!
So there shouldn't be any more problems with Atmos tracks, right?
Can someone please confirm this?

I'm holding ripping Disney Blu-rays because of this problem.

[KayakNate]

A post earlier in this thread mentioned that this issue affected all UHDs, but that Disney ones were more susceptible. Can anyone recommend which UHDs we should re-rip now that this is fixed?

All?
Disney and Disney sub studios like Marvel and Lucas?
Just Disney Pixar?

[spl147]

This “FIX” will NOT solve the dropout issue in KODI! KODI’s issue is a hard coded max bitrate value.

Just a FYI

[KayakNate]

I use Plex. The way everything is described here, it sounds like the issue with the ripping of the correct data to not have droppouts was in makemkv. That is what is fixed, the ripping part? right? And works in Plex? I'm just trying to find out what I should re-rip. I havne't watched all the uhds I own and probably need to re-rip some before I do watch them. Just need to know which.

[SamuriHL]

I would definitely start with Disney, especially Pixar. But we've seen other titles like Resident Evil: Apocalypse that has issues, too.

[Rivdoric]

If my assumption is right, the only discs you should re-rip are Atmos discs where movies are split between multiple m2ts parts .
Except Disney & Pixar, i almost never see such discs.

[domy94]

If my assumption is right, the only discs you should re-rip are Atmos discs where movies are split between multiple m2ts parts .
Except Disney & Pixar, i almost never see such discs.

Yes, discs where the whole movie is just one segment don't need to be re-ripped.
You might also see it for movies that have multiple cuts - Gladiator 4K is one such example, but that is DTS:X and not Atmos.