Official K-Probe Discussion (Tool for Scanning C1C2/PIPO)

[Halc]

I get an access violation with Kprobe 1.1.21 when scanning a really problematic cd-r disc (finalized, one session).

Kprobe starts scanning it, but then starts jumping to next LBA and hogs 99% of my CPU time.



I'm running proper Adaptec ASPI on standard IDE PCI controllers on nForce2 mobo. Drive is LiteOn 48246s (with 52246s firmware).

I have had no other problems with 1.1.21 (except that speed of scanning is not always 48x, but lower, even if I manually set it to 48x).

Please don't take this as a criticism. Just FYI.

Thank you for the excellent utility, Mr Wang!

Best regards,
halcyon

[dolphinius_rex]

Re: CD-RW sizes not showing up properly

Nope my CD-RW was not formatted, just straight out of the package (and no, not the a pre-formatted package)

[rdgrimes]

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]

I noticed the same problem as rdgrimes.

Also, KProbe won't work for me when the CD-RW drive is attached to a PCI IDE controller.

[cfitz]

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.

I noticed the same problem as rdgrimes.

Do you guys mean you are having problems with the Z-order of the KProbe window? In this specific case, are you saying it insists on always being on top of all other windows when it is visible? I haven't seen this problem on my Windows 2000 box with 1.1.21.

It is really strange that a problem like this would happen on some machines but not others, since control of Z-order is such a basic function. Mysterious...

cfitz

[rdgrimes]

I haven't seen this problem on my Windows 2000 box with 1.1.21.

It only happens here after the scan has completed.

[cfitz]

At first I was going to write "Ah! That explains it. The only time I ever cover KProbe with another window is when I am reading something while the scan is underway, but after the scan completes I look at the results and then close KProbe. Thus, I wouldn't ever see a problem after the scan completes."

However, now that you have given more details, I tried waitng until after the scan completes, and I still don't see the problem you and CDRecorder are reporting. Still mysterious...

By the way, I am running Windows 2000 SP4, which I think you are also.

cfitz

[dolphinius_rex]

Regarding my last post about the CD-RW sizing not being correct on K-Probe 1.1.21..... umm, I was wrong, sorry!

Somehow my copy of 1.1.20 ended up in my 1.1.21 folder, I have *no* idea how, and I made the mistake of confusing 1.1.20 for 1.1.21. So when I noticed what I had done, I downloaded the proper 1.1.21, and re-tested the same CD-RW, and yes, it is setting itself to the correct disc size

again, *SORRY*

[MediumRare]

I haven't seen this problem on my Windows 2000 box with 1.1.21.

It only happens here after the scan has completed.

I'm essentially with cfitz on this one- both on how I use KProbe and on keeping it in the background. I'm running XP home SP1, but I don't think that makes a difference.
I've observed the following;
- start a KProbe scan, then activate another application "X"
- KProbe goes in foreground with scan results when finished
- I can click on "X" window any number of times, KProbe is still in foreground
- click on KProbe window once and it behaves normally afterwards (goes in the background when I click on "X")

I think this is eminently reasonable behaviour!

G

[Halc]

Mr Wang,

I have another problem with Kprobe 1.1.21:



Look at the C2 graph and the number of C2 error reported. There is a mismatch (?).

The same disc run in CD Speed (v.2.02) / Surface Scan using the same LiteOn drive:



Why is the C2 graph showing errors, but the C2 counter is not reporting any? Subsequent scans in Kprobe 1.121 show no C2 errors in C2 graph or in C2 count (that is, both are zero).

Any news on the "Access violation error"? I can reproduce it at will, meaning it is always there in 1.1.21 if I scan a disc of bad enough quality?

Best regards,
Halcyon

[MediumRare]

Look at the C2 graph and the number of C2 error reported. There is a mismatch (?).

Halc- are you sure that this is really a C2? A red line shows up in your C1 window too. Have you chosen red to display read errors?

G

[Halc]

>>are you sure that this is really a C2?

I don't think there is actually a read error that constitutes a C2 error on that disc.

Subsequent tests on that and other drives have failed to produce any C2 errors.

>>A red line shows up in your C1 window too.
>>Have you chosen red to display read errors?

I have set up my KProbe as follows:

Line1 color: clGreen
Line2 color: clBlue
Error Color: clRed

So, you are right!

That means that Kprobe reported an "error" and draw that in the graph?

But what is an "error" in Kprobe terminology as opposed to C1 and C2?

I mean all uncorrectable symbol errors at C2 level are also C2 errors (well, its a matter of terminology, but usually they are considered as such).

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?

Thanks for noticing it, mediumrare!

cheers,
Halcyon

[MediumRare]

But what is an "error" in Kprobe terminology as opposed to C1 and C2?

