On Wed, May 14, 2003 at 12:57:33AM -0700, Joris Huizer wrote:
> Hello,
>
> Pigeon and Carl Fink, thank you for your replies!
*modest shrug* :-)
> See below...
>
> --- Pigeon <jah.pigeon@ukonline.co.uk> wrote:
> > On Tue, May 13, 2003 at 01:46:39PM -0700, Joris
> > Huizer wrote:
> > > I using this shell script to burn:
> > >
> > >
> > > #!/bin/sh
> > >
> > > mkisofs -r -o cd_image "$1/"
> > > cdrecord -v speed=24 blank=all dev=0,1,0 -data
> > > cd_image
> > > cdrecord -v -eject speed=24 dev=0,1,0 cd_image
> >
> > I'd try only the one invocation of cdrecord. Delete
> > the line with
> > blank=all in it. Iff you are using CD-RWs do the
> > blanking as a
> > separate, preceding step, by hand.
> >
>
> As I didn't know exactly how to do blanking by hand, I
> tried xcdroast - however, that program uses cdrecord
> too so it doesn't solve anything - what's the program
> to use for blanking ?
Oh, cdrecord with the blank and (paranoidly) -eject options. The point
is that your above script seems to blank and write the CD in one
invocation, then writes it again with the second. I haven't tried
this, but I'd not recommend it... Hopefully, the second invocation
would error out without actually doing anything. If it doesn't, and
does re-write the whole thing, the resulting CD is pretty well
guaranteed to be knackered.
Also, you don't need to blank CD-Rs, only CD-RWs. I don't know what
the effect of blanking a CD-R would be, but I doubt it would be
useful. Again, hopefully, cdrecord would error out, but if it doesn't...
So, I'd recommend you delete the first invocation of cdrecord from the
above script; you then have a script which is suitable for both CD-Rs
and blank CD-RWs. You can blank the CD-RWs in a separate, preceding
operation: use the blanking line from your above shellscript without
the "-data cd_image" bit.
> > > When copying the contents off the cd, I get the
> > > following error output:
> > >
> > > hdc: cdrom_decode_status: status=0x51 { DriveReady
> > > SeekCompleteError }
> > > hdc: cdrom_decode_status: error=0x30
> > >
> > > during the hole damn cd writing process, not a
> > single
> > > other (custom) proces was running; One thing which
> > > feels wrong is, at first the fifo was 100% or 98%
> > -
> > > but after some time it rapidly dropped to very low
> > > values ( < 10% ) - however, I don't know wether
> > this
> > > has something to do with the incorrect burning
> >
> > I should say it probably does. I don't think
> > "burnproof" drives are
> > guaranteed 100% "burnproof" under all conditions.
> >
> > What is the minimum fifo fill reported by cdrecord
> > when it finishes?
> >
>
> I'm not sure, but I think it was extremely low (only a
> few %)
Not good...
> > What sort of HD/MB/CPU have you got?
> >
>
> Sorry I don't know the exact numbers - my dad has the
> info *somewhere* here but I can't find it;
>
> > Try setting speed=2 or something similarly slow and
> > see if your fifo
> > fill levels improve. Use the -dummy option to
> > experiment without
> > wasting CD-Rs.
> >
>
> I tried the following commend:
> cdrecord -v -eject -dummy -force speed=2 dev=0,1,0
> cd_image
>
> The speed seemed to be 98%/100% the hole time - and
> the minimum fifo fill was 81% - do you think this is a
> reasonable number (say, enough to assume this will
> work correctly) or should I try speed=1 ?
Much better. That should be fine at speed=2.
> I was using the high value of speed=24 because that's
> what the cd writer reports (48x24x48) - well any way
> that's too much I see now.
The writer can do it, but it looks like the rest of your system can't
keep up. Is it a slow old machine, or might you have some config-type
problem like DMA being off or HD and CD-RW on the same cable?
--
Pigeon
Be kind to pigeons
Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
Attachment:
pgp5wlDKdoonp.pgp
Description: PGP signature