search

pccasto / rubyripper

Automatically exported from code.google.com/p/rubyripper
0 stars 0 forks source link

Native support for neroAacEnc #280

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
I have been using version 0.5.4 for a while now to rip CDs to m4a using the
neroAacEnc encoder and setting metadata with AtomicParsley.  The command
line is like this:

neroAacEnc -q 0.5 -if %i -of "%o.m4a" && mkdir -p "/home/myname/tmp/m4a/%a
(%y) %b" && AtomicParsley "%o.m4a" -o "/home/myname/tmp/m4a/%a (%y) %b/%n.
%t.m4a" --artist "%a" --album "%b" --tracknum "%n" --year "%y" --title "%t"
&& rm "%o.m4a"

Works like a charm!

After upgrading to 0.5.5 this doesn't work anymore because the new version
insists on changing the command-line to:

neroAacEnc -q 0.5 -if "%i" -of "%o".m4a && mkdir -p
/home/myname/tmp/m4a/"%a" ("%y") "%b" && AtomicParsley "%o".m4a -o
/home/myname/tmp/m4a/"%a" ("%y") "%b"/"%n". "%t".m4a --artist "%a" --album
"%b" --tracknum "%n" --year "%y" --title "%t" && rm "%o".m4a

which obviously doesn't work.

Is this a bug or a feature?

Dr. Z

Original issue reported on code.google.com by zeej...@gmail.com on 8 Feb 2009 at 5:23

GoogleCodeExporter commented 8 years ago 
It seems to me you are very creative in using the other command feature. I 
don't know
what the heck you're doing. This goes way beyond my imagination :D

But I think you can change your commandline by removing the quotes around the
filenames and escape the spaces with a '\':

neroAacEnc -q 0.5 -if %i -of "%o".m4a && mkdir -p /home/myname/tmp/m4a/%a\ 
(%y)\ %b
&& AtomicParsley "%o".m4a -o /home/myname/tmp/m4a/%a\ (%y)\ %b/%n.\ %t.m4a 
--artist
"%a" --album "%b" --tracknum "%n" --year "%y" --title "%t"
&& rm "%o".m4a

Please report if this works :D

Original comment by rubyripp...@gmail.com on 9 Feb 2009 at 10:40

GoogleCodeExporter commented 8 years ago 
I'm not going to take credit for the creativity in the command line I posted. 
This is
something that I lifted out of a post somewhere on hydrogenaudio, with only 
slight
modifications.

If you care I'll explain it.  neroAacEnc is nero's proprietary closed source 
(evil?)
but free aac encoder which generates excellent m4a files that behave well on an 
ipod.
AtomicParsley works well for tagging them (makes a tagged copy of the file with 
a new
filename). the mkdir statement in between just makes sure that the tagged and 
encoded
files end up in a nice clean and logically named directory, and well, then the
cleanup at the end.

Escaping the spaces like you suggested is not enough, but you were almost 
there.  If
we escape the parentheses too it works !

neroAacEnc -q 0.5 -if %i -of "%o".m4a && mkdir -p /home/myname/tmp/m4a/%a\ 
\(%y\)\ %b
&& AtomicParsley "%o".m4a -o /home/myname/tmp/m4a/%a\ \(%y\)\ %b/%n.\ %t.m4a 
--artist
"%a" --album "%b" --tracknum "%n" --year "%y" --title "%t" && rm "%o".m4a

is translated by rubyripper into

neroAacEnc -q 0.5 -if "%i" -of "%o".m4a && mkdir -p /home/myname/tmp/m4a/"%a"\
\("%y"\)\ "%b" && AtomicParsley "%o".m4a -o /home/myname/tmp/m4a/"%a"\ \("%y"\)\
"%b"/"%n".\ "%t".m4a --artist "%a" --album "%b" --tracknum "%n" --year "%y" 
--title
"%t" && rm "%o".m4a

This works.  Thanks !!

The only slight imperfection is that the ripping.log and playlist end up in the
"other" directory, but who cares?

Just one quick question at the end. Isn't the "old" way of handling the "other"
command line more intuitive? I kind of prefer command lines not changing too 
much
behind my back.

Anyway, thanks for a geat program.  Keep up the good work.

Original comment by zeej...@gmail.com on 10 Feb 2009 at 6:50

GoogleCodeExporter commented 8 years ago 
The reason why this was changed is to prevent quote mistakes in the other
commandline. It was not quite consistent as quoting the "%i" chaaracter 
resulted in
an error. So now all quotes are stripped and placed back again.

I can imagine however you'd like this functionality integrated. Therefore I've
changed the summary of this issue. I suppose neroAacEnc doesn't support tags 
natively?

What would be a sensible default value, -q 0.5 ?

Original comment by rubyripp...@gmail.com on 10 Feb 2009 at 9:53

GoogleCodeExporter commented 8 years ago 
Of course having native neroAccEnc support would be neat although I'm not sure 
wheter
I sould advocate it.  After all it's not open source, and only distributed as
binaries from the Nero website 
(http://www.nero.com/eng/technologies-aac-codec.html).
 That's not going to be straight forward for inexperienced users.  Purists won't like
it either.

The encoder doesn't handle tags so there is neroAacTag for that, or as I prefer
AtomicParsley.  Then, aacgain can be used instead of mp3gain to normalize 
volume,
although I usually don't find it necessary.

The default value -q 0.5 will encode at variable bitrate usually between 
170-200. 
Excellent quality but files are not small. Lower bitrates are actually where
neroAccEnc supposedly brings the greatest advantages.

Bottom line is that the convoluted command line above works. Native or not is 
your call.

Original comment by zeej...@gmail.com on 10 Feb 2009 at 11:41

GoogleCodeExporter commented 8 years ago 
Having said that, there's always faac as a fallback for m4a encoding. Quality 
may not
be as good but most people won't notice.  You could make that a native option.

Original comment by zeej...@gmail.com on 10 Feb 2009 at 11:45

GoogleCodeExporter commented 8 years ago 
Well you don't have to enable aac encoding. So why not leave the choice to the 
users?
I know that nero's aac is at least quite competitive in terms of quality. I 
really
doubt how many people use faac, since it's known that either vorbis or mp3 
delivers
better quality.

Original comment by rubyripp...@gmail.com on 11 Feb 2009 at 7:42

GoogleCodeExporter commented 8 years ago 
You are absolutely right. If you can include a neroAacEnc option in a 
user-friendly
way, that would be great.
Faac doesn't seem to be developed anymore and quality is lacking.

Original comment by zeej...@gmail.com on 11 Feb 2009 at 8:37

GoogleCodeExporter commented 8 years ago 
I have a question, this is what I'm writing on rubyripper dialog 

neroAacEnc -q 0.38 -if %i -of %o && neroAacTag %o -meta:artist=%a -meta:album=%b
-meta:track=%n -meta:title=%t -meta:genre=%g -meta:year=%y 
-meta:comment="Rubyripper
Secure Rip"

The Rubbyripper translate command to this 

neroAacEnc -q 0.38 -if "%i" -of "%o" && neroAacTag "%o" -meta:artist="%a"
-meta:album="%b" -meta:track="%n" -meta:title="%t" -meta:genre="%g" 
-meta:year="%y"
-meta:comment=Rubyripper Secure Rip

The confusion comes from "-meta:comment=Rubyripper Secure Rip" and the tags get 
crap
(because of spaces). 
Is there more symbols like  %a, %b ... which can be used in command lines? I 
see in
the debug window for mp3 DISCID ... totaltracks and ... don't remember. The 
standard
tags can be used is 

List of standard Nero Digital metadata field names:
  title
  artist
  year
  album
  genre
  track
  totaltracks
  disc
  totaldiscs
  url
  copyright
  comment
  lyrics
  credits
  rating
  label
  composer
  isrc
  mood
  tempo

and more custom tags (just for info placing here)

Usage:
neroAacTag <file.mp4> <command> [<command> [<command> ...]]
Available commands:
-list-meta                    : Lists existing metadata entries.
-meta:<name>=<value>          : Sets specified metadata field to specified
                                value. Eg. -meta:artist="Pink Floyd"
-meta-user:<name>=<value>     : Sets specified metadata field to specified
                                value. Allows non-standard metadata fields
                                to be added.
                                WARNING: fields added using -meta-user are
                                not guaranteed to be read back on all
                                Nero Digital compliant software/hardware.
-list-standard-meta           : Displays a list of field names usable with
                                -meta command.
-list-covers                  : Lists cover art entries.
-add-cover:<type>:<jpegfile>  : Creates a cover art entry from specified 
                                JPEG file.
                                <type> specifies type of cover art entry and
                                can be "front" or "back".
                                If specified cover art entry already exists,
                                its contents are overwritten.
                                Eg. -add-cover:back:hello.jpg
-dump-cover:<type>:<jpegfile> : Dumps specified cover art entry contents to 
                                a JPEG file.
-remove-cover:<type>          : Removes specified cover art entry.
-remove-cover:all             : Removes all cover art entries.
-list-chapters                : Lists chapters present in the file.
-chapter:<number>             : Sets chapter index metadata edits apply to.
                                Value of 0 (default state) applies edits to
                                all present chapters.
                                Also affects -list-meta output.
-chapters-to-tracknumbers     : Generates track number metadata according to
                                the chapter list.

Original comment by tolos...@gmail.com on 13 Aug 2009 at 2:47

GoogleCodeExporter commented 8 years ago 
I've implemented this in current git now. Had to add some extra code for this 
tagging after encoding idea, but this was easy enough to do. The two commands 
that are automatically verified with a unit test are:

encoding command:
'neroAacEnc -q 1 -if "input_1.wav" -of "/home/nero/1-test.aac"'

tags command:
'neroAacTag "/home/nero/1-test.aac" -meta:artist="trackArtist 1" 
-meta:album="album" -meta:genre="genre" -meta:year="year" -meta-user:"ALBUM 
ARTIST"="artist" -meta:disc=1 -meta-user:ENCODER="Rubyripper test" 
-meta-user:DISCID="ABCDEFGH" -meta:title="trackname 1" -meta:track=1 
-meta:totaltracks=99'

Only the user interface needs to be updated now. Please let me know if you see 
any errors / possible problems.

Original comment by boukewou...@gmail.com on 24 Mar 2012 at 8:55

GoogleCodeExporter commented 8 years ago 
I just found out accgain also exists, I'll have to add this as well.

Original comment by boukewou...@gmail.com on 24 Mar 2012 at 9:42

GoogleCodeExporter commented 8 years ago 
This is fixed in current git and ready for testing :) For your information; 
latest git is quite usable after all the fixes I've done this weekend.

