UPDATE [Better Workaround]. For the wine config file, set the windows version to nt40, most are default at win95. If you do this DVDDecrypter will be able to parse a DVD disk contents without using scsi emulation. Thanks Afterdawn forms for that one.

[Version]
; BUNCH OF STUFF HERE...
"Windows" = "nt40"

This is an old thread so you've probably gotten everythng working. the last version of Decryptor 3.5.40 worked great under FC3, without any scsi emulation. Just set your version to nt40 in the config. Since then I've upgraded to FC4, and once again it doesn't work.

I'm not sure how this will get worked around, as it's not an encryption issue at all, but one of bad sectors. That's going to require a program use dma and apply some logic to a fix. I'm not certain that the current play and css libraries really approach access from that standpoint at all. I might be on the wrong track, but a solution might need be more direct.

Good Luck,
Ben

By FC4, do you mean Fedora Core? Can you explain. Also, try other packages of wine, older rpms and you may have more luck (or compile old versions ,etc). Some versions of wine will freeze in DVDShrink beta 5, as the newer ones I have used do not seem to handle the GUI widgets and windows correctly. Not sure exactly what part, but they will hang etc. Older rpms of wine do not have this problem on my setup.


Do you mean to say there are newer Accros protection schemes on the market now? Please let me know.

Using:
- Mandriva 10.1
-Wine 20041201 from RPM: wine-20041201-mdk.i586.rpm
-Kernel: vmlinuz-2.6.8.1-12mdk

Ahh, yes. I had just posted something in the Fedora forum a moment or two earlier, where FC4 wouldn't have been in question, and wasn't thinking.....

I haven't had time to test other wine versions yet. Shrink works great with the latest, although I had trouble initially with the CVS version I had installed just a day earlier than the 06/28 release version. Figure that. Previously, I had Decrypter working nicely with Fedora 3 and an RPM version I had installed. The problem with trying older versions for Fedora 4 is that it now uses gcc4, and none of the prior releases will compile. There was a patch between the last two releases addressing this. But I could certainly download several other versions in RPM format and try.

More specifically regarding the dummy sector issue: My understanding is that DVD Decryptor circumvents the bad sector protection on the discs by inserting these 'dummy' sectors. Most of the previous methods of extracting data just die when they hit the bad sectors, so getting around it requires recognizing the errors and working around them without all the normal filesystem stuff butting in and taking charge, effectively killing the process. So I guess it will require a slightly different implementation to whichever library should handle the process. I still haven't seen anything directly claiming to be working on this.

DVDDecryptor implemented a solution, it is just a matter of doing something similar (makes me wonder why that Euro fellow who wrote it didn't release the source, odd).

I had a question about DVDShrink, the newest version or so. Everytime I attempt to open a window to the file system on Shrink, all it shows is the desktop tree, with no way to expand it. Have you found a workaround for this? I know I can just shrink from disk, but this seems to take longer than just copying to harddrive and using an older version of shrink to access the file system and shrink the files. Also, shrink is not much for reattempting when a disk is dirty, so I typically use DVDdecrypter to copy to harddrive as it has ample retries, by default.

I remember reading about the dir. tree issue and a potential crash with maximizing a window at a certain time, and the general opinion was that there was no workaround. However, I've theorized that setting a symlink somewhere for the desktop would do the trick, but would probably change you 'windows' desktop globally for other programs too. I just change to the wine directory after shrinking and move it from there.

The last point you make is interesting because it highlights the difference between the standard linux libcss libdvdplay/nav way of getting at the content, and why the bad sector thing throws it. You've probably noticed that every disk in shrink with wine says it's unencrypted? That's because it is using the libcss decryption. So if that set of libraries were able to accommodate the sector thing, shrink would suddenly be able to handle those odd discs under wine. Decrypter uses DMA to get right at the hardware level, and that's why it works around the issue differently. Sad that both these great projects are now dead. Both authors have stated emphatically that the source code will not be released.
Ben

We think alike, I tried out that one Placed in under the Desktop folder in my .wine directory, no luck, unfortunately. However, I may need to tweek wine to follow symlinks (Do you know if this is the case?).

The interesting thing is libcss actually will play disks with this protection. Leading me to believe that the there are 'pointers' to other areas of the file system that allow software to pass over these sectors without noticing them. Seems like if you can play something and see the results of interpretation of bits, you should be able read those bits, wouldn't you gather? A VERY strange issue. Also, why is it we cannot read the bits at a low level and just transfer them to another disk (although lack of interpretation would not allow 'compression' to be possible). Same thing goes for Xbox backups, what gives?

Perhaps I should try writing some low I/O routines to try this all out myself, and *see* why this is the case. It seems all these readers try to interpret the bits, where as in some cases it is not needed.

One more thing to add, the CSS algorithm might be actually hard coded into DVDShrink, so wine does not reference the libcss library in this case. At least as far as I know, since I can still use this without any CSS library installed (but I might be wrong). Also, I am unaware of a generic CSS windows library, that would be needed by shrink should it not be hard coded (unless windows has a general license for all Win32 developers on CSS). If this is not the case, I am quite confused. Either way I have not been able to get shrink to handle Arccos protection.

My thoughts stem from most Windows DVD players, in which case each individual piece of software needs to retrieve a licensed version of a CSS decryptor from Motion Picture Association, etc and each has their own separate implementation of CSS. What a waste of code, what ever happened to re-use?!

There's no generic Windows library for Decryption, but supposedly AnyDVD and DVD43 both work as add-ons in that respect. The latter is free. It provides a middle layer between hardware and application (shrink, in your case) and DVD43 handles Arccos too. But they don't work in Linux. Shrink has the CSS stuff built in, but doesn't need it for wine if you have css libraries installed already.

So Shrink links to library, only if it is being emulated in Wine? That seems like a strange design paradigm. It is kind of like it has the code it needs, but if it finds the library, it links against it... How odd. Not sure why they decided to so that. I am curious,how you find this out, or what led you to conclude this? Is there a wine log level that lists external libraries called. Is it, that you are saying that libcss creates an abstraction that wraps around /dev/dvd etc, and encapsulates CSS decryptions, when something reads from that device. Pretty cool, all very intersting stuff.

No, I read that it worked that way, and have only confirmed it from the sense that is seems any disc I see in preview mode pops up with the "not encrypted" label. If nothing is encrypted that shrink sees, it stands to reason it's being decrypted before it actually reads the data.