burncd -- possible problem

[Malcolm Kay]

On Thu, 15 May 2003 23:16, Shantanu Mahajan wrote:
> +++ Malcolm Kay [15-05-03 20:06 +0930]:
> | On Thu, 15 May 2003 03:38, Shantanu Mahajan wrote:
> | > +++ Malcolm Kay [freebsd] [14-05-03 22:39 +0930]:
> | > | I'm not sure whether I have a problem burning CD-Rs -- certainly
> | > | I don't understand what I observe.
> | > |
> | > | The OS is FreeBSD 4.7-release.
> | > |
> | > | I take a commercial CD-ROM and copy it as an image with:
> | > | # cp /dev/acd1c natins.cd
> | > | which creates the file natins.cd of around 673400*1024 bytes
> | > | without any apparent problem. (I can't remember the exact size
> | > | but was certainly a multiple of 1024).
> | > |
> | > | # md5 natins.cd
> | > | and
> | > | # cat /dev/acd1c | md5
> | > | produce identical results.
> | > |
> | > | Now inserting a blank CD-R:
> | > | # burncd -f /dev/acd1c data natins.cd fixate
> | > | runs apparently normally and without error.
> | > |
> | > | But now
> | > | # cat /dev/acd1c | md5
> | > | produces and IO error and a different checksum
> | > |
> | > | # cp /dev/acd1c natins.back
> | > | produces the same IO error and a file 8*1024 bytes
> | > | shorter than natins.cd.
> | > |
> | > | If I strip off the last 8k from natins.cd and compare the
> | > | result with natins.back I find they are the same.
> | > |
> | > | When I look at the last 8*1024 bytes stripped from natins.cd I
> | > | find these are all zero (ie NUL).
> | > |
> | > | Re-running burncd on a new CD-R blank repeats the result
> | > | exactly; i.e. IO error 8k short of the size of the original but the
> | > | rest matching.
> | > |
> | > | As a mounted cd9660 file system the copy appears normal and
> | > | the visible files test identical to those on the original.
> | > |
> | > | Questions:
> | > | Is what I'm observing normal when writing with burncd?
> | > | Do I have a hardware problem?
> | > | Is this due to some bug in burncd?
> | > |
> | > | Should I worry about this or just ignore?
> | > |
> | > | Malcolm Kay
> | > |
> | > | ------------------------------
> | >
> | > 	*suggestion* (works perfectly for me)
> | > 	instead of
> | > 	# cp /dev/acd1c natins.cd
> | > 	try
> | > 	# dd if=/dev/acd1c of=natins.cd bs=2048
> |
> | Tried that except I forgot bs=2048 so it didn't work.
> | But file produced by cp looks fine and command executes without
> | reporting an error.
> |
> | > 	and then
> | > 	# burncd -f /dev/acd1c data natins.cd fixate
> |
> | This also appeared to go well -- no error reported.
> |
> | > 	Also try mounting natins.cd with help of vnconfig
> |
> | Did that; again no problems.
> |
> | Problem only appears when I try to reread the completed
> | new CD copy as a complete image.
> |
> | Then 'cat /dev/acd1c' and 'cp /dev/acd1c natins.back'
> | both report read errors and don't transfer what should be the last 8k
> | bytes. (I don't have the disk on hand at the moment but I'll try 'dd' on
> | the written CD when I get to work tomorrow.)
> |
> | However the created disk mounts OK and I am not able to find errors in it
> | as a mounted file system.
> |
> | Have you written disks with burncd and then tried to read them as an
> | image?
> |
> | Shantanu,
> | Thanks for your thoughts and also yours, Eduardo.
> |
> | Malcolm
>
> 	try specifying the speed for writing.
> 	I generally use 16 or 20 for my 20x drive.
>
> 	# burncd -f /dev/acd1c -s 20 data cd.iso fixate

Yes, I have tried adding a speed option "-s 24"

>
> 	Regards,
> 	Shantanu

Today I tried reading the copied CD with:
# dd if=/dev/acd1c of=natins.back bs=2048
It still terminated with:
 "dd: /dev/acd1c: Input/output error"
but returned the correct size and the file matched 
the original natins.cd.

So it would appear that the end of media on the
copy is seen as an error rather than as a normal end 
of media; but after correctly reading the required parts.

I can accept that when reading with 'cp' the error might
have aborted the utility write while valid data still remained
in the write buffer leading to the shortened returned file.

On further investigation I find that on this machine (not
the one refered to above) a file written with burncd from
a downloaded and checksummed ISO image gave a 
similar result; that is the readback with dd terminated with 
error but in this case also returned a file one block longer
than the original. Adding count=132656 (the expected size)
caused a read without error and a file that match the original.

It seems that cp or dd or whatever tries to read beyond the 
valid data on generated CDs while it seemed that a normal
end was registered on the commercially produced CD.

I now feel fairly comfortable that the generated CDs are 
valid for their intended purpose but still wonder about the 
termination:-
==   Was I just lucky that the commercial CD read without a 
        termination error?
==   Is there something in burncd or my hardware that causes
       a questionable termination? As chance would have it both 
       machines use the same brand of CD burner --
       Sony 24x/10x/40x 
==   Is it normal for software to try to read past the end of a CD
       when addressed as a complete device, and then report an
       error?

 You patience is appreciated.
Thanks,

Malcolm