Archive for January, 2011

Please, Use HTTP Language Headers

I’ve got my HTTP header set up as “Accept-Language: en-US,en;q=0.9,nl;q=0.8”, but the number of sites that actually seem to use this (that I have encountered) can be counted on one hand. Especially on Belgian sites it’s ludicrous: I’m clearly saying that I don’t want French, so unless there is a choice between English, Dutch, and French (on a minority of sites, sometimes also German) there’s no rationale whatsoever to bug me with the option for French when the only options are French and Dutch.

Don’t get me wrong: I want the option to override this automatic detection system with a language selector in the top-right or some such, but it seems like I’m sending out these headers to waste bandwidth. I guess I should just be grateful that they don’t make their language-selection pages Flash-based, though they do typically come attached with gigantic pictures that aren’t reused on the actual site.

I don’t know what the best method would be to utilize this, but in the case of the aforementioned majority of Belgian sites they tend to be like and, so I’d say just quietly redirect me to (all through HTTP) whereas if I go directly to /nl or /fr nothing should happen.

PS The few sites that initially seemed to utilize this method (like actually perform some IP-based shenanigans. It happens to work out for me in this particular case, but generally speaking I consider that far worse than the redundant language selection screens, although a lot of that depends on overridability as well. Which reminds me of software that insists on displaying itself in Dutch based on my location settings while it should really just align itself with my OS language.


A Decent Audio Player on Linux: Or How to Replace foobar2000

Short answer: you can’t. Slightly longer answer: there are only four applications (of the ginormous number I tried) capable of playing music well: Aqualung, Deadbeef, GogglesMM, and mpd. Anything else simply doesn’t do it for me. In this post I’ll explain my requirements for an audio player.

My most basic requirement for an audio player is, logically, playing audio well. While that sounds too obvious to mention, the primary reason I only came up with four audio players is because none of the other players I tried met what I mean by this, which is the following:

  • Good audio quality. It would seem that all players on Windows as well as Linux have reasonable output quality these days, and I remember that 10 years ago that wasn’t necessarily the case. What player you chose could significantly affect the output. Either way, I still list it because it’s probably the most important requirement.
  • Gapless playback. No fading in and out and no pauses. Fading might be alright between songs from different albums, though I feel that true gapless playback removes any need for silly fading practices. At any rate, even though this applies most strongly to only a minority of albums it’s a prerequisite.
  • ReplayGain. I don’t like to be surprised by overly loud music or some such. But perhaps most important, this means album gain, not just track gain. Many players that support some form of RG fail here because they only do it on a per-track basis.

Then there are some peripheral things I like that aren’t directly related to audio quality:

  • Must not freeze when adding a few files. Preferably it’ll be able to do it completely out of your sight, but I’ll take some kind of “busy” notice as long as it doesn’t interfere with the application’s ability to play music, be paused, go to the next track, and the like. It seems that any Python-based application utterly fails here, including Quod Libet, which says “Do other media libraries choke and die after a mere 10,000 songs?” Perhaps it doesn’t die, but it certainly chokes for enough time for me to stop caring if it will so I’ll kill it manually.
  • Shouldn’t lock out the interface or keyboard bindings while adding music. If the GUI doesn’t freeze, but does lock me out with a “nice” adding files dialog it isn’t really that much better than freezing, is it? Still, at least you’ve got a rough idea regarding what’s going on and whether it’ll take seconds, minutes, or hours before you regain control. Plus there’s usually a cancel button for instant control, whereas a frozen GUI requires killing and restarting for that.
  • Last.FM scrobbling. I just like it. All in all I suppose this is the least important feature.
  • Media library. foobar2000’s library contains a bunch of track metadata and it automatically monitors folders for updates. It’s quite neat.

Neither Aqualung, Deadbeef, GogglesMM, nor mpd quite succeeds at all of these requirements, while they are all part of foobar2000’s base package or easily added with plugins. I haven’t even touched on the wonderful things I can do in foobar2000 with the command line, keyboard bindings, and columns_ui, but I suppose can’t expect that.

Aqualung generally seems to succeed best at the requirements I listed, save for Last.FM submission. However, because I don’t use Ubuntu/Linux as my primary media playing OS (that’s still XP) I generally tend to vary a bit between Aqualung and Deadbeef as my music player of choice. Nevertheless I’m quite confident that Aqualung would be my primary choice if I played more than the occasional few tracks or podcasts.

Rather than explaining what Aqualung does right, which I think I already did while listing my requirements, I’ll explain what’s less optimal about the alternatives from the perspective of my second-favorite player, Deadbeef.

  • it does ReplayGain well, including on MP3 with ID3v2 tags — Aqualung: equivalent; Goggles: worse
  • it doesn’t choke when adding lots of files, but does lock out access to the interface while it’s adding files — Aqualung: superior; Goggles: equivalent to worse (since Goggles requires files to be added to the music library, which isn’t something I necessarily want just to play some random file or song)
  • it only does gapless playback on some filetypes — Aqualung: superior; Goggles: equivalent
  • it supports Last.FM scrobbling — Aqualung: worse; Goggles: equivalent

Aqualung is clearly superior on all accounts save Last.FM support, but I’m glad that Deadbeef, Goggles, and mpd are around to show other players how not to suck. I have to say that if mpd could play random files easily I’d probably be using that instead of anything else. Plus I don’t really want everything to be in a library before I can play it. Since I don’t typically use Linux for “real” music listening I sometimes pick Deadbeef’s or Goggles’ Last.FM submission over Aqualung’s technical superiority.

Basically, Deadbeef and Aqualung deliver what Quod Libet promises: “Are you sick of audio players that think they know how to organize your music for you? Do other media libraries choke and die after a mere 10,000 songs?” Goggles is a little too focused on its library for my taste, but it’s certainly not horrible. Still, the point is that I like Quod Libet’s philosophy better than Goggles’ philosophy. Quod Libet, meanwhile, does not deliver on its promise at all and it chokes horribly. I suspect it’s due to Python, because all Python-based players seem to suffer from the same defect.

Finally, I must admit that I haven’t properly investigated terminal-based players such as cmus and MOC because I only found out about them recently, after I tried tons and tons of music players in order to end up with the list at the top of this post.

If you know any other players that more or less meet these requirements, particularly the playing back music well part, I’d love to hear them.