Programming question: DVD_RPC_KEY

[dvdshrink]

Does anyone know, given the DVD_RPC_KEY structure returned by a DVD drive, what the fields actually mean?

Specifically I need to determine if the drive is RPC-1 or RPC-2, whether or not the region has already been set, whether an RPC-1 drive will refuse authentication if the disc region doesn't match the drive, whether the region mask can specify multiple regions or only one, and any other useful information about this structure:

typedef struct {
UCHAR UserResetsAvailable:3;
UCHAR ManufacturerResetsAvailable:3;
UCHAR TypeCode:2;
UCHAR RegionMask;
UCHAR RpcScheme;
UCHAR Reserved2[1];
} DVD_RPC_KEY;

Somehow one-click-backup-solutions doesn't seem the right place to ask this question ;-)

[LIGHTNING UK!]

I could babble on for ages about it all but it's so much easier if I just send you to download the MMC-4 Command Specs from www.t10.org

Look on page 396 and you'll see what it all means.

http://www.t10.org/drafts.htm#SCSI3_CMNDSETS

The only drives I know of that wont allow a disc to be read if they're RPC2 and the regions dont match are from the Panasonic/Matshita range. All the others let you read the disc, you just cant get the title key for a given file / sector.

[dvdshrink]

Thanks for the link. I was searching on MSDN and getting nowhere.

DVD Shrink does rely on title key exchange, so future versions will prompt the user in case of drive region mismatch.

If you ever did want to babble on, I'd be your most avid listener! A large portion of my bug reports concern ripping failures of one kind or another (the rest are typically burning issues).

Can I ask you a few more questions?

DVD Shrink gets the title key for the first sector in a VOBS (that which contains the first NV_PCK), and assumes the key remains constant throughout the same VOBS. If I remember correctly, DVD Decrypter used to have an option to obtain the title key more frequently, on a VOB_ID or cell basis, but this option is no longer present in current versions. Is this because it was unnecessary?

Is the first sector of a VOBS guaranteed to contain the title key, or is it better to look for it further on, for example in the sector containing the first encrypted pack?

When reading a 64KB block in SPTI/ASPI mode, would it make a difference to read performance if the block is aligned to a 32 sector boundary on the disc?

I'm going to try workaround some Nero bug which resets drive read speed to 1x, by setting it again to max speed after Nero is initialized. I still have no idea how to do this, but will search the documentation. Do you forsee any problems with this approach? Are there reasons why people would rip at less than max speed, which this would cause problems for?

That's about all. I hope you don't mind.

[LIGHTNING UK!]

The option to check for a key more frequently wasnt removed, just renamed to 'Detect Mastering Errors' and now lives on the CSS page in the settings dialog. Its not something I'd ever consider removing as it does no harm being there (although it's better not active - just slows things down!).

In my experience, no, the first sector doesnt have to contain the title key.
I've seen it return 'key not present' for the first sector if the start of a vob contains studio logos and stuff like that. Checking at the first sign of an ecrypted packet is probably a better idea.

64k blocks dont work for everyone. I used to have loads of people asking for support due to the program defaulting to read that amount of data. Newer versions default to 32k. Again, in my experience, there is no / very little difference in speed between 32 and 64k reads. I believe the drives work in multiples of 16 sectors anyway.

I dont quite get the nero issue. Most dvdroms dont even support read speed settings so it shouldnt be a problem for most. Of course if they use their burner for reading, you have a valid point ;)
No I cant see any problem with resetting the speed and other than the slightly improved chance of reading scratched discs, I cant see why people would want to read at 1x anyway.

[dvdshrink]

Thanks for your comments. It looks like I'll have to do a redesign of the decryption module in DVD Shrink. It started off on the wrong foot, so to speak, with me knowing very little about what I was doing.

Would the 64K block size problem occur if I am using ReadFile() API in SPTI mode? I wondered if you are doing the reading with raw SCSI commands or an IOCTL, and if different restrictions would then apply.

I was under the impression that the entire key exchange process (including getting the title key) was necessary before the device would let you even read data. I gather from your comments that this is not the case. After just getting the disc key, would the drive be "authenticated" enough to let you read from it?

According to Nero, their burning engine can send an invalid command to the drive during initialization which causes it to reset read speed to 1x. Anyway I released a Shrink beta with set_cd_speed command to max, and got some positive feedback, so it seems to be working.

[LIGHTNING UK!]

You're actually authenticated before you've got the disc key. Try it for yourself!

put a new disc in and then step through each stage until you've done enough to let you read.

Using ReadFile, you shouldnt have a problem. Windows will still control the buffering for that API.

I use the SCSI_PASSTHROUGH_DIRECT stuff so it's all down to me!

Seems weird that 'SET CD SPEED' would have caused that problem. I'm sure new drives (dvd drives) are supposed to use the 'SET STREAMING' command?!

[dvdshrink]

Maybe I should use SCSI_PASSTHROUGH as well. I do all the groundwork anyway, for ASPI calls under Win98. Then I switch on the OS and do either a raw command for ASPI or ReadFile() for NT. One thought: do you still get the benefit of DMA transfer when using SCSI pass through? If so, then perhaps using ReadFile() is less than optimal, since I just want the data without buffering or any other messing around by the OS. How do you do it, if user is non-administrator?

Also, is sector alignment on the disc important? I don't do aligned reads even for ASPI.

I didn't see the "set streaming" command. I'll check it out! One user reported a big improvement after set_cd_speed(), so maybe it is working, or maybe he changed something else in his configuration, or maybe I changed something else in the beta, God only knows.

