[lug] another cdrom verification strategy

David L. Anselmi anselmi at anselmi.us
Sun Jul 23 17:10:38 MDT 2006


D. Stimits wrote:
> Hmm, I don't know what the weaknesses of this are, but since it was a 
> topic a while back, thought I'd throw it in. I've been using it in the 
> last few days (used to use it and no media ever passed, but recent 
> media...Taiyo Yuden...have all succeeded).
> 
> What I did was take an sha1sum of the iso I used to burn the cd. Then 
> recreate the iso via:
> dd if=/dev/cdrom of=test.iso bs=512
> 
> And then do sha1sum on the test.iso. If it matches, it's good.
> 
> dd seems fairly unforgiving of track errors, I'm not sure how much the 
> system will do to try and deal with bad tracks when reading raw data via 
> dd.

The advice here:

http://www.troubleshooters.com/linux/coasterless.htm

about -dao and -padsize=63s made a huge difference to me.  I never got a 
checksum to match because of errors reading the last few sectors. 
Padding the end of the disk and then reading the .iso length with dd 
fixed that.  (I noticed a page that said -dao was the important piece 
but haven't had a chance to try that without -padsize.)

I think the system handles bad tracks the same way with dd as it does 
when the CD is mounted--retries until it gives up.

There is also a utility called cdck that reports CD quality by read 
times on each sector (i.e., how many tries does it take to read a 
sector) and then tells you whether the disk is good or not.  But it 
reads the padding too, not the image length so it fails on the last few 
sectors.  Maybe that's just cheap hardware I have.

[...]
> PS: I'm wonder how one prints on an inkjettable CD? I don't know of any 
> inkjets that don't curl the paper in the process of printing, which 
> means the cd would be destroyed (or the printer). Are there special 
> inkjets for cd labeling?

There are special inkjets.  CD duplicators come with several burners, a 
robot arm to move the CDs around, and an inkjet to print on them. 
Pretty slick if you can justify having one (though it's easy to get 
robotics that are unreliable, flaky control software, or a printer that 
can't keep up with the burners--you get what you pay for, and sometimes 
  not even that).

Dave



More information about the LUG mailing list