[svlug] k3b, to erase or not to erase

[Akkana Peck]

Mark Weisler writes:
> What happened then? Well the write went pretty well and maybe the verify but 
> eventually K3B spit out the CD and said there was an error on writing (I 
> believe the last tract or sector or something). But K3B has trained me to be 
> skeptical of its comments and warnings so I used K3B to take the MD5 sum of 
> the newly created CD. The MD5 sum matched what the iso vendor said it was 
> supposed to be suggesting to me that the CD was correct and healthy.

Interesting -- I just recently had a similar experience. I was using
the k3b on Ubuntu gutsy to burn a hardy beta ISO, and I checked the
box to verify after burning.  The burn finished, k3b ejected the CD
then loaded it again, and spewed a bunch of errors, repeated many
times, mostly "/dev/hdd: READ 10 failed!" and "Failed to init HAL
context!" and the verify failed. But md5sum from the commandline
gave a sum that matched the one listed on the website.

I put it down to k3b having a new dependency on hal (which I don't
run) and decided it was time to switch to another burner app. But
maybe it had nothing to do with hal, and k3b just has a bug in
its verify code.

> [1] In learning to use K3B I made many coasters by allowing K3B to use its 
> default settings. K3B would happily make a CD and report it was OK but then 
[ ... ]
> The conclusion for me is that when using K3B I use DAO as a writing method and 
> the slowest speed possible.

I've found that all gui burning apps, not just k3b, are overly
optimistic about the speeds they can burn; if I accept the default
speed, I burn a lot of coasters, so I always bump the burning speed
way down, and then I have much better luck. I've seen that over a
sequence of three or four different burners, both CD and DVD/CD.

	...Akkana