[ale] Question: What does "Fixating" mean for burning cd?

David A. De Graaf dad at datix.us
Fri Oct 27 14:17:05 EDT 2006


On Fri, Oct 27, 2006 at 12:24:22PM -0400, James Sumners wrote:
> 1) My answer is not a "non-answer".

I am left still wondering what, exactly, is being written during this
process...

> 2) Your assumption is correct. If you had not told your drive to use
> "burnfree" you would have hit a buffer underrun almost immediately.
> The burnfree method was devised to prevent buffer underruns by
> allowing the burn to sort of stutter through no matter how fast the
> data stream is to the drive. The final quality of a disc that relied
> on burnfree heavily during the burn process as opposed to the quality
> of one that did not is vast. I'm willing to bet that if you reburn
> that disc without relying on burnfree, your new disc will read a lot
> faster than your current one.

You're right; I'm wrong.  I thought I had verified this disk - written
in many spurts, with data coming over a wireless link.  Evidently I
hadn't.  

An attempt just now to measure the read time with sha1sum failed
miserably.  Not only did it fail with an I/O error, but there were
strange sounds emitted by the drive - periodic raspy moo's.
Definitely a bad disk!
I withdraw my original "information".   :-(

Carpenters have a motto - Measure twice, cut once.
I should have applied that principle here.  Sorry.

> 
> 
> On 10/27/06, David A. De Graaf <dad at datix.us> wrote:
> > On Fri, Oct 27, 2006 at 11:10:08AM -0400, James Sumners wrote:
> > > The fixation process is the process of closing the disc to any further
> > > writes. The burn process boils down to three steps: 1) writing the
> > > table of contents, 2) writing the data, and 3) leaving the disc open
> > > to further writes or "fixing" the disc so that nothing else can be
> > > written to it.
> >
> > And to give another non-answer to your question, here's a surprising
> > datum (to me).  Last night I tried to write the FC6 x86_64 iso from a
> > file on another machine accessed via NFS over a wireless link.  I knew
> > that writing this image should take about 40 min, but transmitting it
> > by wireless would take 3.5 hours.  I was surprised to find that it
> > worked.  cdrecord and the NEC ND-3550A DVD?RW drive were perfectly
> > content with writing in spurts.  I had always thought it was critical
> > to maintain a more rapid supply of data than could be written to avoid
> > buffer depletion.  The sha1sum of the new DVD was correct!
> > The command was
> >     cdrecord -v -eject dev=ATA:1,0,0 driveropts=burnfree -dao \
> >       /net/datium/h3/iso/fc6/x86/FC-6-x86_64-DVD.iso
> >
> > I assume the burnfree option is important.
> >
> > I mention this merely as evidence that writing need not be continuous
> > and uninterrupted prior to fixation (whatever that is).

-- 
	David A. De Graaf    DATIX, Inc.    Hendersonville, NC
	dad at datix.us         www.datix.us



More information about the Ale mailing list