UHD-BD : AnyDVD HD vs DeUHD vs MakeMKV Quality

[jmone]

FYI .... On the Pros for a folder based rip for me when used with JRiver Media Center (I have many many hundreds of rips like this and it works beautifully)
- Ripped to a Shared NW Drive that is then accessed by multiple clients for playback over the network
- Folder also contains MC Sidecar Files and additional Coverart
- JRiver Database support "Particle" entries for the various MPLS and even specific ranges from within the MPLS (eg on a Music BD, you can expose each chapter as a song like with a CD)

My workflow is simple, Insert Disc --> MC Rips (AnyDVD HD running in the background), adds coverart and additional MetaData = DoneAll of this gets harder if keeping as an ISO + I never burn the content back to Optical Discs, it is all stored for NW Playback. Folders work. ISOs create a level of complication in this setup.

 

[Foxxy]

So if I’m muxing right from rip to MKV, is folder or .iso preferred?
Surely it doesn’t matter, right?

 

[James]

So if I’m muxing right from rip to MKV, is folder or .iso preferred?
Surely it doesn’t matter, right?

Right. Ripping to folder may take a little longer. But AnyDVD is a real-time decrypter, so you could either copy the m2ts file you want to rip (with explorer, the copy command, ...) or mux directly from the original disc.
Or even better, use CloneBD.

 

[Foxxy]

Is one of your reasons recommending CloneBD because of the multi-threading?
DeUHD struggles big time in this regard. I’ve used ImgBurn a bit, but I believe it’s also single-threaded.

 

[Pete]

- MakeMKV produces different M2TS files (but the streams in the M2TS are the same) = I "think" it is using a remuxer

Can you post two different snippets of such an m2ts file for me to compare and identify the differences?
Just two or three sectors will do.

 

[Pete]

Is one of your reasons recommending CloneBD because of the multi-threading?
DeUHD struggles big time in this regard. I’ve used ImgBurn a bit, but I believe it’s also single-threaded.

You can't really compare DeUHD and CloneBD, because one is a decryptor and the other a transcoder.
DeUHD or ImgBurn wouldn't profit from multi-threading, because what they do, hardly uses the CPU at all.
Why James is recommending CloneBD, is mostly its versatility and user friendliness. And so far it seems to be the only tool, that properly converts between HDR and SDR.

 

[jmone]

@Pete As requested, I've sent you a PM with a link to a sample of MakeMKV and AnyDVD HD (10 sec each).

 

[Curtis]

So if I’m muxing right from rip to MKV, is folder or .iso preferred?
Surely it doesn’t matter, right?

If you are making a MKV using MakeMKV, use an ISO. If you are using MKVToolNix, either works but like James, I find ISO is the most reliable and flexible for any additional things you want to do with it in the future. (That said, I only store my 3D blu-rays as ISO everything else is Movie& lossless audio-only MKV).

 

[Pete]

@Pete As requested, I've sent you a PM with a link to a sample of MakeMKV and AnyDVD HD (10 sec each).

Thank you very much.
Those differences are nothing to really worry about - except for an apparent bug in MakeMKV, which may or may not cause playback problems.

Differences are:

• MakeMKV changes a value in the PMT called "copy generation management information".
  AnyDVD doesn't. That value basically tells any copying software whether or not the content may be copied.
  I doubt, that anyone ever stumbled over a copy software, that actually looks at this flag and honours it.
  So it's commendable, that MakeMKV does this, but it doesn't really make a difference.
  
  
