CPU overloading affects burn quality?



i tried to burn a disc with my 812s@832s while i was using some other applications .
i had a lot of buffer underuns ,the hard disk was running crazy.
The result was bad and the disc(movie) is unplayable after its 80%.

PI Max : 101
PI Average : 7,50
PI Total : 128352
PIF Max :63
PIF Average : 5,16
PIF Total : 88304

My question is if the CPU overloading is affecting the burn quality


It is system dependent (CPU, RAM, CACHESIZE), but generally YES. When burning on your 832S does the drive blink orange and red alot during burning? If so, your HDD is not sending enough data to your burner (that’s why the drive blinks orange).


CPU loading won’t hurt anything, but frequent buffer under-runs can. I burn all the time at 100% CPU. (movie crunching) and never a problem.
Drive’s can handle a few buffer under-runs, but frequent pauses in the burn will invite unreadable sectors. If the pause lasts long enough, the burn will fail.


Just throwing my two cents…when a buffer underrun occurs, the laser disengages from the disc and then has to re-engage when the buffer is ready. Some drives do this better than others. My Liteon 851@832 is not very good at recoupling, and there is always a PIF spike when this occurs, even during a speed shift change. These show up in Kprobe scans. Sometimes there is pixelation or even freezing/skipping in the video at these spots. However, my NEC 3500 and BenQ 1620 does this recoupling seamlessly, and I never have a video problem with them.

Bottom line…it is best to minimize any buffer underruns


Seems that cpu overloading affects the burn quality.
I made a copy with minimum processes running and i got a great result
thanks again people


There is also a random element, and the possibility that your drive is still learning the media if the code has not been seen before, or if the quality has changed.

In general, the underrun recovery should be a safety net, used little if at all, rather than an essential prop.

I thought most burning software ran the burn thread at high priority, to ensure it got CPU when required - though that would not counter saturation of the source disk performance, nor additional load put on another drive on the writer’s cable.


How do you explain the high spikes at the end of the disc?
Weird ah?