Original comment by boukewou...@gmail.com on 25 Mar 2012 at 9:53

GoogleCodeExporter commented 8 years ago 
I would love to try this out but the git version crashes on me as soon as I 
scan the drive for a CD.

Original comment by zeej...@gmail.com on 26 Mar 2012 at 9:59

GoogleCodeExporter commented 8 years ago 
I managed to load a CD by disabling metadata lookup.

Now the git version crashes as soon as I try to start encoding with this error

/home/nn/programs/rubyripper/lib/rubyripper/rubyripper.rb:39:in `require': 
/home/nn/programs/rubyripper/lib/rubyripper/fileScheme.rb:78: syntax error, 
unexpected ')', expecting '='
/home/nn/programs/rubyripper/lib/rubyripper/fileScheme.rb:274: syntax error, 
unexpected kEND, expecting $end

Original comment by zeej...@gmail.com on 26 Mar 2012 at 10:39

GoogleCodeExporter commented 8 years ago 
Are you sure you're up to date? (hint try: git pull). I've just verified it 
works to rip a single track.

If this does not help, please turn on the debug setting and post the terminal 
output before the crash.

Original comment by boukewou...@gmail.com on 26 Mar 2012 at 4:46

GoogleCodeExporter commented 8 years ago 
Git version is up to date.  I just pulled before posting the last comments.

It crashes as soon as I try to rip something no matter which codec I have 
selected.  This is the output with verbose and debug modes enabled:

DEBUG: cdparanoia -d /dev/sr0 -vQ
DEBUG: trackselection = 1
/home/nn/programs/rubyripper/lib/rubyripper/rubyripper.rb:39:in `require': 
/home/nn/programs/rubyripper/lib/rubyripper/fileScheme.rb:78: syntax error, 
unexpected ')', expecting '='
/home/nn/programs/rubyripper/lib/rubyripper/fileScheme.rb:274: syntax error, 
unexpected kEND, expecting $end
         from /home/nn/programs/rubyripper/lib/rubyripper/rubyripper.rb:39:in `checkConfiguration'
         from ./bin/rubyripper_gtk2:369:in `startRip'
         from ./bin/rubyripper_gtk2:215:in `setButtonsLeftsideSignals'
         from ./bin/rubyripper_gtk2:66:in `call'
         from ./bin/rubyripper_gtk2:66:in `main'
         from ./bin/rubyripper_gtk2:66:in `start'
         from ./bin/rubyripper_gtk2:411

