Ripping Dolby Atmos into MKV

[WilliamG]

How do you guys get the dropouts? Where in Frozen II using what player?

Dolby Atmos enabled, during “Into The Unknown” song. Using any Kodi-based player, basically (minus original disc of course).

[spl147]

How do you guys get the dropouts? Where in Frozen II using what player?

Dolby Atmos enabled, during “Into The Unknown” song. Using any Kodi-based player, basically (minus original disc of course).

Yep

[cipher]

That is the same location of "fixed position" dropouts that one or more of Exoplayer/Shield updates fixed. It looks like the Kodi devs haven't addressed this in their player yet.

[Fearless Leader]

I have the same problem with Frozen II during the "Into the Unknown" song. I don't know the exact time it happens, but it occurs when the background is all black and Elsa is doing the various designs with particle effects. I think it happens right around when Elsa makes particles that take the shape of the giants, close but not exactly when it happens.

I'm using Kodi 18 (Leia) on nvidia Shield, however I see the same problem at the exact same point in VLC on nvidia shield as well. So this can't be just a Kodi problem, if VLC has it too.

I'm using a 1Gb connection to a local server, though Kodi has given warnings that the connection is too slow, which is odd since no buffering occurs and the fact that it is a 1Gb connection.

I ripped the folders using MakeMkv and used mkvtoolnix 48.0 "Fortress around your heart" to handle 00800.mpls to create the mkv file.

That is what I've tried. I haven't tried eac3to for this problem.

I also wonder if this is a problem with how the mkv file is constructed. Perhaps segments need to be closer together. I may try mkclean, to see if it can optimize the file.
So eac3to and mkclean are my next attempts.

[cipher]

I have the same problem with Frozen II during the "Into the Unknown" song. I don't know the exact time it happens, but it occurs when the background is all black and Elsa is doing the various designs with particle effects. I think it happens right around when Elsa makes particles that take the shape of the giants, close but not exactly when it happens.

I'm using Kodi 18 (Leia) on nvidia Shield, however I see the same problem at the exact same point in VLC on nvidia shield as well. So this can't be just a Kodi problem, if VLC has it too.

I'm using a 1Gb connection to a local server, though Kodi has given warnings that the connection is too slow, which is odd since no buffering occurs and the fact that it is a 1Gb connection.

I ripped the folders using MakeMkv and used mkvtoolnix 48.0 "Fortress around your heart" to handle 00800.mpls to create the mkv file.

That is what I've tried. I haven't tried eac3to for this problem.

I also wonder if this is a problem with how the mkv file is constructed. Perhaps segments need to be closer together. I may try mkclean, to see if it can optimize the file.
So eac3to and mkclean are my next attempts.

Hi Fearless leader. It may help to understand what's happening here if you read my long post from a few pages back as I go into detail on the various contributing factors for the audio dropouts - viewtopic.php?f=12&t=17597&start=120#p88884

The dropout you're describing above is from specific scenes in Frozen 2 that are repeatable. These were actually some of my goto points for testing and I had this issue until NVidia released a hotfix update for my Shield 2017. Once I installed that update, the dropouts in all the repeatable scenes (eg Frozen, Toy Story 4, Zootopia etc) went away. Now, the big difference for me compared to your setup is that I use Plex on my Shield. At the time I wrote that summary Kodi hadn't addressed those dropouts and I can't say if they have as of today.

[Fearless Leader]

Hi Fearless leader. It may help to understand what's happening here if you read my long post from a few pages back as I go into detail on the various contributing factors for the audio dropouts - viewtopic.php?f=12&t=17597&start=120#p88884

The dropout you're describing above is from specific scenes in Frozen 2 that are repeatable. These were actually some of my goto points for testing and I had this issue until NVidia released a hotfix update for my Shield 2017. Once I installed that update, the dropouts in all the repeatable scenes (eg Frozen, Toy Story 4, Zootopia etc) went away. Now, the big difference for me compared to your setup is that I use Plex on my Shield. At the time I wrote that summary Kodi hadn't addressed those dropouts and I can't say if they have as of today.

HI cipher,

I will wait for the hotfix, but in truth, I don't think it will solve it from new evidence I've seen.

I tried mkclean, which obviously didn't solve the problem.
I ran eac3to -demux, which failed likely because it couldn't handle dolby atmos.
However, when I run eac3to -check, I see six places where the truehd lossless check failed, where the expected value was zero and the actual value was non-zero.

This has happened before with Disney discs Finding Nemo and Brave back in the early days of Blu-ray, and it had the same symptoms (audio-drop outs at very specific spots).
I suspect it is the same issue.

[cipher]

HI cipher,

I will wait for the hotfix, but in truth, I don't think it will solve it from new evidence I've seen.

