Next message: Mark Andrich: "RE: [LUNI] way OT"
I was aware of the standard CD-R layout. My understanding is that CD-RWs are
different and I haven't found a good reference yet explaining how. But CD-RWs
can be accessed like filesystems and files can be written and deleted. My
understanding is that this is due to storing the info in a packet-type format
on CD-RWs which gives the necessary addressing for adding and deleting. But
copying to it like a CD-R will not create the packet layout hence you can
delete by blanking a spot, but you can't write.
Joe Kaplenk
In a message dated 3/22/01 9:00:35 AM Central Standard Time,
yocum@linuxcare.com writes:
> Subj:Re: [LUNI] Bootable CD-RW
> Date:3/22/01 9:00:35 AM Central Standard Time
> From: yocum@linuxcare.com (Dan Yocum)
> Sender: owner-luni@luni.org
> Reply-to: <A HREF="mailto:luni@luni.org">luni@luni.org</A>
> To: luni@luni.org
>
>
>
>
> CD's are not real devices, as Don Holmgren has informed me at length.
> Let's see if I can find his emails to attach here. Ah, here they are
> (quoted at the bottom).
>
> Dan
>
> Jkaplenk@aol.com wrote:
> >
> > Anyone have any experience with or know how to make one that can be
> > accessed
> > like a rw filesystem? I've been checking a lot of the faqs and the
> > best I can
> > find is references to the fact that you need make it just like the
> > CD-R, but
> > that files can only be deleted, but not added.
> >
> > Joe Kaplenk
> > jkaplenk@aol.com
>
> Don Holmgren wrote:
> >
> > Hi Dan -
> >
> > Representation of audio data on a CD is very different from how digital
> > data is represented. There are no sectors, just a stream of D/A data
> > and CRC's. I think the cdparanoia doc's have some links to descriptions
> > of the format.
> >
> > dd and the like can only deal with addressable data (i.e., a specific
> > sector or a specific bytes). The audio streams are time indexed, I
> > think, so asking for byte #x doesn't really work.
> >
> > It's fairly analogous to the old (I mean, old) days of Apple II disks,
> > when programmers could fool willy nilly with the data encoding on
> > diskettes and so make programs uncopyable by standard sector-oriented
> > programs. The copy protected data streams didn't have the standard
> > sector marks. Some clever folks wrote "nibble" copiers, which tried
> > literally to copy the floppies bit for bit. In theory one could nibble
> > copy a CD (folks do that to DVD's, I believe), but not through the
> > standard SCSI/Atapi interfaces.
> >
> > Don Holmgren
> > Fermilab
> > djholm@fnal.gov
> > 630-840-2745
> >
> > On Wed, 6 Sep 2000, Dan Yocum wrote:
> >
> > > Erik Jarvi wrote:
> > > >
> > > > On Sun, Sep 03, 2000 at 07:08:26PM -0700, Herbie Herbert wrote:
> > > > > Now Erik,
> > > > > You know dd don't work for audio CD's :)
> > >
> > >
> > > bits is bits... dd should work... he said a duplicate... nothing about
> > > being able to listen to it.
> > >
> > > [insert time lapse]
> > >
> > > OK - so it don't work. Why not?
> > >
> > >
> > > Dan
> > >
> > > --
> > > Dan Yocum, Sr. Linux Consultant
> > > Linuxcare, Inc.
> > > 630.697.8066 tel
> > > yocum@linuxcare.com, http://www.linuxcare.com
> > >
> > > Linuxcare. Support for the revolution.
> > > -=-
> > > Linux Users Of Northern Illinois: General Discussion Mailing list.
> > > For unsubscription, archives, and announcements only see http://luni.org
> > >
>
>
> Don Holmgren wrote:
> >
> > >From the cdparanoia FAQ: (http://www.xiph.org/paranoia/faq.html)
> >
> > I can play audio CDs perfectly; why is reading the CD into a file so
> > difficult and prone to errors? It's just the same thing.
> >
> > Unfortunately, it isn't that easy.
> >
> > The audio CD is not a random access format. It can only be played
> > from some starting point in sequence until it is done, like a vinyl LP.
> > Unlike a data CD, there are no synchronization or positioning headers in
> > the audio data (a CD, audio or data, uses 2352 byte sectors. In a data
> > CD, 304 bytes of each sector is used for header, sync and error
> > correction. An audio CD uses all 2352 bytes for data). The audio CD
> > *does* have a continuous fragmented subchannel, but this is only good
> > for seeking +/-1 second (or 75 sectors or ~176kB) of the desired area,
> > as per the SCSI spec.
> >
> > When the CD is being played as audio, it is not only moving at 1x,
> > the drive is keeping the media data rate (the spin speed) exactly locked
> > to playback speed. Pick up a portable CD player while it's playing and
> > rotate it 90 degrees. Chances are it will skip; you disturbed this
> > delicate balance. In addition, a player is never distracted from what
> > it's doing... it has nothing else taking up its time. Now add a
> > non-realtime, (relatively) high-latency, multitasking kernel into the
> > mess; it's like picking up the player and constantly shaking it.
> >
> > CDROM drives generally assume that any sort of DAE will be linear
> > and throw a readahead buffer at the task. However, the OS is reading the
> > data as broken up, seperated read requests. The drive is doing readahead
> > buffering and attempting to store additional data as it comes in off
> > media while it waits for the OS to get around to reading previous
> > blocks. Seeing as how, at 36x, data is coming in at 6.2MB/second, and
> > each read is only 13 sectors or ~30k (due to DMA restrictions), one has
> > to get off 208 read requests a second, minimum without any interruption,
> > to avoid skipping. A single swap to disc or flush of filesystem cache by
> > the OS will generally result in loss of streaming, assuming the drive is
> > working flawlessly. Oh, and virtually no PC on earth has that kind of
> > I/O throughput; a Sun Enterprise server might, but a PC does not. Most
> > don't come within a factor of five, assuming perfect realtime behavior.
> >
> > To keep piling on the difficulties, faster drives are often prone
> > to vibration and alignment problems; some are total fiascos. They lose
> > streaming *constantly* even without being interrupted. Philips
> > determined 15 years ago that the CD could only be spun up to 50-60x
> > until the physical CD (made of polycarbonate) would deform from
> > centripetal force badly enough to become unreadable. Today's players are
> > pushing physics to the limit. Few do so terribly reliably.
> >
> > Note that CD 'playback speed' is an excellent example of
> > advertisers making numbers lie for them. A 36x cdrom is generally not
> > spinning at 36x a normal drive's speed. As a 1x drive is adjusting
> > velocity depending on the access's distance from the hub, a 36x drive is
> > probably using a constant angular velocity across the whole surface such
> > that it gets 36x max at the edge. Thus it's actually spinning slower,
> > assuming the '36x' isn't a complete lie, as it is on some drives.
> >
> > Because audio discs have no headers in the data to assist in
> > picking up where things got lost, most drives will just guess.
> >
> > This doesn't even *begin* to get into stupid firmware bugs. Even
> > Plextors have occasionally had DAE bugs (although in every case, Plextor
> > has fixed the bug *and* replaced/repaired drives for free). Cheaper
> > drives are often complete basket cases.
> >
> > Don Holmgren
> > Fermilab
> > djholm@fnal.gov
> > 630-840-2745
>
>
> Don Holmgren wrote:
> >
> > Just say "uncle" when you want me to stop.
> >
> > See http://www.emediapro.net/AprEM/parker4.html:
> >
> > Don Holmgren
> > Fermilab
> > djholm@fnal.gov
> > 630-840-2745
>
> --
> Dan Yocum, Sr. Linux Consultant
> Linuxcare, Inc. 630.697.8066 tel
> yocum@linuxcare.com, http://www.linuxcare.com
> Linuxcare. Putting open source to work.
> -=-
> Linux Users Of Northern Illinois: General Discussion Mailing list.
> For unsubscription, archives, and announcements only see http://luni.org
>
>
> ----------------------- Headers --------------------------------
> Return-Path: <owner-luni@www.aalug.org>
> Received: from rly-xa03.mx.aol.com (rly-xa03.mail.aol.com [172.20.105.72])
> by air-xa03.mail.aol.com (v77_r1.21) with ESMTP; Thu, 22 Mar 2001 10:00:34
> -0500
> Received: from www.aalug.org ([207.229.179.228]) by rly-xa03.mx.aol.com
> (v77_r1.21) with ESMTP; Thu, 22 Mar 2001 10:00:12 -0500
> Received: (from majordomo@localhost)
> by www.aalug.org (8.8.7/8.8.7) id IAA11615
> for luni-outgoing; Thu, 22 Mar 2001 08:53:20 -0600
> X-Authentication-Warning: www.aalug.org: majordomo set sender to
> owner-luni@luni.org using -f
> Received: from topaz.linuxcare.com (chicago.linuxcare.com [64.81.140.52])
> by www.aalug.org (8.8.7/8.8.7) with ESMTP id IAA11611
> for <luni@luni.org>; Thu, 22 Mar 2001 08:53:12 -0600
> Received: from linuxcare.com (IDENT:yocum@localhost.localdomain [127.0.0.1])
> by topaz.linuxcare.com (8.9.3/8.9.3) with ESMTP id IAA01399
> for <luni@luni.org>; Thu, 22 Mar 2001 08:53:26 -0600
> Message-ID: <3ABA11E6.1408F525@linuxcare.com>
> Date: Thu, 22 Mar 2001 08:53:26 -0600
> From: Dan Yocum <yocum@linuxcare.com>
> Organization: Linuxcare, Inc.
> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
> X-Accept-Language: en
> MIME-Version: 1.0
> To: luni@luni.org
> Subject: Re: [LUNI] Bootable CD-RW
> References: <7e.128b61f4.27eadb7e@aol.com>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Sender: owner-luni@luni.org
> Precedence: bulk
> Reply-To: luni@luni.org
>
>
>
-=-
Linux Users Of Northern Illinois: General Discussion Mailing list.
For unsubscription, archives, and announcements only see http://luni.org
This archive was generated by hypermail 2b29
: Thu Mar 22 2001 - 11:33:26 CST