I have always kept the iTunes "Use error correction" box set when importing CD's. I have been unsure of how well this works, though I also use a TOTL external Plextor Plexiwriter Premium which has the most advanced features including error correction--in this case meaning that a track is read over and over until the internal validity checks show no hard errors. I believe this combination of iTunes on Mac with "Use error correction" and a drive capable of re-read such as the Plextor gives you accurate reads or at least it tries hard to give you accurate reads.
Most discs read without a problem, especially recently. I also manually read every disc twice and diff the files. I have scripts which do this quickly for an entire album read twice. People have asked: are you sure you aren't just getting the same garbage twice? But I believe in most cases the answer is no. This "twice reading" is exactly what the computer drives themselves do, and special high accuracy reading programs too (though nowadays the most special programs also check against online databases).
Today I had some kind of near proof. While reading in an old disc, the Plextor was buzzing more than usual. And it seems reads were not at the highest possible speed, only around 15x. Finally, on the last track, the high speed scanning stopped near the end of the track. From that point onward, it read very slowly, at something like single speed (during that time speed was not reported). It did finish the track, however, and I ultimately read in the CD twice completely.
Sure enough, I got differences between the last two readings of the last track.
This shows that iTunes error correction does not guarantee a correct read, though it seems like with the Plextor it did seem to try (if that is what it was doing). But in spite of best efforts, if a correct high speed read cannot be done, it goes with the best slower speed re-read it can do. And I have one more datapoint that when this was obviously happening, my difference method caught it too. I have caught other differences like this too, and it seems whenever the drive is going through fits like this I get differences, which isn't proof that my method works but it does seem like it is.
I read this disc many times with and without error correction. Not once did the diffs for the last track match according to script. When at I disabled "Use Error Correction" it read the last track straight through without slowing down, and all three times. When I switched Error Correction back on, it continued reading the last track straight through for the next few reads, then went back to slowing down on the last track.
Doing this more than a dozen times, the last track checksum value did match twice, but only in the "second read" I discarded before getting the next one because my scripts work that way. Really what the script should do is record checksum scores and keep all reads until you get two having the same checksum. But once I saw the matching checksum, I couldn't get that same matching checksum in the next 4 reads and gave up.
All this tends to confirm my reading strategy of diff'ing files helps catch errors. At least in some cases, the "fill-in" data after reading errors usually doesn't match in cases like this where they don't match once. It's still possible in cases with different kind of errors they would always match, though I have no evidence for that.
Most discs read without a problem, especially recently. I also manually read every disc twice and diff the files. I have scripts which do this quickly for an entire album read twice. People have asked: are you sure you aren't just getting the same garbage twice? But I believe in most cases the answer is no. This "twice reading" is exactly what the computer drives themselves do, and special high accuracy reading programs too (though nowadays the most special programs also check against online databases).
Today I had some kind of near proof. While reading in an old disc, the Plextor was buzzing more than usual. And it seems reads were not at the highest possible speed, only around 15x. Finally, on the last track, the high speed scanning stopped near the end of the track. From that point onward, it read very slowly, at something like single speed (during that time speed was not reported). It did finish the track, however, and I ultimately read in the CD twice completely.
Sure enough, I got differences between the last two readings of the last track.
This shows that iTunes error correction does not guarantee a correct read, though it seems like with the Plextor it did seem to try (if that is what it was doing). But in spite of best efforts, if a correct high speed read cannot be done, it goes with the best slower speed re-read it can do. And I have one more datapoint that when this was obviously happening, my difference method caught it too. I have caught other differences like this too, and it seems whenever the drive is going through fits like this I get differences, which isn't proof that my method works but it does seem like it is.
I read this disc many times with and without error correction. Not once did the diffs for the last track match according to script. When at I disabled "Use Error Correction" it read the last track straight through without slowing down, and all three times. When I switched Error Correction back on, it continued reading the last track straight through for the next few reads, then went back to slowing down on the last track.
Doing this more than a dozen times, the last track checksum value did match twice, but only in the "second read" I discarded before getting the next one because my scripts work that way. Really what the script should do is record checksum scores and keep all reads until you get two having the same checksum. But once I saw the matching checksum, I couldn't get that same matching checksum in the next 4 reads and gave up.
All this tends to confirm my reading strategy of diff'ing files helps catch errors. At least in some cases, the "fill-in" data after reading errors usually doesn't match in cases like this where they don't match once. It's still possible in cases with different kind of errors they would always match, though I have no evidence for that.
No comments:
Post a Comment