DiscImageCreator (Page 128 of 141)

Hi sarami,

I have a few questions for you about the program.

1. How are you detecting RipGuard on DVDs?  Until very recently, I honestly didn't realize it was separate from Sony's ARccOS protection - both would crash DVD Decrypter when trying to rip a disc with it, but your program can differentiate.

I'm told by some people on Discord that ARccOS is detected by looking for files in a certain area of the disc that is normally blank.  This actually caused some older and non-Sony DVDs to be falsely flagged as having ARccOS, which is why this came up.

But RipGuard I have no idea about.

2. I notice for said RipGuard DVDs, your program say "Detected protection: MVSNRGFP"  I assume MVSN = MacroVision (the company who made it) but what is RGFP?  Is this your own acronym, or some official term?  Google only shows one result for it, a post on your GitHub.

3. Are there any other methods of anti-ripping protection (besides the CSS/CPPM encryption that's been standard since DVD's inception) on DVD-Video discs besides "MVSNRGFP" and ARccOS that you are aware of?  I've started running various DVDs through DIC just to see what it shows, trying to find something - but haven't found anything yet.

4. With regards to "RipGuard", I am a little confused why the program behaves as it does.  It typically runs into L-EC uncorrectable errors or other generic I/O error messages and then has to try to re-read the sector multiple times before giving up.  This is why I confused it with ARccOS - isn't that what Sony did for their protection?  RipGuard, I *thought* involved thousands of fake program chains in an IFO file, so that if a program like DVD Decrypter was reading the IFOs to figure out where the titles were, it would freeze up and crash.  DIC is just doing a binary (sector) copy, if I'm not mistaken, so what is causing the fake read errors?

Edit: looking at the source code, I learned the "MVSNRGFP" text is actually contained in the disc contents, and confirmed this by opening a couple DVDs in a hex editor and searching for it.  Kind of weird that Macrovision would actually put that there, seems like it would make ripping easy as soon as you found their little string!  The rest of my questions still stand though.  Like if there are multiple different types of RipGuard.

So, in MPF, that "scan for protection" button apparently uses some program called "burn out sharp", and in the Github for that it mentions:
Cenga ProtectDVD, DVD-Movie-PROTECT, DVD Crypt, ProtectDISC / VOB ProtectCD/DVD, Protect DVD-Video
among other things

I'm sure some of these are DVD-ROM specific, but "DVD Movie Protect" and "Protect DVD-Video" seem pretty obvious what they would be used for... However I have not actually seen these in the wild and Googling most of them only brings you back to the BOS Github page.  Any idea what that's about?

Additionally, some of the DVD ripper programs mention a thing called "Disney X-Copy" protection and tout that they can remove it - however, all my Disney DVDs (from about 2007 through 2011) have RipGuard with the MVSNRGFP text, so it's possible those sites are confused.

They do mention something that I observed once, a long time ago (on Windows XP), where a (Disney) DVD will show up as being like 40GB in size even though that's obviously impossible - and if you try to rip it, it gets stuck in a loop.  I haven't seen such a DVD show up in modern Windows though, so it might have been the same RipGuard "fake PGC" protection that somehow messed up Explorer back then?

I do notice there are two completely distinct types of DVDs both with the MSVNRGFP protection.  One type acts functionally identical to ARccOS, where the ripper will get I/O read errors and have to skip/blank out sectors.  The other type, the IFO files themselves specify hundreds of thousands of PGCs that don't exist, so a program that tries to read those gets thrown off.

Do you know if this is the same thing, but one is just newer?  Maybe Macrovision realized people were using tools like ddrescue to simply skip the bad sectors, so they switched to phony IFOs instead, I don't know.

I do notice that on the latter type with the deformed IFO files, DiscImageCreator still gets stuck on sectors and has to "read back" multiple times.  So it might be the same fake-bad-sector scheme, but with deformed IFOs added to the mix?  I assume DIC isn't even reading IFO files since it's doing binary copies and not trying to decrypt stuff.

Yes.

I can't dump any CDs! I have an "ILLEGAL MODE FOR THIS TRACK" message. Can something be done about it or not? I have the TS-L632H drive. I have the latest TO03 firmware uploaded to it

I tried to dump the USA PC release of Tonic Trouble today, and DIC crashes when "checking EXEs" :

xd8, SubCode: 0]
This drive supports [OpCode: 0xd8, SubCode: 1]
This drive supports [OpCode: 0xd8, SubCode: 2]
This drive supports [OpCode: 0xd8, SubCode: 8]
Checking reading lead-out -> OK
Checking SubQ adr (Track)  1/ 1
Checking SubRtoW (Track)  1/ 1
Checking Pregap sync, msf, mode (LBA)  -2588
Reading DirectoryRecord   73/  73
Checking EXE    3 SETUPTT.EXE: File Version 1, 0, 0, 1
Checking EXE    5

(It crashes just at that last line ("Checking EXE   5")

It's a game that was dumped back in 2019 on redump, so I picked a DIC from that time, and it dumps fine.
That release is quite rare, but "thankfully" it also crashes with more common european versions (french, UK...)

Sorry. I forgot to test for xbox.

DVDAuth also crashes for the same reason. Fixed it.

https://www.mediafire.com/file/eq80y20l … st.7z/file