Re: tlug: enscription thru loop device.

[Kei Furuuchi <kfur@example.com>]

Scott Stone writes:
 > On Sun, 11 Oct 1998, Kei Furuuchi wrote:
 > 
 > > Scott Stone writes:
 > >  > On Sat, 10 Oct 1998, Kei Furuuchi wrote:
 > >  > 
 > >  > > Scott Stone writes:
 > >  > >  
 > >  > >  > > $ dd if=/dev/zero of=cdr.img bs=1024 count=650000
 > >  > >  > > 
 > >  > >  > > ....well, I don't know what the size of a CDROM exactly is. Put
 > >  > >  > > into count the correct number. This is raw size - unformatted.
 > >  > >  > 
 > >  > >  > It's 650 * 1024 = 665600 1k blocks.
 > >  > > 
 > >  > > My Mitsubishi media have 335100(sectors) x 2048(byte/sector) =
 > >  > > 686,284,800 byte. But, it / 4 (byte/sample) / 44100 (sample/sec) / 60
 > >  > > (sec/min) is 64.842 which does not add up to 74 min.

I get a private tip that 2048 byte comes with the error correction
overhead that results in 2352 byte in total. So calculation should be:
 335100 x 2352 = 788,155,200 byte.
 788,155,200 / 4 / 44100 / 60 = 74.467 min which is 74 min 28.02 sec.

 > >  > 
 > >  > well, when I make CD images here, which I do often, as long as the 'du -s'
 > >  > on the .img file reports <= 665600 blocks, it fits on the CD.  More than
 > >  > that, and it doesn't fit :)
 > > 
 > > Other media I know of have capability of 336225 sectors. 
 > > Following your advice, I switched to cdrecord which can exactly write
 > > the sectors mkisofs reports leaving out padding.
 > 
 > Well, a sector isn't the same size as a block.  I *think* that iso9660
 > sectors are 2048 bytes, though.  That would mean that there's a few extra
 > sectors on a disc for padding or whatever, which would make sense.

But, the error correction is done by cd-recordable drive. Not by
computer. So as long as a cumputer is concerned, the sector size is
2048 byte unless there is other data format.

Regards,
Kei.


 > 
 > --------------------------------------------------
 > Scott M. Stone <sstone@example.com, sstone@example.com>
 >                <sstone@example.com>
 > Head of TurboLinux Development/Systems Administrator
 > Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan)
 > http://www.pht.com		http://armadillo.pht.co.jp
 > http://www.pht.co.jp	        http://www.turbolinux.com
 > 
 > 
 > ---------------------------------------------------------------
 > Next Nomikai: 20 November, 19:30 Tengu TokyoEkiMae 03-3275-3691
 > Next Meeting: 12 December, 12:30 Tokyo Station Yaesu central gate
 > ---------------------------------------------------------------
 > Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp
---------------------------------------------------------------
Next Nomikai: 20 November, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Meeting: 12 December, 12:30 Tokyo Station Yaesu central gate
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp