Tag Archives: cd

rubyripper: The options continue to multiply

I should apologize for the gap in communications for a few days this week. I was preoccupied with some personal events, and as luck would have it, I find I am also beset with computer issues. More on that later.

For now, rubyripper is next on the Master List.

2014-04-13-6m47421-rubyripper-01 2014-04-13-6m47421-rubyripper-02 2014-04-13-6m47421-rubyripper-03

We just saw ripit a week ago or so, and while it’s true that there’s only so much you can do with a console-based CD ripper utility, rubyripper seems quite competent.

True, it doesn’t seem to have as many low-level controls as ripit, but there are distinct audiences among computer users, and for some, a simpler, quicker interaction (notice I didn’t say “interface”) is better.

So much as you can see above, rubyripper has options to rip to flac, ogg or mp3, with command-line flag controls manually edited. Suffice to say, if you don’t know what the controls are for lame, you’ll probably just want to keep the defaults. 😉

One thing I like about rubyripper is the default rip location. Without any prompting, rubyripper dropped the resulting tracks into a folder called “vorbis,” which kept them from polluting my home directory. My OCPD thanks you, rubyripper.

abcde is my first-line pick for console CD ripping, but rubyripper has its charms. Following the theme I mentioned with ripit though, sometimes it’s not so much about the overarching program as the underlying support software.

A sad note: It seems the author has drifted away from the project, citing a lack of need to rip CDs any longer, since online services are quicker and easier. Much like I have said several times over, there doesn’t seem to be much call for CD conversion, and I don’t even know how many of my friends own CDs any longer. 😦

It’s the circle of life.

One last bonus with rubyripper: Install ruby-gtk2 and get … a graphical interface!


I don’t see rubyripper in Debian, which is a bit of a shame. So … Arch 🙂 Debian 😦 That could always change though. 😉

ripit: For precise, exacting CD conversions

Among CD ripping tools, I have to say that ripit seems to have its stuff together.


Granted, like some other rippers for the console, ripit primarily relies on some underlying utilities. Depending on your preferences, you can relegate the actual ripping process to cdparanoia, cddda2wav or some other tools.

But ripit has a fantastic number of other options available to it, in addition to the flags passed through to the background utilities. I daresay if you really are keen on controlling the finer points of converting CDs to audio files, ripit might be one of the best choices.

The Arch version, as you can see above, found my optical drive without coaxing, and dashed off to cddb to check the title data.

I did notice that -o flag, which declares a target directory, requires an absolute path, or it assumes you’re ripping to the root directory. By default ripit will leave the target files in your $HOME.

At the end of the day I’m still stuck in an odd place though, in that I don’t have any CDs left and I don’t believe anyone around me still buys them. My homemade backup CD works great with ripit, but after that I’m out of test discs.

But I am sure the worldwide departure from CD-based audio is not over yet. 😉

mybashburn: Much the same animal

Back in September, when I was wading through the B section, I stepped across bashburn. Here’s its derivative, mybashburn.


To read the home page for mybashburn, it sounds very much like a viable offshoot of the original project, and I can see some similarities here and there.

As for which holds the higher ground, I don’t have an answer. I’m still sitting in that loop I mentioned earlier, where I only rarely need to burn a CD (and oddly, it’s usually to test something for this site 😕 ).

So if you prefer one or the other, that is your decision.

mybashburn is not in Debian (bashburn is, and both are in Arch/AUR), which surprises me in a way. I could swear this was one of the earliest console-only CD writers I ran across, years ago, when I was using Ubuntu.

This is another program where I feel obligated to mention that the last update was nearly six years ago. Ordinarily that’s not an issue, but for CD support software and access protocol, I have a fear that it might be.

Now go forth, and etch tiny lines in lacquer-coated circles of polycarbonate. 😉

mp3burn: Straight to video — I mean, audio

If you think I’m nervous about reaching way back to 2001 for something like mp3burn, you needn’t worry.


One thing you can say about Debian, it does a good job preserving its multitude of components.

Of course, that’s Linux Mint 16, which is only a distant cousin to Debian, but mp3burn works well from the repos there. I didn’t find it in Arch. 😯 Amazing, I know.

I’ll admit I didn’t actually burn a CD though; I’m low on CDs right now. 😕 But not bad for a program with an 0.1 version dated 2001. It seems to have aged well.

mp3burn’s claim to fame is that it doesn’t spill decoded mp3s to disk, which saves space in the conversion process.

Remembering back to 2001, I can see why mp3burn would have won a few converts. Disk space was a little tighter 12 years ago, and filling a disk while writing a CD was a danger.

Regardless, mp3burn still works, even if disk space isn’t a worry these days.

Oh, and I know you thought mp3wrap would round out all the mp3* programs. Not by a long shot. 😈

mp3cd: Reverse direction, or should be

I’m going to include mp3cd here today, even though I was a little less than successful with it.


You can look through those error messages, and see if you spot the issue. For my own part, I think this might be out of date with the perl substructure. But I am no perl wizard. Perhaps you are. 😉

I will mention that while there were spaces in the filenames for the music, I had a completely different set of errors. So I consider this an improvement, even though I don’t think this is what should have happened.

And what should have happened? If I understand the home page right, I think this should read an m3u file and send it straight to CD. Sort of a one-shot straight-to-disc tool.

But as you can see, it fell short. If you have any clues, let me know. I have a feeling this is probably workable, but might need some surgery first.

