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.
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?
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.
Another idea might be to move away from sound-juicer and start shipping
GRIP instead, since it is a nice user interface for ripping CD's via
cdda2wav. However, note it only uses cdda2wav for ripping and uses
GStreamer for playing audio from the CD. If we wanted to really use
GRIP, it probably should avoid using GStreamer altogether and only use
cdda2wav. Otherwise you wouldn't be able to play CD's on some machines,
but you would be able to rip them and play the created WAV files. That's
not really acceptable either. So I think GRIP needs some work before it can
replace sound-juicer.
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.
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.
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.
4) Help to make the basic plugin better, so it has better paranoia
support without violating GPL licensing.
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.
> 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 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?
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"?
> 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.
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.
References:
Bug asking GStreamer maintainers to add this simple cdda plugin upstream
and to move the libcdio plugin to gst-plugins-ugly or gst-plugins-bad.
http://bugzilla.gnome.org/show_bug.cgi?id=413705
The above bug report has the cddasrc plugin code as an attachment if
you want to review the code we use for our current "basic" CDDA plugin.
Brian
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
