abrogard

I recently tried to use DVDShrink to copy a DVD which it wouldn't do.

The DVDShrink experts told me that it was because the DVD I was using was old and scratched. (I know, that's why I wanted to copy it)

But DVDShrink didn't just give up. What it did was take dozens of hours. It went all night and still wasn't there.

When I looked at the Task Manager the Idle process was using 98% of cpu cycles. When I looked closer I couldn't find any process that had anything to do with DVDShrink.

Now how can a program spend so much time doing nothing? What is it doing?

Is this acceptable behaviour or is this a programming mistake and if it is, what is the mistake?

regards,

ab

InfoGeek

May be the program is trying to do something over and over again and failing every time.

__________________
PFO - My daily dose of technology.

nnxion

I've had a CD that was very bad, I wanted a virtual CD of it, one block wasn't getting read, it failed and failed and failed, but after 24 hours it finally got the block read. Don't ask me how, 'cause I don't know.

__________________
"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for."
-- Socrates

DaWei

Despite the code posted on the forum, there is error checking in the world. Typically, for a disk read, there will be a number of retries. If the read is critical, the number of retries may be high. If the read is absolutely essential, a large number of retries will be followed by giving up. You may even have seen this phenomenon if you've tried to install an OS with a flakey medium. I am not into the characteristics of CDs, but I can tell you that there are many reasons for magnetic media to fail at first, then eventually succeed. There are also ways to jink with the media reader at a low level, but they aren't commonly employed.

One thing that can be done with flakey media (such as a bar-code on a fiche) is to make many reads and derive some composite result. One may do this a few times and accept the most likely candidate by 'vote'. Sometimes one deals with probabilities of success rather than absolute tolerancing.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

PPoA

Some copy-protection actually defeats copying a disk. From what I've heard, they purposely put broken sectors or something on the disk, and without such and such a key, you don't get a clean copy.

lectricpharaoh

Yup. This was common back in the 80s and early 90s, when floppies were the primary media for commercial software. One protection scheme on a game I used to play employed it; they had unformatted sectors on the disk, so when these sectors were read, it was essentially noise. The drive would interpret it as a series of binary values, but they wouldn't be consistent. The protection method was to read these bad sectors several times, and compare the results; if they were all identical, it concluded the sectors were formatted, and thus, the disk was a copy.

Of course, it wouldn't immediately reject the disk. The programmers were sneaky, and would have the game continue for some time, and mysteriously fail at some later point. Intermittent crashes with the game were a common result of a pirated disk.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

nnxion

Of course you can reverse engineer the method, and then by using lowlevel I/O copying the bad sectors, and making them unidentical.

__________________
"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for."
-- Socrates

lectricpharaoh

Nono, that's not what I meant. Imagine sector X is bad. If you read it, it gives a certain result. But, because it's bad, if you read it again, you're likely to get a different result. Read this sector several times, and if you get the same result each time, it's a properly-formatted sector (and thus exists on a copied disk). Using low-level I/O won't get around it. Low-level I/O might help with the other stunts they used to make the disk difficult to copy (such as different tracks having varying numbers of sectors), but it won't help with the bad sector trick.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

nnxion

Thank you for the insight. How about creating your own diskreader which is able to scratch the disk with its header, so instead of formatting it writes bad sectors. (I'm not sure if that's even possible.)

__________________
"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for."
-- Socrates

DaWei

I guess programs are like programmers, too. Turn your back, some of 'em do nothing.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers