The Big KProbe2 Thread

[morpheusx]

Dont have adaptec aspi installed only aspi from kprobe
here i have 2 scans from same disc but this one's only got twice as much errors.
Lite on 811 @hsoq
traxdata dvd+r 4speed
burned and scanned at 4 speed

[morpheusx]

this with kprobe2

[morpheusx]

scan were better tried everything to get this result back (tried a lot of firmwares, tried MS ide drivers etc) but no luck
also traxdata dvd+r burned at 8x

[rdgrimes]

I think we've seen enough comparisons between KProbe1 and 2. Frankly I don't see much point in it, but if you wish to continue the discussion, please start a new thread for it.

thank you!

[Jamos]

What hes saying is just move on to Kprobe 2 and compare results between kprobe2 no sense in worrying about kprobe 1 any more. It seems krpobe 2 is more accurate. error threshold numbers will have to be hashed out based on the scan comparisons between kprobe2s.

[bichi]

Kprobe v2.0.1
- appears +RW issue is fixed: thank you, Karr and Crew!

Questions:
- if Read speed is set for 4x, "Status" section indicates read speed increase,
after approx, 16~18%, 5.1x and topping out at 7+x towards the end. Bug?

- Settings to approximate old KProbe 1.1.29 scans would be PISum:8 / POSum:4?

[rdgrimes]

- if Read speed is set for 4x, "Status" section indicates read speed increase,

Hmm, what you have there is a max speed scan, not 4x. Can't duplicate that one here. May be a drive or firmware issue, I dunno.

I notice you use real-time chart, shut that off and try again, maybe there's a bug in there.

[DiggnSaeg]

Would be nice if there was a version w/o installer (just the exe and dll).

[bichi]

Yup, turning Realtime Chart off, fixes "Current Speed indicator."
Still consider this a display bug, as opposed to speed acutally going as shown.

Otherwise, what other, errr, "entertainment" do we have whilst scanning? - hehee!

[code65536]

Having RT on also distorts the results, as you can see from your different PI results from the 2 scans.

[bichi]

eh? but RT=ON netted better averages than RT=OFF.
I would have expected the opposite...

Oh well, its all within nominal, err, statistical odds/repeatablity for LiteOn/media
variences... *shrug*

[code65536]

Originally posted by bichi2
its all within nominal, err, statistical odds/repeatablity for LiteOn/media
variences... *shrug*

My guess is that having RT on takes up resources and with KP2 spending more time updating the RT chart instead of reading errors, it could be missing errors. Just a guess...

A 4-fold difference? I guess it's within the statistics, but in my tests, if I vary drive temperature, firmware version, etc., the results have differed by no more than 25%...

[rdgrimes]

Here, RT graph consumes 85% of my CPU, compared to 5% with it off, and the error rates drop noticably with it on.

[rdgrimes]

Well the author wasn't kidding when he said not to use it.



Here's a scan completed with real-time enabled. I found that if you minimize the program to taskbar, the CPU usage stops. But running it maximized, even behind other programs, produces 80-100% CPU usage.

Now, look at the graph above. You see the big notches? The high places are where I had it minimized to taskbar and CPU use droppted to nil. So you can see a pretty dramatic change in the error count caused but the TR graph.

I'm convinced that it should only be used to scan a small section of a disc where you are looking for something specific. The longer it runs in RT mode, the higher the CPU use gets and system slow-downs are seen.

[Ssseth]

It makes one wonder with RT is included at all...

[Jamos]

Originally posted by rdgrimes
Well the author wasn't kidding when he said not to use it.

Here's a scan completed with real-time enabled. I found that if you minimize the program to taskbar, the CPU usage stops. But running it maximized, even behind other programs, produces 80-100% CPU usage.

Now, look at the graph above. You see the big notches? The high places are where I had it minimized to taskbar and CPU use droppted to nil. So you can see a pretty dramatic change in the error count caused but the TR graph.

I'm convinced that it should only be used to scan a small section of a disc where you are looking for something specific. The longer it runs in RT mode, the higher the CPU use gets and system slow-downs are seen.

plus look at your speed its whacked..7.7??

[rdgrimes]

Originally posted by Jamos
plus look at your speed its whacked..7.7??

It actually ran at 4x all the way through, the 7x just popped up in the last instant.

[C0deKing]

Yes the realtime has a hugh CPU overhead . Much more than KP1. I cannot understand why the realtime does not just plot the final result instead of scaling it, across the chart, based on the amount scanned so far. The overhead would just be drawing the vertical line at the place where it would appear when the scan is finished...

[rdgrimes]

DL scanning seems to be working now. This is The Matrix, scanned at max and at 4x speeds. Note that the drive reads DL 4x in CAV mode, which is a bit odd. But since there are no other testing apps that allow read-speed setting, there's no way to know if it's the drive or the program, but logic would suggest this is the drive selecting CAV.

[Jamos]

It looks like inheriently PO/PIs are gonna be higher on the second layer..is this a result of the way the laser has to read it or that the drive is using CAV instead of CLV?

[code65536]

That's very curious...

I didn't get that when I scanned a DL disc a few days ago (The Last Emperor)...

[Jamos]

Ill have to try my drive now with dual layers. you are both using different drives and bioses..maybe your not getting the cav mode like mr grimes is as I would think thats why his errors are so high or hes just got a scratchy disc.

[code65536]

It would make perfect sense for the errors to jump at the layer break... so for the moment, I'm actually leaning towards my scan being flawed somehow...

[rdgrimes]

DL scans in CLV at 2x. Here's the same Matrix DVD scanned at 2x:
Keep in mind that the DL burners may have a completly different approach.

[C0deKing]

Originally posted by code65536
It would make perfect sense for the errors to jump at the layer break... so for the moment, I'm actually leaning towards my scan being flawed somehow...

All of the DL scans that I have done have had more errors on the second layer. Personally I was not surprised by this (longer focal length and looking through the first layer).