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. 😉
“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. 😀
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 love mocp so much!
Btw you can shrink PNG files a lot of you reduce the color depth to say 64 colors. GIMP -> Image -> Mode -> Indexed…
Even this JPEG (artifacts are bad for compression) went down to 2/3 its size. 😉
“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.
I might look for that. I liked Herrie, and if I can avoid the playlist being “eaten” as it is played, I might use it more often. Thanks.
Adding “playq.xmms=yes” to the config file for herrie seems to do the trick, alternatively the repeat mode (toggled by the ‘r’ key) should place the last played track at the bottom of the playlist.
while you are editing the config file for herrie try adding
For a Midnight Commander like colour scheme 😉
Great article once more for reference. I use cmus most of the time and I love it. I love the quicksearch function (hit / and the thing you want to search for), very handy.
Ncmpcpp is what I use almost exclusively.
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 😦 )
re python vs c and memory usage.
the problem is there is no objective/one-way-fits-all approach to measure memory. some people prefer rss, other vss. some people “run python anyway”, and so on.
My favorites are mpg123 and ogg123.
Pingback: Task managers for the console « Motho ke motho ka botho
You might want to check out the MPD frontend PMS (Practical Music Search – http://pms.sourceforge.net/).
Pingback: Three console audio mixers « Motho ke motho ka botho
Great article! Moc is a beautiful piece of software. It just seems to do what I want it to…awesome.
Pingback: vlc, ncurses and the framebuffer … ? « Motho ke motho ka botho
I have always been partial to xmms2.
It isn’t completely polished yet, but it works for what I need it to do.
Pingback: A substitute audio player « Motho ke motho ka botho
Pingback: Shaving megabytes: cplay and mcplay « Motho ke motho ka botho
Pingback: No gift for gab: Four more console tools « Motho ke motho ka botho
Pingback: Keep the customers satisfied: Three more graphical apps « Motho ke motho ka botho
Pingback: Some audio success « Motho ke motho ka botho
Pingback: One pleasant surprise, for 2010 « Motho ke motho ka botho
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.