4 ms·

I also had a quest to build the ultimate music player. My motivation was that most music players got complicated to the point I was unable to use them. My play

I also had a quest to build the ultimate music player. My motivation was that most music players got complicated to the point I was unable to use them. My player is 200 lines of Python, utilizing MPD and Qt (for Docker icon), and has about 3 features. It plays all the mp3 in a directory (including subdirs) randomly, and you can "like" or "dislike" song, which modifies the probability of it being played (and these data are remembered in MPD database). Also has "pause" and "next song" buttons (from the tray menu) and that's it, literally. To each his own, but that's my personal definition of "ultimate".

JTon 13y ago
Sounds good to me too. I'd like to set a "mood" as well. The probabilities for each track adjust based on the mood selected (aside: in the future the mood selection will be automatically and accurately determined via bio-sensors :)
fragmede 13y ago
> utilizing MPD Yeah, that's a non-starter for reasons that are well described in the post. (But to each their own.)
- eikenberry 13y ago
  The only substantive criticism of MPD in the article was it oddly choosing APEv2 for it's replay-gain headers on MP3s. This is fairly easy to work around using one of the various scripts that will add the APEv2 tags to mp3s and MPD has good support for Flac and Ogg-Vorbis replay-gain tags. But it's cool to see more going on in this space. MPD has really been the only player on the field for to long. Hopefully it will work with ffmpeg as it is seeing most of the active development these days and looks to be back in Debian soon [ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 ].
  - fragmede 13y ago
    Having to import my mp3 collection into MPD has always turned me off. Why is that not a substantive criticism in your view?
    - eikenberry 13y ago
      Semantics I guess. To me the internal db is a feature and not wanting it falls under the category of the application not fitting the need. Instead of a problem with the app itself.
aaronem 13y ago
I'd try something like that, but most of what I listen to is from the common-practice era, so the quantum of content is not an individual file, but a playlist. "Shuffle" therefore doesn't work for me; what I really need is a player whose playlists can contain either individual files or other playlists. I wouldn't have thought this would be all that outré a desire, but apparently everyone who's ever implemented a music player disagrees with me...
- drenei 13y ago
  Not sure if you're on the OS X / iTunes ecosystem... You can have a playlist that is made up of other playlists by creating a smart playlist and adding a rule that includes songs from source playlists of your choice. This will atomically include any changes you make to the source playlists. I manage my music with genres — and to a large part, stay away from smart playlists — however they can be a powerful feature.
  - aaronem 13y ago
    I no longer have an OS X box, but I do have iTunes installed on my Windows machines in support of various pocketable devices of Cupertinian provenance. I've never actually tried using iTunes as a music player, so I didn't know about the capability you describe, and I appreciate you pointing it out to me. Unfortunately, it doesn't sound as though it would satisfy my requirement; while I can see some use in an automatically updated playlist consisting of tracks from the playlists I designate, almost all of my (near 100GB) music library consists of pieces which are broken up into a single track per movement. This being the case, it doesn't sound like a smart playlist would solve the "shuffle" problem of jumping from (e.g.) one piece's third movement to another piece's second, any more than any other sort of playlist does. If I can define a smart playlist whose members are other playlists, of course, that's a different matter, and I'll have to take a look and see whether I actually can do that. It doesn't seem too likely, though; as I said elsewhere, I'm not sure why the idea of a playlist containing other playlists is so apparently strange to music player implementers, but I've yet to find anything with the capability. (I'm not sure whether they're afraid of graph cycles, but I'm also not sure whether those would actually pose a problem, and even if they did, it shouldn't be too hard to exclude them by checking at "add to playlist" time and refusing to complete the task if it would create a cycle in the graph.)

JTon 13y ago

Sounds good to me too. I'd like to set a "mood" as well. The probabilities for each track adjust based on the mood selected (aside: in the future the mood selection will be automatically and accurately determined via bio-sensors :)

fragmede 13y ago

> utilizing MPD Yeah, that's a non-starter for reasons that are well described in the post. (But to each their own.)

eikenberry 13y ago
The only substantive criticism of MPD in the article was it oddly choosing APEv2 for it's replay-gain headers on MP3s. This is fairly easy to work around using one of the various scripts that will add the APEv2 tags to mp3s and MPD has good support for Flac and Ogg-Vorbis replay-gain tags. But it's cool to see more going on in this space. MPD has really been the only player on the field for to long. Hopefully it will work with ffmpeg as it is seeing most of the active development these days and looks to be back in Debian soon [ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 ].
- fragmede 13y ago
  Having to import my mp3 collection into MPD has always turned me off. Why is that not a substantive criticism in your view?
  - eikenberry 13y ago
    Semantics I guess. To me the internal db is a feature and not wanting it falls under the category of the application not fitting the need. Instead of a problem with the app itself.

aaronem 13y ago

I'd try something like that, but most of what I listen to is from the common-practice era, so the quantum of content is not an individual file, but a playlist. "Shuffle" therefore doesn't work for me; what I really need is a player whose playlists can contain either individual files or other playlists. I wouldn't have thought this would be all that outré a desire, but apparently everyone who's ever implemented a music player disagrees with me...

drenei 13y ago
Not sure if you're on the OS X / iTunes ecosystem... You can have a playlist that is made up of other playlists by creating a smart playlist and adding a rule that includes songs from source playlists of your choice. This will atomically include any changes you make to the source playlists. I manage my music with genres — and to a large part, stay away from smart playlists — however they can be a powerful feature.
- aaronem 13y ago
  I no longer have an OS X box, but I do have iTunes installed on my Windows machines in support of various pocketable devices of Cupertinian provenance. I've never actually tried using iTunes as a music player, so I didn't know about the capability you describe, and I appreciate you pointing it out to me. Unfortunately, it doesn't sound as though it would satisfy my requirement; while I can see some use in an automatically updated playlist consisting of tracks from the playlists I designate, almost all of my (near 100GB) music library consists of pieces which are broken up into a single track per movement. This being the case, it doesn't sound like a smart playlist would solve the "shuffle" problem of jumping from (e.g.) one piece's third movement to another piece's second, any more than any other sort of playlist does. If I can define a smart playlist whose members are other playlists, of course, that's a different matter, and I'll have to take a look and see whether I actually can do that. It doesn't seem too likely, though; as I said elsewhere, I'm not sure why the idea of a playlist containing other playlists is so apparently strange to music player implementers, but I've yet to find anything with the capability. (I'm not sure whether they're afraid of graph cycles, but I'm also not sure whether those would actually pose a problem, and even if they did, it shouldn't be too hard to exclude them by checking at "add to playlist" time and refusing to complete the task if it would create a cycle in the graph.)