Created attachment 350312 [details] morituri-9999 ebuild https://github.com/thomasvs/morituri/ A CD ripper aiming for accuracy over speed The only ripper available on Linux that supports AccurateRip information, as well as offset calculation, etc. I've found live ebuilds, but I haven't been able to edit it into a version that works for a specific release, since the program is dependent on a git submodule. I don't know if that has to be broken out into it's own package, and dependent on. I guess so? I'm attaching the live ebuild I have that works except for one thing: The shebang is generated incorrectly for it, and I have no idea why. But I have a feeling you old Gentoo magicians will be able to spot the error immediately :) It should say #!/usr/bin/python2.7 but now say #!/var/tmp/portage/media-sound/morituri-9999/temp/python2.72.7/bin/python I'd also like to enable/disable doc building/test based on IUSE, and not always disable it like now.
http://git.overlays.gentoo.org/gitweb/?p=dev/dev-zero.git;a=tree;f=media-sound/morituri could be bumped to version 0.2.0 from here: https://github.com/thomasvs/morituri/tags @dev-zero: would you be willing to add the ebuild from your dev-overlay to the maintree?
Bump...
I've been using this -9999 version for a while now, and ripped perhaps 20 cd's using it.
Created attachment 380888 [details] morituri-0.2.3.ebuild see http://thomas.apestaart.org/log/?p=1574 ebuild changes: * remove use flags for runtime dependencies * depend on media-plugins/gst-plugins-meta:0.10 * add RESTRICT="test"
Hi guys, any chance the dev-zero ebuild will get in?
Peter's ebuild (9999) emerges for me, but the program seems to require gst-python:0.10 at this point. ...I couldn't get it to do much, though. It will confirm an offset (rip offset find), but only if the CD one tests with is in MusicBrainz limited database (compared to freedb.org's); otherwise it tries random offsets forever. This happened in my tests of 0.2.3 from a .deb on Ubuntu as well. It won't analyze the drive with cdparanoia (rip drive analyze), claiming there is no CD present, despite cdparanoia having no trouble ripping the CD on its own. This actually worked with 0.2.3 on Ubuntu, but also only for a CD already in MusicBrainz. Anything that relies on the config file having been written is problematic, as without commands like the preceding working, the magical syntax of the config file is, without converting so many lines of Python to "English", largely a mystery. The actual rip command (rip cd rip) doesn't work if the CD is not only in MusicBrainz's database (which it finds by identifying its CDDB id successfully), but also associated with a 'disc id'. Forcing the rip with -U (for allowing "/U/nknown" rips) immediately identifies the disc from FreeDB, but fails to apply any metadata to tracks. Complains about not being able to find flac plugin. It seems... real bad, even for a version starting with '0.' or straight from the VCS.
Created attachment 430216 [details] Fixed ebuild Fixed ebuild for morituri (needed gstreamer 0.10)
A little fix to require for gstreamer 0.10 everywhere it's needed.
Morituri functionality has been broken for me as well, for a couple of months. I think this is because of its dependencies being updated, and it hasn't been ported to the new library versions yet. It was working really nicely a year (or so) ago, and I used it daily as my ripper.
(In reply to Peter Asplund from comment #9) > It was working really nicely a year (or so) ago, and I used it daily as my Could you be more specific? What's your log got as the date for when you first installed it and it worked correctly?
(In reply to reisio from comment #10) > (In reply to Peter Asplund from comment #9) > > It was working really nicely a year (or so) ago, and I used it daily as my > > Could you be more specific? What's your log got as the date for when you > first installed it and it worked correctly? Wow, good question. When I created this bug, the ebuild was working fine. I'm pretty sure it was fine by the time I wrote comment #5, so 2014-07-28. I guess we could file a bug upstream and see if there is any activity. The project development seems to have slowed a lot.
Upstream appears to be abandoned, the last commit was in 2015, the last actual code change in 2014. The maintainer also does not appear to have responded to issues in years. There's a fork though, which is quite active and probably the way to go: https://github.com/JoeLametta/whipper
I agree, it seems the way to go.
I just checked, and the fork 'Whipper' now seems to be in portage, so I guess this bug can be closed as obsolete. * media-sound/whipper Available versions: (~)0.7.0 {test PYTHON_TARGETS="python2_7"} Homepage: https://github.com/whipper-team/whipper Description: A Python CD-DA ripper preferring accuracy over speed (forked from morituri)
