Today I tried scannig the same disc G04 silver top changing the read speed and turning RT chart on and off and I got pretty disappointed with KP(1.1.23 and 29).
First thnig the disc was burned and read with a 411@811 Z4 with firmware HS0K; all scans were make ECC sum 8 and for time reasons I scanned the first 10000 block at the beginning of the disc.
Scan#1: 2x, RT chart OFF, PI=45, PO=4.5 averages
Scan#2: 2x, RT chart ON, PI=34, PO=3.3 avg
Scan#3:4x, RT chart OFF, PI=33, PO=0.44 avg
Scan#4:4x, RT ON, PI=18, PO=0.2 avg
On all scans I tracked down the CPU usage and was well below the limits(4-30%).
IMHO KP has some problem of consistency and reliability. If I scan a disc at a lower speed I expect better results, but thisd is not he case(PO over 4!!!)
I’m not convinced either that scannig with RTC on gives lower errors becase of high CPU usage. I’m not new to programming and I know that in the digital world if a CPU can’t cope up with the software, the algorithm hangs or falls behind, it cannot happen that the algorithm tries to make calculations quicker and so it makes errors. Either it runs or it doesn’t.
Another thing that makes me think that is a software fault is that with RTC off the graph are flat, while with RTC on there are variation, as it should be ( we know that some part of a disc get written better of others).
I did another test with ECC set to one and guess what, turning realtime char on or off doesn’t make any differece, the graphs are very similar and so are the values:
RTC ON: PI=4.192 PO=0.067
RTC OFF: PI=4.343 PO=0.072
And this results with RTC on were obtaind with a CPU usage over 70%, this means that it is not a problem of CPU usage, as I stated before, but a software fault.
If my result are confirmed by someone else I suggest to change the default settings for the scannig af DVDs to ECC SUM 1 and maximum PI=35 and max PO=4 to be within the specs(this are obvoiusly conservative values on the PI side)
Comments and further investigation is apreciated.