For Shield owners running native Shield apps and the native Plex client this "fixed position dropout" issue was resolved a few months back. For example, Shield2019 users had this fixed in v8.1.1, while Shield2017 users had this fixed in v8.0.2 3rd Hotfix (note: this version is still in beta, I think they are up to hotfix 5 now, so Shield2017 users still have to request this Beta update to get it on their Shield hardware). I've experienced this issue with 5 Disney UHD titles on both my 2017 and 2019 versions of the Shield. Before the fixes I had to default the audio for my daughter to the DD 5.1 track. After the updates, she can now watch these titles with the full Dolby Atmos/TrueHD tracks engaged.

For those running other software clients like Kodi, the developers on those platforms also need to update their software. As NVidia mentioned in their release notes: "This fix will apply to apps using SHIELDs audio engine like -Plex/Photos & Videos. Kodi has its own engine which has not fixed this bug yet so the fix will not apply to Kodi and apps like it.". The easiest way to hear this difference would be to run a native app on the Shield and you should see those fixed position audio dropouts no longer show up.

Also, I don't keep up on Kodi issues/development, but here's a recent post from a couple of days ago discussing the dropout issue - https://forum.kodi.tv/showthread.php?ti ... pid2961189

The other item to keep in mind is there has been so much trouble getting Dolby Atmos/TrueHD to rip correctly and work on various hardware/software platforms that you also need to ensure you are using the latest version of all the platforms. Even the latest version of MakeMKV (1.1.15) had a note on TrueHD fixes so if you've got an old file causing issues even after updating all you firmware/software layers it wouldn't hurt to re-rip any problematic titles.

Now, do I think all Atmos/TrueHD ripping/playback issues have been solved? No, I don't think we're there yet and in fact just last month I read that NVidia were still working with Plex on some Dolby issues. However, I'm hoping all the software rippers/players will have this resolved soon so that were guaranteed to get 100% accurate audio rips and 100% accurate playback. For the time being though, most people who have updated their systems and are playing clients like Plex are not experiencing the issues that have been reported for the past year and a half.

[Fearless Leader]

For Shield owners running native Shield apps and the native Plex client this "fixed position dropout" issue was resolved a few months back. For example, Shield2019 users had this fixed in v8.1.1, while Shield2017 users had this fixed in v8.0.2 3rd Hotfix (note: this version is still in beta, I think they are up to hotfix 5 now, so Shield2017 users still have to request this Beta update to get it on their Shield hardware). I've experienced this issue with 5 Disney UHD titles on both my 2017 and 2019 versions of the Shield. Before the fixes I had to default the audio for my daughter to the DD 5.1 track. After the updates, she can now watch these titles with the full Dolby Atmos/TrueHD tracks engaged.

For those running other software clients like Kodi, the developers on those platforms also need to update their software. As NVidia mentioned in their release notes: "This fix will apply to apps using SHIELDs audio engine like -Plex/Photos & Videos. Kodi has its own engine which has not fixed this bug yet so the fix will not apply to Kodi and apps like it.". The easiest way to hear this difference would be to run a native app on the Shield and you should see those fixed position audio dropouts no longer show up.

Also, I don't keep up on Kodi issues/development, but here's a recent post from a couple of days ago discussing the dropout issue - https://forum.kodi.tv/showthread.php?ti ... pid2961189

The other item to keep in mind is there has been so much trouble getting Dolby Atmos/TrueHD to rip correctly and work on various hardware/software platforms that you also need to ensure you are using the latest version of all the platforms. Even the latest version of MakeMKV (1.1.15) had a note on TrueHD fixes so if you've got an old file causing issues even after updating all you firmware/software layers it wouldn't hurt to re-rip any problematic titles.

Now, do I think all Atmos/TrueHD ripping/playback issues have been solved? No, I don't think we're there yet and in fact just last month I read that NVidia were still working with Plex on some Dolby issues. However, I'm hoping all the software rippers/players will have this resolved soon so that were guaranteed to get 100% accurate audio rips and 100% accurate playback. For the time being though, most people who have updated their systems and are playing clients like Plex are not experiencing the issues that have been reported for the past year and a half.

In my original message, I mentioned I also saw the problem in VLC, not just in Kodi. While it is possible that VLC may not be using nvidia's audio engine, I find it unlikely that VLC and Kodi are using the same audio engine. And if they aren't, it is even more unlikely that VLC and Kodi have the exact same bug in separate audio engines.

