From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 771EA139A89 for ; Tue, 8 Sep 2015 07:09:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6196314292; Tue, 8 Sep 2015 07:09:27 +0000 (UTC) Received: from mail0200.smtp25.com (mail0200.smtp25.com [174.37.170.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 935C3141E9 for ; Tue, 8 Sep 2015 07:09:25 +0000 (UTC) Received: from ccs.covici.com (localhost [127.0.0.1]) by ccs.covici.com (8.14.9/8.14.8) with ESMTP id t8879KVo023455 for ; Tue, 8 Sep 2015 03:09:21 -0400 From: covici@ccs.covici.com To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] CD ripper that generates song titles? In-reply-to: References: <20150826200610.GA22849@waltdnes.org> <15543.1441685354@ccs.covici.com> Comments: In-reply-to Fernando Rodriguez message dated "Tue, 08 Sep 2015 01:02:04 -0400." X-Mailer: MH-E 8.5; nmh 1.6; GNU Emacs 23.4.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23453.1441696160.1@ccs.covici.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 08 Sep 2015 03:09:20 -0400 Message-ID: <23454.1441696160@ccs.covici.com> X-SpamH-OriginatingIP: 70.109.53.110 X-SpamH-Filter: s-out-001.smtp25.com-t8879MiB011571 X-Archives-Salt: 4e5ce8ae-3e10-4992-9e61-38adad899937 X-Archives-Hash: 9de543c64d4dfdfc76bbb0d4a92ca4ba Fernando Rodriguez wrote: > On Tuesday, September 08, 2015 12:09:14 AM covici@ccs.covici.com wrote: > > Fernando Rodriguez wrote: > > = > > > On Monday, September 07, 2015 7:45:47 PM covici@ccs.covici.com wrote= : > > > > Alex Corkwell wrote: > > > > = > > > > > On Wed, Aug 26, 2015 at 04:06:10PM -0400, Walter Dnes wrote: > > > > > > I went to the CNE (Canadian National Exhibition) yesterday a= nd > > > > > > indulged in a buying spree of 18 CD sets of my fave music (bas= ically > > > > > > anything pop/rock/country pre-Beatles). I now have over 20 CD= s that = > I > > > > > > want to rip to flac eventually. I dread the gruntwork in rena= ming > > > > > > tracks like track01.cdda.wav, etc. What Gentoo ebuilds are th= ere = > for > > > > > > stuff that'll get ahold of track titles? Is it in the form of= = > metadata > > > > > > on the CD? > > > > > = > > > > > I personally like using morituri [1] for ripping my CDs. > > > > > It's a little bit slower than some, but very accurate (I believe= it > > > > > compares several reads, just to make sure there were no errors). > > > > > It's not available in the main portage tree, but it's in the dev= -zero > > > > > overlay as media-sound/morituri. > > > > > = > > > > > It can rip to flac (with optional cue files) and works from the > > > > > terminal, if you prefer that. > > > > > Additionally, it can adjust for drive read offsets when writing = files, > > > > > and is one of the few Linux things I've found which check the ri= ps > > > > > against AccurateRip. > > > > > = > > > > > What's particularly nice about it is that it uses what little me= tadata > > > > > and such it can get from the CD to look it up in MusicBrainz and= add = > in > > > > > the title, artist, etc. > > > > > It also uses this to name the files according to album, artist, = song > > > > > title, etc. > > > > > The template it uses to name the files and directories is relati= vely > > > > > configurable, as well. > > > > > = > > > > > If you need more configurable tagging, cover art downloading, an= d such, > > > > > then look into Picard [2], which is in the main portage tree as > > > > > media-sound/picard. > > > > > It uses MusicBrainz [3] to get a whole bunch of metadata, tags, = cover > > > > > art, and other stuff, and can rename files much more flexibly th= an > > > > > morituri. > > > > > = > > > > > This is especially nice in combination with morituri, since mori= turi > > > > > saves the MusicBrainz ID into the metadata of the ripped files. > > > > > Normally, Picard looks files up by either the available metadata= , or by > > > > > the acoustic fingerprint. > > > > > Since the MusicBrainz ID is already there, it immediately knows = which > > > > > album it is (although it may have the wrong release if you want = to be > > > > > that precise). > > > > > = > > > > > The only caveats with Picard that I know of are that it's GUI on= ly, it > > > > > can't embed full size cover art if the image is above some large > > > > > resolution, and I think that submitting extra fingerprints requi= res you > > > > > to register with AcoustID [4]. > > > > > Also, it's not an actual ripper. > > > > > It just works on the metadata and tags of flac, mp3, and maybe a= few > > > > > other types. > > > > > = > > > > > I personally like to rip with morituri, then polish the tagging = and = > get > > > > > the cover art with Picard. > > > > > = > > > > > [1] http://thomas.apestaart.org/morituri/trac/wiki > > > > > [2] https://picard.musicbrainz.org/ > > > > > [3] https://musicbrainz.org/ > > > > > [4] https://acoustid.org/ > > > > = > > > > In trying to emerge morituri from the overlay I get the folloing: > > > > = > > > > make[1]: Entering directory > > > > '/var/tmp/portage/media-sound/morituri-0.2.3/work/morituri-0.2.3' > > > > if test -e ./.git; then make REVISION; fi > > > > make[1]: Leaving directory > > > > '/var/tmp/portage/media-sound/morituri-0.2.3/work/morituri-0.2.3' > > > > ** Message: pygobject_register_sinkfunc is deprecated (GstObject) > > > > Progress: > > > > 00:10 > > > > (null)*(null) (null)ACCESS DENIED(null): mkstemp: > > > > = > > > = > /run/user/0/orcexec.XXXXXX----------------------------------------------= ---------------------------] > > > > Building documentation: morituri.common.checksum > > > > (/var/tmp/portage/media- > > > sound/morituri-0.2.3/work/morituri-0.2.3/morituri/common/checksum.py= ) > > > > (gst-plugin-scanner:3783): GStreamer-CRITICAL **: > > > > gst_structure_empty_new: assertion 'gst_structure_validate_name (n= ame)' > > > > failed > > > > = > > > > (gst-plugin-scanner:3783): Clutter-CRITICAL **: Unable to initiali= ze > > > > Clutter: Could not initialize Gdk > > > > ** Message: pygobject_register_sinkfunc is deprecated (GstObject) > > > > Warning: Unable to extract the base list for > > > > twisted.trial.unittest.TestDecorator: Bad dotted name > > > > Warning: Module gobject._gobject is shadowed by a variable with th= e same > > > > name. > > > > Warning: 18 markup errors were found while processing docstrings. = Use > > > > the verbose switch (-v) to display markup errors. > > > > >>> Source compiled. > > > > (null)*(null) --------------------------- ACCESS VIOLATION SUMMAR= Y > > > > --------------------------- > > > > (null)*(null) LOG FILE: "/var/log/sandbox/sandbox-3700.log" > > > > (null)*(null) > > > > VERSION 1.0 > > > > FORMAT: F - Function called > > > > FORMAT: S - Access Status > > > > FORMAT: P - Path as passed to function > > > > FORMAT: A - Absolute Path (not canonical) > > > > FORMAT: R - Canonical Path > > > > FORMAT: C - Command Line > > > > = > > > > F: mkstemp > > > > S: deny > > > > P: /run/user/0/orcexec.XXXXXX > > > > A: /run/user/0/orcexec.XXXXXX > > > > R: /run/user/0/orcexec.XXXXXX > > > > C: /usr/lib64/gstreamer-0.10/gst-plugin-scanner -l > > > > (null)*(null) > > > > = > > > = > ------------------------------------------------------------------------= -------- > > > > = > > > > >>> Failed to emerge media-sound/morituri-0.2.3, Log file: > > > > = > > > > >>> '/var/log/portage/media-sound:morituri-0.2.3:20150907-233836.= log' > > > > = > > > > = > > > > So, how can I fix or is this a dead package i.e. no maintainance? > > > > = > > > > Thanks in advance for any ideas. > > > > = > > > > = > > > > = > > > = > > > If you trust the ebuild you can try emerging it with FEATURES=3D"-sa= ndbox" = > or = > > > add an exception for the temp directory on the ebuild. > > > = > > > https://devmanual.gentoo.org/function-reference/sandbox-functions/ > > = > > So, if I wanted to add addpredict /run where would I put it? Somewher= e > > in the ebuild? I still tink its pretty funky. > > = > > = > = > It looks like it's happening during the compile phase so at the top of = > src_compile(). If it's a live (git) ebuild it's likely that it's an upst= ream = > change since the ebuild was written. If a malicious ebuild wants to esca= pe the = > sandbox it's easy (clear LD_PRELOAD or load a dummy sandbox library) so = it's = > likely just bad practices. > = > I don't know if addpredict will work but it's worth a try, in any case I= think = > it'll be harmless to write there (any user can do it). If there's no = > src_compile() make it: > = > src_compile() { > addpredict /run/user/0/ > default > } > = > I don't remember if that's the right syntax for a directory, it may be = > addpredict "/run/user/0/*" Well, I did get it to emerge, but it was very broke, like they never finished the thing, even valid commands would always give a traceback, so I got rid of the thing. Thanks anyway for all your help -- I learned something anyway. -- = Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com