A secure ripper for linux, My latest Python programming results Options

[k.eight.a]

Add --id3v1-only to your command-line options.

You mean in "Preferences > Codecs > Lame Mp3" add:

CODE

-V 2 -Y --id3v1-only

...right?

I have tried it and now I have both ID3V1 and ID3V2. Before I had only ID3V2.

I have 2 Metallica CD's Master of Puppets (1986) & ...and Justice for All (1988). The latter one I was never able to rip by EAC with matching CRC or Accurate Rip confidence. With RubyRipper it seems that I was successful:

CODE

This log is created by Rubyripper, version 0.5.3
Website: http://code.google.com/p/rubyripper

Cdrom player used to rip:
HL-DT-ST DVDRAM GSA-4165B DL04
Cdrom offset used: 667

Ripper used: cdparanoia -Z
Matches required for all chunks: 2
Matches required for erroneous chunks: 2

Codec(s) used:
-mp3 -> -V 2 -Y --id3v1-only
(LAME 32bits version 3.98 (http://www.mp3dev.org/)

CDDB INFO

Artist = Metallica
Album = ...and Justice for All
Year = 1988
Genre = Thrash Metal
Tracks = 9

01 - Blackened
02 - ...and Justice for All
03 - Eye of the Beholder
04 - One
05 - The Shortest Straw
06 - Harvester of Sorrow
07 - The Frayed Ends of Sanity
08 - To Live Is to Die
09 - Dyers Eve

STATUS

Starting to rip track 1, trial #1
Starting to rip track 1, trial #2
Analyzing files for mismatching chunks
Every chunk matched 2 times
MD5 sum: 210f4fd7b4f8169781a5b0a45a6ebffe

Starting to rip track 2, trial #1
Starting to rip track 2, trial #2
Analyzing files for mismatching chunks
54 chunk(s) didn't match 2 times.
Starting to rip track 2, trial #3
16 chunk(s) didn't match 2 times.
Starting to rip track 2, trial #4
6 chunk(s) didn't match 2 times.
Starting to rip track 2, trial #5
6 chunk(s) didn't match 2 times.
Starting to rip track 2, trial #6
2 chunk(s) didn't match 2 times.
Starting to rip track 2, trial #7
Error(s) succesfully corrected, 2 matches found for each chunk
MD5 sum: 492a40f63f21a246b211a661c94024b5

Starting to rip track 3, trial #1
Starting to rip track 3, trial #2
Analyzing files for mismatching chunks
Every chunk matched 2 times
MD5 sum: c2f9859b9ee217f9bab2bfd43f46f85e

Starting to rip track 4, trial #1
Starting to rip track 4, trial #2
Analyzing files for mismatching chunks
Every chunk matched 2 times
MD5 sum: e9cdbee250d44578a76de1a2ce0259c7

Starting to rip track 5, trial #1
Starting to rip track 5, trial #2
Analyzing files for mismatching chunks
Every chunk matched 2 times
MD5 sum: 31b2fddffa50dc445dcb74172b34ef13

Starting to rip track 6, trial #1
Starting to rip track 6, trial #2
Analyzing files for mismatching chunks
Every chunk matched 2 times
MD5 sum: 7b6df15211aaf61073bd0768db21b7a9

Starting to rip track 7, trial #1
Starting to rip track 7, trial #2
Analyzing files for mismatching chunks
1 chunk(s) didn't match 2 times.
Starting to rip track 7, trial #3
Error(s) succesfully corrected, 2 matches found for each chunk
MD5 sum: adfbedb58a320ee63480be6fe557de0d

Starting to rip track 8, trial #1
Starting to rip track 8, trial #2
Analyzing files for mismatching chunks
Every chunk matched 2 times
MD5 sum: 20d89f994ce9120143d928d5ce28f931

Starting to rip track 9, trial #1
Starting to rip track 9, trial #2
Analyzing files for mismatching chunks
23 chunk(s) didn't match 2 times.
Starting to rip track 9, trial #3
8 chunk(s) didn't match 2 times.
Starting to rip track 9, trial #4
3 chunk(s) didn't match 2 times.
Starting to rip track 9, trial #5
Error(s) succesfully corrected, 2 matches found for each chunk
MD5 sum: 96b27376bec45c837bb2e6ba07151b31


RIPPING SUMMARY

All chunks were tried to match at least 2 times.
Some track(s) needed correction,but could
be corrected within the maximum amount of trials

SUSPICION POSITION ANALYSIS

Since there are 75 chunks per second, after making the notion of the
suspicion position, the amount of initially mismatched chunks for that position is shown.

TRACK 2
Suspicion position : 06:38 (1 x) (CORRECTED at trial 4
Suspicion position : 06:39 (6 x) (CORRECTED at trial 6
Suspicion position : 06:40 (3 x) (CORRECTED at trial 6
Suspicion position : 06:41 (3 x) (CORRECTED at trial 6
Suspicion position : 06:42 (7 x) (CORRECTED at trial 7
Suspicion position : 06:43 (8 x) (CORRECTED at trial 7
Suspicion position : 06:44 (6 x) (CORRECTED at trial 3
Suspicion position : 06:45 (4 x) (CORRECTED at trial 6
Suspicion position : 06:46 (3 x) (CORRECTED at trial 4
Suspicion position : 06:47 (7 x) (CORRECTED at trial 4
Suspicion position : 06:48 (3 x) (CORRECTED at trial 3
Suspicion position : 06:49 (2 x) (CORRECTED at trial 4
Suspicion position : 09:25 (1 x) (CORRECTED at trial 3
TRACK 7
Suspicion position : 05:44 (1 x) (CORRECTED at trial 3
TRACK 9
Suspicion position : 01:17 (3 x) (CORRECTED at trial 3
Suspicion position : 01:18 (1 x) (CORRECTED at trial 3
Suspicion position : 01:19 (1 x) (CORRECTED at trial 4
Suspicion position : 01:26 (1 x) (CORRECTED at trial 3
Suspicion position : 01:28 (1 x) (CORRECTED at trial 3
Suspicion position : 01:29 (1 x) (CORRECTED at trial 3
Suspicion position : 01:30 (2 x) (CORRECTED at trial 5
Suspicion position : 01:32 (1 x) (CORRECTED at trial 3
Suspicion position : 01:53 (1 x) (CORRECTED at trial 5
Suspicion position : 01:54 (3 x) (CORRECTED at trial 3
Suspicion position : 01:57 (2 x) (CORRECTED at trial 4
Suspicion position : 01:58 (3 x) (CORRECTED at trial 5
Suspicion position : 01:59 (3 x) (CORRECTED at trial 4

Good job!

[robert]

"--id3v1-only" doesn't work with 3.98, but look here:

http://lame.cvs.sourceforge.net/*checkout*...ml/history.html

[k.eight.a]

"--id3v1-only" doesn't work with 3.98, but look here:

http://lame.cvs.sourceforge.net/*checkout*...ml/history.html

Thank you for the information. Strange thing is that it worked for me on Windows.

Anyway, that is "great". Another certain Linux delay. 3.98 is not included at official repositories yet, so 3.98.1 won't be any time soon.

[Rasi]

I really love this tool... a qt gui would be cool tho

What is bothering me tho is the fact that it is so slow... i tried on several cds with eac+wine and rubyripper.
Eac beats rubyripper on every single cd - and i am not talking seconds here...
Mind you rubyripper is not the source of this problem, as cdparanoia on its own is awfully slow too...

[chromium]

With RubyRipper it seems that I was successful:

Be careful and listen to the track. I also thought I was lucky, but there were audible glitches in the track. There *is* a chance that an error is reproduced on a subsequent rip, and as soon as you have three times the same error, it will pass.

[k.eight.a]

With RubyRipper it seems that I was successful:

Be careful and listen to the track. I also thought I was lucky, but there were audible glitches in the track. There *is* a chance that an error is reproduced on a subsequent rip, and as soon as you have three times the same error, it will pass.

I checked the extracted CD carefully and it sounds OK.

[Rasi]

What would be great is an option to enter something like "albumartist" or "disc" manually... maybe even add the possibility to add freeform-tags (TFXX in mp3)

Also flac files are not replaygained in album mode properly (it adds the tags instantly after each song, instead of scanning all files after the rip)

Some problems with replaygain seem to remain anyway.. sometimes it adds 2 or more albumgain values to the same album...

This post has been edited by Rasi: Sep 24 2008, 08:26

[xmixahlx]

i'm packaging 0.5.3 for rarewares and there seems to be a few problems...

1. the gui is not updating after the first track and the tracks only complete as per the number of threads enabled in the config. also, after the cd is ripped the gui just hangs.

i've selected flac, wav & mp3 and all react the same.

if i exit the gui early it will immediately encode that last track ripped but skip the previous ones.

a problem with how it is handling threads, perhaps?

the cli does not have this problem.

2. lame is not writing the tags correctly. vorbis and flac are working fine. (perhaps a UTF8 problem? my locale is UTF8. both xmms and easytag report the tag is writing incorrectly by dumping all the information in the title field incomplete.)

3. i set flac, vorbis, and lame to encode after extraction and on a single track (track5) vorbis failed to encode - the log indicated it was in the "waiting room" and then didn't execute.

4. when ripping to a single file, i receive this error:

CODE

/usr/lib/ruby/1.8/rr_lib.rb:346:in `trackinfo': undefined method `startsector' for #<Disc:0x7f385d5d5c68> (NoMethodError)

...also, is there a way to configure the settings with the cli? maybe a --config option?

i agree that a post-rip replaygain execution would be a good idea. and even for lame, encoding after the rip complets with --nogap --nogaptags could be useful, too. perhaps an option to [] wait for encoding after rip is complete would work. rubyripper could create a cue file and use that for tagging.


i really like the changes from 0.4, thanks!


later

This post has been edited by xmixahlx: Sep 26 2008, 22:02

[frodoontop]

There are some problems due to the release of the ruby-gtk2-0.17 bindings (issue 1+3). To solve this, please set extra encoding threats to 0.

For single file ripping is currently an issue open which has to be investigated.

I don't know about any problems with UTF characters for lame. Please file a bug report and mention your lame version.

If anyone wants a problem to get solved, file a bug report. As simple as that. I simply don't have time to create them myself for all issues google shows up with.

[Pepzhez]

Has Rubyripper switched to cdparanoia 10.2 yet?

[Mr_Rabid_Teddybe...]

Hi. Thanks for the program!

I'm trying to rip to Vorbis and to Wavpack simultaneously here with 0.5.3

The Vorbis encoding works nice with the Vorbis encoder. However my choice of "other", Wavpack, fails with:

WARNING: Encoding to other exited with an error with track 1!

The line I've entered in the RR "other" codebox I've also tested in the shell (with RRs placeholder tags replaced with actual values ofcourse) and it works hunky dory there... This is the commandline:

CODE

~/usr/bin/wavpack -w "Artist=%a" -w "Title=%t" -w "Album=%b" -w "Year=%y" -w "Track=%n" -w "Genre=%g" -w "Encodedby=Myself" -hx3mt "%i" -o "%o"

Anybody got any clues?

(And yes, I have installed the latest Wavpack to my $HOME directory, no mistake in the tilde...)

[xmixahlx]

is wavpack really located in ~/usr/bin/wavpack ?

sure it's not /usr/bin/wavpack or ~/bin/wavpack ?

if it is in your $PATH just use the executable in the script.

this worked for me: (i'm not familiar with the Encodedby tag...)

wavpack -w "Artist=%a" -w "Title=%t" -w "Album=%b" -w "Year=%y" -w "Track=%n" -w "Genre=%g" -w "Comment=ripped with rubyripper 0.5.3" -hx3mt %i -o "%o.wv"

notes:
* rubyripper puts %i in quotes, so you don't need to use them in the script
* rubyripper DOESN'T put %o in quotes.
* you need to manually add the extension when using the OTHER encoders like above


@frodo - i dropped the extra threads parameter to zero and the gui is working great! thanks!


later

[Mr_Rabid_Teddybe...]

Thanks! Fixing the bit
-hx3mt %i -o "%o.wv"
was all it took to make it work. I guess sending the input filename with two sets of doublequotes was what made it croak...

More encoding threads works fine for me. But then I got ruby-gtk2-0.16 so I understand that explains that...

Edit:
Maybe ability to pass 'nice' value(s) to the encoding thread(s) could be a good feature request...?

This post has been edited by Mr_Rabid_Teddybear: Sep 30 2008, 17:07

[xmixahlx]

you can just add "nice --adjustment=#" (where # is your desired niceness) in the OTHER encoder field.

glad it worked for you

[viktor]

Has Rubyripper switched to cdparanoia 10.2 yet?

rubyripper uses the version you install on your system. they are 2 separate programs.

[Pepzhez]

What I mean to ask is: does it it work correctly with 10.2? Any issues?

[Mr_Rabid_Teddybe...]

you can just add "nice --adjustment=#" (where # is your desired niceness) in the OTHER encoder field.

glad it worked for you

Wow! Well, I've got wavpack in the 'other' field and it's already playing "nice". It's the buildtin call to oggenc thats not "nice" at all... It's grabbing all the CPU it can get...

[viktor]

What I mean to ask is: does it it work correctly with 10.2? Any issues?

since rr uses the executable binary itself (not the library), there shouldn't be more issues than if you used cdparanoia directly (IMHO), except if the logic that feeds cdparanoia is flawed at some point, but that's not related to the version of cdparanoia

This post has been edited by viktor: Oct 1 2008, 12:20

[Mr_Rabid_Teddybe...]

Another question:
Parameter passed to cdparanoia with default install of rubyripper are -Z

-Z --disable-paranoia : disable all paranoia checking

As rubyripper are ripping chunks twice and comparing I guess timeconsuming paranoia is not really needed, and also previous versions of cdparanoia is stated to have been possibly 'unsafe' (?) regarding drives with bigger audiocache than a megabyte or so...
Anyway I have now compiled cdparanoia 10.2 in which there has been stated that this (possible) issue have been resolved and made sure rubyripper calls that one up.

Would there be any possible advantage in using other parameters for cdparanoia? Enabling paranoia checking and such? Or is the current checking every chunk twice so safe that it's just a waste of time and electricity....?

(I'm ripping with a Plextor PX-W4824A and cdparanoia -A reports "Drive tests OK with Paranoia.", if that would mean anything...)

[dleemiller]

Since there are no python bindings to cdparanoia this is difficult to achieve for me. It would require to make changes in the source code of cdparanoia, which is (I think) written in C. I simply do not have the skills for that.

But for what we have now, it's already a big improvement in my humble opinion. Test and copy was nowhere available in linux yet for as far as I know. At the least you can be certain that a rip was either succesfull or failed.

@damaki: Good to hear, this works for others too. I only had two discs so far with a mismatch.

sorry i'm getting in on this a little late. i'm an amateur python programmer and i've often read about the python-ctypes library (though never used it). it's a very powerful tool since it allows you to directly import c libraries into python for direct use.

i've seen examples of it in use and it looks relatively easy...but i've never done it since for the applications i program it's more efficient to write python extensions in C and import them later that way. anyway, i haven't read this whole thread, but i thought i'd bring it up.

[xmixahlx]

it appears frodo released rubyripper 0.5.4 silently and it's available at the google code site.

@ frodo:

i'm still having an issue with the "[" and "]" characters within the album field.

they will be written to the tracks as "(" and ")" respectively and i'd like it to not do that, lol.

so like "At The Drive-In - Vaya [EP]" is being written as "Vaya (EP)" for the file naming schemes, but it DOES write it correctly for the CUEFILE and all the TAGS are correct. weird.


later

[Mr_Rabid_Teddybe...]

it appears frodo released rubyripper 0.5.4 silently and it's available at the google code site.

@ frodo:

i'm still having an issue with the "[" and "]" characters within the album field.

they will be written to the tracks as "(" and ")" respectively and i'd like it to not do that, lol.

so like "At The Drive-In - Vaya [EP]" is being written as "Vaya (EP)" for the file naming schemes, but it DOES write it correctly for the CUEFILE and all the TAGS are correct. weird.


later

I think rr silently does some char replacements in filenames. Personally I'd like all chars as original in tags (and cuesheets and such) and to do replacement in file- and directorynames for chars that are not allowed in FAT32 filesystem, such as on my 2 rockboxed DAPs. However, more or less all chars are possible in filenames on ext2/ext3 filesystem, such as I rip to (however there are some diagreement with my friends about / in filnames, but I think it's also possible in linux filenames). Anyway I use a python script to replace the chars that are not possible on FAT32, and hence, AFAIK, on any filesystem that are used today by more than 5 people....

The following script can be ran as e.g. "python fixchars.py" from top directory of your ripped files and will replace the chars \ / : * ? " < > | with an underscore in names of files and directories:

CODE

import os
import os.path
import re

badchars=re.compile(r"""[\\/:*?"<>|]""")

def replacer(match):
#print match.group(0)
return "_"

def traverse(dir):
print "Traversing dir: %s" % dir
for node in os.listdir(dir):
path=os.path.join(dir,node)
if os.path.isdir(path):
traverse(path)
if badchars.search(node):
newnode=badchars.sub(replacer,node)
newpath=os.path.join(dir,newnode)
n=0
while os.path.exists(newpath):
print newpath,"exists"
newnewnode="%s-%d" % (newnode,n)
newpath=os.path.join(dir,newnewnode)
n +=1
print "RENAMED: %s - %s" % (path, newpath)
os.rename(path,newpath)
else:
pass
#print "OK: "+path

traverse(".")

The chars mentioned in the post [ ] & are AFAIK not disallowed on any filesystem that I know, only those I mentioned above (with exeption of some extremely exotic filesystems maybe). And I think rr should either leave all chars as is in file- and directory names also, or replace those 9 chars in file- and directory names, but not in any way in tags (or cuesheets) ...

[EDIT]
I did not take illegal "invisible" chars like atleast newline into consideration in the previous, but I find it hard to belive that rr could produce such in file- or directorynames anyway, neither that names for artists, albums, songs etc. fetched from CDDB could contain such...
[/EDIT]

This post has been edited by Mr_Rabid_Teddybear: Nov 1 2008, 14:41

[nomnex]

Need help with Rubyripper:

it correctly recognizes my notebook DVD drive (/dev/cdrom), however I am using an external CD-DVD USB drive. Rubyripper does not recognize it and I don't know what to enter in the configuration options.

Thanks.

Linux Ubuntu (Jaunty & Karmic)
Rubyripper version 5.7.-1. (from Getdeb)