• the bug I mentioned: there's another value in each packet, similar to the above, called copy_permission_indicator. AnyDVD resets them all, MakeMKV only some of them.
  The difference to the above is, that some licensed players assume (or at least used to in the early days), that when these bits are set, then the data must be encrypted - and seeing, that it isn't, refuse to play.
  Also, some copy programs use this value to determine, whether the source is still protected (and if so, abort, because they can't copy encrypted data).

MediaPortal, for example checks the latter and refuses to play, if set.

But meanwhile, instead of fixing MakeMKV, the world has built workarounds for it.
A code comment in libbluray states:
/* Some streams have Copy_permission_indicator incorrectly set. */
and they use a different method for checking for encryption instead.

So - in the end, everything is more or less fine.
But AnyDVD is best and its best companion is CloneBD.
Forget everything else

 

[jmone]

Thanks Pete, good to know as it was killing me why the MT2S files were different, but the streams were the same.... FYI, AnyDVD and DeUHD (since 1.0.0.8) produce identical output - it was MakeMKV that was the "odd man out". DeUHD content ripped with 1.0.0.7 had other bits changed as well and I'll end up re-ripping these. So, I'm happy that I'll rip with AnyDVD for discs with a VUK and DeUHD for ones they support.

 

[mikech]

MakeMKV changes a value in the PMT called "copy generation management information".

No, MakeMKV never ever done that (it did removed copyright SEI from MPEG a while back, but that's irrelevant for Blu-ray)

the bug I mentioned: there's another value in each packet, similar to the above, called copy_permission_indicator. AnyDVD resets them all, MakeMKV only some of them. The difference to the above is, that some licensed players assume (or at least used to in the early days), that when these bits are set, then the data must be encrypted - and seeing, that it isn't, refuse to play. Also, some copy programs use this value to determine, whether the source is still protected (and if so, abort, because they can't copy encrypted data). But meanwhile, instead of fixing MakeMKV, the world has built workarounds for it.

Highly questionable. The blu-ray AV spec (part 3) does specify CPI bits on each packet, but specifically mentions them as reserved in scope of that spec and states that their meaning is defined in content protection spec. So these bits MUST be ignored on TS packet level. The AACS spec defines encryption (both AACS and bus) only on aligned unit boundary and defines meaning of CPI bits for entire aligned unit. Which in turn defines that CPI bits are valid only on first TS packet in aligned unit. Looking at CPI bits value anywhere else is a bug.

For the sake of lemming solidarity, MakeMKV will clear these bits in the next version

 

[diverjones]

We are talking un-protected UHD disks right? Because I thought UHD protections had not been cracked yet and we did not know if AnyDVD was even going to do that, OR that there wasn’t enough UHD content on disk to warrant AnyDVD even attempting it yet.

 

[James]

We are talking un-protected UHD disks right?

Not really. Have a look at the latest AnyDVD beta changelog.

 

[diverjones]

James, you are the man! Of course I am not there yet with UHD because one has to have all new equipment and not enough content for me to worry with the expense, HOWEVER, it IS good news and I am sure when I start investing in a 4K TV and UHD burners/players etc you will have everything as easy as all other discs are right now. Thanks for your devotion to making AnyDVD the best!

 

[jmone]

FYI - Got another sample posted to try to work out an ATMOS Audio Drop out (Bitstreaming) issue on some Disney Titles. At this stage these discs are only Supported by DeUHD and we are looking forward to seeing if it is a decryption issue with DeUHD (will need to wait for a VUK), or if it is something to do with players based on ffdshow. Summary of all the info in this thread if anyone is skilled at looking at a sample to see what is different at the point the audio drops out.

 

[ddjmagic]

FYI - Got another sample posted to try to work out an ATMOS Audio Drop out (Bitstreaming) issue on some Disney Titles. At this stage these discs are only Supported by DeUHD and we are looking forward to seeing if it is a decryption issue with DeUHD (will need to wait for a VUK), or if it is something to do with players based on ffdshow. Summary of all the info in this thread if anyone is skilled at looking at a sample to see what is different at the point the audio drops out.

I get a very slight drop at 33 seconds with MPC-HC/LAV and also Kodi on both PC and a Nvidia Shield (so all FFmpeg based players I believe) - my receiver still displays Atmos during it and I probably wouldn't have noticed it unless I was listening for it, however PowerDVD on the same PC does not appear to drop out at all, so I'd say it's a player issue rather than a decryption problem.

Do any of the problematic titles have the Atmos track on the standard BD? (I'm assuming not if there all Disney titles)

 

[jmone]

Thanks for testing. Both are Disney Titles and have very high peak Atmos bitrate of 11.3mbps. Other Disney ATMOS titles are around 7mbps. I'm guessing I hear a much bigger gap as my PJ (JVC 7500) takes about 10sec to sync. Others are reporting a second or so of lost sound with their setups. All get some drop out. I've also post the sample in the LAV Doom thread so hopefully Nev/Hendrik will be able to confirm if it is a FFmpeg issue.

 

[jmone]

....also tested on a 5.1 System and I can hear the drop but it is only brief as you describe. On my 7.2.4 setup it is a full 10 sec.

 

[SamuriHL]

That sounds like a bug we fixed back when bitstreaming was first being worked on. TrueHD had an issue almost identical to that. I can't remember exactly what the issue was but I submitted a code fix for it and it worked ever since then. I'm wondering if the same problem reappeared because Atmos is higher bit rate.

Sent from my Pixel XL using Tapatalk

 

[jmone]

Thanks - Any idea on who/how to send the sample to for analysis? I've posted in the LAV forum for Hendrik/Nev but I'm not sure if that is the right place.