Photos & Videos has no DLNA support, which not acceptable given my setup.
I may give Plex another try, but it is not ideal (as I don't like having to use account with my library), and the Plex server is a memory/cpu hog.

Of course I'm using 8.1.1, since my shield automatically updates. There are no newer updates currently except for hotfixes (which I will not do, due to the restrictions certain apps that cannot be installed/updated/etc and the fact that a hotfix cannot be rolled back).

Of course I'm using the latest software, since they tend to notify me of latest versions when I run them.
mkvtoolnix has all sorts of seamless branching tricks now, like MakeMKV, but then again, seamless branching has been around for a while and this bug seems very weird to have gone undetected for so long. But seamless branching is unrelated to my audio drop out in "Into the Unknown" since it doesn't occur at a branch point.

[Fearless Leader]

For Shield owners running native Shield apps and the native Plex client this "fixed position dropout" issue was resolved a few months back. For example, Shield2019 users had this fixed in v8.1.1, while Shield2017 users had this fixed in v8.0.2 3rd Hotfix (note: this version is still in beta, I think they are up to hotfix 5 now, so Shield2017 users still have to request this Beta update to get it on their Shield hardware). I've experienced this issue with 5 Disney UHD titles on both my 2017 and 2019 versions of the Shield. Before the fixes I had to default the audio for my daughter to the DD 5.1 track. After the updates, she can now watch these titles with the full Dolby Atmos/TrueHD tracks engaged.

I'll give kudos when kudos are due. Switching to Plex did make the problem go away, and I still get the dolby atmos with thd core. So, kudos.

On the flipside though, unlike dlna servers where the processes takes <1% CPU usage while streaming (since it is just I/O), Plex shows two threads taking up roughly 22% cpu usage while streaming. While 22% doesn't sound like much, I expect multiple users streaming simultaneously, which the other dlna server (minidlna, mediatomb, etc) could do easily. Using dlna servers, my mem usage stays around 53%, while with Plex it jumps to 74%.

A dlna server should just retrieve the file and send via tcp to the client, which is all I/O driven. Doesn't need much cpu at all, which means Plex is doing something else.

I strongly suspect Plex is doing something with file (though manage GUI shows direct play for both HEVC and dolby truehd streams). Video transcoding is disabled, and I don't think Plex can transcode Dolby Atmos for free.

I wonder if Plex is separating the video/audio streams when reading file, packetizing them differently, and sending them to the Plex client for re-multiplexing at the client, which might better handle spikes in the Atmos bandwidth.

[Bajdman]

This issue has been bothering me more than it should over the last few months, so I ended up writing my own tool because still no demuxer (including MakeMKV 1.15.1) handles TrueHD flawlessly.

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

[cipher]

I'll give kudos when kudos are due. Switching to Plex did make the problem go away, and I still get the dolby atmos with thd core. So, kudos.

On the flipside though, unlike dlna servers where the processes takes <1% CPU usage while streaming (since it is just I/O), Plex shows two threads taking up roughly 22% cpu usage while streaming. While 22% doesn't sound like much, I expect multiple users streaming simultaneously, which the other dlna server (minidlna, mediatomb, etc) could do easily. Using dlna servers, my mem usage stays around 53%, while with Plex it jumps to 74%.

A dlna server should just retrieve the file and send via tcp to the client, which is all I/O driven. Doesn't need much cpu at all, which means Plex is doing something else.

I strongly suspect Plex is doing something with file (though manage GUI shows direct play for both HEVC and dolby truehd streams). Video transcoding is disabled, and I don't think Plex can transcode Dolby Atmos for free.

I wonder if Plex is separating the video/audio streams when reading file, packetizing them differently, and sending them to the Plex client for re-multiplexing at the client, which might better handle spikes in the Atmos bandwidth.

I just noticed this reply, are you still seeing the same issue? I just checked my Plex Server while playing Frozen 2 UHD and the Plex Media Server process is always under 1.5% on my system. I also checked the scenes where fixed dropouts were occurring and the process percentage doesn't change.

If you don't have it installed, Id recommend installing Tautulli as it will allow you to verify if there is any transcoding occurring. That is normally the reason for higher CPU usage on my system. Although, I hardly ever see this now since I'm almost always using the Nvidia Shield Plex client.

[domy94]

This issue has been bothering me more than it should over the last few months, so I ended up writing my own tool because still no demuxer (including MakeMKV 1.15.1) handles TrueHD flawlessly.

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

It's still occuring in MakeMKV 1.15.3.

[karbre]

This issue has been bothering me more than it should over the last few months, so I ended up writing my own tool because still no demuxer (including MakeMKV 1.15.1) handles TrueHD flawlessly.

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

It's still occuring in MakeMKV 1.15.3.

Does anyone know if the MakeMKV dev is aware of this issue? As I understand it, faulty generation of MKV files should be a top priority to fix in a program called MakeMKV. Maybe domy94's code can be translated and incorporated into the main program?

[mike admin]

This issue has been bothering me more than it should over the last few months, so I ended up writing my own tool because still no demuxer (including MakeMKV 1.15.1) handles TrueHD flawlessly.

@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...

[karbre]

Btw, I was wondering why it is even necessary to rely on heuristics like covariance for the merging of TrueHD streams. Then, I remembered that several years ago, there was already a replacement program for "Total Recall" (2012) because it used Seamless Branching and TrueHD. IIRC, the replaced discs still used the same combination though, so I'm not sure how they actually mitigated this.

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?