Disk Quality Test Read speed spikes

Most of the time when I burn a disk I get a scan that looks like the first trace.

But last night I started to get scans that looked like the second trace.

What do all those spikes mean on the write trace? I fiddled with a few things (checked for updates to Nero CDSpeed, etc.) and in the middle of a scan they just stopped. I know it means the drive is spinning down but why? Why so consistent and repatative? Scoured the forums with little luck.


damn those are awesome burns…sorry I can not answer your question

the second is set to maximum rather than 8X and involves a different strategy.
Just set speed back to 8x

Well, OK…but the problem cleared up in the middle of a scan (during that scan-I can’t remember if I had it at Max or 8x though…I know I didn’t change it during the scan).

Could it be a sign of imminent drive failure?

From your post I gather it’s still a good burn…


It looks like an excellent burn. From a practical point of view I don’t see any difference between a burn with 46 PIF or one with 2000 PIF. Scans with low scores look pretty but I would question how much better they are than ones with higher scores. less than 16 PIF and less than 250 PIE is the book answer.
any scan with a value of 90% or more is good enough.

If you want to see a bad scan - which still plays fine goto


YUK! I’d give that to the kids for target practice!

You’re probably on to something…I just upgraded DD to 3.5.4 (or whatever the newest dot 4 version is) from the dot 2 version. My defaults changed without me noticing. I also upgraded Nero to 3.75 and its defaults changed…(everything went to MAX). I’ll check a few more this weekend.

Want to make sure the drive isn’t failiing…

BTW…TYG02 seems to burn cleanest (B7P9 FW version) at 8x…12x is a little crappier.


I think the issue is longevity of the data on the disc…
nobody seems to know how important lower really is…clearly if it is in spec it should work…but poorer quality burn the data maybe lost over time???

did you upgraded firmware between yours two scans ??

my two scans of the same disk

No, no, no…nothing like that. All I did was to update DVDD from 3.5.2 to 3.5.4. In so doing it reset all my default burn settings. My subsequent burn was at 12x…unnoticed. After the burn I checked disk quality w/ Nero CDSpeed and got a poorer quality report than I was used to seeing.

Seeing a “bad burn” with CDSpeed (and seeing that mysterious rhythmic drop in read speed), I checked to see if there were any updates to Nero CDSpeed. There were (3.69 to 3.75). Updating it did a similar thing, it reset my desired CDSpeed scan speed from 8x to Max.

My experience has been that with B7P9, TYG02, and 8x I get the best quality/time ratio…12x only saves a minute or so and the PIF’s go way up…but probably still usable.

I’m still not totally convinced that the drive is OK. I’m 85% sure that if I set DVDD to burn at 8x and Nero CDSpeed to read at 8x, I will get the cleanest quality reports. 15% of me still thinks that something goofy was going on with the drive…those spikes in the read speed mysteriously stopped during one of the quality scans…I didn’t touch anything. Maybe the read algorithm changed mid-disk or something.


miro68-in your post, which trace is read and which is write?


The trace shown in my post is the “read”…with those spikes in the read speed.


on my scans:
read => yellow
write => white

Some time ago I bought new BenQ DW1620 OEM with f/w G7H9 and flashed
it to B7P9 with WinDWFlash.exe and .cvt file.
Drive was made in September 2004.
I returned it to service due to problem with recognizing -R media on
this drive but recorded on others (NEC ND-3500, Lite-On SOHW 1653S).
As I remember I didn’t get reading spikes (sure 99%).

They replaced the drive on the same made in September 2004.
Then I flashed my BenQ using other method described on this forum.

Downloded these ones:

and change in hex editor some bytes to allow it to flash into my drive
with current firmware (B5A9 -> G7H9), picture below.

So it was like this:
G7H9 -> B5G9 -> 1600-1620_B7K9 -> B7P9

After that BenQ still couldn’t recognize -R disks from other recorders
and more I got reading spikes like you and during that drive slowed
down every spike even at 8x speed test but not always. Sometimes after
reboot I got good scan with only one spike.

Second time I send this drive to service and recieved OEM but with
B7T9 f/w and made in January 2005.
Now BenQ reads all -R disk which I couldn’t get to work before and
scans looks good, some I did at different speeds.

Maybe in my case doing DW1620(OEM) -> DW1600(B5G9) -> DW1620(B7P9)
caused this problem with spikes ???

@ miro68 and all other members, DON’T EVER mess with firmware. :a
Obviously you don’t know what you are up to.

You will find all firmwares you ever need here or at The Dangerous Brothers page.

Safest way crossflashing to different models is by using .CVT file and TDB doze flasher. :cool:

I have read elsewhere here that some people think that the order of flashing might be important. Something about leaving some areas of the eprom settings untouched, not overwriting them, blah, blah. I’m certainly not an expert but to me, burning an eprom is an all or nothing endevour. It’s a matrix of hex numbers. When you burn one you burn them all. I don’t think there is any higher order alogrithm that looks at certain bits and leaves them. Your burning the entire eprom. So why would the order matter…unless your burning software cared!!! This leads to:

Much has also been said about only being able to burn in a certain order. Me thinks that some of the burning tools are hard-coded to only allow a burn if it sees a certain prior version. But other burning software (Dangerous Brothers) don’t care what FW is in the eprom. They don’t check. You can burn whatever you put after the switch to whichever eprom you want (dangerous but if you’re careful not too bad). That’s what I used/did. I skipped all this G=>T=>P stuff and did one eprom burn straight to B7P9.

Why wouldn’t it read -R’s? Was the media on the approved/tested list for that FW version? Each FW rev. adds alternate beam focus and intensity algorithms to work with additional media types…could have been the case with yours.

Your scans? I think Harry Smith has it right…above 8x a different read strategy kicks in…reads a little…drops back…reads a little…drops back…


In fact, there was a thread regarding the periodic speed drop while scanning.

After posting it, I tried to test every possible hypothesis. Firmwares, flashing methods, CDSpeed setup, media selection, etc. My conclusion is, there is no standard way to initiate or to get rid of the spike. It suddenly happens, then suddenly disappears. It is possible that a scan starts with the drop, then the drop disappears halfway in the middle.
I even have an experience of scanning the same disc twice in a low, first with the speed drop, second without it. Case closed. :slight_smile:

A few very vague rules I found.

  1. Not everybody observes it. Definitely it is related to the hardware or software setup. I usually see it, then it disappears for a few discs in a low. That is the reason I started testing it.

  2. With the speed drop, the scan looks a little bit worse. Near the spin down-spin up the scan values (especially jitter) are not consistent. It is purely an artifact, nothing about the quality of the disc or the drive itself.

  3. When the system “feels” that a disc is bad, the chance of getting the speed drop is higher. I can’t quantitatively explain this. For example, longer disc loading time may be related to this. The discs that is read without the speed drop is usually very good. But more tests are necessary to say anything more about this.

  4. Even when your burner is stuck with the speed drop, it has nothing to do with the expected quality of your next burn.

That about wraps it up…Good summary…have a nice weekend everyone!


dun really know the crux of the story here…:smiley:

eleewhm–huh? Crux? Are you being silly?

Read speed drops/spikes. Before I didn’t have them. Now I do. Now I don’t. Why? Why not?


BTW-It WAS a good summary! :stuck_out_tongue: