Tag Archives: client

juke: Just a little more than the bare minimum

At the absolute minimum, you could expect to get sound playback out of your computer simply by tacking on file names and a few oddball flags to something like mpg123 or sox.

It’s not ideal, and it lacks the grace and dignity of a proper console application, but it will work and there are plenty of similar tools that can do it. So even in a worst-case scenario, you have your tunes.

In that sense, juke doesn’t offer a whole lot over those programs, either in terms of an interface or playback controls. In fact, juke is really only doing the tiniest bit over the bare minimum.

2014-12-24-jsgqk71-juke-01 2014-12-24-jsgqk71-juke-02

juke takes on a two-screen approach that might remind you of cplay or its kin. By default juke starts in a browser mode, showing files that you can add to a playlist with “a”, or navigate with HJKL or arrow keys.

Once you add a tune, it immediately starts playing. Press “t” to switch to the playlist view, and your navigation keys will again allow you to move through queue. If you need more help than that, press “h” and juke is kind enough to give you a rundown on key commands. There aren’t many to learn.

I made the point about juke offering very little over a command-line playback tool because juke is really just a frontend for mpg123 or sox. So you might find that it’s only the tiniest improvement over tacking filenames on to those programs.

juke adds a small layer of obfuscation as well. juke won’t start without a .juke.conf file in your home directory, but there’s no sample, and you need to copy-and-paste one out of the MANUAL file in the source tarball (it’s not terribly confusing).

juke also seems to also require a target directory, in the same way as ksmp3play or muzikq. I won’t split hairs here: That style is obtuse for me, and all the more so since juke is prepared to navigate through directories to find music files. So why not just start in the directory where the executable was issued? :\

juke is also not particularly beautiful, and aside from tagging files with a “q” when they are added to the queue, not a whole lot happens visually.

There’s also no time display, no obvious controls for playback except to skip titles, and no indicator that playback is started, unless you can hear it playing. I would strongly recommend you don’t use juke to troubleshoot your audio hardware. 😦

juke has two small positive points that I can find: It’s written in C, and that means it’s fairly light. Neither of those makes up for juke’s extremely lackluster performance though.

If you clicked on the link above, you already know the home page 404s. The source code for juke is in the Debian repos, and I was able to build it in Arch and use juke without issue. Oddly, the Debian rendition would install through the Mint repos but wouldn’t play back any sounds for me.

No major loss. I don’t think juke is a particularly fantastic audio playback tool, but I suppose it could hold its charms … if you’re looking for one step above the absolute minimum. 😐

aylet: Sounds across the Spectrum

I never had a ZX Spectrum. I never had a *00-series Atari computer either. I spent my formative years in front of a C64, as I have oft mentioned, and so a lot of the developments or innovations on other hardware is a little lost on me.

I can appreciate attempts to preserve the musical artistry of a generation or architecture though, so aylet is interesting to me.


So if the genius of the General Instrument AY-3-8910 sound chip escapes my appreciation, aylet is still fun to work with.

This might look a little like stymulator to you, and that was the first thing I thought of when I saw it. I didn’t take the time to dig through the history of aylet and stymulator, but it may be that they share the same author or code tree.

Key controls are on the screen, with switches for track control and a few other options. aylet may not be as visually attractive as some other players, but it knows its audience and does not disappoint.

aylet is in Debian but not in Arch/AUR; I compiled what you see there with the original source code from the Debian package page and had no problems. I needed alsa-oss again to keep it working with “modern” sound arrangements though. 😉

Oh, I almost forgot: You’ll need some sound files, of course. Start here and see what you can find. I am sure there’s something in there that will trigger the nostalgia region of your brain. 😉

bitpocket: Your in-house drop box

I have three i686 machines at the moment, all three of which are running Arch. One acts as a wireless relay to the other two (thanks, create_ap), and shares its wired connection with the two others.

It also is set up to sync itself against the Arch repositories once a day, and then I manually rsync between the other two and share the downloaded updates. This saves me the drag of triple-updating machines, since my in-house wireless connection is considerably faster than the wired line.

Anything leftover or specific to one piece of hardware — like video drivers — gets downloaded normally, when a specific machine does its update.

I do end up doing some double-back synchronization, from satellite computers to the central hub. That’s more of an insurance measure or to make backups of individual packages that were downloaded to specific machines.

