[oi-dev] sound-juicer removal?

[Joerg Schilling]

Alexander Pyhalov <alp at rsu.ru> wrote:

> Now more news... I was able to build it in such configuration, but it 
> doesn't work. Moreover, old soundjuicer, which we currently have, also 
> likely doesn't work (I haven't checked, but code is the same).
>
> sound-juicer queries cdda file info over gvfs. But our (and Solaris) 
> gvfs doesn't support cdda location. Even if I compile 
> libcdio,libcdio_paranoia and gvfs cdda backend, it seems I have to 
> enable fuse support in gvfs 

What I can tell is that libcdio_paranoia is a half hearted port from the 
paranoia code ripped off from cdparanoia. It does not fix the known bugs and it 
will not work on Mac OS as shared lib as it depends on a spaghetti type of 
interface that is not supported by the Apple dynamic linker.

> (https://bugs.launchpad.net/ubuntu/+source/sound-juicer/+bug/627008), so 
> that it could actually mount it. And our libfuse 2.7.6 is not enough to 
> compile gvfsd-fuse.
> I wonder how it worked earlier...

I believe that sound-juicer did previously send a READ TOC to the drive and 
then used libgstcdda-0.10.so to read blocks known from the TOC that has been 
previously read. When I did my tests, I replaced libgstcdda-0.10.so by the 
cdda2wav based library.

The problem with what you explain for gvfs would be that this is code written 
by laymen (who miss the needed skills for CD-type media) and it will therefore 
prevent you from being able to read out so called "UN-CDs". 

How about using cdda2wav to read the TOC? Cdda2wav will do this in a way that 
does not cause the drive to go into an endless loop when there are certain 
types of "UN-CDs".

A few years ago, I did have a look into libcdio and what I can tell from that 
is that it used code ripped off from antique versions of cdda2wav, ignoring 
that the related code was "GPLv2-only". In general, libcdio looks like an 
agglomeration of code ripped of from various other projects (e.g. mkisofs and 
cdrtools) that has no view of a clean own interface.

Jörg

-- 
 EMail:joerg at schily.net                    (home) Jörg Schilling D-13353 Berlin
    joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'