Description of problem: cdrkit contains a copy of libparanoia II (probably from 1997) libparanoia II is outdated, there is a libparanoia III (with improved anti-cache detection) In addition, the manpage of cdrkit does not mention the use of an outdated library. Users could check their drive with 'cdparanoia -A' and expect that icedax would work as well (because the manpage of icedax claims that icedax uses the cdparanoia libraries) Version-Release number of selected component (if applicable): cdrkit-1.1.11 How reproducible: N/A: just look into cdrkit-1.1.11/libparanoia/README.paranoia Steps to Reproduce: Actual results: There is libparanoia II Expected results: There should be some glue code that links to libcdda_paranoia.so or libcdio_paranoia.so Additional info:
If this is true, cdrkit is in violation of Fedora packaging standards, which disallow use of bundled libraries. The relevant packaging policy page does not list cdrkit has having been granted an exception. http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Unfortunately this is true. cdrkit bundles paranoia for a long time and what's more, it changed it's behaviour a lot, even though the API has been changed only a little. I've tried to unbundle the library and use the one from cdparanoia package instead, but I haven't manage to get it to work. It's possible to build, but reading audio files doesn't work. The main issue is that cdrkit uses own structures to communicate with device and these structures are not compatible with those used in cdparanoia package. It is also possible to build package even without paranoia extension, but I wouldn't go that way, because icedax utility would lost a really nice feature. It's possible someone will be more successful, but right now I'm thinking of filling a FPC ticket to get an exception. Thoughts?
If they've made incompatible changes to the bundled cdparanoia which can't be pushed upstream, it does sound like a good candidate for an exception.
a) As I wrote, icedax uses libparanoia II - which is broken on modern drives. A broken option does not make any sense - thus removing -paranoia would make more sense than adding an exception. b) For my own scripts for readings CDs, I now use icedax for looking up cddb and then I call cdparanoia to read the content. Would it be possible to call cdparanoia and then use a pipe to get it into icedax?
Removing -paranoia doesn't make sense as it will remove functionality for those of us that do have drives that work with it. The proposed bundling exception would only be intended to be used until someone (who?) does the work of getting cdrkit to use the non-bundled Paranoia III.
(In reply to comment #4) > b) For my own scripts for readings CDs, I now use icedax for looking up cddb > and then I call cdparanoia to read the content. > Would it be possible to call cdparanoia and then use a pipe to get it into > icedax? I was trying to do something like this on the code basis, but haven't succeeded yet. But I'll keep trying.
(In reply to comment #5) > Removing -paranoia doesn't make sense as it will remove functionality for > those of us that do have drives that work with it. That would be one option, but at least in must be documented as BUGS: Something like: > > - "-paranoia" uses libparanoia II, which is on most drives > reports every read operation as "perfect", regardless of > amount of scratches. There is no automatic way to detect > if your drive works or not. Especially, using "cdparanoia -A" > is not sufficient because cdparanoia uses better algorithms > that the library bundled with icedax. > Or drop it entirely - a silent misbehavior is the worst possible behavior. Attached is a patch that disables libparanoia, just as a proposal. The "-paranoia" option is still accepted, the "standard" icedax algorithm is used.
Created attachment 601019 [details] Propsal: do not use libparanoia II, update icedax man page
Created attachment 601296 [details] Patch to use system-wide cdparanoia library Things seem better today, I believe unbundling of paranoia library was successful, at least in my random testing. With the attached patch icedax should use cdrkit's tools only for track reading and cdparanoia library for reading data itself, in case -paranoia option is used. Guys, if you can test the patch in your use cases, I'd be glad for any feedback.
cdrkit-1.1.11-12.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/cdrkit-1.1.11-12.fc17
cdrkit-1.1.11-12.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/cdrkit-1.1.11-12.fc16
Package cdrkit-1.1.11-12.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cdrkit-1.1.11-12.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-11365/cdrkit-1.1.11-12.fc17 then log in and leave karma (feedback).
Hi, icedax-1.1.11-12.fc17 fixes the issue: "-paranoia" now works properly. I.e.: read a CD: icedax-1.1.11-11, with "-paranoia": no warnings at all icedax-1.11.11-12, with "-paranoia": some warnings (as it should be), audible retries (as it should be). Test system: Fedora release 17 (Beefy Miracle) AMD Phenom 3.4.4-5.fc17.x86_64 Thanks a lot! -- Manfred
cdrkit-1.1.11-12.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
cdrkit-1.1.11-12.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.