www.makemkv.com

When I try to rip the UHD E.T Extra-terrestrial (ET40TH_UPK5), I got stuck in the initial analysis phase (after decryption that seems ok) when makemkv tries to get all the pieces of videos and audio. In the list of events displayed in the makemkv window , I have lots AV sync error and I finally get stuck on file 00134 with. I have no other info from makemkv, the disk is still read but after 30mn waiting I did not get the end of the analysis.
I get the disk replaced but still the same behaviour.
And my multimedia player can read it from start to end of the film.

Anyone else get the same problem ?

Have you tried gently cleaning the disc? Often even brand new discs benefit from cleaning.

Thanks for your reply, and yes I always clean the disk before ripping it. But does not change the error.

I think I may have found an issue with the UHD disc **ET40TH_UPK5** (French release, EAN 3701432065694). It looks related to the issue discussed in this thread.

**Environment**

* MakeMKV 1.18.4
* macOS
* Pioneer BDR-UD04 1.14 (LibreDrive)

To exclude a defective disc, I first created a complete sector-by-sector image using GNU ddrescue.

Results:

* Disc size: ~97 GB
* 0 read errors
* 0 bad sectors

The UHD also plays perfectly from beginning to end on my standalone UHD player.

However, MakeMKV fails while analysing the disc.

The first errors are reported on **00134.m2ts**:

* Hash check failed for file 00134.m2ts
* Too many hash check errors
* Too many AV synchronization issues
* Failed to decode audio/video data

Later in the log I also get:

```
The source file '/BDMV/STREAM/00543.m2ts' is corrupt or invalid at offset 502468608, attempting to work around
```

`00543.m2ts` is the main movie stream.

After that, MakeMKV appears to enter a loop continuously writing `tp=` lines to the log. The log eventually grows to more than **60 GB** if left running.

Additional information:

* SHA-256 of `00134.m2ts`:
`5c35608d6c5cabba02fc46d13fe61e5390d36db5abc0c2c902b00df125661ed2`

* I can also provide:

* AACS ContentHash tables (`ContentHash000.tbl`, `001`, `002`)
* the full ddrescue log
* additional MakeMKV logs
* small extracts from the affected M2TS files if needed.

Because the disc can be read completely without any physical read errors and plays correctly on standalone hardware, I'm wondering whether this could be related to the content hash verification or to the way this particular disc was authored.

If you would like me to collect any additional diagnostic information, I'd be happy to do so.

I don't know if Mike is still following this thread, but I have one question.

Since the disc can be read completely (verified with GNU ddrescue: 0 read errors, 0 bad sectors) and it plays perfectly on a standalone UHD player, would it be possible to disable or bypass the M2TS content hash verification and let MakeMKV continue with the extraction?

I completely understand why the verification exists. I'm only wondering if there is an advanced/debug option that allows MakeMKV to continue despite hash verification failures.

In my case, I'd simply like to extract the M2TS files and verify whether the resulting video is actually playable.

If such an option already exists (command-line switch, hidden setting, debug mode, etc.), I'd be very interested to try it.

Thank you.

Are you trying to just rip the movie? Or are you doing a decrypted backup of the disc? Do you get the same behavior if you try both methods?

Thanks for the suggestion.

Following your message, I performed some additional tests.

First, I created a decrypted backup using MakeMKV with the Decrypt video files option enabled.

The backup completed successfully.

However, when I load the resulting BDMV folder back into MakeMKV, I get exactly the same behavior: MakeMKV starts the analysis, reaches the content hash verification, and then appears to loop indefinitely.

I also tried opening the ISO image that I previously created with GNU ddrescue (0 read errors, 0 bad sectors). The result is exactly the same: the analysis eventually fails with the same hash check errors.

So, at least in my case, the problem is reproducible from:

- the original UHD disc,
- a decrypted MakeMKV backup (BDMV),
- and a sector-by-sector ISO created with ddrescue.

This seems to rule out the optical drive and the physical media, since all three sources produce the same result.

My copy of ET is the one from 2017, not the 40th anniversary release from 2022, which is, I think, the one you have. Mine worked fine when I processed it a few years ago.

It is my understanding, although I can't say with absolute certainty, that when one does a backup in MakeMKV, content hash verification is still performed in order to make sure what is read from the disc is accurate. In fact, a backup can fail with hash check errors. I find it curious that your backup succeeds but that making .mkv files from the rip fails.

If you have a paid key for MakeMKV, you could try older versions to see if the error persists. Depending on your version of macOS, however, you might be limited how for back you can go. macOS 15.4 introduced a change that required an update to MakeMKV. (https://forum.makemkv.com/forum/viewtopic.php?p=172237#p172237) I think only 1.18.1 and later works on macOS 15.4 and later. If you have an older version of macOS, you can run older versions of MakeMKV.

Additionally, you could try MakeMKV on Windows or Linux, perhaps even in a VM. Your successful backup from your Mac should open on MakeMKV running on any supported platform.