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: Ripping wavpack images with integrated cuesheets with rubyripper using (Read 2739 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Ripping wavpack images with integrated cuesheets with rubyripper using

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: [Select]
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:
Spoiler (click to show/hide)
(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: [Select]
#! /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: [Select]
/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?

Ripping wavpack images with integrated cuesheets with rubyripper using

Reply #1
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).


Ripping wavpack images with integrated cuesheets with rubyripper using

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