[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: -tao vs -sao



> ~# ./cdrecord -toc
> Cdrecord-Clone 2.01 (i586-pc-linux-gnu) ....
> ....
> first: 1 last 1
> track:   1 lba:         0 (        0) 00:02:00 adr: 1 control: 4 mode: 1
> track:lout lba:    351369 (  1405476) 78:06:69 adr: 1 control: 4 mode: -1
> 
> 
> However after ./cdrecord -tao ./KNOPPIX_V3.8.1-2005-04-08-EN.iso I get:
> 
> ~# ./cdrecord -toc
> Cdrecord-Clone 2.01 (i586-pc-linux-gnu) ....
> ....
> first: 1 last 1
> track:   1 lba:         0 (        0) 00:02:00 adr: 1 control: 4 mode: 1
> track:lout lba:    351371 (  1405484) 78:06:71 adr: 1 control: 4 mode: -1

Just ignore the 2 extra blocks exist.

> ~# dd if=/dev/hdd of=some.image bs=2k skip=351367 count=4
> dd: reading `/dev/hdd': Input/output error
> 1+0 records in
> 1+0 records out

You ought to be able to read 351369 blocks, but not more than that.
Don't try to read the 2 additional blocks, they're meaningless to you.
If you want to compare the iso's md5 checksum, make sure you only read
351369 blocks from the media. (I've got an md5 script in my scriptutils
to do this automatically).

As you see you can't even read 351369 blocks - this a long-standing
Linux kernel bug. There is no fix, only a workround - when burning, burn
a suitably long stream of nulls immediately following the iso image
data. cdrecord -pad is meant to do this, but the amount of nulls added
is insufficient to be a reliably workaround. Something like up to at
least 200kb need to be added. I found that cdrecord -pad padsize=10x75s
has always allowed me to read the full amount of iso blocks.

Volker

-- 
Volker Kuhlmann			is possibly list0570 with the domain in header
http://volker.dnsalias.net/		Please do not CC list postings to me.



Reply to: