zebraxor wrote:The problem was resolved as of last night:
I don't think so- I haven't signed up at your bug-track site, but the following description doesn't fit:
nicw wrote:The discrepancy is simply that the scanning speed option in DVDInfoPro is broken and its scanning speed is fixed at 2x.
if you re-run the tests with cdspeed fixed @ 2x you will see the values are equal. The error rate skyrockets at higher scan speeds.
Sorry, I have to disagree with that on both counts, at least for my drive and the version of DIP I'm using (4.5.0.3):
1. I did 2 further scans of the same disc with CD-Speed: one @2x (really 2.5x) and one @1x (all with the same scale). I'll also repeat the 4x scan, since this is posted in a
different thread.
The PI Sum 8 distribution doesn't differ significantly from the 4x scan, nor does the total count. The PIF count actually
increases with lower scan speed. I've seen this before, though I don't usually do low-speed scans (they just take too long). A bigger differemce in the pattern of PI-values usually comes when going from 4x to 6x (CLV to CAV).
2. I reran the DIP scan and timed it. Apart from the 4x CLV trace in the diagram, the elapsed time (13:50) also speaks for a 4x scan, not 2x.
So the similarity of the PI Sum 1 KProbe scan and the DIP results (as shown in the
original post) still indicate that
DIP did a 1 ECC, 4x scan.
Now I want to elaborate on the other point I mentioned: the total and average values. Dolphinius_rex sent me some scans from a LiteOn 1635S in the meantime and they show exactly the same behaviour (his BenQ scans look consistent between CD-Speed and DIP, so it looks like a DIP/LiteOn problem). His remarks indicate that he didn't understand the point I was making so I want to elaborate it a bit.
Basis is
this remark by Erik Deppe on how CD Speed calculates averages:
Only the maximum value of a certain range is plotted on the graph. The average is calculated from these values. So it's more the average of the values which you can see on the graph.
The problem with the averages is that it depends what you're averaging.
CD-Speed uses a display with ca. 420 pixels width to show the PI/PIF counts. There are > 140,000 ECC blocks (@ 16 sectors) on a disc. For PIF, there are ideally as many samples (in practice fewer because not all ECC blocks are counted), for PI Sum 8, 1/8 that value (17640), which is still much larger than 420. Now obviously you can't display all these numbers, so you group your internal counting bins in 420 display bins and determine a representative value to display. Each displayed value stands for over 333 (PIF) or ca. 42 (PI Sum 8 ) basic values.
One procedure, which most tools seem to use, is to display the
maximum count in the group.
Now obviously, if you only show the maximum value in a display bin, the count look more dramatic than if you show the average. It's a choice an author has to make, and personally I think showing the max. is OK if you don't want to go the extra mile that alexnoe did. Alexnoe uses a modified approach in his tool to show more information: he varies the intensity of the line in accordance with the peaking factor (maximum/average) of each bin. As a result, the PxScan displays look finer and more delicate than the simple line- or bar-graphs used elsewhere and consequently represent the available information better.
I consider it problematic when you use the
displayed values to determine the average (or worse yet) the total counts. CD-Speed does the first, DIP seems to do both for LiteOn drives (see e.g. the PIF count I mentioned in the first post).
Consider an extreme case: of 42 PI Sum 8 values represented by 1 line, one is, say, 100 and the others are 1. And assume that this is the case for
every display bin. The diplayed maximum is then 100 for each display bin and the average of these displayed values is also 100. The total as displayed would be 100*420 = 42,000. But the other 41 samples per displayed value are ignored. The true total is 59,220 = 141*420 and the true average is 3.36 = 59,220/(42*420). This sampling will always
overstate the average and understate the totals. Note that this example is extreme wrt. average. If the other 41 samples were 99, the true sum would be ca. 40x greater!
This effect is apparent in comparing CD-Speed with KProbe results: The PI totals are comparable, but the average CD-Speed shows is significantly higher (8.3 vs. 5.8 ).
And the DIP scan in the original post definitely does this for PIF (you can count the values shown) and also for PI: the display is 450 pixels wide, the average = 4 and the sum is ca. 1800 = 450*4.
G
(who is off to bed).
edit: corrected overstated
maximum to
average.