4 ms·
So look at how the data is broken down: > Drive: HL-DT-ST - BD-RE BH14NS48 (116 users): Submissions: 10260 accurate, 23 inaccurate, 99.7763 % accuracy 23
by nickelpro 4y ago
So look at how the data is broken down:
> Drive: HL-DT-ST - BD-RE BH14NS48 (116 users): Submissions: 10260 accurate, 23 inaccurate, 99.7763 % accuracy
23 of these submissions come from a broken drive, or the disc is damaged to the point a correct read cannot be made. It's not that the drive is producing 99.7% accurate data, there are 10260 100% accurate submissions and there are 23 wrong submissions.
It's a binary state, either the drive is functional and the CD in decent condition, or the drive is broken/CD is damaged. Some drives may have a higher failure rate than other drives, but every drive is either 100% accurate or busted, there is no 95% accurate drive. That's just a broken drive.
- mvhvv 4y agoIt's definitely unclear what "inaccurate" means in this sense? Is an entire track inaccurate if a single sample is inaccurate? In that case then yeah, rather than measuring some level of audio purity, this is measuring your likelihood of getting a perfect rip before taking CD condition into account.
- mlyle 4y ago> It's a binary state, either the drive is functional and the CD in decent condition No. How good the drive is at reading marginal discs varies a lot between drives. The problem is, these populations are not identical disks, and the error rates are low enough that we're not really sure we're seeing a good metric of this.
- kohlerm 4y agoI inclined to believe this is all non-sense. Did ever someone hear a difference or compare hashes and got sometimes an error and sometimes not?
- sandreas 4y agoAuthor here, I did (personally). CD: The Weeknd - The Highlights Drive: Pioneer BDR-XD05TB (not listed in my article) Accurate Rip reported errors on 3 Tracks. Ripping with hp GUE1N flawlessly worked on the first try. Although I also doubt that the error would be audible, but I have a better feeling if the hashes are correct.
- rossy 4y agoI did it with a simple program that just issued READ CD commands to the drive using SCSI passthrough and saved the first ten minutes of the disc to a raw PCM file. Running that program twice produced two files that sounded the same to me, but had different hashes (and it wasn't a "sample offset" issue either.) The disc had no visible scratches, and it was the same drive that I'd ripped half my music collection from with EAC, so that experiment was solid evidence for me of what the proponents of secure ripping software like EAC keep saying, which is that read errors when burst-ripping on consumer drives are very common.