If you can write code, I highly recommend taking a stab at writing yourself the tools that you use the most (whether that is a music player, chat client, text editor, etc.).
Sure, it isn't trivial - but modern languages and libraries (I'm a big fan of Python, both for the language and its ecosystem) make it a very reasonable project. You can get an MVP working in a few weeks of work (if you spend 5-10 hours a week on it), and then you can add features and tweak the thing over the months and years as you use it.
And in the end, you get a piece of software that you deeply know, to which you can add any feature you want, that is customized to fit perfectly in your workflow, etc. It's a bit of work, but it's really cool and IMO one of the neatest things you can do for yourself as a programmer. Additionally, if it's something that works well for you, chances are that other people will like it- open sourcing it and getting other people to use it is a high of its own.
I'm working on a few such apps myself (todo list, mail client, and a few others), as console applications using ncurses to make something with a responsive, smart, effective and efficient style of UI that I don't think has been done before (mostly because no one has been trying to innovate in the domain of console applications in the past 20 years- but I think interesting things can be done). When I'm at an interesting point, I'll open source it and write a few posts about it.
I hear the naysayers saying that it's a waste of time, that there are already 8000 different open source mail clients and music players and todo lists apps and that it's better to contribute to old open source projects than create your own, etc... those arguments aren't wrong, but IMO they don't outweigh the pros I outlined above.
If it is just for a first try to experiment with structuring those kinds of application, or if your needs aren't even that complicated, it can even be quite close to trivial sometimes. But it's hard to know what is out there, and how useful it would be. Things that I've done on the side that weren't too hard and even more fun than I imagined beforehand:
* Media Players (Video and Audio) with GStreamer (0.10 can be okay'ish, 1.0 is very nice so far)
* Text Editors (via Gtk-Source or embedded GVim)
* I've tried building a specialized browser with WebKit. Was also quite easily used, except that I gave up when trying to get the Flash plugin to run turned out to be not-fun. Others may have more motivation.
Note that I mostly try these things in Gtk2/3 with either Perl 5 or Vala. Python seems to have very good Gtk/GObject bindings as well, so that should mostly apply the same way. And I'm sure if you look at the Qt and Wx ecosystems there will also be many preexisting useful components, or ways to plug them in.
This is absolutely true. You'll come to love the tools you make (and hopefully other people will too!)
I'd love to write my own text editor, though I imagine that I'd want a whole lot more features than my "optimal" music player (probably some sort of autocomplete, syntax checking, heck just make it a full-blown multi-language IDE).
By random coincidence, I've been writing (and using for the past year) my own super minimalist ncurses music player (https://github.com/spotco/ScrapePlayerDESKTOP , one python file, powered by sox and most likely only works on OSX).
My needs were definitely very different from the OP (I just wanted the ability to play music by all folder, and all folder recursively), but it's really interesting to see other people's versions of their "optimal" player.
> I'm working on a few such apps myself (todo list, mail client, and a few others), as console applications using ncurses to make something with a responsive, smart, effective and efficient style of UI that I don't think has been done before
I'd love to see what you're doing there, as I've spent the past few months working on a console mail-client, and reached a point where I have to decide to leave it alone or start v2 now I've learned more about how I handle email.
I really like this kind of solution for android stuff. There are some very specific things that I end up doing all of the time and it's relatively easy to write the thing that solves my exact problem in the fewest number of screen taps. I'm not sure if it saves me time overall, but I also enjoy solving the problem.
One problem that really interests me is the "dynamic playlist." Once your music library becomes sufficiently large and diverse, simply shuffling songs ceases to be an acceptable way to listen to music. You'll randomly switch between vastly different genres, come across tracks that aren't enjoyable outside the context of an album, jump in halfway through some pieces. It's a mess.
I wrote a simple script which uses Last.fm data to generate a "path" through the artists in my music library based on their similarities. It's very far from perfect, but it suffices to build an album playlist which slowly takes me through several genres. Some day I'll improve it to work based on albums rather than artists.
Ideally, I'd like to be able to run queries on my music library and have an interesting playlist returned to me.
> Ideally, I'd like to be able to run queries on my music library and have an interesting playlist returned to me.
You want Beets.[1] Anything you could possibly want is doable with the smart playlist feature[2] and the redonkulous power of the queries and metadata (chromaprint/musicbrainz/echonest). There is a plugin for last.fm genres but I have not used it. I am not sure how you got similarities from last.fm but you can definitely use the echonest data to find similar music. There was a good discussion of beets here not so long ago.
I wrote the play plugin for beets last weekend that turns a query into a temporary playlist and opens it with your systems music player for just this reason.
I've been meaning to work more on this, but my free time is fairly limited. At the very least I should probably put my script on GitHub (although it's far from groundbreaking).
For me, one of the pain points is quality of metadata. It's all very well collecting genres, tags, and similar artists from a service like Last.fm, but you need to be reasonably confident that they align with your own ideas about music. Since everyone's ideas about music are different, this puts you in a tight spot.
rateyourmusic.com's genre system works pretty well, it's based on user voting on genres for an album (genres are selected from a list, which is constantly being updated by democratic process too)
This looks really cool! As a classical music fan, the one feature that I've always wanted but have never found is the ability to link several tracks together. Often times classical CDs break up a single piece into multiple tracks, so if you're listening to your library on shuffle, you will often jump into the middle of a piece, which is annoying. It would be so cool if there were a music player where you could link several tracks together as one piece so that shuffle would always start from the beginning and wouldn't shuffle away until the end.
Modern music players and online stores are really neglectful of classical music. I downloaded an album of Jascha Heifetz recordings from the Google Play store, and the track titles are all of the form "Violin Concerto in D Major", "Violin Concerto no. 2", etc, with no indication at all of who composed which piece. The tagging is terribly inconsistent, with the artist sometimes being the composer, sometimes the orchestra, sometimes the conductor, sometimes the soloist, sometimes an arbitrary subset of all those.
I'd really like for someone to make a music player or online store that worked better with classical music. Hell, I'd settle for one that didn't suck.
Have you tried arkivmusic.com? They're classical music only, and a pretty good place to get music. I buy physical CDs only (the crappy tagging being one of the reasons), but they seem to take classical music seriously, so my guess is their digital downloads would be pretty good regarding tags and other info.
Tag your music with musicbrainz.org, they have very strict guidelines for tagging, and when they don't have a release you have bought, you can research and add the information yourself.
The Redbook audio specification allows for indexes (ability to have tracks within tracks), which was intended for jumping to the next movement within classical pieces. I haven't seen the buttons for this on a CD player (real or virtual) since the late 1980s.
Interesting idea. I've thought about that too, for songs that seamlessly transition into each other. The tricky part is how to incorporate that into the UI in a way that is not confusing and doesn't add a bunch of clutter.
Seems like the type of thing that you would have needed to consider pretty early in the architecture of the application. At least to be done elegantly. You'd probably need the ability to have track entries that are "faux" (not mapped from a media file) metadata track entries that the app understands and will spider out to the real files/tracks behind the scenes whenever encountered in a playlist or whatever play context.
That might not be trivial at this stage. But yeah, I agree, the trickiest part would be crafting an intuitive UI around the feature.
Doesn't seem too difficult to me for either UI or playing. iTunes already supports this idea with their "grouping" tag (though it doesn't really do anything AFAIK). It doesn't need to be constantly visible in the UI. Being available with right click and "Get Info" is good enough for me. If you wanted more, you could add a "grouping" column to the view and a button on that column to collapse or un-collapse groups to appear as one track with the group name.
If you're shuffle playing and the next song in the queue has a non-empty group tag, remove it from the queue and instead add the whole group in the correct order. Everything else should be handled the same.
It might be a bad way of handling it (and if it is, I'd be glad to know why). But that's how I would implement such a feature.
So far my idea is that this would be exposed in the album view in the library - you could show line segments connecting songs which have been "grouped". This would make the state obvious and also provide a convenient way to multiselect and toggle grouping. Also when a song comes up solo (perhaps because the user chose to do so) since there is no where to draw a line segment to it would simply have a dot in a predictable location to indicate that it is missing its sister track.
Yeah I like the idea of representing the linkage as chain links.
Then you could show a broken chain link if a linked track is shown in a view by itself sans sibling(s).
That type of UI would be simple enough when you want to link tracks that appear in sequence on an album. Are there any use cases for the ability to link unrelated tracks X Y Z together? Probably not. Playlisting pretty much covers all that functionality.
Music players with cue sheet support kinda support the inverse of this. Throw a .cue into foobar and it will turn a whole album encoded as a single, giant .tta file (how I wish the Japanese knew of FLAC) into logically separate tracks. As I mentioned above, however, this isn't really necessary when album shuffle mode + a separate playlist solves the problem just fine on every existing music player.
The best way I've found to handle this for DJ sets is to use a single MP3 file and a CUE sheet with the times each subtrack starts. Then your media player has to support CUE sheets (Winamp has/had a plugin, Foobar2000 does, other than those YMMV). Matroska Audio showed promise in being the format where this would just work out of the box, but loses due to first mover advantage of mp3s and the market reach of other formats.
iTunes will let you do this when you're importing a cd. From memory, you right click on the tracks you want joined (before they're imported) and select the appropriate option. The only drawback is that iTunes Match (if you use it) won't match the joined file, so it'll have to upload manually.
You don't really need special support for this. Most music players have a mode for shuffling albums at a time, not individual tracks. Just make a classical playlist and select that mode.
As for shuffling your entire library, I don't understand why you'd want to do that. I get in the mood for certain genres; I don't want to jump from Rainbow to nordloef to Massive Attack randomly over the course of 10 minutes.
iTunes can do that -- and it was added specifically for classical music. It's even called Groupping.
Another nice feature it has, is that it lets you handle albums with various artists as one entity, that is, you can set those tracks as "part of a compilation".
How, though? As discussed elsewhere in the thread, it doesn't seem as though "smart playlists" are quite that smart, and I'm not familiar enough with iTunes to make a guess as to how else it might be accomplished.
The solution is to analyze each song before playing it to figure out how "loud" it sounds to humans. Then the music player adjusts the playback volume of each track to compensate for the perceived loudness. This way, the user does not have to adjust the volume for each track that comes on.
This is just going to perpetuate the arms race, because it's not hard to spoof that sort of thing by monkeying around with crest factors in transient designers, plus people seem to have quite different preferences for compression/limiting. Just tweaking gain and falling back to compression/limiting past a certain threshold is just going to lead to pumping on some program material.
There is a standard for measuring this stuff, and thanks to years of people like me complaining about jumps in volume during commercial breaks on TV and the like, a loudness-measuring standard has been formalized and is being demanded by broadcast regulators (so it will become standard in audio production software over the next year or three). It's here: http://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-2...
Waves, Dolby, Izotope etc. have all released plugins or free updates for 1770-3 comaptibility so it should become ubiquitous by mid-decade, as will automatic loudness normalization at the mastering stage, which wasn't previously possible in the absence of an industry-standard metric.
I use iVolume - http://www.mani.de/en/ivolume/ - with iTunes on a Mac as an attempt to solve the loudness problem, and it seems to work quite well to my untrained ears.
This article rings true with me on so many points.
I spent years searching for, and coding my dream music player/manager. Going through tens of different backends, servers, etc, not limited to:
- MediaMonkey: windows only
- Amarok: terrible interface, slow and hard to extend
- foobar2000: closed source/windows only/columns UI stopped working
- MPD: Just not enough, also poor codec support (I use wavpack)
- xmms2: was a baby at the time
- ExFalso
I started coding my own, dubbed lomp: https://code.google.com/p/lomp/
I solved so many interesting issues that seemed to plague other music software: I got client/server working, output redirection, even ended up coding my own library management, then tagging library.
Tangentaly, tagging is HARD, no one does it correctly. The best library I found on ANY platform or in ANY language was Mutagen, part of the Quodlibet https://code.google.com/p/quodlibet/ project; but even it got a few things wrong. I eventually tried to split off my efforts as 'lamt' https://github.com/daurnimator/lamt but didn't dedicate enough time.
Also worked on a wide range of front ends: console, web, etc.
But as I coded this media player, I could never settle on a decoding or output library; I went through SO many:
- controling mplayer/cplay/aplay via a pipe
- libvlc
- gstreamer
- Phonon
- libavcodec
But none were enough, or way too buggy...
After years of failing, I decided I better just do it myself, so I started again: https://github.com/daurnimator/lomp2/
This time using LuaJIT's brand new (at the time) ffi to directly talk to libao (which I found to be the best cross platform audio output solution)
I ran out of time to work on lomp when I was at university, and now I have a job that keeps me busy.
I wonder how many of my pain points you guys have solved.....
Feel free to reach out to me if you want to discuss more.
The idea is that you might edit tags for a file which doesn't even support tags, such as AAC. So it would let you do that, and the changes would then be reflected in the DB. However we would also have a UI pane for "Suggested Library Fixes" or something like that. This would be things like moving files to their canonical location, updating incorrect duration tags, duplicate file detection, etc. It would also have suggestions like this:
* These songs have tag edits that you have made but they cannot be saved. Do you accept this change? (Proposed change: wrap the file in a container format which supports tags)
> I'm particularly interested in your opinions on tagging. Can you explain what most software gets wrong about tagging?
First up, tagging is such a personal preference, from the highest level things like which fields to fill in (e.g. Album Artist), to small differences (e.g. do tracknumbers have a leading 0?), but also technical differences and compatibility choices (e.g. which tagging format? for MP3 you can have any of APE1, APE2, ID3v1 or ID3v2.{2,3,4})
Next these different tagging formats are in no way uniform:
APE2 and vorbiscomments are a string map with somegenerally agreed upon conventions,
ID3v1 has very limited fields,
ID3v2 is extremely over specified with a tag for everything in practice this just seems to mean that every program gets them wrong somewhere.
There are several other formats too...
Next, the tagging systems are very tricky to locate and modify: they all have various forms of headers, footers, padding, and odd storage formats.
e.g. flac/vorbiscomments keep swapping back and forth betweeen little and big endien.
This is made mode complex by the various fighting container formats that have their own escaping, rules etc on top e.g. Ogg, MPEG, Matroska....
To make things even harder, things aren't even correct without context. To take the duration issue from the article, VBR MP3 has no way to calculate duration without completely parsing the files: this takes too long for most files (reading the whole file into memory just to get the length???? no way!) so there's all sorts of heuristics and weird headers (e.g. Xing)
- multi language - id3v2 tags support having multiple title tags. Yet software will assume there is only one, and won't show alternative titles. This becomes problem when exactly same song has multiple names, one in original script, one transliterated, one English translation.
- old international tags - most software can't deal with Russian KOI8 and Polish Mazovia at the same time
- multiple artists - there are songs that are collaborations of multiple artists. For example: 'Will.I.Am & Brittney Spears' gets treated as own artist, as opposed to collaboration. Music Brainz and Discogs handles this in their data.
- alternative artist names - Some artists produce under alternative names. Most tags assume that 'Norman Cook' and 'FatBoy Slim' are two different artists. Same with 'Richard James' and 'Aphex Twin'. Discogs handles this
- hierarchical, multiple genre tags - Most software supports simple genre tags. Few applications can handle multiple genre tags. What about tag hierarchy (ie: Rock -> Symphonic Rock -> Kraut Rock?).
- Extended info tags: mood, style, bpm, key - Sometimes when I am melancholy I care for love songs, I don't care for genre, it can be jazz, or death metal (last.fm data contains enough to map mood/style/decades). When I DJ, I need info on BPM and Key (ie: A Minor), so that one song fits the next. (from Echonest / Beatport support this)
- composer vs performer - for classical music it is as important to know who composed a piece (ie: Chopin - Funeral March) as who was the perfomer (was it Rubenstein or Padarewski)
- spoken word - music listening is quite different from spoken word, like audiobooks. Most software sees just a music file and doesn't handle proper spoken word distinction, while use case is very different
- tag sources - while writting tags, there should be additional tag saying where it came from. Foobar's Foo_discogs and Foo_musicBrainz plugins will write source ID, so that at a later time songs can be updated to online db (assuming discogs/musicbrains has updated their db entry)
- song popularity - there are tags to track song popularity and ratings, yet most software ignores it, or does this badly themselves
- stand alone songs vs mixed songs - some albums / artists have stand alone songs. These can be listened to randomly. Other albums will have songs flow one into another (listen to any Jean Michelle Jarre album, or live dance music split into tracks). There is no proper handling of how these flow
- replay gain - most software is not smart to handle album vs song replay gain properly. Not to mention that there are two types of replay gain for mp3s alone. One will change quantization values, one will write tags.
- images - APIC tag adds image support, yet most software barely reads cover APIC, and ignores remaining APIC (like label logos). Not to mention that this is lost space as each song in album will contain own APIC, making a duplicate of images.
- label tags - Some people like to listen music based on the label that published it. UKF Dubstep, Monstercat, or Ninja Tune are just some labels that people keep track of.
- alternative versions - some songs will have alternative versions, I don't mean remixes or covers by someone else, but main artist will often release few copies of the song. Sometimes the difference is in swear words (explicit vs censored), othertimes it is matter of length (original 7 minute mix vs radio 3 minute mix), other times it is matter of single having vocal vs instrumental versions. Sometimes it is a matter of live recording (ie: mtv unplugged). Most software will either assume songs are different because title tag is different, or will assume they are exactly same.
- sort tag - artists have one name they are to be displayed while should be sorted differently. For example: The Beatles should be under letter 'B'. Most software sucks at this, even though we have the tags, they are not there.
- album subtitle - some albums will have CD1 and CD2 with a subname. For example two cd album 'Destination Lounge: New York City', has CD1 subtitled 'Relax' and CD2 'Revive'. Most software either will need to drop the per cd subtitle, or will split and consider CD1 as separate album from CD2.
http://musicbrainz.org/release/cec1efa8-6541-4f9c-8f55-c86b1...
Not sure if you are interested but I maintain an entire blog on the subject... http://www.blisshq.com/music-library-management-blog/categor... (that's just one category, see others) please note: this is my own commercial site. It'd be great to discuss with you!
Your statement rings VERY TRUE to me as much as the original article, and there may be an opportunity here. I've spent some time (I'm sure not nearly as much as you have) hacking on this problem, but primarily from the library management aspect, and I lean on VLC plugins for play/streaming. This seems to mesh quite nicely with the sides of this that you touch; tagging and such are exactly the sort of problems I'd find most compelling, whereas I'm quite out of my league in the media aspects of it. (my biggest "pain points" were good integration of torrenting/a programmable pipeline for dealing with torrents, library organization, and various distributed features... less pain points I guess, and more things I found compelling enough to not procrastinate on hacking on.)
I also have a job that eats my time, but if you would like to trade contact info, I'd be more than happy for a chance to pick the brain of someone who's been attacking this longer than I have, as well as potentially see what could come of it.
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".
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 :)
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...
Foobar 2000 has a 'Shuffle Albums' mode. I guess other players would too.
Even if your music doesn't quite fit into that box, it could be abused to do what you want (multi song collections turn into albums given the same album name, a single file has some other album name so is it's own album).
I made sure to check that the mode respects order within the albums.
Edit: And you can tweak the album grouping, so you wouldn't have to destroy album tags to make it work, just use some custom tag for the grouping.
I should've mentioned earlier that I've run across that and found it not really suitable for my purposes; I have close to a hundred gigabytes of music, much of which is not properly tagged so that "Shuffle (albums)" does what I want. It's also not broken down into directories by piece (a lot of it's in FLAC/CUE-per-album format, and one album usually contains several pieces), so "Shuffle (directories)" wouldn't work either.
I appreciate you taking the time to mention it, though, all the same.
Edit in re: to your edit: True, but even so, I can't see a way of making that work that doesn't involve many hours of manual tagging effort, which is something I'm sort of trying to avoid.
Yeah, bad tags are a problem and they aren't any fun to fix.
I would think that you could mechanically recognize many of the multi track pieces though (and then just dump some identifier in a grouping tag). So it's "just" a scripting problem, at least if you ignore finding decent and reliable libraries to do the tagging.
Sure, I could do that, and I don't mind driving command-line tools to do the tag modification so that's no real problem, but even with a 99.9% success rate, the size of my music library makes manually fixing up the ones that don't come out right a considerable task -- to say nothing of identifying them in the first place, another problem which doesn't really admit of easy programmatic solution.
In theory, I suppose I should just block out a weekend day or so, put on my headphones, and bite the bullet. But being able to add playlists, as playlists, to playlists, would neatly solve the problem without requiring me to spend a day engaged in such drudgery, and would offer other UI benefits besides. What I've got right now works well enough to be going on with for most of my purposes, and I suppose I just keep hoping someone will come along and satisfy my now rather forlorn hopes as to the rest.
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.
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.)
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 ].
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.
This post makes me feel bad about myself. How many "passion projects" have I started and gave up on the first time something difficult came up? Too many to count.
There are several lessons to be learned from this post. Perseverance. Starting small. Not sacrificing your vision. Willingness to go as low-level as needed. Patience. This is an inspiring post. I think I'm going to dust off one of my old projects now and get back to work.
Really good article, but if you're going to bundle libraries, PLEASE provide a way to make configuration fail if you can't get to the system copy.
A lot of projects (libgroove included) will try the system copy and then fall back to the bundled copy if the system one wasn't found. That's nice for users (maybe), but it's a pain for packagers. If the packager just happens to have one of the dependencies installed, the package will automagically find it but it will have incorrect deps.
That's funny, seems like a lot of us have built music players because none have seemed adequate :)
I built CloudPlay (http://cloudplay.fm) because I wasn't satisfied with Mac music players and none supported streaming from YouTube or SoundCloud. At the time, I had also been itching to build my first Mac app, so what better opportunity to learn Objective-C/Cocoa and improve my music listening experience?
It turned out to be a longer journey than it should have. I got most of it working in a month or two, but I spent too much time with unnecessary detours like:
- writing a low-level audio streaming framework that I scrapped once I discovered a higher-level API
- building a basic search index and deciding to use LuaJIT (!) to implement it, thereby requiring me to build my own Objective-C/Lua bridge, only to discover that the OS already provided a full-text search framework
Yes, I could've read the documentation more carefully, but it's also easy to get sucked down a rabbit hole building stuff from scratch for the sake of exploration. Sometimes building at a lower level helps you appreciate and understand the higher level and why you shouldn't always reinvent the wheel :)
Yes, I could've read the documentation more carefully, but it's also easy to get sucked down a rabbit hole building stuff from scratch for the sake of exploration. Sometimes building at a lower level helps you appreciate and understand the higher level and why you shouldn't always reinvent the wheel :)
Quick question - are people listening to a lot of music through their laptops ?
do note I wrote "through" not "on" - which means that you may still have your music on your laptop, but you could be listening through your mobile (streaming through plex, dlna,etc)
I find the audio quality of listening through mobile phones to be far better than my laptop (and I have a latitude - the highest end of its generation). In general the music player is of far better quality as well (Poweramp, etc.).
The only drawback I can think of is battery consumption, which is easily solvable via a USB cable. It also works great because an incoming call will pause the music and resume when done - as opposed to manually pausing and resuming on the laptop.
And if you are on earphones with a mic, then you understand the true meaning of "gapless" - or do you prefer taking off your foam-covered in-ear 'phones every time you get a call ?
The thing about loudness compensation is that it only further reduces the dynamic range of your music collection (unless you have programmatic control over the analog gain of your amplifier, which you probably don't), so the arguments for it shouldn't really appeal to dynamic range.
The end result is that the music comes out sounding quieter, so the user ends up increasing the analog gain of their amplifier. This increases dynamic range because the alternative is having the highly compressed music sound very loud resulting in users keeping their amplifier gain low.
Without replaygain your loud songs have a small dynamic range and your quiet songs have a large dynamic range most of which is below the noise floor. With replaygain your loud songs have the same dynamic range, your quiet songs have the same dynamic range, but a larger proportion of the latter is above the noise floor, meaning you've effectively increased the dynamic range.
Only if they're clipped after raising the level, which is often unavoidable but also often not noticeable for the brief transients that end up getting clipped.
In the end, digital volume leveling can't be lossless. So you don't have to use it. But for mixed playlists, it's very nice.
The argument of whether it would be noticeable is a valid one, but it also weakens the strict dynamic range argument. All you can do is use a limiter, which is a special case of a compressor, which is so named precisely because it limits the dynamic range of a signal.
e: to further, I don't understand why you think that would affect dynamic range. Dynamic range being the difference between the quietest and loudest parts of a song. If the loud bit is 10 times the volume of the quiet bit, and you reduce the volume of the whole song uniformly to 1/10 of its original volume, the loud bit is still 10 times the volume of the quiet bit
You've failed to consider the way that digital audio works. If you have a 16 bit audio file, each sample can take on 2^16 values. If you reduce the volume in software, then each sample of the audio stream can take on fewer than 2^16 values. In the extreme case, you could reduce the volume in software so much that each sample can only take on a tiny number of values, in which case the audio will probably be unrecognizable.
Yes I'm well aware of that but that isn't what dynamic range is referring to in the above. The only thing you affect by reducing the volume in a digital signal is increasing the noise floor, or decreasing the signal-to-noise ratio. 16-bit audio already has a noise floor well below what a human can hear for a recording which has a "normal" volume as you might find on any CD. On top of this, when you use replaygain in your audio player, the digital volume adjustment is applied to a 24bit signal, and Windows (or whatever OS) has a 24bit or 32bit float signal path, and then most or all DACs are 24bit (for example newish Realtek integrated audio). So it really makes no difference to effective SNR either.
Great idea for a project! I too was a big fan of Amarok, and have been disappointed by music players since having used it.
One thing I haven't seen mentioned, which Amarok, excelled at but other players haven't, was dealing with large (>100gb) collections hosted over a network. Hopefully you'll include this in your testing. As well Amarok allowed you to store metadata in arbitrary databases (which QT had support for) hosted on a network, thus allowing for metadata to be shared by computers for a given account. Quite common nowadays is to use SQLite locally; however SQLite does not support working over a network :-/
A general observation, which the comments in this thread have brought to the point of perceptibility:
Perhaps only in the field of music management and playback is it considered so reasonable to suggest that an acceptable solution to lousy user interface design is to modify the otherwise well-formed data presented by that interface, rather than just to fix the interface and be done with it.
I'm not sure why this is, and I don't mean by it to denigrate people who develop music player software, but it does seem awfully odd to me by comparison with pretty much any other specialization of software design.
What about the whole "everybody is doing loudness compensation wrong" issue I pointed out? That's an example of something that is not merely a user interface design issue.
If you're referring to the comment I'm thinking of, in which you mentioned mpd not knowing how to read but one format of ReplayGain tags, then it's a good example of what I'm talking about. The correct solution to that problem is to teach mpd about other tag formats, not to require that users retag their entire music libraries to compensate.
Update: The comment I'm thinking of wasn't yours, so presumably it's not the one to which you're referring. I've looked through the thread, but I'm not sure to what you are referring. Can you link it, so that I'll be able to update this comment with a response to what you're actually talking about, instead of merely to what I incorrectly gathered you were? Thanks!
I don't know if I agree that that falls within the scope of my plaint, because as far as I'm concerned, the modern habit of mismastering albums with half a decibel of dynamic range produces a result which can't reasonably be called "well-formed". Worse, not only is it broken, it's irretrievably so, because there is no way to restore the information thrown out in the mastering process.
(I think that's actually why I misapprehended your question so badly; with only the most occasional exception, if something's mastered that badly, I can't stand to listen to it anyway because it's either too quiet to hear or a constant assault on my eardrums.)
Actually what you said about mpd replaygain support is wrong. mpd support both replaygain info store in id3v2 and apev2. It even support flac replaygain.
It may just be me being old fashion, but I haven't seen or used a good music player since XMMS. Every single new media player seems want to take up a huge amount of screen space or have a ton of useless feature.
XMMS was great, simple and pretty interface, just add the files you want to play and you could queue up tracks (A feature that seem to elude iTunes ).
> At some point I plan to write a tutorial article detailing exactly how to get this application running on a Raspberry Pi. It's mostly straightforward but there are enough "gotchas" here and there that I think it could be a useful article.
I was wondering what is the differences (pro/cons) between DLNA/UPNP protocols and your solution ?
With a XBMC server, you can play song over network from any sources thanks to UPNP
xmms2 seems like it fits the required bill the best, though the project is pretty stagnant and there's never been a real release. It does seem to get all the big issues right.
I posit that the "just work on X," where X is the dominant player does not contribute anything to the discussion. Why can't we trust people to have investigated this possibility ahead of time?
Given the author's level of gumption, I'm glad he's not hacking on Rhythmbox. Rhythmbox is probably my favorite music player, but it's good to shake things up.
He's certainly within his right to work on whatever he wants. From an effort vs impact perspective however, it is usually better to build on something than reinvent.
In fact I would say this is major drawback on the Linux platform where there's a lot of duplication of effort that ends in half-baked solutions.
In any case, I merely asked; as I said the OP is free to pursue his interest as he sees fit.
Can you install rhythmbox on a Pi without pulling whole GUI circus with it? OP already said he had started hacking on MPD (which IMO is much more suitable as a starting point than Rhythmbox), and gave up for really good and well elaborated reasons.
All modifications to music files will be done in a separate temporary file on the same device and then rename(2) will be used to atomically overwite the old file. This way race conditions and power failure have no chance of corrupting the file.
It's planned that all modifications to music files would be on a "suggested library improvements" pane. In other words, Groove Basin would propose actions such as writing the updated tags you just typed in to the music files, and the user would accept or reject these proposals.
So it's a compromise between wanting to take over and help you organize, yet respecting your file system.
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.
I find this to be an incredibly annoying feature, when it is the default. For the most part, I like to listen to songs the way they have been recorded, especially if I'm listening to albums. In addition, many of the albums that I've listened to already have somewhat of a gapless playback, in that one song bleeds into or is immediately cut off by next song. With gapless playback in the music player, then the small gap between the songs end up just being like dialing down the volume and then back up again in the span of one fifth of a second, which sounds silly.
Whereas, with most of the albums I listen to, the "cuts" are just time markers and the music is continuous across tracks, and a lack of gapless playback is jarring. Classical/baroque, much of classic and progressive rock, a fair amount of jazz and perhaps the entire genre of ambient/trance work out pretty much that way.
> Whereas, with most of the albums I listen to, the "cuts" are just time markers and the music is continuous across tracks, and a lack of gapless playback is jarring.
Whereas? That is exactly what I described in the last part of my post. The music bleeds into/continues or change mood at exactly the beginning of the next song. Why "whereas"?
Dewie I think you're confusing "gapless playback" and "crossfade playback". Gapless playback just means playing the songs exactly as you would hear them on a CD. Groove Basin doesn't even support crossfade playback and I'm not sure that it ever will.
If you can write code, I highly recommend taking a stab at writing yourself the tools that you use the most (whether that is a music player, chat client, text editor, etc.).
Sure, it isn't trivial - but modern languages and libraries (I'm a big fan of Python, both for the language and its ecosystem) make it a very reasonable project. You can get an MVP working in a few weeks of work (if you spend 5-10 hours a week on it), and then you can add features and tweak the thing over the months and years as you use it.
And in the end, you get a piece of software that you deeply know, to which you can add any feature you want, that is customized to fit perfectly in your workflow, etc. It's a bit of work, but it's really cool and IMO one of the neatest things you can do for yourself as a programmer. Additionally, if it's something that works well for you, chances are that other people will like it- open sourcing it and getting other people to use it is a high of its own.
I'm working on a few such apps myself (todo list, mail client, and a few others), as console applications using ncurses to make something with a responsive, smart, effective and efficient style of UI that I don't think has been done before (mostly because no one has been trying to innovate in the domain of console applications in the past 20 years- but I think interesting things can be done). When I'm at an interesting point, I'll open source it and write a few posts about it.
I hear the naysayers saying that it's a waste of time, that there are already 8000 different open source mail clients and music players and todo lists apps and that it's better to contribute to old open source projects than create your own, etc... those arguments aren't wrong, but IMO they don't outweigh the pros I outlined above.
This talk by Gary Bernhardt is relevant: https://www.destroyallsoftware.com/talks/a-whole-new-world