Nero CD-DVD Speed 4.50 released with CLV/P-CAV scanning speeds for BenQ drives

Sorry for the late response - I tried scans using 4x CLV and 8x P-CAV and there was not a significant change, the high jitter levels still effect the results in a similar manner. I also scanned the disc at 8x in the Liteon, which is CAV instead of CLV as the 4x scan is, and the results were quite similar, a mild increase in overall errors but the overall scan result is about the same.

This is an extreme case and points back to the high jitter, with Liteon burns of lower jitter, discs scan similar in both drives.

It's not an issue with the 1640 either, at least with BSLB.

I have been using my LiteOn based DRU-710A to do all my scanning and media test before I got my dw1655. On the 710A I always scan at 4x for DQ test so now with CD/DVD Speed 4.50 if I use 4x CLV they should be more comparable right?

I know that there are differences in how various drives compensate for and report errors and they will never be exactly the same. It just seems it is better to scan at a constant speed to eliminate that as a variable to the results.

Not a full disc but here is a 4x CLV scan

A simple Transfer Rate Test (that olmost any DVD/DVDRW drive is able to perform) would have revealed readability of your (now) unreadable discs.
No need for "2 burners".

8x P-CAV sometimes may to produce higher PI level and jitter at the beginning of disc, at the CAV part (vibration? ).

8x CAV, 4x CLV, 6x CLV, 8x P-CAV scans from the same disc.

Same disk, bad scan at 8x now ok with clv or p-cav?
I returned this batch of media because of terrible burns, (some had massive POF at the outer edge) now I'm not sure if I should have.
Which scanning method would be deemed most representative of the actual disk quality?

Thank you for taking the time to check this. I don't normally hang around the BenQ forum, but try to make some sense of what's going on in the scanning game (aone of my major interests). I've been following this thread but am staying out of the discussion of accurate or inaccurate in this non-exact "science").

G

I, too, noticed this strange discrepancy between P-CAV and CAV with some discs that I had put aside because of a rise in PIE/PIFs near the edge. That's a difficult question and I'm not sure we'll have a definitive answer...

On one hand, P-CAV is in theory closer to the way scans "should" be performed according to ECMA recommendations, as according to these, scans should be performed in CLV. And 8X P-CAV is actually, here, CLV for the most part...

On the other hand, when performing 8X CAV scanning, the increase in errors near the edge is certainly not something that happens with most discs! So if some discs show this increase, there must be "something" causing it, that the CAV scans catches, and the P-CAV ones don't.

What baffles me is that the difference in scanning speed between P-CAV and CAV, in the area where problems arise with the aforementioned discs, near the outer edge, is negligible ( < 0.5%). That's the moments when I feel totally ignorant.

Another test done burning an ISO image with cd-dvd speed 4.50. I did two scans, 8x CAV and 8x P-CAV. It seems to me that results are the same, but P-CAV require less time do complete scan.

I think also that my LG don't like these media; maybe a bad batch (the same disc burned with liteon give results that I don't like too much )

Sorry if it's off-topic: I burned these discs with my LG4167 but I posted here because I did scans with benq 1640, to compare results between 8x CAV and 8x P-CAV. I think that results are consistent, and that there are no significative differences between the two scans.

Brand: Verbatim -R 16x (Made in India)
Mediacode: MCC03RG20
Burner: LG 4167 DL13
Software: CD-DVD Speed 4.50
Burnspeed possible: 2x - 4x - 8x - 16x ( firmware don't have a strategy to burn these discs @12x???)
Burnspeed selected: 16x
Booktype: -R
Burning time: 5:28
Reader: BenQ 1640 BSLB
scan 1 = 8x P-CAV [scan time 7:22]
scan 2 = 8x CAV [scan time 9:43]

It's fine geno888. It doesn't need to be a BenQ burns. I'd love to see scans on various media made by other burners as well.

This may be an early observations, but from my experience and what I've seen so far here, the variation between 8x P-CAV and 8x CAV only exists on some DW1640 scans at the end and/or beginning of the disc? On some scans, the 8x CAV will show high PIF and/or PIE and it doesn't appear on 8x P-CAV...

BenQ 1650/1655 seems to report consistent error rates on various speed scans.

Thanks zevia

Do you think that 8x P-CAV is a valid choice based on results seen until now?

EDIT: you preceeded me

My current opinion on this, based only on scans of several YUDEN000 T03 discs burned at 16x in a BenQ 1655 with different SolidBurn/WOPC settings, is that the start/stop dips when scanning cause phantom PIE/Jitter spikes to appear, which makes it hard to get an "accurate" scan.

These start/stop dips for me on my 1655 are worse at 8x P-CAV and 8x CAV than they are at 6x CLV, so my current choice would be 6 CLV as scanning speed.

Except for the phantom PIE/Jitter spikes at the start/stop points, there is usually little difference between the PIE/PIF/Jitter values at these scan speeds, except perhaps at the very beginning of the disc.

Maybe I should perform some scans of media burned in my other burners to see how the various scanning speeds affect the result?

Do someone was able to determine definitely if these start/stop dips are firmware or hardware/software related? I never had similar issues with my 1640 fw BSLB, but many have this issue with newer firmwares.

The dips are firmware related. BSLB is one of the firmwares doesn't have this issues. This bug reappeared in the newer firmwares (this is the reason I never upgraded to a newer firmware).

I saw 1 speed dip on my dw1655-BCDB in version 4.11 around 148MBs everytime, I tend to believe it is FW as well.

Not sure if someone already posted this cosmetic bug in 4.50 but here is a results capture. Pretty good scan at 51x

But they are not only related to firmware. The CDSpeed version also plays a significant role!

Using the same disc the same burner and the same firmware, here are three scans at 8x (CAV).

1. CDSpeed 4.11 before installing 4.50
2. CDSpeed 4.50
3. CDSpeed 4.11 after installing 4.50

The 4.11 scans only show 1-2 dips, while the 4.50 scan shows 22 dips!

It has been reported in the media testing forum. http://club.cdfreaks.com/showthread....72#post1333272

Ah, thanks. I need to go read that one as well.

I tend to believe the existence of scanning dips depend on CDSpeed, firmware and the drive/system.

My 1650/1655 does not show repeated dips on 8x CAV.

I might have been a bit premature in declaring 4.11 to be better at avoiding dips when scanning at 8x CAV. I re-scanned the same disc with CDSpeed 4.11 a third time, and this time I got 22 dips just like with 4.50!

There might be some random factor involved as well.

DrageMester: I think you better check your system, IDE cable, move around the drive (Master/Slave) or perhaps reflash? I browse the 1655 scan thread again (quick browse) and don't see any scanning dips on 4.11 and 1655.

No. When this issue is fixed (like in BSLB), you don't get even one dip.. no matter what speed you choose. The firmwares that have this issue always show at least 1 dip.. but can always have more. 16x scanning on such a firmware will almost every time have continuous dips.

What are this dips actually? During scanning the drive suddenly stops sending data (and spins down - like the scanning has ended) and the program must reinitialize the scan (set to the location where the scanning has stopped and spin up again). It doesn't matter what program you use.. but may depend on hardware and the drive itself how may times the drive stops sending the data. However as I said above 1640 BSLB (and some other releases around BSLB + 1620 B7W9) doesn't have this issue no matter what drive you use or which program or what hardware you have. This issue in those firmwares is really fixed.

My drive has the same dips with this new version and has had some with older versions too. I think its a bug between the drive and the software and hopefully one end or the other will figure it out soon.