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

[Peter Jones]

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.  That
is, from what I can tell looking at your CVS repo, you've sucked
libcdda_interface and libcdda_paranoia into libcdio.  

I'm not sure I understand the point here; you've even kept all the nasty
find_a_cdrom and cdda_identify* code, 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.

> So as not to set the expectations too high though, what's there in the
> way of cdparanoia is what was checked into paranoia CVS. Patches
> people may added to a "port" is probably not there.

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.

> 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.

In general, I don't think this is the right route to make cdparanoia
more portable.  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
2) make the transport layer modular.

[...]
> 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.

> 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

Ok, so you've basically just sucked the bits in from cdparanoia as a
whole.  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; 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.

-- 
        Peter