Douglas Kilpatrick wrote:
> This message is NOT CC'd to l-k.
>
> On Tue, 4 Apr 2000, David Elliott wrote:
>
> > Couple that with the fact that trying to present an interface to read a
> > specific sector off of an audio CD is a broken idea anyway.
>
> Er, I was assuming by track.
>
I understand that, but you will inevitably have people trying to seek to different
parts of the file.
>
> > PLEASE read the "color books" for CDs. Try the red book, and also I think
> > the white book, and also read the documentation for cdparanoia. If you
>
> I've read the doc's for cdparanoia. Got a URL for the others?
>
Hmm.. good question. I know there is some info available in the help file for
CDR-Win (www.goldenhawk.com) you can download a demo and I think there are tools
for converting from winhelp format to rtf or other things. I did a preliminary
search with google for "CD Red Book". The Red book is definitely the one you'd
want to look at.
>
> > understand those, you will understand why it's a bad idea to present an
> > interface that encourages trying to read a cd audio track sector by sector.
>
> The point of the Unix namespace is to present as many object as possible
> under a consistant interface. If its conceptually an stream of data, it
> is represented by a file.
>
Correct
>
> Audio tracks are conceptually a stream of files. IMHO, they should be
> representable by files.
>
Actually, I think this is why we are having this argument. I don't believe that
audio tracks are conceptually a stream of data. I know it sounds stupid because
you would think that you play it and it's a stream of audio, but there are so many
different possibilities with the Table of Contents on the CD, as well as the
inevitable scratches on the disk that make thinking of tracks as simply a stream
of audio a bad idea. In addition, trying to keep a marker of the last position in
the file is even problematic. I am not saying that it couldn't be done, it could,
but it's way too kludgy.
>
> I'm not claiming that this is the only way to represent them. They are
> already, in a sence, represented by files in the form of /dev/cdrom.
> Maybe that's enough.
>
IMHO it isn't necessarily enough for data, we should definitely support multiple
data tracks. We may even support audio tracks somewhat like Win9x does. That is,
you would have a file for every track and if you read the file you get a
description of the track (basically its entry in the TOC). Of course Win9x's way
is somewhat broken, we could do better in Linux. Then to do all the reading you
would use the regular CD-ROM device... hmm.. maybe some info in the /proc
filesystem about the CD would be better. Of course the real thing is that you can
already get all this info simply by parsing the CD TOC yourself, so it's not
neccessary to do this in kernel space.
>
> But that form does not match the logical streams of data on the resource,
> and I think that's a shame and in conflict with "The Unix Way."
>
err.. well, actually I think we are doing it correctly. Trying to force
everything to have a logical stream of data is not such a great idea. CD Audio
really isn't a logical stream of data (actually, it's a completely and totally
illogical stream of data!). Joking aside though, I don't think we can complain to
the CD makers that CD Audio does not fit with the UNIX streaming model and we
should change all CDs. ;)
>
> > Basically, the reason I feel so strongly about this is that right now we have
> > very good CD Audio tools for linux (cdparanoia, and even cdda or whatever)
>
> *nod*. My whole collection is on my HD. I obviously need to buy more
> CD's. :)
>
> > MP3s. Compare this with the hundreds of poorly written Windows audio ripping
> > programs. Hell, some people even record the audio with the sound card out of
>
> Irrelevant? You are saying "Someone could do something bad with this."
> True, but irrelevant. Someone could do something bad with the current
> interface too. The question is: "What will make it easiest for people to
> do something good".
>
Actually, I think exporting a wav file name space would make it easier to do
something bad, which is a very bad thing to do. And it unfortunately doesn't make
it easier to do something good. If you want to do it the right way, you'd still
need to use cdparanoia by itself.
>
> I'm not claiming audiofs is that. (I don't think it is). I just don't
> think you've presented good arguments why that namespace unification is a
> bad thing, and I see what I feel are good arguments why that namespace
> unificiation is the right thing to do.
>
Hopefully I cleared that up with this message.. to recap:
1. Audio tracks do not fit very well into the streaming model, CD Audio is stupid,
but we have to live with it.
2. A UNIX system should provide a streaming interface for anything that resembles
a stream
3. Since CD Audio really isn't streaming, we don't want to make a streaming
interface for it.
4. While we could provide info about tracks from kernel space, or even from a user
FS, that info can already be gotten in a standard way from a user program. Maybe
a good audio reading library is a better solution... Hmm, actually cdparanoia IS
a library as well as a program, so this has already been taken care of.
Sorry I can't find the red book standard on the net with a quick search, but I am
sure you will find some info if you plow through enough of it.
One thing to be aware of is that CD audio players routinely interpolate or mute
parts of audio they can't immediately read, this is obviously not a good solution
for ripping audio tracks. However, MS has used the CD-DA interface on new CD-ROMs
to allow for quick and dirty playing of audio tracks digitally into something like
a USB speaker system. We may at some point want some sort of an interface like
this. But it should clearly warn programmers that it is for playing the data, not
copying it or making MP3s out of it.
-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:13 EST