K.Mandla's blog of Linux experiences

Audio players for the console

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. ;)

Post navigation

26 thoughts on “Audio players for the console”

“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. ”

odd. i just run mpd with a “userspace” config (all relevant files/directories located according to the xdg basedir spec, eg ~/.config/mpd/mpd.conf and so on) so you don’t need root, and then all frontends “just work”. no need to change or specify the listen port etc. defaults work fine for me.

It’s my own failing, much in the same way I seem to have rotten luck with mutt. I’ve tried several howtos and a bunch of different configurations, but it always seems to give me a great big goose egg. … :(

On your observance that the only difference between two of the programs was that one is written in C and the other in Python, and that doesn’t matter to you as you like both languages.
I think that this contradicts your advocacy of lightweight apps, as an application written in Python spawns a Python interpreter (don’t have any measurements but I would guess that’s at least 10MB of RAM for each Python interpreter running on the system) which takes up more RAM than a compiled program and runs slower.

This reminds me of the VolWheel program. It’s hailed as an ‘light system tray volume control application for users of lightweight WMs like Openbox…’… yea, and it’s written in Python. I checked it out and it ate more RAM than GNOME’s volume control panel applet. Good one.

Whenever you see ‘lightweight’ and a scripting language name (Python, Perl, Ruby (god forbid)) in an application’s description, run away. :D

You have a point; my indifference was only in the sense that the net results for both programs is more or less the same. I’ve never really gotten up close on resource use between two programs intended to be identical, but written in different languages. Perhaps it’s worth investigating further. mcplay/cplay might be a good test subject for a comparison. Thanks for the idea. …

“I don’t like that titles seem to be removed from the list as soon as they are finished playing”

I could be wrong but if memory serves me right… Herrie has two modes, an xmms like mode and a party mode and in one of these modes (xmms I think) the tracks disappear. Probably also worth noting also that herrie has Last.fm/audioscrobbler support built-in.

Very similar to ncmpc, but, as the website says in comparison “…it provides new useful features such as support for regular expressions in search engine, extended song format, items filtering, last.fm support, ability to sort playlist, local filesystem browser and other minor functions.”

One old laptop running as music storage and and mpd server with speakers attached, and the rest running ncmpcpp clients.

I surprised the Arch MPD wiki didn’t get you sorted out. That was the guide I used. I don’t remember how I set it up now, but I know it worked. :)

Mplayer’s the boss if you just want to be able to play anything – whatever you come across, not only mp3’s & oggs. As long as you have all the codecs, eg the w32codecs package from mediabuntu. (not free of course :( )

Enjoyed reading about other console options for music players. Always nice to hear about other programs I’m not familiar with. Will definitely check some of them out. I’ll share some I like that weren’t listed. Timidity++ is one of my favorites. It’s good for playing mod and midi files (including karaoke midi) and can also convert either format to wave. If you’re going to use the karaoke midi feature, be sure you have an up-to-date version (even if you have to get it from cvs). Several fixes were adding to karaoke timing properly (including allowing it to display lyrics created by ABC notation programs like abc2midi). I also like gramofile and of course, there’s sox. I’ve also run across snd and ecasound for audio editing, but haven’t worked with them much.

I enjoyed reading the point yasen made about compiled programs versus interpreted ones. That’s one of the things I always look for in a light-weight program. The compiled ones certainly seem to run faster on my computers for any task that’s resource intensive.