Hi, Michael Lange wrote: > I discovered then that, unless I missed something, that verifying the > success of the burning procedure appears to be surprisingly (to me at > least) non-trivial.
In part because of the hardware properties of the various media types and the associated drive firmware behavior. In part because of a flaw in the specification of the SCSI command READ CAPACITY with TAO CDs, which led to two decades of workarounds by the burn programs - mostly based on a false theory about the cause of the Linux i/o errors at the end of the media. (It can be fixed in Linux for single session CDs. But multi-session CDs will never play nice with the ahead-reading block device i/o of Linux.) In part because the specifications for DVD+R media might have led me as developer of libburn to a wrong assumption about alignment needs of this media type. (I would have to waste a spindle of DVD+R in order to learn about the real behavior of my drives if i omit aligment to 32 KiB.) > For data-discs I finally found a recipe that seems to > work in the archives of debianforum.de : > $ wc -c whatever.iso > 8237400064 whatever.iso > $ dd if=/dev/sr0 | head -c 8237400064 | md5sum Yes. See also the FAQ about Debian ISO images: https://www.debian.org/CD/faq/#verify The trick is to curb the reader to the size of the ISO image for which you know the checksum. The ISO images themselves contain a data field with their filesystem size. This may or may not be the size of the ISO image file. So it is better to record both, image size and checksum for the purpose of later verification. > Unfortunately there is apparently no way to control the reading > speed here, so maybe one should be careful with these Pioneer drives :) You would need a filter program which takes care not to read more than ~ 20 MB/s. Then the drive slows down automatically. (It is not decided who is at fault with the BD-RE cracks: Pioneer or Verbatim or both ...) > So, does anyone know about a way to verify the integrity of burned > audio-CDs? Success is normally judged by playing the CD on the intended player device, which in most cases is not the CD burner. Difficulties are to be expected if you want to verify the burn success by audio data comparison: There are programs like cdda2wav, readcd, or readom which read audio data from CD media. You may also use cdrskin to extract the tracks and compare them with the original track data. mkdir /home/me/my_cd cdrskin -v dev=/dev/sr0 \ extract_audio_to=/home/me/my_cd \ cdtext_to_v07t=/home/me/my_cd/cdtext.v07t This produces track files (NN = track number) and a CD-TEXT file /home/me/my_cd/NN.wav /home/me/my_cd/cdtext.v07t The audio sectors lack the self-address field of data sectors, which make the Logical Block Address an exact way of addressing data. So it depends on the firmware's capability to exactly find the start of each track. Each extracted file gets from cdrskin a WAVE header of 44 bytes. This could differ from the WAVE header of the original track input file. The original header might even be larger. Further the size of the extracted file will always be a multiple of 2352 bytes. The audio payload of the track input might be up to 2351 bytes less than that. So you will have to extract the audio payload from the track input file and from the extracted file. If you are lucky, the data start in the track input file at byte offset 44 and reach up to the end of the file. Have a nice day :) Thomas
