Re: [gentoo-user] CD ripper that generates song titles?

[Fernando Rodriguez <frodriguez.developer@outlook.com>]

On Monday, September 07, 2015 10:51:18 PM covici@ccs.covici.com wrote:
> Fernando Rodriguez <frodriguez.developer@outlook.com> wrote:
> 
> > On Monday, September 07, 2015 7:45:47 PM covici@ccs.covici.com wrote:
> > > Alex Corkwell <i.am.the.memory@gmail.com> wrote:
> > > 
> > > > On Wed, Aug 26, 2015 at 04:06:10PM -0400, Walter Dnes wrote:
> > > > >   I went to the CNE (Canadian National Exhibition) yesterday and
> > > > > indulged in a buying spree of 18 CD sets of my fave music (basically
> > > > > anything pop/rock/country pre-Beatles).  I now have over 20 CDs that 
I
> > > > > want to rip to flac eventually.  I dread the gruntwork in renaming
> > > > > tracks like track01.cdda.wav, etc.  What Gentoo ebuilds are there 
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 rips
> > > > against AccurateRip.
> > > > 
> > > > What's particularly nice about it is that it uses what little metadata
> > > > 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 relatively
> > > > configurable, as well.
> > > > 
> > > > If you need more configurable tagging, cover art downloading, and 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 than
> > > > morituri.
> > > > 
> > > > This is especially nice in combination with morituri, since morituri
> > > > 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 only, it
> > > > can't embed full size cover art if the image is above some large
> > > > resolution, and I think that submitting extra fingerprints requires 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 (name)'
> > > failed
> > > 
> > > (gst-plugin-scanner:3783): Clutter-CRITICAL **: Unable to initialize
> > > 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 the 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 SUMMARY
> > >  ---------------------------
> > >  (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="-sandbox" 
or 
> > add an exception for the temp directory on the ebuild.
> > 
> > https://devmanual.gentoo.org/function-reference/sandbox-functions/
> 
> But what is it really complaining about?  I don't want to do this
> arbitrarily, it is there for a reason.

In that case it looks like it's just trying to create a temp file under /run. 
Portage defines a temp directory within the sandbox but it looks like the build 
system uses some other method to determine the temp dir. Also note that it is 
running as root (I think that's because the ebuild has userpriv set) so 
although a temp file sounds harmless there's no way to tell what else it'll do 
if you run it without the sandbox. You can use the addwrite function at the 
top of the src_compile() function to allow it to write only to that directory.

-- 
Fernando Rodriguez