[Paranoia-dev] An OS-independent cdparanoia via libcdio

[R. Bernstein]

Peter Jones writes:
 > On Mon, 2005-01-17 at 22:41 -0500, R. Bernstein wrote:
 > > Recently I've taught a copy of cdparnaoia to use the CD reading and
 > > control routines from the package libcdio
 > > (http://www.gnu.org/software/libcdio).
 > 
 > It looks like you've done exactly the opposite of that, though.  

No, although the description was perhaps a little too anthropomorphic,
it was essentially correct: any place that the cdparanoia package used
to access a CD, for controlling a CD-ROM, for getting control
information, or for reading the CD-ROM, it now does this via
libcdio. It "understands" how to use libcdio rather than do it itself.

 > That is, from what I can tell looking at your CVS repo, you've sucked
 > libcdda_interface and libcdda_paranoia into libcdio.  

I'm sorry to have made a somewhat fanciful description. Perhaps it was
confusing and encouraged a similar metaphorical reply which I don't
understand. What is meant by "sucked libcdda_interface and
libcdda_paranoia into libcdio"?

Sure, libcdda_interface and libcdda_paranoia are currently in the
libcdio source tree; but I think this is a superficial distinction. It
doesn't really have to be that way.

Initially, on my local disk I was keeping these as two separate
projects: the paranoia part in a local CVS. But it then became
expedient, as the next step, to put it in the libcdio CVS so that
other libcdio folks could access and contribute. libcdio already the
contains auto-mess boilerplate, cdparanoia doesn't -- which may or may
not be a good thing. And of course there's the obvious reason that I
don't have CVS write access for cdparanoia. (I'm not suggesting I
should - I'm just trying to describe why things are the way they are,
and why it seemed totally logical and natural.)

I've considered and would consider maintaining this as a project
outside libcdio; if there were an enthusiastic force behind it I'd
think it would be a good thing. But again I'm not exactly sure what is
meant by the "sucked" description except that it seems a bit negative.

 > I'm not sure I understand the point here; 

These are always my favorite remarks. Requires an essay question not a
multiple-choice answer. 

Often when I mention libcdio in another project that might benefit
from it or where there is mutual benefit, I get a "What's the point?"
remark. In one project: "Unless libcdio supports my OS (that I don't
use and) that makes it difficult to issue SCSI MMC commands, what's
the point?" In another: "libcdio does an okay job at classifying all
the different kind of CD's but I want to be able to classify CD's
*and* various kinds of DVD's that I'm interested in. So unless it can
do that, what's the point?"

One of the things I really appreciated reading recently was this from
the cdparanoia FAQ:
  
   Why don't you implement CDDB? A GUI? Four million other features I
   want?

   ... 
   The goal of cdparanoia is perfect, rock-solid audio from every
   capable cdrom on every platform. As this goal has not yet been met,
   I'm uninterested in adding unrelated capability to the core engine.

In my view what makes cdparanoia unique is it's libcdda_paranoia
library to detect and correct jitter and provide robustness where
there was none in the underlying medium. 

I am also impressed with libcdda_interface, especially in the
unrelentless way it tries to make things simple for the outside
layer. However, that part however ingenious, is far from close to
working on every platform: as is in CVS, to my knowledge it *only*
works on GNU/Linux.

So the point (please pay attention since you asked) is to provide the
platform-independence for libcdda_paranoia; at present libcdio 
does a much better job at at this. 

 > you've even kept all the nasty
 > find_a_cdrom and cdda_identify* code, 

Yes, they are kept because those are part of the *PUBLIC*
interface. Were those to disappear, folks who have written
applications which use libcdda_interface would be asking "What's the
point?"

 > but then just made it so it can't
 > use anything but the really horrible cooked mode.
 > 
 > Using only the cooked mode makes it very very difficult to guarantee
 > what's going wrong; there's no way to get reasonable errors back from
 > the drive at all, we just know something has gone wrong.  It also makes
 > it likely to be *very* slow.

Yes, I see you are not familiar with libcdio nor have tried running
the code. And I infer from the above comments you haven't grasped what
was done. (But please don't let that stop you from offering an
opinion....)

Yes, you've ascertained that I have changed cooked_interface.{c,h} and
that I have modified the existing subroutine names that start
cooked_. But I guess what you failed to notice is that the file
descriptor field inside the structure cdrom_drive_s has disappeared
(as well as things involving SCSI). And in its place now appears this
field called p_cdio with a funny opaque CdIo_t type.

No, it is not true that in the GNU/Linux audio blocks are in fact read
using "cooked" mode. 

Now suppose I wanted replace libcdda_interface. I found two places
that I thought seemed natural to do this: somewhere in
cooked_interface.c or somewhere in scsi_interface.c. Which one has
less extraneous code and is simpler?  I chose
cooked_interface.c. Although it might confuse folks, that wasn't an
initial concern. And it is kind of helpful to be able to make the
correspondences initially between the old code and what's been
replaced.  I do have it in mind to eventually rename the filename and
routines.

 > Yeah, my SG_IO stuff isn't there obviously, because I've not committed
 > it to the main tree.  But that's my fault, and you've completely
 > disabled the SCSI stuff anyway.

