Summary: | media-sound/morituri - CD ripper aiming for accuracy over speed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter Asplund <azpegath> |
Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
Status: | RESOLVED OBSOLETE | ||
Severity: | enhancement | CC: | dev-zero, jwbraun, poncho, v_2e |
Priority: | Normal | Keywords: | EBUILD |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://github.com/thomasvs/morituri/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
morituri-9999 ebuild
morituri-0.2.3.ebuild Fixed ebuild |
Description
Peter Asplund
2013-06-06 22:38:27 UTC
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) |