


rdgrimes wrote:Minor issue: With the most recent version(s) of Kprobe, it refuses to "go to the back" when you try to use another window. I have to hit the minimize button on Kprobe to get it out of the way.
CDRecorder wrote:I noticed the same problem as rdgrimes.
rdgrimes wrote:I haven't seen this problem on my Windows 2000 box with 1.1.21.
It only happens here after the scan has completed.
Halc wrote:Look at the C2 graph and the number of C2 error reported. There is a mismatch (?).
Halc wrote:But what is an "error" in Kprobe terminology as opposed to C1 and C2?
Halc wrote:What are these 'error' lines that I see in the area labeled 'c2', but which do not count as in the 'c2 total' errors? Are they loss of synch errors?
Now I'm even more confused
Maybe this has been discussed elsewhere, but I must have missed it. Could somebody fill me in, please?
Halc wrote:Thanks for noticing it, mediumrare!
ECMA 267 standard wrote:A row of an ECC Block (see clause 18 ) that has at least 1 byte in error constitutes a PI error.
ECMA 267 standard wrote: In any 8 consecutive ECC Blocks the total number of PI errors before correction shall not exceed 280.
cfitz wrote:Hi Karr,
Can you confirm that this is what KProbe is reporting? In other words, that KProbe is reporting the number of rows with at least 1 byte in error and not the total number of bytes in error?
ECMA 267 standard wrote: In any 8 consecutive ECC Blocks the total number of PI errors before correction shall not exceed 280.
Assuming that KProbe is reporting PI errors as defined in ECMA 267, is it reporting them on a data sector basis, an ECC block basis, or an 8 consecutive ECC blocks basis? It is important to know which, since there are 16 data sectors per ECC block and, obviously, 8 ECC blocks per 8 consecutive ECC blocks. Thus, without knowing which basis KProbe uses, the interpretation of the PI levels could be 8, 16 or even 128 times off their true values.
If KProbe is not plotting on an 8 consecutive ECC block basis, it would be neat to add an option for plotting on an 8 consecutive ECC block basis. That way we could compare the KProbe results directly to the 280 maximum PI errors standard.
cfitz
ECMA 267 standard wrote:A row of an ECC Block (see clause 18 ) that has at least 1 byte in error constitutes a PI error.
Halc wrote:Would it be possible to plot A) running 8 consecutive ECC blocks PI sum AND B) 1 ECC block PO count at the same time (in PI and PO graphs respectively)?
This way we could see if the disc is within specifications (DVD and DVD+R) for that particular drive?
Halc wrote:Would it be possible to plot A) running 8 consecutive ECC blocks PI sum AND B) 1 ECC block PO count at the same time (in PI and PO graphs respectively)?
This way we could see if the disc is within specifications (DVD and DVD+R) for that particular drive?
dodecahedron wrote:sorry if this is a silly question, but do you mind clarifying?ECMA 267 standard wrote:A row of an ECC Block (see clause 18 ) that has at least 1 byte in error constitutes a PI error.
what's a "row of an ECC block" ?
each ECC block (= 16 sectors) is subdivided into "rows"? how many? how big is each?
dodecahedron wrote:and 1 PI error is one row with a at least one erroneous byte?
Return to Recordable Media Discussion
Users browsing this forum: No registered users and 1 guest
All Content is Copyright (c) 20012020 CDRLabs Inc. 