If your code is great stuff, the place to put it is in libcdio, and
not in libcdda_paranoia or the cdparanoia program. 

 > 
 > > In fact getting some drive capabilities either by a list or by
 > > OS-specific magic for determining if a drive understands ATAPI
 > > commands is also not there. Nor are all the various SCSI read
 > > routines. 
 > 
 > Mostly that's drive-specific, not OS-specific.

What I was thinking here is was the stuff that is still in cooked that
checks to see if a device name is a block or character device and the
stuff that uses <linux/major.h> to make a determination if a drive is
ATAPI or not and to get specific CDROM device names like
MATSUSHITA_CDROM_MAJOR. This stuff is OS specific. (On MS-Windows you
can't even "stat" a drive letter.)

But as you might put it, "What's your point?" An erroneous attempt at
factual correction?

 > 
 > In general, I don't think this is the right route to make cdparanoia
 > more portable.  

Ummm.... modulo the problems in the paranoia library that I don't
understand all that well, it in fact now *does* run on Solaris,
GNU/Linux, OSX (probably BSDI and FreeBSD) and even cygwin. It's the
only single source-code base that I know of that currently does.

Also, it turned out not to be all that difficult to do which I was a
bit surprised at, given cdparanoia's exacting nature and level of
involvement with the CD-ROM.

However I suppose it shouldn't have come as a surprise: if one builds
something to specification and something else follows the spec it
just works. (Good engineering always amazes me.)

At any rate, given that things largely work, I guess I'd have to beg
to differ and say that perhaps this was not such a bad route to
take. :-)


 > What really needs to be done is this:
 > 
 > 1) separate out the command transport layer from the code that decides
 > what drive you have and what commands to send

You might might find some of this already in libcdio. 

 > 2) make the transport layer modular.

Interesting idea. You might find some of this too already in libcdio.

 > 
 > [...]
 > > However the regression tests are very basic and I'm not convinced that
 > > the paranoia routines work perfectly. (But they also don't fail 
 > > perfectly either.)
 > 
 > I'm not convinced either way either; that code is pretty hard to follow.
 > I've seen them have some pretty wacky failures, but always with fairly
 > broken hardware and/or kernel.  In particular, the logic to retry with a
 > shorter read seems to have some issues if your reads are too short to
 > begin with.

Okay, I'll take that under advisement. Thanks!

 > 
 > > For those two of you who might still be interested, here's where you
 > > can get CVS information; https://savannah.gnu.org/cvs/?group=libcdio

I stand corrected: For the zero people who might still be
interested...  (Or maybe I'm still being too optimistic because
negative numbers may be in order)

 > 
 > Ok, so you've basically just sucked the bits in from cdparanoia as a
 > whole.  

Thanks for the lavish praise. 

 > This is not the way...
 > You'd be just as well off just linking against libcdda_paranoia and
 > cloning the libcdda_interface API using your own read routines.
 > Probably better off; 

I'm not so sure about this. Let's say I work on a media player that
plays both CD-DA's and VCD's. I'm not saying I actually do this or
that such media players exist; let's just suppose this
*hypothetically*. In the VCD portion one might want to scan for a
CD-ROM drive just as one might do for the CD-DA portion. So if there
is a "VCD paranoia" along the lines of "CD paranoia" I guess it too
would have its drive-scanning routine and we have duplication of
CD-ROM determination code.

Actually there might be several things the media player might want to
do regarding CD-ROMs. 
  1: Scan for CD-ROM that has a CD-DA in it. 
  2: Scan for a CD-ROM that a VCD in it, 
  3: Scan for a CD-ROM that has *anything* loaded in it and do the
     appropriate thing to "play" that - it might be a VCD or CD-DA or
     PhotoCD or an ISO-9660 filesystem with Oggs. It's not clear that
     the drive-scanning part really belongs inside libcdda_interface.

Although this should be enough. Here's yet another related problem
which could have been listed as #4 above. Currently we have
libcdda_interface that wants to "own" the CD-ROM. As currently
written, libmusicbrainz is also extremely user-friendly too and wants
to retrieve CD information all by itself without you having to supply
any messy or ugly track information. Like cdparanoia you either give
it nothing and it figures things out (differently than cdparanoia does
it), or you can specify a device name in which case it takes control
of the CD while it does it's work. From the media player's standpoint,
this is a bit of a dance and a hassle: at this point I have to give
control of the CD to musicbrainz, now I need to make sure control
comes back so that when I call cdparanoia it has control of
it. Oooops! the user hit a drive-eject button asynchronously!

 > it'd mean that if I stop being lazy and put any
 > work into cdparanoia (or anybody else does ;), and it goes in
 > libcdda_paranoia, you wouldn't have to forward port it to your fork.

I'm sorry I can't help you with your laziness, and I'm sure you have
much to contribute. 

On the other hand, I've noticed that the world isn't waiting for
either of us to come through. I welcome whatever help I can get on
those projects I think needs to moved forward. (And something like
libcdio is not only sorely needed but long long overdue as was my
debugger for bash, or a debugger for GNU Makefiles).

So again I'd suggest the appropriate place put your SG_IO patches
might be in libcdio, not libcdda_interface.