I will try this on a different computer when I have a chance to find out if 
this is just because of my setup.

Original comment by zeej...@gmail.com on 26 Mar 2012 at 5:17

GoogleCodeExporter commented 8 years ago 
What happens when you open up a terminal:
* cd /home/nn/programs/rubyripper/lib
* irb
* $:.insert(0, '.')
* require 'rubyripper/base'
* require 'rubyripper/fileScheme'

Original comment by boukewou...@gmail.com on 26 Mar 2012 at 5:35

GoogleCodeExporter commented 8 years ago 
I am on a different computer now runing Arch linux
Did a fresh git pull.
rubyripper_gtk2 crashes if freedb or musicbrainz are enabled (maybe not 
relevant to this thread).
Trying to encode a single track with neroAacEnc got me a bit further than on 
the Fedora 16 box I was using before. On this one the ripping actually starts 
before a crash. This is the output with debug enabled.

DEBUG: cdparanoia -d /dev/cdrom -vQ
DEBUG: trackselection = [1]
DEBUG: cd-info -C /dev/cdrom -A --no-cddb
DEBUG: cdparanoia --version
DEBUG: Ripping track 1
DEBUG: Expected filesize for track 1 is 46120412 bytes.
DEBUG: LANG=C; df "/home/zjons/tmp/nero/Band (1980) Album"
DEBUG: Free disk space is 7598148 MB
DEBUG: Minutes ripping is 0.0010612518666666669.
DEBUG: cdparanoia -Z [.0]-[.19608] -d /dev/cdrom -O 0 
"/home/zjons/tmp/nero/temp_cdrom/track_1_1.wav"
DEBUG: Minutes ripping is 0.29914586575.
DEBUG: cdparanoia -Z [.0]-[.19608] -d /dev/cdrom -O 0 
"/home/zjons/tmp/nero/temp_cdrom/track_1_2.wav"
/home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/secureRip.rb:425:i
n `getCRC': uninitialized constant SecureRip::Zlib (NameError)
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/secureRip.rb:227:in `block in analyzeFiles'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/secureRip.rb:227:in `times'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/secureRip.rb:227:in `analyzeFiles'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/secureRip.rb:139:in `main'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/secureRip.rb:97:in `ripTrack'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/secureRip.rb:68:in `block in ripTracks'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/secureRip.rb:65:in `each'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/secureRip.rb:65:in `ripTracks'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/rubyripper.rb:62:in `startRip'
        from ./bin/rubyripper_gtk2:384:in `block in updateInterfaceAndStartRip'

I switched to the stable branch and have no problems with freeccdb or ripping 
there. 

I don't have time to try the suggestion in your last comment just yet but I 
will report as soon as I have.

Original comment by zeej...@gmail.com on 26 Mar 2012 at 6:11

