Ripping wavpack images with integrated cuesheets with rubyripper using Options

[LaserSokrates]

I recently decided to start ripping my CD collection or at least parts of it to a lossless format, and I chose wavpack because hardware compatibility is no issue for me and should I need it, I can just convert my saved tracks to mp3. However, as I was thinking more of images, I wanted to convert my disks to single .wv files with integrated cuesheet as I felt that'd be the closest I can get to a real image. If you are looking for instructions (can be applied to similiar scenarios as well) read on. Mods: if you think this belongs into the wiki, feel free to add it, I have no account there.

I will go into a bit of detail here to explain why I set all this up like I did. If you're just looking for the perhaps not-perfect solution, skip to the second-last codebox.

rubyripper supports creating cuesheets for rips and also wavpack as an external codec. However, these two programs both seem to suffer a bug each (or a bug and a not-too-well-advertised feature) that, in combination, prevents one from backing up his discs under Linux the way I described. According to the official wavpack documentation, wavpack's -w "Cuesheet=@*.cue" should make wavpack import subtrack information from a .cue file in the working directory. It did not for me. It wasn't a syntax error either, as I believe, because when I did -w "Cuesheet=@Exact Filename here.cue" it just worked. It was a single cue file in the working directory, but wavpack wouldn't read from it. Might be a shell problem, I don't really know, but I didn't like it.

So, to circumvent this (and also get a cleaner solution), wavpack is called with the exact filename of the cue file from rubyripper, which is "Artist - Album (other).cue" for me. So we just use this as our "other codec in rubyripper:

CODE

wavpack -hhm -w Cuesheet="%a - %b (other).cue" %i -o %o.wv

which unfortunately doesn't work.
To make it easier for the user, rubyripper replaces all variables with their proper values encapsulated in double quotes in order to retain spaces. However, as not to break anything, the user-supplied command-line has to be cleared of double-quotes beforehand. From rr_lib.rb:

CODE

        def checkOtherSettings
                copyString = ""
                lastChar = ""

                #first remove all double quotes. then iterate over each char
                @settings['othersettings'].delete('"').split(//).each do |char|
                        if char == '%' # prepend double quote before %
                                copyString << '"' + char
                        elsif lastChar == '%' # append double quote after %char
                                copyString << char + '"'
                        else
                                copyString << char
                        end
                        lastChar = char
                end

                # above won't work for various artist
                copyString.gsub!('"%v"a', '"%va"')

                @settings['othersettings'] = copyString

                puts @settings['othersettings'] if @settings['debug']
        end

(This codebox is supposed to be spoilered for readability.) This leads to wavpack being called with -w Cuesheet=@"Artist" - "Album" (other).cue ... with which, of course, wavpack doesn't know what to do.
The easiest solution now IMHO is a shell script like this:

CODE

#! /bin/bash
wavpack -hhm -w Cuesheet=@"$(echo $2 | sed s/.wv/' (other).cue'/g)" "$1" -o "$2"

(remember to make it executable!) which can then be called in rubyripper via

CODE

/path/to/yourscript.sh %i %o.wv

Of course, this only works if your .wv and .cue-files are named similiar. As I mainly backup albums, this works for me right now. I don't know how rubyripper decides how to name the cuesheets, so the script might be of limited usefulness. I spent quite some time on finding a solution nevertheless, and I thought it might be helpful for some as the scenario is not too uncommon. Perhaps some shell guru (or a programmer in a "real" language) can add some command line parsing and some extra features, I'd appreciate it Hope I could help or inspire someone.

Now if another player besides foobar supported this, it'd be awesome. I have it running under wine here. Oh, how I would love to see a port.

Edit: title is truncated or I'm too tired to actually write one. Can a mod give this a proper name, pretty please?

This post has been edited by LaserSokrates: Jan 18 2013, 13:02

[bryant]

Sorry about the problem with the wildcard expansion not working on Linux. If I recall correctly, I added that feature to get something in EAC (Windows) working right and never ported it into Linux because it's kind of a hack and it seemed like the invoker would generally know the exact filename (I don't recall why EAC needed this).

In any event, I will try to get this into the next release if people find it useful...although of course you have gotten around it for now.

Thanks for posting your scripts, BTW! I have been playing with a few CD rippers on Linux, but have not tried Rubyripper (and am disappointed by the lack of support AccurateRip on Linux).

[LaserSokrates]

Sorry about the problem with the wildcard expansion not working on Linux. If I recall correctly, I added that feature to get something in EAC (Windows) working right and never ported it into Linux because it's kind of a hack and it seemed like the invoker would generally know the exact filename (I don't recall why EAC needed this).

Ah, okay. Yeah, you know the filename when ripping with rubyripper, but as I wrote, it is impossible to let rubyripper substitute the variables properly.

In any event, I will try to get this into the next release if people find it useful...although of course you have gotten around it for now.

Well, as you said, it is generally not needed. A perhaps better solution would be to add a variable to rubyripper that gets expanded to the cue sheet's filename. And if the feature is no longer needed in wavpack, it could be removed in the next version... haven't used EAC in quite some time though, and it might still be needed.

Thanks for posting your scripts, BTW! I have been playing with a few CD rippers on Linux, but have not tried Rubyripper (and am disappointed by the lack of support AccurateRip on Linux).

No problem! I think rubyripper is the best we have right now, which is basically cdparanoia and checking if the CD/track can be read a given amount of tries. My results are not always perfect, I checked them with foobar. Some Iron Maiden CDs give problems, though I hear no errors in the rips, so it can not be severe. But I agree: the audio situation under Linux could be better, both ripper and player-wise. cdparanoia is very good, but I prefer a frontend, be it graphical or command line