1004/1008 and CDSpeed V3 Disc Quality Test

vbimport

#1

In previous posts, there are indication that KProbe scan on BTC drive are not exactly accurate, does the indication still hold true for CDSpeed V3 and DVDInfoPro V3(currently beta)??? I know 1108 is on the support list of CDSpeed.

I tried it on 1004, the values in PI/PO are much higher than when using LiteOn drive.

Thank you.


#2

I tried CD/DVDSPEED 3.0 today with my BTC 1004IM and im kind of confused is this test accurate or is it not the best thing to test BTC drives ?
And why do i get some strange error msg/see attachement) O.o
And what are good rates on0 the pi/po scale ?
I kinda dont get it. ^^’’

edit: i never before used that program only dvdinfopro readspeed error testing
and the drive has the neweset Firmware before that i used 0150.

edit2: weird thing i get i tested the same DVD-R now at different speeds and with lower speed (not max but 4x) i get horrible peaks at the pi/po scale O.o
General Information
Drive: DVDRW IDE1004
Firmware: 0350
Disc: DVD-R (TTG01)
Selected speed: 4 X
PI errors
Maximum: 926
Average: 131.34
Total: 436064
PI failures
Maximum: 149
Average: 7.36
Total: 24435
PO failures: n/a
Jitter: n/a
Scanning statistics
Number of samples: 3320
Average scanning interval: 42.07 ECC
Glitches removed: 16

now im really screwed i dont get the error msg at 4x read speed but at max. At max speed the errors are not so great but the test wont finish with the posted error msg.





#3

sorry wrong thread


#4

This is the result I got from BTC. I don’t have my LiteOn with me, but the I know that PI is about 180, PO has max of 3 to 4 if I use LiteOn to scan

General Information
Drive: DVDRW IDE1004
Firmware: 0050
Disc: DVD+RW (INFODISC A01)
Selected speed: 4 X
PI errors
Maximum: 1278
Average: 248.82
Total: 795821
PI failures
Maximum: 85
Average: 9.76
Total: 31222
PO failures: n/a
Jitter: n/a
Scanning statistics
Number of samples: 3228
Average scanning interval: 41.68 ECC
Glitches removed: 332


#5

ILLEGAL MODE FOR THIS TRACK = The disc is unreadable from this point.

If you get that message you SHOULD worry as that is not a good sign.


#6

According to the summary screens asdf and Clany posted the scanning resolution is low with this drive which means you cannot compare results with other drives.
Basically the PI errors are up to 5 times higher and PI failures (PO errors in KProbe) are up to 40 times higher compared with LiteOn drives.


#7

Funny the discs are 100% percent readable checked it with DVDinfopro and nero
no errors and the files are good to copy on the HD
My normal DVD-Rom Drive is a LG-8162B (not the best and the Dvd-R are working perfect)
I never had prbs with any burned medias on the BTC 1004IM and now i m confused about the results thats weird and i cant really think about it that the results are correct. O.o


#8

I notice that the BTC 1004 and 1008 are now on the list of supported drives, so I scan the discs with BTC 1004IM (0051, RPC1) and LiteOn 411s(FS0J) and CD-DVD speed V3.12

first is the DVD+RW disc, burn as Data. Only the BTC has the summary because LiteOn has issues(see last picture), appearently what I thought was a bug in KProbe with DVD+RW is actually LiteOn drive’s fault. Notice it detected ~4.4GB when BTC shows ~4.2GB. LiteOn was scan twice due to the error, I though the first scan had issues, but both time turns out have the same error. Result is slightly different though.

The only thing that is consistant base on the 3 scan is that at about middle of disc (~2.5GB area), the PI is always higher than the rest… consistant through out other disc in the batch as well.







#9

This here is DVD-R, burn as Video DVD. BTC has two scans because the first scan shows higher PI at end of disc, second shows much lower, even though they are the same disc.

I’m aware the crappy quality of Princo, but look at BTC’s scan… it’s less than the result in the LiteOn Scan…

Which is not consistant with the previous DVD+RW, where BTC shows much higher scan than LiteOn. So the previous assumption of BTC shows higher scan result than LiteOn is not entirely true here…