Oppenheimer (2023)

[RobbieT1974]

3CB4 was already submitted on the 17th of November.
See the first page of the topic.

No need to submit it again normally.

[SamuriHL]

Because you must have had two different physical "Oppenheimer" disks in your possession to create two entries.

No, I don't. That's an assumption that is incorrect. All I had to do was ensure that the key worked for someone else who has the disc with a different disc id.

Is this because UHD disks use AACS 2.0? For all of the non-UHD disks I own, the DiscID is the SHA1 hash of the AACS/Unit_Key_RO.inf file rather than the keys themselves. (I don't know the format of that file.)

That file IS the encrypted unit keys for the disc. It's the same for blu-ray and UHD. Hashing that file is what gives us the disc id.

But didn't you prove that both of those disks have the same unit key anyway?

Yup. But the unit keys inside the unit_key_ro.inf file were encrypted with a different VUK. That's why the disc id is different but the same unit key works for both.

[ShoutingMan]

I only get about one hour 30GB of the three hour 90 GB movie saved out by MakeMKV. Is this a known problem that will hopefully be fixed in a coming update?

Retail disc from Amazon.

[dcoke22]

I only get about one hour 30GB of the three hour 90 GB movie saved out by MakeMKV. Is this a known problem that will hopefully be fixed in a coming update?

Retail disc from Amazon.

What does MakeMKV's log file say? Maybe post it here.

[deltaexray]

Just my input really quick:

My Oppenheimer 4K Blu Ray came today and it can't be opened, 3CB4 als mentioned by others as well.
I guess we just have to wait and see when it's gonna work, just kinda meh wanted to watch it today.

[MrPenguin]

But the unit keys inside the unit_key_ro.inf file were encrypted with a different VUK. That's why the disc id is different but the same unit key works for both.

Which returns us to the question of why are there two distinct disks of the same film? I would have expected that each "release" (of a given format) would consist of copies of a single "master" disk, but that cannot be the case here.

FWIW my own non-UHD "Oppenheimer" disk actually has 7 unit keys rather than just 1. Would your "methodology" detect all of a disk's unit keys?

[SamuriHL]

Which returns us to the question of why are there two distinct disks of the same film? I would have expected that each "release" (of a given format) would consist of copies of a single "master" disk, but that cannot be the case here.

FWIW my own non-UHD "Oppenheimer" disk actually has 7 unit keys rather than just 1. Would your "methodology" detect all of a disk's unit keys?

I only deal with UHD's personally. And there are several UHD's that have multiple unit keys (Inception is one, but Oppenheimer is afaik not). But yes, the method I use to extract keys works on those discs with multiple keys. It's not a method I created or take ANY credit for at all...you can easily search for it if you're interested in ahem "find"ing your "vuk". The only difference here is, as I explained to you in the PM I sent you, that I have a different way of validating the extracted keys, and that validation method allows others to test the same key on different discs.

As for your question, it's technically the "same" master but they used a different volume unique id (VID) when creating the VUK used to encrypt the unit keys stored in the unit_key_ro.inf file. But that's literally the only difference between my disc and the other person whom I had test my unit key. All the metadata (dates, labels, disc name, even the volume size) were identical and I verified that myself. The only difference between the discs was the VID used to create the VUK and thusly encrypt the (same) unit key. That's why I was able to easily create a keydb entry for them....all I had to do was add a new entry with their disc ID using all the same metadata from mine since I validated they were the same.

And to make it more fun, the studios also had different masters with different metadata and a different unit key. They do indeed like to keep things entertaining for us. LMAO

[H3cxDev]

3CB4 still not working for me, will try again tomorrow

[mw2002]

3CB4 still not working for me, will try again tomorrow

Ditto

[Matista217]

Best Buy steel with tag 9DF6 still not decrypting, log file sent

[Matista217]

BB steel book ripped fine for me yesterday.

Me too

what .tgz file did it give y'all?

[Matista217]

Dump file sent to svq@makemkv.com


MKB20_v77_Oppenheimer_9DF6.tgz

[ShoutingMan]

I only get about one hour 30GB of the three hour 90 GB movie saved out by MakeMKV. Is this a known problem that will hopefully be fixed in a coming update?

Retail disc from Amazon.

What does MakeMKV's log file say? Maybe post it here.

I don't know how to get to the log, I don't any option for that in the menu. But here's the output:

Code: Select all

Error 'Scsi error - ILLEGAL REQUEST:INVALID FIELD IN CDB' occurred while reading '/BDMV/STREAM/00294.m2ts' at offset '32384876544'
Error 'OS error - The specified request is not a valid operation for the target device' occurred while reading '\Device\CdRom0' at offset '32384876544'
Error 'OS error - The specified request is not a valid operation for the target device' occurred while reading '\Device\CdRom0' at offset '32384876544'
Error 'OS error - The specified request is not a valid operation for the target device' occurred while reading '\Device\CdRom0' at offset '32384876544'
Error 'OS error - The specified request is not a valid operation for the target device' occurred while reading '\Device\CdRom0' at offset '32384876544'
Error 'OS error - The specified request is not a valid operation for the target device' occurred while reading '\Device\CdRom0' at offset '32384876544'
Error 'Scsi error - ILLEGAL REQUEST:INVALID FIELD IN CDB' occurred while reading '/BDMV/STREAM/00294.m2ts' at offset '32384876544'
Error 'Scsi error - ILLEGAL REQUEST:INVALID FIELD IN CDB' occurred while reading '/BDMV/STREAM/00294.m2ts' at offset '32384876544'
Error 'Scsi error - ILLEGAL REQUEST:INVALID FIELD IN CDB' occurred while reading '/BDMV/STREAM/00294.m2ts' at offset '32384876544'
Error 'Scsi error - ILLEGAL REQUEST:INVALID FIELD IN CDB' occurred while reading '/BDMV/STREAM/00294.m2ts' at offset '32384876544'
Error 'Scsi error - ILLEGAL REQUEST:INVALID FIELD IN CDB' occurred while reading '/BDMV/STREAM/00294.m2ts' at offset '32384876544'
Error 'Scsi error - ILLEGAL REQUEST:INVALID FIELD IN CDB' occurred while reading '/BDMV/STREAM/00294.m2ts' at offset '32384876544'
Failed to save title 0 to file C:/Users/_/Videos/Scratch/Movie 3/Oppenheimer (2023)_t00.mkv
0 titles saved, 1 failed

[SamuriHL]

Those are read errors. Either try to clean the disc "even if it looks spotless" or get the disc replaced.

[dcoke22]

It might also be the case that your drive is running out of power part way through the rip. If you have a USB powered drive make sure both plugs are plugged in to either high powered ports in a powered USB hub or directly into your computer (at the back).

As for the log file, if you scroll back in the output window of MakeMKV, near the beginning will be a line that tells you where the log file is being written on your file system. In any case, copy & pasting it as you did is better than attaching a file anyway.