Alexander Pyhalov <[email protected]> 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:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/' _______________________________________________ oi-dev mailing list [email protected] https://openindiana.org/mailman/listinfo/oi-dev
