E.T. extra-terrestrial UHD disk (ET40TH_UPK5) : never stop analysing the disk, too many sync errors

[brurab]

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 ?

[dcoke22]

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

[brurab]

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

[YannArtoie]

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.

[YannArtoie]

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.

[dcoke22]

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?

[YannArtoie]

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.

[dcoke22]

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.

[YannArtoie]

Thank you for the suggestions.

I performed another test today, this time on a completely different machine.
I repeated the entire process on a Windows PC, using the same UHD disc.

Unfortunately, I get exactly the same behavior : the same hash check failures and the same failure during analysis.
I also tested the original UHD disc and a brand new the decrypted MakeMKV backup (BDMV).

All of them produce exactly the same result on both macOS and Windows.

At this point, it doesn't appear to be platform-specific.

[YannArtoie]

I also performed some additional tests that may help narrow this down.
I tested the decrypted BDMV backups created on both macOS and Windows with several older MakeMKV Mac versions (v12.0, v17.7, v16.7, v15.4)
The result is identical with every version.

The decrypted BDMV still fails during analysis with the same hash check.

[tomty89]

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

If you have a decrypted backup, then you can try remuxing it into MKV with something else, such as mkvtoolnix or even ffmpeg. Or you can even just play the M2TS.

It almost sounds like something went wrong during the decryption process...is this disc protected with anything other than AACS?

[YannArtoie]

I tried that.

I tested both the original `00543.m2ts` from the disc and the `00543.m2ts` from the MakeMKV decrypted backup.

Neither FFmpeg nor MKVToolNix recognize either file as a valid stream, and VLC does not play them directly.

However, the main issue remains that MakeMKV also fails to analyze its own decrypted backup, producing exactly the same hash check and AV synchronization errors as with the original disc.

[tomty89]

If I were you, I'd probably try to make an encrypted backup with MakeMKV, then try to decrypt it with libaacs instead and see if it makes any difference. To test that, you'd need to make sure VLC leverages libaacs (and maybe libbdplus as well) instead of libmmbd.

There's also the program bluraybackup that would allow you to produce decrypted M2TS using libaacs and libbdplus. It can work from an encrypted backup instead of from the disc directly but that requires two lines of useless check removed from the source code. It's a simple C program but I have no idea if that means you can compile and use it on macOS. (Also make sure you don't "fake" the two libraries with libmmbd.)

P.S. Note that "encrypted backup" implies a copy without bus encryption applied, which means it may not be the same thing as "a sector-by-sector ISO created with ddrescue" -- depending on whether bus encryption has been temporarily disabled when the ISO is made. Similarly when you try to have bluraybackup work from the disc directly, you'd need to disable bus encryption through MakeMKV first. (Unless you are using one of those crossflashed Pioneer drives that does not / cannot do bus encryption at all.)

---

There's also this tool from the Xreveal team which you can use to verify (again) a backup against the hashes. Apparently the current version even allows you to verify a decrypted one when KEYDB.cfg (one with key for the title) is supplied. (It probably re-encrypts the decrypted files and then verify the result against the hashes? Either way, the result might give you some insight.)

However I don't know what would be the story if the title is protected with more than just AACS (and bus encryption), and if it's not, it seems very unlikely the decryption could go wrong either.

[YannArtoie]

Thank you for the detailed suggestions. I have now tested as much of your proposed procedure as I could.

1. MakeMKV encrypted backup


I created a new MakeMKV backup with “Decrypt video files” disabled.

The backup was created successfully and contains the original AACS structure. It is detected as:

Disc ID: 924A532D93B1F099A83C1858E200C8901FFAC2D2
AACS MKB version: 76
BD+ detected: no

So, as far as I can tell, this title uses AACS and bus encryption, but not BD+.


2. libaacs / VLC test

On macOS, I installed:

libaacs 0.11.1
libbluray 1.4.1

I also checked that neither libmmbd nor MakeMKV’s VLC integration was being used.

After placing KEYDB.cfg in the correct macOS location, libaacs loaded the configuration correctly, but it could not open this disc:

Error calculating media key. Missing right processing key?
AACS handled: no
(no matching processing key)

The disc ID is not present in my KEYDB.cfg, and the available processing keys are apparently not sufficient for MKB v76.

Therefore I could not complete an independent decryption using libaacs.


3. bluraybackup

For the same reason, I have not yet been able to use bluraybackup successfully: libaacs cannot calculate the media key for this title.

I also confirmed that BD+ is not present, so libbdplus should not be required in this case.


4. Bus encryption and the ddrescue ISO

Your warning about the ddrescue ISO was correct.

My original sector-by-sector ISO may have been created while bus encryption was still active, so I no longer consider it equivalent to a proper MakeMKV encrypted backup.

When checked with XReveal’s Content Hash Verifier, that ISO produces widespread mismatches from offset 0, continuing every 196608 bytes across entire M2TS files.

For example:

00302.m2ts content hash mismatch at offset 0
00302.m2ts content hash mismatch at offset 196608
00302.m2ts content hash mismatch at offset 393216

So the ddrescue ISO result may simply reflect the bus-encrypted representation captured from the drive.


5. XReveal Content Hash Verifier

I used the free command-line Content Hash Verifier 1.3.

A complete successful verification of the physical UHD disc produced:

Content hash : match
Total files : 548
Matched files : 373
Skipped files : 175

Most importantly, both files involved in the MakeMKV failure were validated successfully:

00134.m2ts content hash match
00543.m2ts content hash match

This strongly suggests that the physical disc and its ContentHash tables are internally consistent.

However, there is one very strange observation: repeated verification of the same physical disc is not always deterministic.

Most runs verify normally, but occasionally a run switches into a completely different state where entire M2TS files mismatch from offset 0 onward, at every 196608-byte hash unit. It is not a small number of isolated or random sectors; the whole file representation is different.

This makes me suspect that Content Hash Verifier sometimes sees the stream with bus encryption active and sometimes without it, depending on the current state of the drive.

6. Encrypted MakeMKV backup verification

The MakeMKV encrypted backup also produces widespread Content Hash Verifier mismatches from offset 0 across complete M2TS files.

The pattern is similar to the ddrescue ISO:

00302.m2ts content hash mismatch at offset 0
00302.m2ts content hash mismatch at offset 196608

I am not yet sure whether this is expected because the backup no longer contains the bus-encrypted representation expected by the original ContentHash tables, or whether the verifier should be able to account for that.

I have not purchased the XReveal GUI/Pro version, so I have not tested its specific decrypted-backup verification feature with a title key.

Current status

So far:

Physical disc: can pass a complete ContentHash verification.
00134.m2ts: verified successfully on the physical disc.
00543.m2ts: verified successfully on the physical disc.
BD+: not present.
libaacs: installed and correctly loaded, but blocked by the absence of a matching processing key/title key.
bluraybackup: therefore not yet usable.
ddrescue ISO: not considered reliable because bus encryption may have been active.
MakeMKV encrypted backup: widespread ContentHash mismatches, although I do not yet know whether that is expected for a backup with bus encryption removed.


Does the encrypted MakeMKV backup result look normal to you, given that bus encryption has been removed? Or should Content Hash Verifier still be able to validate it directly against the original ContentHash tables?

[YannArtoie]

I have a couple of additional updates since my previous post.

First, I repeated the encrypted backup experiment several times.

Initially, every encrypted MakeMKV backup I created produced widespread Content Hash Verifier mismatches across entire M2TS files.

However, after completely power-cycling the Blu-ray drive (disconnecting it from power and reconnecting it) and creating a brand-new encrypted backup, I finally obtained a backup that validates correctly.

The Content Hash Verifier reports:

Content hash: match
Total files: 548
Matched files: 373
Skipped files: 175

This suggests that an encrypted MakeMKV backup can be perfectly valid. It also makes me wonder whether the drive (or the AACS/bus-encryption session) can sometimes end up in a different state, resulting in a completely different representation of the M2TS data.

I also followed your bluraybackup suggestion.

I downloaded the source, compiled it on macOS, and removed the block-device check you mentioned so that it can operate directly on an encrypted MakeMKV backup stored as a directory.

That modification works as expected: bluraybackup successfully opens the encrypted backup.

However, it then fails at exactly the same point as bd_info:

Error calculating media key. Missing right processing key?
AACS handled: no
(no matching processing key)
Unsupported AACS encoding.

So at this point, it seems the remaining blocker is no longer the backup itself but libaacs, which cannot calculate the Media Key for this title because my KEYDB.cfg does not contain a matching disc/title key (or sufficient Processing Keys for this MKB v76 disc).

This makes me think the encrypted backup itself is no longer the issue. The remaining limitation appears to be entirely within libaacs.