speed47
commented
3 years ago I did a few tests and never observed that! Could you maybe share a photo of your CDROM, so that I can try to reproduce the same thing? I have a few CD-Rs to spare.
Closed averov90 closed 2 years ago
speed47
commented
3 years ago I did a few tests and never observed that! Could you maybe share a photo of your CDROM, so that I can try to reproduce the same thing? I have a few CD-Rs to spare.
averov90
commented
3 years ago Unfortunately, I didn't have a broken disk. However, the test disk was not even one and all showed incomplete recovery. After a series of tests, I realized that the problem was in the program.
The RS03 discs has already been discarded. However, I can say that this disc was made by Verbatim (exactly the same as in the attached photo):
The dvdisaster settings were as follows (the program does not support switching languages, so there are pieces of text in Russian):
For simplicity, in recent "damage" tests I have drawn circles on the disc with a red disc marker. This made it very difficult for the laser to read the painted parts. And my marker also supported the "erase" feature (this is a marker defect), so that I could erase the drawn circle, after which the stained area was read again.
The surface of the non-soiled disc looked something like this:
And the surface of the stained disk looked like this (points added through Photoshop, but in reality they were about the same):
In fact, there weren't many scratches on the discs tested. More precisely, there were no scratches at all. There were only red points (or even one point).
The disk from the photo is the RS02 algorithm test disk. This disk is simply not readable completely due to the frizzy paint (you can see the remnants of a red stripe in the upper part), but thanks to redundancy, the data is completely restored.
speed47
commented
3 years ago So, I recreated a data disc as close as I could than yours, with the information you provided.
I created an ISO with random files in it, with a size of 567 MB, so that when I added RS03 correction data to it, I ended up with 22.6% redundancy (47 roots), exactly as you did:
Then, I burnt this ISO file to a CD-R, and asked dvdisaster to read the data from the CD-R:
Interestingly, my CD-R already has a few read errors at the end (the CD-R I used is a bad noname quality, so this is to be expected). The error is in the ECC range, so the actual data is okay, as can be seen with the "verify" button:
Then, I added 3 red spots with a marker, roughly to the same locations than yours, here is a photo of the disc:
Now, reading it again with dvdisaster. As expected, we get more errors zones:
Now, let's use the verify button so that dvdisaster validates the image, each data/crc/ecc block it contains, and tells us whether it thinks this is repairable:
Apparently it is! Let's go ahead and use the "fix" button:
The data is recovered. This graph looks very different from yours: you never have less than ~15 errors, on all blocks it seems. My guess here is that you had a bad burned disc (aka toast), and that so much of it has been unreadable from the start, even without scratches or red spots, that the ECC data added by dvdisaster can't possibly save it, as can be seen by the constant ~15 errors on each and every block. Did you try to read the disc right after burning it, and before applying the red spots to it?
averov90
commented
3 years ago Yes, I tried it. It was read completely and without speed drops. It is worth saying that I used imgburn with the lowest write speed allowed. I chose the minimum allowable speed among those supported by the disk.
I have spoiled discs in many ways. Starting from laying the disc in the sun, finishing adding scratches and freezing it in water, as well as chewing discs under an ultraviolet lamp. All this was extremely ineffective. Maybe lay the disc under the lamp for a couple of months, it would give results. I also tried to "brew" the disks. At a temperature of about 90 degrees, the disks were actively deteriorating. Only 1 disc withstood boiling for 30 seconds at 90-100 degrees Celsius and could be read. And it was on this that I first discovered the strange behavior of dvdisaster. Other discs did not survive: some had the foil peeled off, some were extremely rusted due to moisture on the reflective layer, one disc exploded in the drive...
Eventually I came up with an idea with markers. And it worked. To be honest, I do not understand why problem not reproducing. Perhaps the point is really that the dots are too small. It is also worth mentioning that I drew not only dots, but also rectangles. Including rather large (about 1 cm^2).
However, I repeat, I have a magic marker that can be erased from the disk with any rag. If your marker doesn't wear off like this, add redness slowly.
Also I noticed that in your speed graph (link), the speed never drops to zero. I was falling. It is worth clarifying that I did not weld the discs that I tested with the marker. I did not scratch them or freeze them. I just drew on them. I wrote about other experiments to the question of the quality of disks. They are really good. Even 15 seconds at 100 degrees is a victory (given that the official threshold is 90).
The experiment with markers as a whole was repeated many times. There were always sharp peaks. It seems to me that such a sharp peak is clearly something that should not be in normal operation. And besides, I gave above the statistics of one of the disks (the last one). Still, he had to recover to the end in theory.
If it doesn't work for you, I can try to reproduce the problem myself again. Only in this case, I do not know how to transfer data.
P.S. On this picture: link i've selected SSE2, BUT in my case have being selected other variant - auto. As I can to remember, dvdisaster used a SSE2 (as it displayed me), but I can't guarantee, that is was a REALLY what the dvdisaster used.
speed47
commented
3 years ago I added some more red marks, up to getting this result in the read phase:
After the first read cycle, the verify phase said that it had too many errors to be repaired. So in Options > Read attempts, I went from "skip 16 sectors after read error" to "skip 0 sectors after read error", and relaunched a read phase. It went and tries to read the missing sectors without skipping any. It took some hours before reading correctly just enough sectors for the repair to be possible (I stopped it before it reached the end of the disc a second time), and the verify phase was now like this:
And the repair phase:
After repair, the verify is flawless:
So I can't seem to be able to reproduce your issue :(
If you're willing to try it again, please grab the latest version (patchlevel 9), it doesn't have many differences, but adds more verbose log output in the read phase. To enable logging, please go to the Misc tab of the options, tick "Verbose logging" and "copy to log file". Of course, you can choose the log file location as you see fit. Maybe in this log it'll become apparent why you have these red spikes on 7 of your ECC blocks.
averov90
commented
2 years ago I recently returned to the topic of disk redundancy and ran my experiments again. This time I took the newer version for the recording of the disc (https://github.com/speed47/dvdisaster/release/tag/v0.79.10-pl1).
Here is the log record:
Here is the check log immediately after recording:
Next, I gave a disk a little lie under the straight sunshine. Later painted several points and performed reading on the same version. When reading, damaged sectors were reset. However, an attempt to restore was completed successfully. I painted a different number of points of different sizes, but earlier the error no longer appeared. After that, I took the old version: https://github.com/speed47/dvdisaster/releases/tag/v0.79.6-pl8
The results were as follows:
After starting, the correction got the following:
Unfortunately, I could not reproduce the problem again, although I took enough attempts. Probably the error is not reproduced due to the fact that I performed the addition of the image in a newer version.
Probably the problem was in the algorithm that complemented the image of the error correction data. In the new version, this error apparently corrected. I will hope for it :)
As far as I understood, RS03 is still at the stage of development (there is a remark about it in the program), so it's not worth using it on a serious basis.
I noticed that when using the RS03 algorithm, redundancy is less than when using RS02. RS03 turns out less roots.
Why is this happening? It turns out, the RS03 algorithm is less effective?
speed47
commented
2 years ago Thanks for the detailed report. It's nice to see that you couldn't reproduce the problems you had previously, and that RS03 seems to work correctly for you now. About RS03 maturity, the original author recently removed the mention of "work in progress" on this codec, so it can be considered as complete. Now, RS02 has been around for a longer time, so you might consider it as more mature, it's really up to you. You are correct in noticing that RS03 has slightly less error correction data available compared to RS02. This can be seen in the quick comparison table on the front page, under "space efficiency", you'll see that RS03 has 4 stars, while RS02 has 5. This is, however, completely normal: this is the "price" to pay for increased resiliency. Indeed, RS03 is more resistant to corruption, as there is no "master block", as this is the case for RS02. This means that corruption can happen anywhere on the media, if you've been using RS03, then error correction data will still be found no matter what. With RS02, if you're very unlucky and the corruption happens on the master block, then RS02 correction data will not be found, even if it's present and could be used. So, that's all really a matter of personal preference and the tradeoff you want to make. That's also why RS01, RS02 and RS03 are all available and supported: you get to choose which one fits your preference, as each codec has its pros & cons.
averov90
commented
2 years ago OK, thanks for the clarification. Now this issue can be considered closed, since the problem been solved. Thanks.
I used the latest release version (0.79.6 patchlevel 8).
I checked the work of this program on CD-R before the clean recording and found out that the RS03 algorithm does not give full recovery for any damage (even small).
I have a CD-R 703 MB with 80% fullness was supplemented to 701 MB with 22.6% redundancy (47 roots) using the RS03 algorithm.
After that, on the working surface of the disc, I draw a small red circle with a disc marker. The program cannot read some of the information and is forced to restore the image using ECC.
In this case, 94.9% of all sectors were successfully read. The "corruption" was in the middle of the disk, before the start of the ECC segment (I suppose), so the restore should have returned the entire image to me. However, the data was not fully recovered!
Only 19393 sectors were damaged, but only 92.5% were recovered as a result. Redundancy - 20% of all disk space. Ultimately, 1449 sectors were not rebuilt. Because of this, I did not receive all the information that was originally recorded. Why weren't the mistakes corrected? (I assume this is a software bug.)
A software problem is also hinted at by the error correction graph (attached). Oddly enough, recovery errors are spike-shaped and repeat at roughly equal intervals.