I have a long history with console music players, going back well into the early days of my Linux experiences. I staked out an early preference for cplay, which unfortunately was akin to betting on a losing horse, since cplay has since vanished. But these days I am a staunch moc supporter — now there’s a console music player with a serious future.

But there are a lot more than just two console music players out there in the wild. Take a casual walk through Arch-plus-AUR with a sprinkle of Google in there, and you can come up with at least six more working options, plus references to just as many more that are hard to find. Take a look.

At the top left is Orpheus, and opposite it is Herrie. Center left is mp3blaster, next to cmus. And at the bottom left is ncmpc, next to mcplay. (Sorry about the jpg artifacts. Your bandwidth is precious.)

I can’t practically examine every single one here, but I can tell you a little about each one’s style and approach. Much in the same way as graphical music players, some maintain libraries of your music titles, while others rely on file browsers and playlists. Both styles have their fans; I for one happen to resent music “managers” and prefer browsers and lists.

Orpheus, for example, would probably be my player of choice if I didn’t have moc to enjoy. Nicely colored and easy to figure out, it has a clear playlist and straightforward commands to add things. Good use of screen space and a built-in search function. Technically it’s a few years out of development, but that doesn’t keep the Arch version from working.

Herrie would probably be my third choice, since it also has a playlist/browser approach, but Herrie’s style seems somewhat cumbersome at times. Although the default keybindings and controls are similar to cplay, I don’t like that titles seem to be removed from the list as soon as they are finished playing. Sometimes I like to hear a song again, and a queue-system like that is less attractive.

mp3blaster was the first console-based music player I ever remember trying, and it doesn’t seem to have changed much in the time since then. It is actively developed though, or at least received a stable update in the last year. From a strictly superficial standpoint, it’s probably the most obvious to figure out, since all the keypress options are labeled on-screen — all the way down to accessing your audio card controls. On the other hand, it seems a little cluttered now, which is probably a side effect of having worked with moc for so long.

cmus is opposite of mp3blaster in that screenshot, and it’s easy for me to understand why it has a following. Keystrokes mimic a lot of vim commands, it uses a library system to access files, and it has a quick, clean feel about it. Personally I got a few screen artifacts while running cmus, particularly while accessing files inside folders with unusually long names. Not that that is a dealbreaker, but in addition to the fact that I don’t like music managers, it’s enough to keep me happy where I’m at.

I have ncmpc in that screenshot but it’s not configured, which is why you see error messages there. ncmpc is a terrifically terse frontend for the mpd system, but it’s only useful if you can get both of them installed, configured and handshaking. That last part has always been the stumbling block for me. 😦

The last one you see there is mcplay, which looks and behaves almost keypress-for-keypress the same as cplay. That’s intentional, with the code-level distinction of being written in C, as opposed to the original’s Python. Whether that’s a good thing or a bad thing depends on which language you prefer to use. To me, there’s no difference.

Many of these players reach back to the early part of this decade, and some of them might even have their roots in this one.

That’s mjs, the MP3 Jukebox System, a program so old it was intended for use on Pentium I and Cyrix machines. The code is still available, and its predecssor — a program called mms — is still in some RPM archives. mjs will compile in Arch, although I got some strange screen colors while I was running it in rxvt-unicode, and I couldn’t get it to connect to my audio hardware. However, if you need an extremely lightweight player that can handle mp3 files, this might be the winner. Be prepared to dig around in its guts though.

Also on the list, but not in a working state for me, were jinamp, benmp3 and pytone.

If you’re willing to work with the old XMMS audio player, you have several CLI interfaces that might be useful to you.

Left to right that’s …

xcplay, which also mimics the cplay interface;

clxmms, which works like a command-line interface prompt for xmms; and

ncxmms, which might have the easiest interface to learn.

These might be useful over ssh, in a situation where you have a remote machine that can handle the oh-so-taxing graphical demands of XMMS and GTK1.2, but want to control it from the console. Being terribly honest, I don’t know if I personally would bother with any of them, since a machine that can handle XMMS can likely do fine by itself without a CLI prod.

Also be aware that some common video applications have audio playback capability. Here, top to bottom, are alsaplayer with the -i text flag, MPlayer playing audio files, and VLC‘s ncurses interface — which I must admit, I find very attractive.

The first two are rather primitive, with little in the way of interaction that doesn’t fall outside their normal keypress playback. The vlc version is just as useful as — and probably more flexible than — most of the console applications you see above.

This isn’t all of them, of course; it’s just not possible to scrape up all the audio players out there, even at the console level. This is a rough list, and if you’re looking for something to run light and take up little space, it might be helpful. Otherwise, if I’ve forgotten one, remind me of it. 😉