mp3c: And so it begins

I’m behind the power curve again today, mostly because of oddball computer issues that took up much of my day yesterday.

I got a secondhand HP G60-125NR from a friend for a very decent price, and was astounded when Arch Linux rolled over and barfed when I tried to use it.

Disappearing mouse control. Sketchy video playback and overheating issues with nouveau driver. Even sketchier playback with the proprietary driver, and no framebuffer support. Endless kernel messages about /dev/sdb1 so long as the ums_realtek module was inserted, which spawned endless confusion between sdb and sdc when an external drive was plugged in. Freezing screens and system lockups with x264 videos.

The list goes on. Oddly enough, most of that disappeared with Linux Mint and the nvidia-319 package out of the Mint/Ubuntu repositories. I didn’t plan on running Mint 24/7 on it, but what works is what works.

All that is neither here nor there, since the application of the day (for yesterday) is (was) mp3c.


mp3c made me happy again, just by being itself. 🙂 A fullscreen, command-line application with a good dose of workability.

In-program help screens, extensive options menu, smart enough to find the CD drive and connect to cddb. Good visibility and decent colors, and my only complaint is that it might be out of date.

I couldn’t get it to do any actual reading or ripping, probably because it seeks out cdda2wav, which doesn’t seem to be part of cdparanoia — at least in the Arch version. Maybe it was, once long ago. (Edit: I found it. It’s in cdrkit, cdrtools and dvdrtools. Not cdparanoia, even if mp3c’s home page suggests that.)

I think if I stuck with it long enough I could configure it to use another ripper, and it probably wouldn’t take much more than a substitution for proper tool.

I leave that to later though; I don’t have any CDs aside from the homemade one I use for testing. If you still use them, this might be useful for you. 😉

Now I have to go back to ripping the guts out of Linux Mint. And what’s with these 8200M cards, anyway? Nvidia is out to get me, I swear. … 👿

crip: Picking up what others leave out

I showed cdparanoia a few days ago, and mentioned that it deliberately leaves out access to online databases, for reasons they can explain.

crip adds that back into the scheme, and does a few other things automatically too.

2013-09-26-4dkln41-crip-01 2013-09-26-4dkln41-crip-02

As you can see, it prompts for missing information (because of course, my homemade CD isn’t in the database), genre, and so forth.

I believe it only does ogg encoding, which is what I prefer, so I’m fine with that. If you’re an mp3 (or another format) fan, you might need a different program.

On the other hand, crip will automatically convert international characters, normalize or adjust gain, trim digital silence and some other nifty tricks.

Aside from that, crip has cdparanoia as its backend, so if you’ve seen it in action, much of what crip does will look familiar.

cdrtools, cdrkit and cdrskin: Untying the knot

Let me see if I have this straight.

In the beginning, there was cdrtools. Most everybody used it, and nobody had any complaints.

Then in 2006, the programmer changed the license from the GPL to the CDDL, although I don’t know why.

All is well except for Debian, whose grand poo-bahs say, “Hey, that there ain’t in line with our philosophies.” Although I don’t know why.

So in what could only be called a coup d’état, the Debian masterminds scalp the last GPL-licensed release of cdrtools, dub it cdrkit, and promise to keep stride with whatever happens in the original. Although I get the general idea why.

So now there were two symmetric projects, and sometimes one is available in your distribution. Sometimes the other. Sometimes … both! Although I don’t know why.

Here’s where things get even more blurry for me. Along comes cdrskin, which is part of a separate project, but is designed as a drop-in replacement for cdrtools’ original cdrecord program.

So there’s a CD burner project, plus another that mimics it but is licensed differently, and yet a third that pretends to be the original, but actually comes from a completely different direction. And I don’t know why.

Now there is a strong possibility that some or all of this little drama has been misunderstood on my part. If so, my sincerest apologies.

But in short, if I’m right, all three should look roughly the same.


And this time … maybe I know why. 😐

cdw: A proper console application

I always like finding a good, well designed console application.


Not out of any sense of spite, but because it reinforces something I decided a very long time ago: that in many cases, console or even CLI applications can do just as much, and just as well, as graphical counterparts.

cdw is like that. Here’s something that looks and behaves just as a graphical application might.

Configuration, CD composition, status and disc info … everything is right up front and easy to navigate.

Lots of colors too. I like colors.

I like this arrangement over something like bashburn too. I acknowledge that bashburn works (I just used it the other day, as a matter of fact), but the menu arrangement and configuration are sometimes obtuse for me.

No matter. cdw and bashburn are both choices, and that’s what this is all about: choice. 😉

cdparanoia: Nothing to fear

Among CD rippers for the console, cdparanoia might be one of the easiest to remember.


Not just for the clever name, but for the ubiquitous emoticons it uses as status indicators. They’re even listed in the Wikipedia article.

It also strikes me as unusual for eschewing a CDDB interface. I’ll let them explain their rationale for that.

My favorite point of cdparanoia is its ability to analyze a drive for caching and reading behavior, etc.

That’s what you see in the image above; cdparanoia is double-checking the optical drive on this machine, and making sure it’s performing as expected. (It’s fine, in case you were worried.)

Not that I really know what most of that stuff means, but knowing it’s “OK with Paranoia” is good enough for me.

For the audiophiles in the crowd, I don’t have any advice on sound quality. If this does a better job than abcde, or perhaps acripper, that’s something you’ll have to investigate on your own. 😉