I'd like to agree with you on that, and a year ago I would have done, but foobar2000 has some problems which, combined with its closed-source nature, have driven me out of bed with it and back to the music-player equivalent of Match.com, with occasional late-night trips to the corner of YouTube and Audiobox.fm, when I'm looking to play something right now and can't find satisfaction anywhere else.
I think that metaphor sort of got away from me toward the end. In any case, foobar2000's support for HTTPS streaming is lousy ranging to unusable; specifically, there is no mechanism, including the Windows CA certificate store, by which foobar2000 can be induced to accept a self-signed certificate as valid. When you can't stream music from home over your Comcast circuit without getting throttled because Comcast assumes MP3 data going upstream means BitTorrent, this poses a problem.
There's also the problem of the playback queue not working the way it should. In theory, a playback queue is to a playlist as a lambda is to a named function; in practice, when foobar2000 reaches the end of a queue, it blithely continues playing tracks off the playlist whence came the last item in the queue, which is frankly ridiculous. I can understand from an implementation perspective why it works that way, but that doesn't make it any less broken.
These are the reasons why I'm looking for a better music player. I wish I had any hope of ever finding one.
I can only conclude they do that or something like it, based on the following observations:
1. When I stream MP3 content unencrypted from home to any other location, everything works well for up to the first half hour or so, and then packets start coming through so slowly as to result in about five seconds of buffering per second of music played. Once this starts to happen, I'm similarly unable to access, due to timeouts, any of the other services I host from home for my own use. If I stop MP3 playback and wait a couple of hours, the problem clears up, but only until I start streaming music again.
2. When I stream Ogg or FLAC content unencrypted &c., &c., I always get smooth playback for as long as I care to use it, and all my other home services work fine.
3. When I stream MP3 content via HTTPS &c., &c., I always get smooth playback for as long as I care to use it, and all my other home services work fine.
Of further note: All the locations from which I've observed this problem offer sufficient downstream bandwidth to support streaming of 320Kbps CBR MP3 files, as indicated both by the fact that doing so over HTTPS works fine, and that streaming FLAC at much higher bitrates also works fine. I used to stream MP3 (but not FLAC) over Verizon DSL, which had barely enough upstream bandwidth to support it (and not enough for FLAC), and never had this sort of problem. The only variables in the admittedly informal tests I've run have been transport encryption and content encoding; in particular, all the content, regardless of format, comes from the same hardware, through the same HTTP server, across the same path through my local network.
I suppose these observations might plausibly lead to some conclusion other than the one I've drawn, but I don't see how; if you do, I'd like to hear about it.
I disagree with your point about the queue behaviour. If you want it to work like that, why not just use another playlist? The queue as it is actually complements the normal playlist-centric behaviour instead of being completely redundant.
I don't listen to online radios much and when I do, mplayer handles the ones I like just fine, so this is an honest question: why on earth do you need to stream over HTTPS?
See my comments elsewhere in this thread for the detailed answer. The short version is that I'm streaming from home, and for some reason, if I do that with MP3-encoded content over an unencrypted transport, I can only get about a half-hour of playback at best before my packets start vanishing into the ether. Perhaps it's unreasonable of me to conclude this is because Comcast is throttling my traffic, but I used to do the same thing over Verizon DSL (whose upstream bandwidth was much more limited) and never had a problem, so...
>In any case, foobar2000's support for HTTPS streaming is lousy ranging to unusable; specifically, there is no mechanism, including the Windows CA certificate store, by which foobar2000 can be induced to accept a self-signed certificate as valid. When you can't stream music from home over your Comcast circuit without getting throttled because Comcast assumes MP3 data going upstream means BitTorrent, this poses a problem.
This is a scenario where I wish foobar2000 was open source so this could be fixed independently, but have you tried mentioning this to the developer? Very few people are going to run into this problem, I think it's acceptable for them to miss this use case on the first try. As a last resort, I'm sure there's a plugin to transcode on the fly to vorbis or something.
>in practice, when foobar2000 reaches the end of a queue, it blithely continues playing tracks off the playlist whence came the last item in the queue, which is frankly ridiculous. I can understand from an implementation perspective why it works that way, but that doesn't make it any less broken.
It may seem broken to you, but to others it's useful functionality and the way I expect things to work. I use it all the time to queue up a certain album in a large playlist just by queuing the first track. Easier than selecting the whole thing, and I'd rather have something play when the album's done than be met by silence. If you double click a song to play it, it goes to the next song when it finishes. Why would making a short queue do anything different?
Maybe there is a case for having an option for queues to work like you want, but frankly, this is yet another scenario where the existing tools work just fine to begin with. Make a new playlist and change to "Default" mode and it will stop playback after it completes. Unlike with the queue, which is only intended for short queues, you can easily order things however you like on the fly this way.
There's something like a "UNIX philosophy" argument going on here: Most people agree that it's simpler to use text files for configuration instead of introducing a unique binary format with its own unique editor for every single program you might want to use. Similarly, I think it's simpler and more powerful to just work with the cheap and easy playlist primitive rather than try to hard-code everyone's special snowflake pet feature and getting a bloated, incomprehensible mess of a program. You can convince yourself you need all of these subtly different ways to group a bunch of songs together and always be in search of something more... or you can just make a playlist, which does the exact same thing if you squint a little, and be happy with just about any music player since Winamp.
That it is closed source is a big problem to me, but if "not being able to stream over self-signed https connections" and "the queue mechanism is kinda different than I expected" are the biggest problems you have with foobar, you don't really have anything to complain about.
> As a last resort, I'm sure there's a plugin to transcode on the fly to vorbis or something.
I'd have to do that on the server, which is plausible in theory, but would be an ugly mess when it came to FLAC/CUE-per-album stuff. I could also set up a VPN endpoint at home and connect to it from elsewhere, but it was easier just to find another player that doesn't get upset over self-signed SSL certs. (It seems to me that at least a rudimentary "do you trust this cert?" UI should be part and parcel of any HTTPS implementation, but I've never implemented an HTTPS client as such, so I suppose my opinion there is of suspect value.)
As for the rest of your comment, have you read Richard Gabriel's "Worse is Better"? He makes some trenchant points about how the Unix philosophy you describe privileges implementation simplicity over interface simplicity, and if that makes life hard for the user, well, so be it; making life easy for the programmer is more important.
Your argument here -- that it's entirely reasonable to require a lot of manual work in order to achieve perhaps a little more than fifty percent of the fashion in which I desire my music player to behave (the two problems you discount not being at all my only problems with the player) -- so transparently embodies the sort of thinking Gabriel decries, that I'm really confused as to whether you're doing it with a straight face. I waver between being so convinced, and believing instead that your comment is perhaps the single most subtly and delicately crafted example of satire that I have ever seen in my life.
If the latter be true, then, sir, please accept my most profoundly sincere congratulations on having brought Dr. Swift's art to a new apotheosis. If the former, well, I suppose I can at least agree with you that it'd be nice if Pawlowski opened the source.
Just noticed this reply, possibly the most eloquent way anyone has ever told me that they think I'm a moron. Yes, I've read Worse is Better. No, I don't think that the Unix philosophy is always the right one. I was 100% serious, though, no satire. On the contrary, I'm the one having a hard time believing the things people complained about in this thread. I mean, seriously? Make a new playlist and drag and drop the song into it vs. right click the song and hit "add to queue." I simply cannot believe that this is the kind of thing that would be a deal breaker for someone. If I may be so trite, it is a "first world problem" if ever there was one. "This program is perfect except for one minor detail; I don't care if there's a baby in it, this bathwater needs to be gone yesterday."
One thing we might be able to agree on is the value of providing simple building blocks and a powerful but easy to use scripting interface. I think we could both learn to love the child of emacs and foobar, that would let you happily do whatever silly things you want to do with your queues while I remain none the wiser.
In closing, to echo your passive aggressive tone, have heard this quote by Alan J. Perlis? "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." Perhaps the same could be said about programs that expose many different and separate interfaces for fundamentally similar problems.
A fair response, although I might quibble with your choice of the term "moron"; if that was what I thought, I doubt I'd have bothered replying to you at all.
(I note also that, in my earlier reply, I forgot to mention that several Foobar2000 users have requested better self-signed cert support from Pawlowski, whom I've never seen to respond favorably to such a request. I saw little value in registering for the HydrogenAudio forums, solely in order to weigh in on the side of a feature which the developer plainly doesn't consider worth his while to add.)
I've never seen a playback queue as anything other than possibly an imperfect workaround for the limitations imposed by the inability of playlists to contain nodes pointing to other playlists, and my frustration around the subject of Foobar's playback queue stems from the fact that it's not even any good at that, much less at being a good idea in its own right -- the fact that the queue's contents aren't even exposed in the UI without adding a plugin should, I concede, have served as a strong clue. (And your choice of Perlis' epigram strikes me as truly inspired! Why, indeed, should we have these two things, the playlist and the playback queue, which behave similarly but not identically, and whose coexistence requires a bunch of otherwise unnecessary special cases?)
I can appreciate your incredulity at playback queue (mis)behavior being a deal-breaker for anyone with foobar2000; annoying as I find those idiosyncrasies, they don't rise to that level. The brokenness around self-signed SSL certs does, though, because it makes the player effectively unusable for my purposes anywhere but at home -- hardly, I think, something which qualifies my abandonment of foobar2000 for streaming use as "throwing the baby out with the bathwater".
It's funny you should mention "the child of Emacs and foobar"; as it happens, there is a music-player integration package [1] for Emacs, which I've occasionally considered trying out since that is the editor I use. Unfortunately, EMMS doesn't appear to support FLAC/CUE-per-album, which I regard as a sine qua non since so much of my library is in that format.
Given the increasingly solid multimedia support in modern browsers, and given also the existence of a pure-Javascript FLAC decoding library [2] which has worked surprisingly nicely in my trials, I've lately been mulling over the thought of writing my own relatively simple-minded player, which I could host in the same place as my music library and just fire up in a browser when I wanted to use it -- and which, yes, would support adding playlists to playlists, and be able to shuffle among playlist nodes in a sensible way. By succeeding in such an effort, I could both satisfy my own desire for a particular combination of features, and make a very convincing public argument for my belief that the current style of user interaction around music playlists is neither the last nor the best word on the matter.
On that note, I appreciate your taking the time to argue with me in this thread; any opportunity to refine my thinking, on any subject, is of value.
J. River Media Center is a fantastic media player for Windows. Recently they have ported it to Mac [2] and an early port is available for Linux. The Mac port was still a little buggy last I tried, but a quick scan of the absolute features identified in the OP blog seem to be covered. I use it on Windows as a Media Center to serve audio/video/pics to all the devices in my home via DLNA.
What really crosses me about iTunes on OS X is that there seems to be no way to pry the media control keys loose from it, which I found perennially vexatious back when I still had an Apple laptop.
iTunes is still a serviceable player and works well for standard formats.
Vox is lightweight and can read a ton of file formats, as well as load up your iTunes library. I think you can set it to auto-load a directory at launch as well.
I used to think Songbird (now Nightingale) was going places. I remember being so excited when Songbird 0.1a came out! Unfortunately things went downhill after a couple of years until POTI killed the project and progress on the community fork has been excruciatingly slow. I want to get involved, but its hard to know where to start.
Nightingale is what I actually ended up using after I failed to convince foobar2000 on the subject of self-signed SSL certs. A little flaky on occasion, sure, but for my relatively simple purposes, it worked nicely.
I've had good results running it over Wine on OS X. I see no reason why it shouldn't work at least as well under Linux, subject to that platform's perennial audio output woes.
I can tell you some things that appealed to me initially, if it helps - OS native UI, lightweight, nice separation of core and plugin features, core working flawlessly, very extensive plugin ecosystem, customizability, automatic tagging, fast media library indexing.
The ability to play every music format under the sun; an infinitely configurable UI; a reasonably broad plugin ecosystem, albeit not one which encourages new developers very well.