All that rsyncing back and forth relies on sshd of course, and it gets a little tedious having to re-enter passwords on every rsync, but I don’t know if there’s anything to be done about that. It’s the nature of the beast.

I thought perhaps working a little bit with bitpocket might give me some ideas, since bitpocket is intended as a do-it-yourself Dropbox-style network storage tool, built upon the mighty rsync.


It did and it didn’t. bitpocket runs into much the same issue as I had, where I needed to supply a password four times — actually five — to get the proper access across the network and update the master folder on the central machine.

I don’t hold that out as a fault of bitpocket though, since whatever setting or configuration I’m after to solve my own problem isn’t bitpocket’s responsibility. I shall pursue that independently.

bitpocket itself is rather useful, and very easy to set up. Supply a proper folder and identity for your server machine, create a folder for a corresponding copy on the client, and just call bitpocket from that folder. bitpocket can check for updates, synchronize new files, delete old ones and generally handle everything as it should be done.

bitpocket has some other features that are nifty, such as the ability to tell you what will be updated (in other words, what changes exist since the last sync) and delete protection, where it moves “deleted” files into a hidden folder, in case you make a mistake.

If you already do fairly regular rsyncs against a master machine, or if you just want to streamline the process of keeping work folders up to date, I can see where bitpocket might improve upon a long chain of rsync commands.

In my case, I really need to find out how to authenticate rsync without being prompted each time, and follow through with that. (Edit: I figured it out, thanks. I just needed to generate an id_rsa.pub key, and move it over to the server. 😉 )

ncdc: Direct connect in ncurses

I missed a step somwhere, around the turn of the century, when direct connect became a thing for file sharing. Somehow I went straight from the naivete of Napster to the vicious intricacy of Gnutella to the hideous maelstrom of malware and Kazaa, then popped out somewhere around rtorrent and youtube-dl. :\

I never received the memo about direct connect, and as a result I always manage to confuse that with direct cable connection, which is not only totally unrelated, but a nightmare of bad memories in its own right. 😯 And as luck would have it, I’m not really in the market much for peer-to-peer file sharing these days, unless it has to do with a newly released Linux ISO.

So ncdc, an ncurses client for direct connect, is pleasing … but about a dozen years late to really pique my interest.

2014-11-04-2sjx281-ncdc-01 2014-11-04-2sjx281-ncdc-02

I had no trouble building ncdc, and it connected without effort too. The quick instructions on the home page were enough to get me into ncdc as far as you see, plus a little more.

I didn’t actually download anything, but I did browse a few files just out of curiosity. ncdc never balked and never spat an error, unless I did something outside the bounds of normal.

What strikes me most about ncdc, strictly from an interface standpoint, is how much it resembles programs like irssi and some other IRC clients. ncdc includes a “tabbed” interface, and you bounce between tabs via the ALT key and the number of the tab. The main or original tab is a kind of system log. Connecting and searching and listing connected users is done with slash-commands. All very much like irssi (but not like rhapsody 😉 ).

So even if you don’t have much experience with direct connect, like me, you’ll probably be mostly comfortable getting ncdc started.

Beyond that I don’t have much advice for ncdc. Most of the basic commands are found on the home page or by triggering the help function to show in the main tab. If you’re still an avid file sharer and need something lightweight for direct connect transfers, ncdc could fill the bill. 🙂

lienmp3: How far we’ve come

Ordinarily when a program fails to deliver as badly as lienmp3 did, I’m content to roll it into a post with some other remainders. In this case though, I’m going to make an exception.

Everything about lienmp3 is likely to be disappointing to you: The download link was hidden, the source code is as much as a dozen years out of date, the interface is loud and poorly arranged, and ultimately, even though it would compile and run, when comes time to play music, lienmp3 just flat quits and returns you to the prompt. It’s a collection of faults.

So why mention it at all?


No, it’s not the abundant use of color, even if that’s more than I could ever ask for. And it’s not the relatively easy navigation and on-screen key legend. Even that is a bit … mangled.

If I have to be honest, it’s because I’m sentimental. :\

Almost a decade ago, I was pushing people not to discard 800Mhz machines. Five years ago that had risen to 2.5Ghz. Now I find myself suffering the dreadful weight of the web on a 12-year-old Pentium 4. Times change.

So when the home page for lienmp3 claimed it was (at some point in time) quite usable on 90Mhz Pentium-grade hardware, and could possibly work on slower machines if you were willing to downgrade to mono output … I felt a little nostalgic.

A boast of that nature just doesn’t happen any more. Nobody tries to align their software with the hardware of 1998; it’s just assumed that you’re running multiple cores and double-digit gigabytes of memory. Console software isn’t valued by its ability to transfer to sub-100Mhz CPUs any longer.

And claiming a foothold on the Pentium-era hardware means lienmp3 ostensibly falls into a discrete class of software, on par with things like mjs and a few other ancient titles, that were striving for lower system specs at a time when “lower” meant pre-1996. 😐

So forgive me if I hold up a broken, poorly arranged, difficult-to-find mp3 player on the grounds of a claim I can’t even verify. In this case, it’s just interesting to look back, and see how far we’ve come.

musiql: Perhaps the obvious answer to music management

I’m not a fan of applications that attempt to manage my music collection, mostly because I have the music arranged, in folders, how I like it. Similarly I’m not interested in ratings systems, fuzzy searches, popularity statistics or tagging, other than making sure the data in the built-in tag matches the file name. Sorry. It’s just not my nature.

I do, however, respect programmers and their applications that incorporate those features, not because I want them, but because I know it’s an accomplishment to get them working. So for example, cmus is all the more impressive because it runs perfectly on Pentium 1 hardware and has a lot of useful management features.

I suppose though, if you really wanted to get physical with the console music management concept, you could go to the logical extreme with musiql.


musiql doesn’t have much of an interface, won’t show you pretty timers or multicolor counters, and come to think of it, doesn’t really care what you’re listening to or how it’s arranged.

musiql jams your music collection into SQLite, and sets you free to sort, filter, search and booleanize to your heart’s delight. Once you’ve set the rules for what you want to listen to, musiql pipes everything through mplayer, and the deed is done.

There are a couple of obvious points here that I will go ahead and make, just for clarity.

First and foremost, you’ll need some familiarity with SQLite to get it working. What I showed above is really just a crude hack job that I copied off the examples from the help flags. If you need more intricate selections, you’ll need more intricate selection skills.

Second, if you’re looking for something with more visual panache, musiql isn’t it. In fact, musiql is pretty much a hands-off application, and just serves up your request to mplayer, which does everything else (a job it is more than qualified to do, I should add). You can, of course, send along a few flags to mplayer, if needed (in other words, you can enable -really-quiet).

Third, musiql itself is capable of most fundamental management tasks through command line flags, and will even handle smaller details like last.fm submissions (or disable them, to be more specific). It’s not so obvious (to me) how you can edit or micromanage that music database once it’s built, short of some more SQLite expertise.

On the other hand, I can see where this might open the field to a few more nifty tools. If you’re familiar with SQLite and you’re not intimidated by a music database in that format, this might be the cat’s meow. And I’m sure there are tools (for the console or otherwise) that will assist in reading, editing or at least giving more control over the database itself.

And given that SQLite is intended for high-end servers, corporate-level databases, etc., etc., I’m guessing it can handle the biggest, densest music collection out there. So if you’re touting a 4Tb music melange and lacking for a console application that can wrangle it all, this might be the one for you.

musiql is not the only music player to embrace SQLite, but it might be the one that offers (requires?) the most low-level, hands-on control.

For that, I’ll give a thumbs-up to musiql, and for merging SQLite and mplayer in a fashion I didn’t expect, and for maybe being the most obvious solution for music management. It’s not something I’d adopt any time soon, but I can see the attraction for other folks. Enjoy, at your own risk. 😉

dradio: Not to be blamed

I got a tip about dradio from a frequent contributor who prefers anonymity. If I could coach people on how to make a decent text-based interface, dradio would be a good place to start.


Simple arrow keys to select a station, and enter to cue it. Super-big logo. There are playback controls visible in a pop-up help box, and one or two at the command line. Clean and simple.

dradio is a frontend to mplayer and is more or less hard-wired to connect only with Danmarks Radio. Which leads me into the only problem I had with dradio: No audio (or for that matter, video) output. Checking the log shows the corresponding address connecting and resolving, but after that … nothing.