See (for example) this recent post by rdgrimes: http://www.cdrlabs.com/phpBB/viewtopic.php?p=72823#72823

The error display was introduced here: http://www.cdrlabs.com/phpBB/viewtopic.php?p=61165#61165
and Karr explained a bit here: http://www.cdrlabs.com/phpBB/viewtopic.php?p=63383#63383

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?

See above. I think Karr Wang elected to place the read errors in both windows (I normally have them combined). I chose an amplitude of 100 for these, so there's no chance of missing them (I've only encountered them on really bad discs to date).

Thanks for noticing it, mediumrare!

You're welcome!! This is the thread I try to keep up on!

G

[rdgrimes]

I've been able to duplicate the speed downshift (scanning at 52x) on my 52327S drive, same as the 6S drive. It occurs only with high C2 error rates, and thusfar has only happened late in the scan. But it does also downshift to 32x to complete the scan.

[cfitz]

Hi Karr,

There has been a discussion going on in another forum here regarding DVD testing tools, including KProbe:

http://www.cdrlabs.com/phpBB/viewtopic.php?t=12034

Part of that discussion has centered around what KProbe is actually plotting for PI/PO errors. Here is the definition of PI errors according to the ECMA 267 standard:

A row of an ECC Block (see clause 18 ) that has at least 1 byte in error constitutes a PI error.

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?

The ECMA 267 standard further goes on to say:

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

[CDHero]

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?

Default , drive report PI error per 16 sectors(1 ECC block)

The ECMA 267 standard further goes on to say:

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

KProbe report errors on 1 ECC block basis,so if you want to get errors on an 8 ECC blocks , you must select PI/PO sum 8 ECC blocks , Kprobe will sum 8 errors reported by drive to 1 error and save it as 1 record and plot it.[/quote]

[cfitz]

Thanks Karr! Boy do I have egg on my face (meaning that I am embarrassed) . I see on your web site that you added this feature almost three weeks ago when you released version 1.1.20. Nice anticipation! As for me, I need to pay better attention.

By the way, when we use the PI/PO Sum option, does that set a feature within the MediaTek chipset so that it calculates the sum and delivers the processed data, or do you do it in software from raw data returned by the MediaTek chipset?

In defense of me not noticing this nice new feature, I will plead that I haven't been doing any DVD testing, and in the release notes posted here at CDRLabs (but not the ones on your site) the PI/PO summing over ECC blocks wasn't mentioned as a new feature, just the read EEPROM:

http://www.cdrlabs.com/phpBB/viewtopic. ... 3738#73738

Also, the drop down box that lets one select how many ECC blocks to sum only shows up when a DVD is in the drive:







Wow! The sum over 8 ECC blocks sure makes my cheapo Cheerios DVD look bad.

cfitz

[cfitz]

Okay, let me try with another suggestion. I don't think you have already implemented this one, Karr.

Since the reported error levels for DVD testing vary considerably depending the number of ECC blocks selected for the PI/PO Sum, could you include the value of this setting in the summary header at the top of the saved test result graphics files?

Thanks,

cfitz

[Halc]

Very good work cfitz and thanks for the information Karr!

Have I understood correctly that while DVD specification has a limit for random PI errors per eight consecutive blocks (just as explained), there is no limit for PO errors?

However AFAIK, PO error limit for DVD+R is 4 uncorrectable PO errors per one ECC block (not eight consecutive ECC blocks), after the PI stage.

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?

Also, I wonder if the PI error count is RAW error count (before error correction) and if PO is remaining error count (after PI error correction)? If they are, then we can use the data for above comparison.

I'm still a little confused about all the standars and may have made mistakes, so please bear with me and my ramblings.

Thanks again for additional information!

best regards,
halcyon

[dodecahedron]

sorry if this is a silly question, but do you mind clarifying?

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?
and 1 PI error is one row with a at least one erroneous byte?

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?

yes, that is a very good idea (= a good suggestion for Karr).

[CDHero]

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?

Thanks all of you , I will do my best !

[cfitz]

sorry if this is a silly question, but do you mind clarifying?

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?

http://www.opticaldisc-systems.com/2002NovDec/DVD82.htm

The actual ECAM 267 standard may be downloaded here:

http://www.ecma-international.org/publi ... ma-267.htm

Look on page 19 (page 29 according to Acrobat's way of thinking) for the definition of a PI error, and page 25 (page 35 to Acrobat) for clause 18 showing the ECC block layout.

and 1 PI error is one row with a at least one erroneous byte?

Yes.

cfitz

[dodecahedron]

thanks!

[cfitz]

You're welcome.

cfitz

[cfitz]

Thanks all of you , I will do my best !

We should really be thanking you, but, you're welcome. I'm looking forward to your next release. Let us know if we can do anything to help.

cfitz