Gabriel Sechan wrote:
>
>
>
> >From: "John H. Robinson, IV" <[EMAIL PROTECTED]>
> >Let's see what a filesystem has, in a very basic way:
> >It has files, and ways of referencing those files.
> >
> >Let's see what a music cd has, in a very basic way:
> >It has a stream of data, and a way of indexing that data.
> >
> >They might look the same, but a music cd has no *reliable* way of
> >extracting the information. A data CD, however, has checksum and
> >tracking information on it. These are *very* different beasts. If a
> >music CD had a filesystem, we would not need cdparanoia to get reliable
> >rips.
> >
>
> FAT doesn't have checksum or other such data. Is it not a filesystem?
Yes. You are ignoring the fact that hard drives are designed to pull
data off reliably. CD ROM drives were designed to pull data off well
enough. Tracking on those is *hard*
> I don't see the difference. A FS specifies where pieces of data (called
> files) are found on a device (weher a physical or logical device). A TOC
> on a musice cd specifies where pieces of data (called tracks) are on a cd.
> Sounds like a filesystem to me.
Read the Red Book. It describes the CDDA specifications.
In researching that, I found that I was wrong. There is some error
correction going on, in the manner of parity bits. There is also
interleaving going on.
http://www.digitalprosound.com/Features/2000/Sept/RecCD3.htm
However, the biggest problem with the CDDA ``filesystem'' is that of
actually tracking.
http://www.cdrfaq.org/faq02.html#S2-15
The problem occurs because the Philips CD specification doesn't
require block-accurate addressing. While the audio data is being fed
into a buffer (a FIFO whose high- and low-water marks control the
spindle speed), the address information for audio blocks is pulled out
of the subcode channel and fed into a different part of the
controller. Because the data and address information are disconnected,
the CD player is unable to identify the exact start of each block. The
inaccuracy is small, but if the system doing the extraction has to
stop, write data to disk, and then go back to where it left off, it
won't be able to seek to the exact same position. As a result, the
extraction process will restart a few samples early or late, resulting
in doubled or omitted samples. These glitches often sound like tiny
repeating clicks during playback.
So you may have a ``filesystem'' but it can't reliably get the start of
it. For audio, given the lengths of times being discussed, this is not a
*real* issue. For data, this is a very real issue. This is also why the
*same* audio cd, ripped twice, will give different data.
If you still think that, because there is data and a way of indexing it,
that you have a filesystem, then I have to say (paraphrasing Comic Book
Guy[1]) Worst Filesystem Ever.
-john
[1] http://en.wikipedia.org/wiki/Comic_Book_Guy
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