I don’t fault dradio for that, since force-feeding mplayer with the same addresses that are available from dradio’s configuration files yields an identical amount of nothing.

So either the links are wrong, or have moved, or are disallowed on geographic bounds (I am not in Denmark right now). In any case, it appears the fault is not in its stars, and dradio is doing as much as it can to bring music to my ears.

It’s a shame that dradio apparently isn’t open to other radio stations though; I suppose I could try to trick it into opening, for example, a stream from soma.fm (because I’m sure it works) by writing it into the configuration files. But otherwise I think dradio is a one-band man.

If you have any clues for me, on how to prod dradio into action, please let me know, I can always do with a little audio entertainment. 😉

muzikq: With some small improvements

I promised yesterday that I would show ksmp3play‘s heir apparent, and I’m glad I tackled them in chronological order, because it makes things a little bit easier.

muzikq is a good looking audio player, with a similar-yet-different arrangement it obviously inherited from ksmp3play.


Green is a good step for a music player; it’s not often I see an audio tool done over in green and black. And the addition of the info panel on the left is a strong point for me, just be cause I like details at a glance.

Aside from the aesthetic, muzikq picks up on a lot of the strong points that ksmp3play had: Most of the fine-tuning options can be triggered from the command line. File size is shown at the bottom. The scroll bar on the right is animated; as you move through your playlist, the bar highlight shows your relative distance from the top or bottom. Software volume is shown at the upper right, across from a file name display and with timers. It’s a good arrangement and I like it.

But (and you probably know where I’m going with this) muzikq also inherits some of the quirks of its forefather. I can’t start the interface without first selecting a file, although muzikq at least offers a selection dialog as a gesture of goodwill.

You can select multiple files to add, but you still can’t recursively add a folder — which is a huge shortcoming to me. If you don’t add a file, or if you try to just add a folder, muzikq collapses and sends you back to the prompt.

The add dialog has a provision for entering a path, but it’s limited to a specific number of characters, and doesn’t seem to add files from there, or move your selection prompt to that folder. I’m not sure if that feature is actually complete yet. I also had some corruption of longer lists, where paging through the folders skipped over some names by virtue of the size of the screen. That’s a little difficult to imagine, but if you see it happen, you’ll know what I mean.

Once you have a list of files added, muzikq lets you sort them on several points, but also has a provision for a rating system, which is a nice touch. How those ratings are used, or if you can sort with them, or if they’re figured into randomized play … I’m not sure.

My only other notes were on occasional screen corruption, where resizing the terminal might cause labels or data (particularly in the info box) to spill over and make a mess. Even at 80×24 the file size display was consistently broken. And there are some other places where the otherwise clean lines and enjoyable interface gets polluted.

I should also note that, like ksmp3play, muzikQ relies on SDL mixer (in the AUR version) and a couple other packages that might (I’ll just say might, since I can’t be sure) imply an X environment. So if you’re not keen on dragging in everything that X involves, be careful when installing this one.

I’ll let muzikq go now. It’s certainly not a bad program and does play music, like it promises. It has a lot of features I like but there are some parts of it I can’t get past, like the lack of an add-folder options. So, does the rest of the world just keep all their music in one flat folder … ?! 😕

ksmp3play: Simple and direct, but incomplete

I have two music players that I want to show, but I have to write about them in the correct order, because one is an offshoot of the other. And I screwed up the whole roguelike evolution over the past 10 days, which was a disservice to some of the later ones.

Here’s ksmp3play, which is a little hard to find and appears to have drifted away around 2008.

2014-10-23-9brnr91-ksmp3play-01 2014-10-23-9brnr91-ksmp3play-02

ksmp3play is tagged as “beta” software on Sourceforge, and that’s obvious from using it just for a little while. It has a nice, colorful arrangement, with most of the file and playback information pinned to the top of the display, and the playlist stretching down below. It’s clever mostly because it allows you to stretch the terminal to almost any dimension without scrambling the display. Tiling window manager, here we come.

ksmp3play has a few other features that are worth note: It will play at random or circle through in a loop, and it shows individual file times at the top and a total time at the bottom, along with a file size total, which is an interesting touch.