GoogleCodeExporter commented 8 years ago 
Please pull again; I've fixed this particular error.

Original comment by boukewou...@gmail.com on 26 Mar 2012 at 7:16

GoogleCodeExporter commented 8 years ago 
Back on Fedora 16
Did a fresh pull
Went to rubyripper/lib and did what you suggested. This is the output:

[zjons@svampur lib]$ irb
irb(main):001:0> $:.insert(0, '.')
=> [".", "/usr/lib/ruby/site_ruby/1.8", "/usr/lib64/ruby/site_ruby/1.8", 
"/usr/lib64/ruby/site_ruby/1.8/x86_64-linux", "/usr/lib/ruby/site_ruby", 
"/usr/lib64/ruby/site_ruby", "/usr/lib64/site_ruby/1.8", 
"/usr/lib64/site_ruby/1.8/x86_64-linux", "/usr/lib64/site_ruby", 
"/usr/lib/ruby/1.8", "/usr/lib64/ruby/1.8", "/usr/lib64/ruby/1.8/x86_64-linux", 
"."]
irb(main):002:0> require 'rubyripper/base'
=> true
irb(main):003:0> require 'rubyripper/fileScheme'
SyntaxError: ./rubyripper/fileScheme.rb:78: syntax error, unexpected ')', 
expecting '='
./rubyripper/fileScheme.rb:274: syntax error, unexpected kEND, expecting $end
        from (irb):3:in `require'
        from (irb):3
        from :0

rubyripper crashes with the same errors as before

Original comment by zeej...@gmail.com on 26 Mar 2012 at 7:49

GoogleCodeExporter commented 8 years ago 
I think it's a ruby 1.8 bug. Please pull again.

Original comment by boukewou...@gmail.com on 26 Mar 2012 at 8:12

GoogleCodeExporter commented 8 years ago 
Pulled again.  Same bugs.

Original comment by zeej...@gmail.com on 26 Mar 2012 at 8:29

GoogleCodeExporter commented 8 years ago 
Maybe you can try to upgrade to ruby 1.9 ? It is kinda hard to debug particular 
behaviour of the old ruby interpreter.

Original comment by boukewou...@gmail.com on 26 Mar 2012 at 8:33

GoogleCodeExporter commented 8 years ago 
Just for the record, it works for me ofcourse:

[bouke@woudstra lib]$ irb
irb(main):001:0> $:.insert(0, '.')
=> [".", "/usr/lib/ruby/site_ruby/1.9.1", 
"/usr/lib/ruby/site_ruby/1.9.1/x86_64-linux", "/usr/lib/ruby/site_ruby", 
"/usr/lib/ruby/vendor_ruby/1.9.1", 
"/usr/lib/ruby/vendor_ruby/1.9.1/x86_64-linux", "/usr/lib/ruby/vendor_ruby", 
"/usr/lib/ruby/1.9.1", "/usr/lib/ruby/1.9.1/x86_64-linux"]
irb(main):002:0> require 'rubyripper/base'
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': iconv will be 
deprecated in the future, use String#encode instead.
/home/bouke/.gem/ruby/1.9.1/gems/gettext-2.1.0/lib/gettext/runtime/locale_path.r
b:20: Use RbConfig instead of obsolete and deprecated Config.
=> true
irb(main):003:0> require 'rubyripper/fileScheme'
=> true

Original comment by boukewou...@gmail.com on 26 Mar 2012 at 8:35

GoogleCodeExporter commented 8 years ago 
Upgrading to 1.9 on Fedora 16 is not trivial since the rpm's are not in the 
repos, not even in testing. It should be possible to upgrade with rvm but I 
don't want to risk breaking things.

I have 1.9 installed on Arch and I'll test there again when I have time.

Original comment by zeej...@gmail.com on 26 Mar 2012 at 8:58

GoogleCodeExporter commented 8 years ago 
For now I've explicitly raised the requirement to use 1.9 or higher. It will 
take too much time to debug all kind of strange "bugs" otherwise. As a 
developer I like the new features of 1.9 and I cannot maintain backward 
compatibility forever.

But I am sure debugging will be more fruitfull with Arch linux since I am 
running that one myself :)

Original comment by boukewou...@gmail.com on 26 Mar 2012 at 9:08

GoogleCodeExporter commented 8 years ago 
Encoding works on Arch with ruby 1.9.1 but there are still issues:

1) Crashes immediately when disk is loaded if metadata lookup is enabled.
2) The aac files are not tagged.
3) It would be useful to toggle the extension to .m4a

Original comment by zeej...@gmail.com on 27 Mar 2012 at 2:46

GoogleCodeExporter commented 8 years ago 
Good to hear we're getting there :)

1) Please post the crash when launched from a terminal.
2) Fixed. The logic was there but was never triggered.
3) Fixed.

By the way, please try to set the metadata to freedb. I found it to be more 
stable right now.

Original comment by boukewou...@gmail.com on 27 Mar 2012 at 5:13

GoogleCodeExporter commented 8 years ago 
Still crashes when freedb is enabled. This is the output:

DEBUG: cd-discid /dev/cdrom                                                     

/home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/disc/calcFreedbID.
rb:61:in `getFreedbString': undefined method `split' for #<Array:0x94fe5bc> 
(NoMethodError)                                                           
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/disc/calcFreedbID.rb:44:in `discid'     
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/disc/disc.rb:60:in `freedbDiscid'       
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/metadata/freedb.rb:65:in `isLocalFileFound?'                                                                                                               
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/metadata/freedb.rb:45:in `get'          
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/metadata/main.rb:69:in `freedb'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/metadata/main.rb:55:in `startup'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/metadata/main.rb:36:in `block in get'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/metadata/main.rb:35:in `each'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/metadata/main.rb:35:in `get'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/disc/disc.rb:98:in `setMetadata'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/disc/disc.rb:39:in `scan'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/gtk2/gtkDisc.rb:42:in `refresh'
        from ./bin/rubyripper_gtk2:140:in `block in scanDisc'

Also, if this may be helpful ...

irb(main):001:0> $:.insert(0, '.')
=> [".", "/usr/lib/ruby/site_ruby/1.9.1", 
"/usr/lib/ruby/site_ruby/1.9.1/i686-linux", "/usr/lib/ruby/site_ruby", 
"/usr/lib/ruby/vendor_ruby/1.9.1", 
"/usr/lib/ruby/vendor_ruby/1.9.1/i686-linux", "/usr/lib/ruby/vendor_ruby", 
"/usr/lib/ruby/1.9.1", "/usr/lib/ruby/1.9.1/i686-linux"]
irb(main):002:0> require 'rubyripper/base'
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': iconv will be 
deprecated in the future, use String#encode instead.
/usr/lib/ruby/gems/1.9.1/gems/gettext-2.1.0/lib/gettext/runtime/locale_path.rb:2
0: Use RbConfig instead of obsolete and deprecated Config.
undefined method `size' for nil:NilClass
/usr/lib/ruby/gems/1.9.1/gems/locale-2.0.5/lib/locale.rb:239:in 
`collect_candidates'
/usr/lib/ruby/gems/1.9.1/gems/locale-2.0.5/lib/locale.rb:222:in `candidates'
/usr/lib/ruby/gems/1.9.1/gems/gettext-2.1.0/lib/gettext/runtime/textdomain_manag
er.rb:78:in `each_textdomains'
/usr/lib/ruby/gems/1.9.1/gems/gettext-2.1.0/lib/gettext/runtime/textdomain_manag
er.rb:102:in `translate_singluar_message'
/usr/lib/ruby/gems/1.9.1/gems/gettext-2.1.0/lib/gettext.rb:128:in `gettext'
/home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/base.rb:46:in 
`<class:TestIfGetTextDoesNotCrash>'
/home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/base.rb:43:in 
`<top (required)>'
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
(irb):2:in `irb_binding'
/usr/lib/ruby/1.9.1/irb/workspace.rb:80:in `eval'
/usr/lib/ruby/1.9.1/irb/workspace.rb:80:in `evaluate'
/usr/lib/ruby/1.9.1/irb/context.rb:254:in `evaluate'
/usr/lib/ruby/1.9.1/irb.rb:159:in `block (2 levels) in eval_input'
/usr/lib/ruby/1.9.1/irb.rb:273:in `signal_status'
/usr/lib/ruby/1.9.1/irb.rb:156:in `block in eval_input'
/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:243:in `block (2 levels) in 
each_top_level_statement'
/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in `loop'
/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in `block in each_top_level_statement'
/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:228:in `catch'
/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:228:in `each_top_level_statement'
/usr/lib/ruby/1.9.1/irb.rb:155:in `eval_input'
/usr/lib/ruby/1.9.1/irb.rb:70:in `block in start'
/usr/lib/ruby/1.9.1/irb.rb:69:in `catch'
/usr/lib/ruby/1.9.1/irb.rb:69:in `start'
/usr/bin/irb:12:in `<main>'
ruby-gettext is crashing. Translations are disabled!
=> true
irb(main):003:0> require 'rubyripper/fileScheme'
=> true
irb(main):004:0> 

