Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Jan 2001 16:28:52 +0200
From:      Giorgos Keramidas <keramida@ceid.upatras.gr>
To:        "Daniel O'Connor" <doconnor@gsoft.com.au>
Cc:        Soren Schmidt <sos@freebsd.dk>, freebsd-chat@FreeBSD.ORG, SXren Schmidt <sos@FreeBSD.ORG>
Subject:   Re: cvs commit: src/sys/dev/ata atapi-cd.c atapi-cd.h
Message-ID:  <20010105162852.C6404@gray.westgate.gr>
In-Reply-To: <XFMail.010105213349.doconnor@gsoft.com.au>; from doconnor@gsoft.com.au on Fri, Jan 05, 2001 at 09:33:49PM %2B1030
References:  <200101050829.JAA95057@freebsd.dk> <XFMail.010105213349.doconnor@gsoft.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 05, 2001 at 09:33:49PM +1030, Daniel O'Connor wrote:
> 
> On 05-Jan-01 Soren Schmidt wrote:
> >  Burnproof is a technology that allow the laser to be switched on/off
> >  very quickly, so if you have a buffer underrun the drive just stops
> >  writing, when data arrives again, it starts off where it stopped
> >  without any noticeable gaps. This seems like a natural thing to do,
> >  but burners havn't been able to this until now, they needed a fair
> >  amount of time to switch on/off which would create non wanted
> >  gaps in the recorded data...
> >  
> >  I have no idea why burner's wasn't created this way to begin with :)
> 
> Ahh OK, makes sense, but as you say, why didn't they do that to begin with? :)

Probably because they hadn't come up with the idea yet?  But as Soren
explained, the time required to turn off/on the beam would create large
gaps in the cdrom and they did not use it until recently.

Another reason I could think for not using this is that if you have an
image that barely fits an empty disk, leaving gaps might result in the
image being partially written on the resulting cdrom disk :/

- giorgos


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010105162852.C6404>