Is it generally OK to send commands like set_cd_speed or set_streaming at a drive, even if the commands are not supported? Or should I be checking what's supported before doing this? (I hope not because just released 3.1.6).

I'll investigate the authentication process more thoroughly. You've prompted me with a better algorithm:

(1) get the disc key at initialization. This should never change, and hopefully, should never need to be gotten again.

(2) get the title key only if a sector is marked encrypted.

(3) reset the key at beginning of each VOBS (will force another get for the first encrypted sector)

(4) scan video packs for start codes and make sure they seem correctly decrypted - for example, the first video pack of a vobu should contain sequence_header_code and gop_start_code, so if they aren't there, get the title key for that sector and decrypt again?

---

Sorry about all the questions. I'm finding this incredibly valuable. Anything you need to know about shrinking?

:-)

[LIGHTNING UK!]

Yup you still benefit from DMA. It would be awful if you didn't because PIO limits to 2x!
There is no way around the admin user rights issue really. I've seen a little machine security policy workaround but that's about it.
If people really cant have admin rights, get them to use ASPI. Or maybe use the 'Run As' command?!

I'm not 100% sure what you mean by 'aligned' reads. You can read data from anywhere on the disc and any length - so long as it doesn't exceed the drivers/controllers 'max transfer length' - thats the 32k / 64k bit.

There shouldn't be a problem sending the commands to the drive - whether it supports them or not. The problem lies on how well the firmware does its job! Sometimes drives get stuck when they shouldn't but there is nothing you or I can do about it!

I wouldn't go overboard on the decryption stuff. Just checking the css flag (2 bits) should be enough. If its set and you don't have a key for that file, get it.

[RB]

Originally posted by LIGHTNING UK!
There is no way around the admin user rights issue really. The solution would be to move the I/O stuff into a service. I realize this will introduce some interesting IPC problems, though :)

[LIGHTNING UK!]

Originally posted by RB
The solution would be to move the I/O stuff into a service. I realize this will introduce some interesting IPC problems, though :)

Yeah that's why it's easier to just use ASPI! According to what I've read elsewhere, Adaptecs ASPI layers bypasses several layers and talks directly to the drivers or something (which it shouldnt do - and its why programmers dont have to make their programs 'open' a channel to the device - they're always open). That's why it's possible to use it even when you're not ADMIN.
That's also why Microsoft probably dont like it/recommend it for newer OS's! They have less control over what it does and cant lock it down like other stuff.

[dvdshrink]

I've put off improving the ripping code, instead I'm working now on direct encode to an ISO file - without Nero, and without requiring temporary files to be output to hard drive first.

I'll add a checkbox or something to start DVD Decrypter and burn the ISO, if that's OK. I saw the registry option:

"HKCU\Software\DVD Decrypter\InstallDirectory"

I assume you won't be changing this in future versions?

Also, I have some questions about ISO generation, I'm confused by the spec, maybe you'll know. I'm OK right until the end, and then it says, the Second Anchor Point should be at "last LSN" but shouldn't that be "Last LSN-1"? Otherwise it is outside of the UDF partition.

I checked an image file output by Nero, and at the end of the file they write about 200 or so "second anchor points" in a row, some of them inside the partition, some of them outside. What's the purpose of that?

Is there a standard way of finishing an ISO file? Like, should the final size always be a multiple of 16 or 32 sectors, so pad with anchor points at the end?

[LIGHTNING UK!]

Yup, that reg key is fine.

To be honest, I dont like the images created by many programs!

The only ones I like are those created by DVD Maestro. Nero, as you say, pads it with loads of crap. CloneDVD does a similar thing.
If you take a look at an ISO from an original disc, the second anchor point is the last sector in the image - as the UDF specs say it should be. The sector before that is actual file data - which is good I guess?!

I dont think rounding up to 16 / 32 sectors is an issue. Just end the ISO when you've run out of data and written your anchor point.

[dvdshrink]

Thanks.

Do you have a /SHUTDOWN when finished option? mrbass said it might be coming soon...

[LIGHTNING UK!]

Yup, that's in there now.

[dvdshrink]

/SHUTDOWN doesn't work in 3.1.9.0.

[LIGHTNING UK!]

no, it's new for 3.2.0.0 which (hopefully) I'll release today

p.s while I've got your attention, could you look at the 'overlapped i/o' post in this forum please - its about DVD Shrink so you're the best person to answer it!

[dvdshrink]

3.1.7 beta 3 is live, with support for reading and writing ISO files directly. I added a burn with DVD Decrypter checkbox. /SHUTDOWN and /ERASE arguments are passed, depending on the options set in DVD Shrink preferences and backup options.

Later I'll add an option to set the target burner, for now I'm assuming DVD Decrypter will select one automatically.

Together we make a seamless backup solution, completely freeware! :-)

[LIGHTNING UK!]

Blimey, I can't believe how quickly you've put together that ISO/UDF creation code! I tried it once but it seemed like a mammoth task and I just gave up.

You Sir, are a genius!

[dvdshrink]

It took me 40 hours from start to finish, using the TR-071 document and HexCmp to check the output. I got worried by the scale of the task about 1/3 of the way through, but it came out OK - I drank coffee and smoked a 200 carton of cigarettes. Thanks for the compliment - I'm not a genius, and I'm only quick because once I start, I don't stop!

There's bound to be a few bugs, so it'll stay in beta for a while. If you're interested in the code, perhaps we could negotiate an exchange, because I'd sure as hell like to see some of yours ;-)