Brian Cameron <[EMAIL PROTECTED]> wrote:

>
> Matthew/Artem:
>
> Yes, if sound-juicer is having trouble ripping files, then this is likely
> because the CDDA plugin we use (cddasrc) is not very sophisticated.  We
> have been using this basic cddasrc CDDA plugin since Vermillion devel build 
> 62.
>
> Previously we were using the GStreamer libcdio plugin (cdiocddasrc), but we
> stopped shipping it when we realized that we were linking GPL libcdio into a
> LGPL GStreamer plugin.  Unfortunately both of the popular CDDA plugins 
> supported
> by GStreamer depend on GPL libraries (libcdio and libcdparanoia).  We've 
> talked
> with the libcdio maintainer and they have no interest in changing license to
> LGPL.  The libcdparanoia code doesn't compile or work on Solaris.

The libcdio maintainer has no authority to change the license as he is not the 
author (although he claims to be the author of "libcdio"). The audio part of 
libcdio has been made by minor modifications on the "cdparanoia" program. This
program is mainly made of:

-       a 1997 GPld version of cdda2wav from Heiko Eißfeldt

-       the paranoia code from Monty.

The license for cda2wav may only be changed by Heiko Eißfeldt

The license for the paranoia code may only be changed by Monty.

Libcdio is illegal even if you use it in a pure GPL environment as the paranoia
code has been changed from GPLv2 only to GPLv2 or any later without permission
from Monty.


> This basic cddasrc plugin just accesses the CD device using simple ioctl's
> and has no error correction or logic to deal with skips, artifacts, damage
> correction, etc.  Also there are known issues with the ioctl's not working
> well with some CD drives.
>
> Support for things like cdparanoia could be added, but we can't copy code
> from any of the existing GPL'ed projects such as cdparanoia or libcdio.
> I know that Jörg uses a LGPL-compatible permutation of cdparanoia in
> cdda2wav, but I don't believe the needed headers/libraries are exposed by
> cdda2wav on Solaris for GStreamer to use.  Or am I wrong here?


I did make the paranoia code portable in 2002 (2 years before libcdio was 
created) and I did get the permission from Monty to make my libparanoia LGPL.

I did change the license for cdda2wav from GPL to CDDL as agreeed with Heiko 
Eißfeldt.

The easy usability of libparanoia depends on the "star" integration project.
This is PSARC 2004/480

http://www.opensolaris.org/os/project/star/

http://www.opensolaris.org/os/community/arc/caselog/2004/480/

The goal for this project is to create a wrapper to create a static speudo
environment for the ON compilation. Note that the ON makefile system is static 
and single platform while the Schily makefilesystem is dynamic ant platform
independent. As ON makefiles allow to run something like "rpcgen", it is 
possible to hide the dynamic stuff here.

Once star is in, it would be a task of minutes to integrate more from the
"schily enviroment".


> There was also some talk about making sound-juicer use cdda2wav to take
> advantage of its higher quality and the fact that it works on a wider
> set of CD players.  However, cdda2wav is a command-line utility that
> doesn't integrate cleanly with a GStreamer plugin.  The GSTreamer plugin
> wants to read the file one sector at a time, including situations where
> users may hit the pause button and there could be a long delay between
> sector reads.  If cdda2wav provided a set of interfaces that could be
> used by GStreamer, it wouldn't be hard to write a CDDA plugin to use
> cdda2wav interfaces.  Note the existing cddasrc pluging is less than 600
> lines of code, so it isn't much code to write a CDDA plugin.

I proposed to negotiate an interface for this purpose, but at that time
the mail exchange was not continued.... 


> So if you have problems in this area, here are your options:
>
> 1) Use cdda2wav (or GRIP) for ripping and don't use sound-juicer.

This is the preferred method

> 2) Get a CD drive that works with the basic CDDA plugin and throw
>     away your current drive that doesn't work well with Solaris ioctl's
>     anyway.  Do you really want to use a CD drive that requires error
>     correction to just read from any CD?  I'd say such drives would be
>     less reliable overall.

This will not work, as most drives work with 60% of the CDs and cdda2wav
is the key to raise this number.


> 3) Install libcdio from SFE, rebuild SUNWgnome-media packages so that
>     the cdiocddasrc plugin gets built, and use that.  It's not as good
>     as cdda2wav, but will work with sound-juicer, and is better than the
>     basic CDDA plugin.

This still violates the livenses of the original code (see above).


> 4) Help to make the basic plugin better, so it has better paranoia
>     support without violating GPL licensing.

If you like all the features of cdda2wav, you need all of it's code ;-)

> 5) Get involved with the cdda2wav project and make it possible for
>     GStreamer to use its interfaces, which are supposed to work better
>     than libcdio and do not have GPL legal issues.

How does this differ from 1)?

> > Artem, did you implement your replacement code the way I did propose (by 
> > calling
> > cdda2wav)?
>
> I also worked on the cddasrc plugin with Artem.  No, we didn't take your
> suggestons due to all the issues spelled out above.  In fact, Jörg, I pinged
> you on March 16th and April 14th, earlier this year about these issues, but
> you never responded (private thread between you, me, and Artem titled
> "Unable to play CD's with snv_59").

I did respond but at some time, I believe I expected a reply from your side.
In April I was in St. Petersburg on the Sun tech days and may have missed your 
second mail.

> I know that cdda2wav does allow sector reading at a time, but you didn't
> make it clear how to use cdda2wav interfaces to handle things like a user
> hitting pause, then hitting unpause.  Or a user sliding the time bar to
> move the play-time to a point earlier or later in the song.  Does cdda2wav
> provide interfaces that would make such things possible?

We could add signals for async commands.


> Also, it doesn't seem to make sense to run cdda2wav over and over for each
> sector.  Is there a way to run cdda2wav once and then control it via signals 
> or
> something so that you can say, things like "give me the next sector now" or
> "give me sector xyz now"?

It will only work in a senseful way if you let cddawav at least extract a track.
Note that cdda2wav include all the code to _play_ the data while extracting.


> > If you did not..... cdda2wav is full of tricks that allow it to work around 
> > typical bugs (deviations from the CD standard) and to play or extract audio
> > in as many cases as possible.
>
> The biggest drawback to cdda2wav is that it doesn't seem to provide any
> interfaces to GStreamer that would allow users to take advantage of these
> features from GStreamer based programs like totem, rhythmbox or sound-juicer.

What do you need except for pause/resume?

> I also know that cdda2wav does things with RBAC privileges so that
> normal users have read permission from the CD device (and not just the
> root user).  So this makes it a bit harder to port cdda2wav code into
> GStreamer.  Not sure if it makes sense for a library to require such
> privilege if you use one of its plugins.  Although we know the programs
> we ship that use the cdda plugin, this would create hassles for users
> who download and install programs that want to use this plugin, for
> example.

I am not sure whether cdda2wav may work without special privs. It will 
definitely not be able to do device scanning.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
       [EMAIL PROTECTED]                (uni)  
       [EMAIL PROTECTED]     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to