And of course, any time a program can give me a popup help screen, I’m a fan. That, and the dialog for adding files is quite helpful. I also like onboard volume controls that adjust the application’s output, and I like tag editing commands too. 🙂

Those are most of the good points. Here are some bad ones …

That help screen I mentioned is slightly jumbled. Some of the commands listed there are off by a line, meaning “Add files to playlist” isn’t the left bracket, it’s the “a” key. And so forth. If you pay attention you can decipher it, but it’s not as “helpful” as it should be.

At the least provocation, ksmp3play comes to a screeching halt. Enter an empty filename for a playlist, and your music stops and you’re back at your prompt. Skip to an impossible point in a song with the arrow keys, and you’ll know because again, you’ll be back at your shell cursor. It also locks frequently and I get a lot of “stack smashing” errors. ksmp3play needs a lot more error trapping.

Probably irritating to me, as someone who actively looks for well drawn and well designed text-based interfaces, is ksmp3play’s refusal to just start up without a specified file to play. If I enter ksmp3play without a target, I get the help flags list. I can add files to the playlist once ksmp3play is up and running, but if I don’t give it a target to start with, it shudders and blinks like a confused pet.

There are some foggy options, too. ksmp3play offers three different options for randomised play, but nowhere can I find a description of what those three are. You can specify a delay between songs at the command line, but apparently not at the interface (unless I overlooked it). ksmp3play doesn’t bother to remember what volume level it last played at, which means it’s always going to start up at 90 percent of max (I think that’s what it is).

But the worst transgression to me is the lack of a recursive add function. I’d be satisfied to just spin up ksmp3play and feed it my master directory of music, but ksmp3play won’t have any of that. If I want to play a file I have to add it singly, one at a time, through the add dialog. (I get around that nonsense by feeding the results of find through xargs and back in to ksmp3play, which works … sometimes.)

ksmp3play is not in AUR or Debian; the author has a precompiled .deb package on the Sourceforge page, which is what you see running in Mint up there. You’ll need to install libsmpeg0 as well, which begs the question of whether ksmp3play will actually work in a nongraphical environment, if that drags in any SDL, which might drag in Xorg, and so forth.

I’m willing to give the same halfhearted recommendation to ksmp3play as I have to other incomplete projects that dwindled away in the past. It’s easy to see where software didn’t quite reach the level of “completeness” its authors probably wanted. In ksmp3play’s case, “completeness” was still a long way off. 😐

Tomorrow: ksmp3play’s “progeny.”

qplay: More music, in the code of C

I can afford to bring out another music player today, even if it does have a little less visual appeal. This is qplay, which does a nice job of carving down the music playback task.


I’m eager to try out qplay on something rather lightweight, because it’s written in C but wisely (to me at least) avoids becoming a music manager.

Granted, one of the best and lightest music players I know of, cmus, does a lot of management on top of its playback duties, and does not suffer in the least for it. But let’s just say it’s a feature I avoid. 😐

qplay relegates actual playback to mpg123 or ogg123, but apparently can accept “modules” for other formats. The interface is very vim-like, with arrow keys as well as the HJKL set for playlist navigation and seek functions. There are also paging and five-count skip keys, if you’re working with a very big list of music.

There are hotkeys for randomizing, shuffling and repeat functions, as well as a status bar to show if they are enabled, and time displays for individual files. Add files to your playlist by starting qplay with the -r and jump out of it with the “q” key. Simple enough.

Some features don’t appear to be quite … done, which seems to be a recurring theme these days. Help pages are missing, most notably, and the command line “add” function didn’t … add when I asked. O_o

But by most accounts, qplay is taking up a very slender space in memory. qplay itself floats in around 500Kb while running, which is considerably less than, for example, mocp’s claim of 6.5Mb on the same machine. Of course, qplay implies you’ll need another 3.4Mb for ogg123, but that still sets the entire suite around 4Mb, and I’m betting you can afford it.

So let’s review:

  • Written in C, so very lightweight.
  • Uses the time-honored mpg123 and ogg123 tools.
  • Follows vim-like controls, with a healthy addition of other one-key commands.
  • Doesn’t try to manage my music.

And so far its only real shortcoming is a few unfinished features. Not bad for a music player that has been on the shelf since 2005. Oh, did I not mention it was a decade beyond its best-before date? My apologies. … 😈