It became apparent while perusing any of the threads with Disk Quality Posts that the PIF totals listed and the Graphed totals (count and add them up) rarely agree. The listed totals usually are higher than the graph totals. When watching a scan in action, occasionally the graph spike won’t spike as high as the listed total goes up. This renders the Quality score inaccurate, as the spikes arent reaching the amplitude necessary to justify the increase in the listed total. Presently, PIF amplitude determines Disk Quality Score. Only having a 1620, I can’t say this is drive specific or a Nero Cd DVD Speed problem in general. However, take Disk Quality Test scores with a grain of salt until it can be determined which depiction is accurate.
Errr, you can’t add it up from the graph. There are far too many ECC blocks for each to have a discrete vertical bar. Each column of pixels ends up representing hundreds of error samples.
I have used Disk Quality Test and some of my best scores not even play on my stand alone dvd player while some bad scores work fine so i dont put any stock
in those Disk Quality Test there very unreliable
rugger, look at any of the “Hall of Fame” posts where the PIF toatals are low enough to manually count and please explain to me how your expanation is valid. I’d like to understand.
Maybe I can explain, I’ve seen the same issue with Kprobe and my Liteon. It’s basically a resolution issue…with Kprobe you can delete the highest value spike. Some spikes appear to be single lines but are actually multiple, consecutive spikes that require 2 (or more) deletions to remove. The graph just doesn’t have the resolution to represent both spikes. Even if it did, your eyes probably couldn’t at that size.
This will be even more evident with CDSpeed, since the graphs are physically smaller than Kprobes. I think if you watch a scan, you’ll only see a spike drawn when the error count is going up…many times the count will go up more than the spike…this is actually 2 or more lines graphically “overlayed”.
These graphs are typically not used for counting total errors. They are used to represent consecutive, un-correctable areas on the disk. This helps to see problem areas on that disk. A 40 count of total PI errors sounds like a good burn, but if they are 2 - 20 consecutive spikes, then you’ll have a nice skip on that disk at the location of those spikes (which may look like one spike on the graph).
The highest value of ~45 samples are one line in the graph… because graph length is 400 pixels and maximum sample count if scanned at 8 ECC is ~18000 samples.
At 1 ECC maximum possible sample count is ~144000 samples (8 times higher)… so one line represents the highest value of ~357 samples.
Okay, Quikee and Hawseman, I got it. Thanks!