Could be a configuration problem on my end

Original comment by zeej...@gmail.com on 27 Mar 2012 at 7:13

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I found the problem, only happened when cd-discid or discid was installed. 
There was a bug in the unit test, fixed that as well :)

Original comment by boukewou...@gmail.com on 27 Mar 2012 at 8:06

GoogleCodeExporter commented 8 years ago 
Note that I created the <class:TestIfGetTextDoesNotCrash> because of the 
unreliable behaviour of ruby-gettext. It automatically detects in base.rb if 
gettext does succesfully work, if not an alternative Gettext module is defined 
where translations are disabled.

Original comment by boukewou...@gmail.com on 27 Mar 2012 at 8:13

GoogleCodeExporter commented 8 years ago 
Getting better.  Freedb (or musicbrainz) lookup still doesn't work but at least 
the gettext error doesn't crash rubyripper anymore.

I could encode a single track but tagging didn't work and crashed rr with the 
following output:

DEBUG: cdparanoia -Z [.19012]-[.20369] -d /dev/cdrom -O 0 
"/home/zjons/tmp/nero/temp_cdrom/track_2_2.wav"
/home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/codecs/main.rb:78:
in `setTagsAfterEncoding': wrong number of arguments (0 for 1) (ArgumentError)
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/encode.rb:122:in `encodeTrack'
        from /home/zjons/Programs/rubyripper/rubyripper-git/lib/rubyripper/encode.rb:76:in `block (2 levels) in startEncoding'

Original comment by zeej...@gmail.com on 27 Mar 2012 at 11:06

GoogleCodeExporter commented 8 years ago 
Hmmm, that's what is wrong with quick fixes, easy to make little mistakes. 
Crash should be fixed now.

Original comment by boukewou...@gmail.com on 28 Mar 2012 at 6:05

GoogleCodeExporter commented 8 years ago 
It worked perfectly on Arch.  Now even musicbraiz lookups work and I could rip 
a full CD without problems.

On Gentoo (with ruby 1.9.3 installed) I am seeing a different problem.  I get 
read errors and then invariably rr crashes after the 4th read. Maybe there is 
something wrong with the cd drive but I can rip without problems using ripperX. 
 Anyway, that's a different bug altogether and I won't bother you with it 
unless you are interested.

Original comment by zeej...@gmail.com on 30 Mar 2012 at 11:17

GoogleCodeExporter commented 8 years ago 
Thanks for your feedback, I'll update the status to Verified. Feel free to 
create a new issue for the read problems. I can't guarantee it will get my 
attention right now though.

There are still a lot of cleanups going on. It just so happened I cleaned up 
the encoding part. I thought the best way to prove the new design is by showing 
how easy it is to add new codecs.

Original comment by boukewou...@gmail.com on 31 Mar 2012 at 7:17