Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: A secure ripper for linux (Read 162858 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

A secure ripper for linux

Reply #200
Add --id3v1-only to your command-line options.
You mean in "Preferences > Codecs > Lame Mp3" add:
Code: [Select]
-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: [Select]
This log is created by Rubyripper, version 0.5.3
Website: [url=http://code.google.com/p/rubyripper]http://code.google.com/p/rubyripper[/url]

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!
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."


A secure ripper for linux

Reply #202
"--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.
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

A secure ripper for linux

Reply #203
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...

A secure ripper for linux

Reply #204
Quote
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.

A secure ripper for linux

Reply #205
Quote
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.
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

A secure ripper for linux

Reply #206
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...

A secure ripper for linux

Reply #207
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: [Select]
/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

A secure ripper for linux

Reply #208
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.
A secure audio ripper for linux: code.google.com/p/rubyripper

A secure ripper for linux

Reply #209
Has Rubyripper switched to cdparanoia 10.2 yet?

A secure ripper for linux

Reply #210
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:

Quote
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: [Select]
~/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...)
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

A secure ripper for linux

Reply #211
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

A secure ripper for linux

Reply #212
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...?
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

A secure ripper for linux

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

glad it worked for you


A secure ripper for linux

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

A secure ripper for linux

Reply #216
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...
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

A secure ripper for linux

Reply #217
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

A secure ripper for linux

Reply #218
Another question:
Parameter passed to cdparanoia with default install of rubyripper are -Z
Quote
-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...)
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

A secure ripper for linux

Reply #219
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.

A secure ripper for linux

Reply #220
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

A secure ripper for linux

Reply #221
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: [Select]
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]
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
        - Oceania Association of Autonomous Astronauts

A secure ripper for linux

Reply #222
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)