Improving music playback in GNOME (1/2)

13 March, 2007

As a college student studying engineering and music performance, and as a loonix geek, I’ve spent far too much time thinking about music players. Some of the first hacking projects I worked on in high school were tools to sensibly shuffle and play my music library. Now I’m more interested in the GNOME desktop, user interface design, and integration; I’d like to combine some of these ideas to take music playback on the GNOME desktop beyond iTunes.

In this frighteningly long post/article, I’m going to lay those ideas out in hopes of getting some helpful feedback. 🙂

State of the music playback and management: some context
First generation music players dutifully do their thing when the file manager tells them to. They show you the awesome metadata for each “song”¹. A point arrived a few years ago when people started realizing that a track’s metadata can be more useful than its file name in a single library, because file names are typically an inconsistent jumble that are redundant with tagged metadata anyways. Searching through directories full of this sort of file is a pain unless you’re obsessive enough (like, say, me or David) to go through and sort things using some sort of recursive renaming tool and then tweak by hand.

Apple’s iTunes took a step toward rectifying the situation. It integrated nicely with the iPod and that crazy internet shopping thing, but it also took the metadata feature a step further, and made the jumbled file names invisible to the user. It favored metadata instead. This turned out pretty nicely, and a whole slew of GNOME applications have imitated this idea to varying extents: rhythmbox is the most obvious (since its goal seems to be to replicate iTunes as closely as possible), but banshee, quodlibet, listen, and muine do too, somewhat.

Those projects have done a good job with that, but I think we can do better. Here’s why:

  • Beagle and Tracker already index music metadata. Why index them separately? Let’s not.
  • None of the existing GNOME music players integrates all that well into the desktop infrastructure (nautilus, menus, the panel..) yet. Let’s make this better.
  • Shuffling has always been horribly sloppy in every music player I’ve ever seen. This is not an exaggeration. We can make track selection more intelligent, and improve transitions.

¹ Pet peeve: this term is perpetually inaccurate in music-playing software. I don’t care how hip you’re trying to be, or what your target denominator is. A much less annoying word choice is “track.” A “song” is a specific term with a specific meaning. That meaning is not “the stuff in this sound file” any more than it is a measure of disk space. A symphony is not a “song,” a jazz tune is not necessarily a “song,” and anything that’s a dance is not a “song,” so please don’t write software that assumes every track in my library is a song. Thank you.

Bone to Pick #1: Metadata indexing
The second generation of music players was ahead of the desktop curve in terms of the metadata/tagging craze. Desktops are slowly evolving in that direction; in GNOME this is driven by the beagle and tracker indexing tools. If this trend continues, file names may no longer be relevant on desktops within a few years. Awesomely, these services also index music. Yay! This means we shouldn’t need to do that separately in music players any more, right? Jamie McCracken has stated plans to start implementing this via a tracker backend into rhythmbox soon, but in the meantime consider this (very nonscientific) survey of system resources consumed by some GNOME music players for my ~5000 track library:

  • Memory consumption on startup:
    • banshee: 62M
    • listen: 78M (!more than firefox with 4 tabs open to fancy JS pages)
    • quodlibet: 46M
    • rhythmbox: 32M
  • Disk space consumption of library index:
    • banshee: 7M
    • rhythmbox: 3M
    • quodlibet: 2M
    • listen: 7M

Bone to Pick #2: Shuffling
As I said above, this is horribly sloppy in every single player I have ever seen or used. Music players have supported this feature since they first appeared, so it’s kind of impressive to me that nobody does it right. A proper shuffler should be able to semi-intelligently group tracks together, and insert an appropriate brief delay between tracks and groups, pretty much like a DJ on the radio who might play more than one genre. Yet I’ve still only ever observed exactly two different approaches of grouping files for shuffling, and they are both rigid and simplistic, and I haven’t seen audio transition options in any of the GNOME players.

The most common approach (a la iTunes, rhythmbox, banshee, listen, and quodlibet) is to select a random track out of the library’s lnog list of tracks. With this scheme, it is inevitable (in my library certainly) that tracks are chosen from somewhere in the middle of a symphony, or that 30-second “Stop” track from The Wall, or a spoken-word segue in a Kanye West album, or another track that generally don’t make sense out of context. This drives me crazy. Unless your music library is made up of Brittney Spears-alikes and random singles (which is admittedly actually kind of common), this approach to shuffling will not be very satisfying, and will demand frequent intervention by the user.

The second common approach has been to select and play a random album (as in muine and quodlibet). This approach has drawbacks too: any tracks I have that are missing an album tag tend to get ignored. Further, if I start listening to certain sets end-to-end (e.g., any Beck albums, or Bach or Shostakovich Preludes and Fugues) I’m likely to go slightly crazy and move on.

It seems clear to me that rigidly enforcing either of these shuffling schemes doesn’t work well. I want to be able to group some albums (like The Wall) entirely together, split some into smaller groups (i.e., each prelude paired with its fugue), or even play every track separately (such as Beck albums). How to go about doing this? Most generally, different genres ought to grouped and treated differently by default, according to the traditions of that genre. Multi-movement classical pieces, modal jazz albums (hoo-ray Miles Davis!), and progrock typically require the context of the rest of the group in order to make sense. Folk music, most rock, big band jazz, and many ethnic musics are sometimes placed on an album for convenience rather than artistic cohesion, and users may be used to hearing them as singles on the radio, so there is often little reason for them to be grouped together. Clearly these defaults are rough stereotypes; it would still be necessary to provide a mechanism to tweak grouping individually, but it would be a start.

The last shuffling issue I’d like to address is that of song transitions. This is another situation where traditions vary by musical genre and artist. Typically in classical music, for example, you don’t want to add any extra delay in between movements, because it will fubar the flow, but every player I’ve used adds a delay while it loads the next file. On the other hand, it’s traditional in many popular idioms (and can sound rather nice) to let a finished song hang in the air for a second or two between tracks, or to crossfade (I understand this is possible in Amarok.. why shouldn’t GNOME players be able to do this?).

Bone to Pick #3: Desktop Integration
And now the fun part. Music playback has become a staple task for desktop computers. Desktop instant messaging developers recognized the same fact about their arena, and started the telepathy project, yet I haven’t seen anything like this for music playback.

I think we can avoid the monolithic (and frankly often sluggish) iTunes-alike music playback approach by adopting a decentralized dbus-based music infrastructure remeniscent of the telepathy design:

  • A playback application with a minimal interface. Its jobs could be to
    • Prioritize playback requests from other components (or let PulseAudio do this?)
    • Handle *all* aspects of playback using gstreamer
    • Higher-priority playback requests preempt lower-priority playback requests by pausing, fading or muting to background
    • Lower-priority playback requests queued for playback after higher-priority requests
    • Not need to know anything about music libraries
    • React intelligently to preemption requests (for new files or from PulseAudio)
    • Sit (in the panel?) and respond to control and information requests over dbus.
  • A shuffling app in to configure and generate pseudorandom/ambient playback (like a radio DJ) appropriately for the relevant style of music
    • Play at lowest priority; requests probably preempted in the player when specific files are requested by other components
  • A metadata search app to find and play specific sets/tracks – why not do this in nautilus using beagle or tracker?
    • Send requests to player when user opens a set or track
    • Inside music:/// URI in nautilus?
  • A podcast/internet radio browsing app – could even be firefox+google reader..
  • A tagging/metadata management app?
  • An iTunes store app?
  • A portable music player handling app?

Mostly in this post I’ve focused on what I’d like to do. In Part 2, I’ll discuss more about how I plan to do it. I’d love feedback from anyone who happens to read this. My secret plan is to apply to GNOME to start part of this as a Google SoC project!


41 Responses to “Improving music playback in GNOME (1/2)”

  1. […] Lurgy ha fatto qualche misurazione (non strettamente scientifica!) tra le dimensioni di alcune librerie di lettori più conosciuti: dello spazio su disco e della memoria che occupano per circa 5000 brani: […]

  2. saracen Says:

    This sounds great man. Hope that you decide to do it in Python :). And don’t forget about a nice plugin architecture.

    Power to you!

  3. Alex Jones Says:

    Can we chat?

  4. Walther Says:

    Ok, here is some feedback 🙂

    #1 Would be very nice to have and is doable on short term.
    But how would you handle a usb stick with oggs that gets inserted? It will take some time for the tracker to pick up that meta information.

    #2 Shuffling is not a high priority for me. This seems hard to get right without user intervention.

    #3 As a developer I like this kind of design. But I’m not sure what a user would get out of it. Most of these things can just as well be done by e.g. rhythmbox with the right plugins.
    The only thing I would really like to have is automatic muting when a voip call comes in or when I launch a game with its own sound. For that you could create a very simple DBUS-protocol that all the players can implement.

    It’s always nice when people try to rethink the desktop experience. Keep going and good luck with your secret plan 🙂

  5. vitaminmoo Says:

    Excellent commentary. I especially agree with the desktop integration piece. I’d actually rather be quite Draconian about it, and not have file browsing capability inside of a music player at all. It seems to me that there are two basic types of music browsing – the first being browsing one’s collection as a whole, which either the file manager or a very encompassing query through a properly designed search interface would accomplish, and the second being browsing for something specific, be it artist, album, genre, bpm, or something so crazy no one has even conceived it yet. What’s that? I just described a nicely modular search framework with audio metadata support? Works for me. Redundancy, bad. Modularity, good.

  6. Alan Says:

    Very nice idea, although I’m not quite sure about having separate applications for each type of task. There’s a reason iTunes is used for handling music _and_ my iPod. I don’t want to rip a CD (intending to stick it on my iPod) and then opening a different application to stick it on my iPod.

    Of course, I understand if a user is listening to music in the background, and then decides to listen to some streaming internet radio instead. But will the average user understand that they don’t have to stop playback in music_player_x to listen to the radio station in player_y, but that it will work automatically?

    Of course, I understand entirely where you’re coming from, but I felt like pointing out a few raw points in your ideas. I can definitely see this working though.

  7. Cody Russell Says:

    Great post! Being another person who happens to have a lot of classical music and live music, I have one more thing I’d like to add to this: get rid of the gaps/spaces in between tracks! With live music and a lot of classical music, you buy CDs that have no space (attacca movements in classical) and you want a smooth transition. It works with CDs, but not any of the Linux music players that I have tried. When I play with Banshee or Muine there is this ugly and abrupt stop in the sound.

  8. lurgy Says:

    Thanks for the feedback everybody, keep it coming! I’ll respond in a little more detail tomorrow after my digital filtering exam 🙂

  9. Simon Francis Says:

    I’m a big fan of the way Muine reorders the playlist instead of just skipping to a random song next. This allows me to move things around myself and plan a few songs ahead. I haven’t seen any other player do this, but it is by far better than what most players do.

  10. kerrick Says:

    As far as shuffling goes, I have never had any complaint with Muine’s Ruffle plugin. It extrapolates what music you would like to listen to next based on what your playing now, pulling the same artists, genres, and similar artists from

  11. Joe Shaw Says:

    I don’t really agree with #1…

    The first problem is that the indexers crawl all your data (Tracker files, Beagle more) and that can take a long time. It’s not searching only for your music.

    Secondly, the data stores for music players can be a lot faster and more efficient than how Beagle or Tracker can store them, because it inherently knows more about the type of data stored in their databases. They can optimize for certain types of searches, which the indexers could never do.

    A 5000 library is probably something like 50 gigs, right? A 2-7 meg library is inconsequential. Even if this was duplicated in the indexers, that’s still a small amount of disk space.

    The memory usage is pretty high, but I suspect it’s because the entire audio library is kept in RAM. The audio players would still have to cache at least a large chunk of it in memory if using Beagle or Tracker, because every time it wanted to get additional info, it would have to do an IPC call and a search. This will always be slower than a simple SQLite query on a 5000 row table, which is how I assume most of the players work now.

    All that said, I *totally* agree that Beagle and Tracker and the media players should go further to integrate. If music players could use the indexers to automatically find music and populate the library, that would be great. You want all that music metadata indexed and searchable, and you want changes to that metadata to be pushed back into the music player and the audio files themselves.

  12. hircus Says:

    Simon: Rhythmbox and Quodlibet already have “play queues”; so I guess as a proof-of-concept one could just write a shuffling plugin that would populate these queues (in effect, simulating iTunes’ Party Shuffle).

    In the long run, I agree that a separate playback component that sits on top of Gstreamer (so it can intelligently pause if, say, a voice conversation is starting) would be ideal. There are all sorts of neat scenarios that Mac users can do with Salling Clicker to control their iTunes jukebox, but IMHO should not be tied down to any specific player. You want, instead, to be able to specify a rule like “if my phone goes out of range of the computer, then pause music playback” regardless of application.

  13. Simon Says:

    Sounds interesting. I don’t find all the problems you identify to be a big deal myself, but you’ve got some good points – certainly, using an existing file indexer like Beagle/Tracker makes sense. Integration with Nautilus and stuff, I’m not so fussed about – Nautilus is a file manager, and to me has nothing to do with playing audio tracks.

  14. Alex Says:

    1. metadata indexing
    First, beagle’s indexing brings my laptop to its knees, while quodlibet handles my massive library of mp3s with perfectly respectable performance. At the moment, tying music players to beagle seems unwise, at least for low-end machines.

    Second, paths and filenames matter. I may have several versions of the same track: the high-bitrate original (in ~/mp3/artist/album/), the low-bitrate version for my portable player (in ~/mp3/lofi/), the normalized version for burning to a mix CD for my car (in ~/tmp/mp3gain-iso/), and the one that I’m fooling around with in audacity (in ~/audacity-proj/). Note that all four files have the exact same metadata, but I only want my music player to play the first file.

    2. shuffling
    I fully agree with you on this point. Shuffling algorithms should take cues from the genre and from the metadata of the other tracks in the album.

    3. desktop integration
    I suspect the decentralized music system version will have higher memory requirements and worse performance than a monolithic app. Same argument as microkernels vs. monolithic kernels. Of course, the decentralized version would be much more flexible, so it might be worth it…

  15. ken Says:

    You make some excellent points. I’m working on an app (that has nothing to do with music), and I’ve long since decided to simply write a Beagle filter and use that to provide an iTunes-ish browsing/searching interface. It’s the way of the future.

    The one time I cringed is when you suggested splitting everything up into little apps to do one thing. Well, as a student of UI design, one of the things that Apple got pretty much right is direct manipulation: you see it, you can edit it. Splitting out a “tagging/metadata management app” sounds like it’s just going to make things less obvious for users. But I’ll try to withhold final judgement until I see a more complete plan, because heck, I’ve been wrong before.

    As for shuffling, yes, it’s not useful for that, but how I always use it is to: put it on shuffle, hit “next” until I hear something good, and then turn off shuffle (and go to the beginning of that album). It’s not useful to jump into the middle of most of my albums, but shuffle is a great way to say “find me something I haven’t heard recently”. Making it less than fully random would hurt this — though a “shuffle albums” would really help here. It’s odd that many players have “repeat one / repeat all / repeat off”, but no analogous feature for “shuffle”, which is where I really want it.

  16. Sven Neumann Says:

    What would be really nice would be a music player that uses the knowledge gathered on to find similar music in my music collection. That way I could just select one song that fits my current mood and would tell the music player to keep playing tracks similar to the one that I selected.

    I don’t know if offers an API that could be used to implement this. If it did, it shouldn’t be too difficult.

  17. James Says:

    Don’t forget exaile. Also see and mpd (music player daemon) which is a server with many different clients available.

  18. It seems to me that a lot of people think that if the player is to select the next track it should do this based on metadata. I don’t think this is right: it should be doing something like what pandora is doing, i.e. select a track that is similar to the one just played. Pandora does this by manually describing each piece of music which is cumbersome. Recent Machine Learning efforts by Lars Kai Hansen ( shows that it can be done automaticly. Modern players need to intergrate things like this (IMHO)

  19. mathias Says:

    Great post.

    And because not all audio is music (as not all music is “song”), let me add two things:

    – gapless playback: no more annoying 1 second gaps between files
    – start _exactly_ where you are (e.g. file X, second Y)

    I listen to a lot of audio courses, and it’s tiring to have to allways search for the place in a one-hour session where you left of yesterday.

    And ken:

    splitting the app up does not nessecarily mean splitting up the UI (even if it’s done like that way to often). We could still write a music management ui, bundling all the task usually needed and expected for managing audio & call the modular pieces where needed. UI != app, even if it’s the current thinking style.

  20. James Says:

    Don’t forget exaile. Also see and mpd (music player daemon) which can be controlled by a variety of clients.

  21. ion Says:

    Re: smoother transitions, I hope some player implemented this idea,

    Alex: Tracker shouldn’t be such a resource hog as Beagle.

  22. Chris Says:

    Please don’t forget one thing:

    The metadata index must be shareable. Not only to different programs, but also to different accounts/machines.

    I want to use the *same* one and only index one day on my desktop machine and the next day on my laptop. And maybe on my desktop machine, I want to use Bansheee, while on my Laptop, I’d love to use Rhythmbox.

    From the development point of view, I’d say that anything but a database would not be sufficcient here (and todays’ hardware should not have any problems with having a database as prerequisite).

  23. Inkubux Says:

    I think your ideas are really great, but we need to integrate all the tools in one app, maby have them a bit like they do in kde with kcontrol and kontact, every applications is a standalone application while a metaprogram integrate them together so you can have you central music management software.

    I like the music:/// thing , but it would need to be configurable to the bone, maby provide different views for it that could be plugin driven, so for people who likes full blown gui like Itunes coverflow can have it, and people who like simple track listing like winamp can also have it.

  24. Meneer R Says:

    @ Alex

    Beagle is slow indeed, but pushed by Novell since it uses Mono.
    Tracker (which works just like Beagle) is blazingly fast and very memory friendly.

    Try tracker. On Ubuntu Feisty it would be a:

    sudo aptitude install tracker libdeskbar-tracker

    There are some issues with the desbkar-plugin though. You want to remove ‘trackerd’ from your default session. (deskbar will launch it and _not_ crash). But this will be fixed before final release, i’m sure.

  25. Meneer R Says:

    As to Beagle/Tracker file-system integration.
    It doesn’t just concern music. It also concerns, say, Photo’s and Movies.

    Why not just throw the file-manager out?
    Suggested gnome-menu structure:

    UserName (this menu has your name on it)
    – Documents
    – Contacts
    – Calendar
    – Mail
    – News
    – Bookmarks
    – Music
    – Videos
    – Photos
    – Games
    – Tools (such as a calculator)
    – Choices (or Preferences)
    Log out..

    Task (this menu dynamically contains all running tasks)
    – Downloads
    – Printer Queue
    – Services (running webservers, etc)
    – CD-Ripping
    – File operations
    – etc.

    – Administration
    – Drives
    – Printers
    – Network Locations
    – Help
    – About
    – Reboot
    – Sleep
    – Shutdown

    [Search Entry]
    – Deskbar should be the 4th menu

    Each menu fills the entire screen. Let get rid op applications window’s while we are at it.
    We hate them. (why else are we all into tabs nowayadays?)

    And integrate all these apps (places, locations, whatever) in a breadcrumbs single-window mode ‘browser’. So if i’m looking at all the albums in my music, it should look like this:

    MyUserName -> Music -> Albums

    If i’m editing my screen resolution I would be at:

    MyUserName -> Choices -> Screen Resolution

    If i’m using synaptic I would be at:

    System -> Administration -> Synaptic Package Management

    No windows (except for modal ones)
    No task-bar

    If I want to have two ‘places’ visible at the same time I’ll use two desktops.
    And integrate menu’s and toolbars. One bar maximum. At the bottom please.
    The top panel contains menu, search bar and other applets. No tray icons. (they are in tasks!)

    No save option, (just auto-versioning of documents and automatic saving, etc.)
    No running or not running applications. Everything should feel ‘persistent’.

    Just my two cents. We are so stuck in this applications and file -methodology. Its tunnel-vision.
    Both are useless abstractions that only deal with the user having to manually manage resources.

  26. Dean Says:

    Svenn: The ruffle plugin for Muine currently does exactly that.

  27. Jon Says:

    I think mpd does a lot of the stuff at the moment, however it does not use gstreamer as a backend and does not plan to in the future. Because of this I think it would be a good idea to create a new music daemon with a DBUS interface and some C and python bindings which handles the playback of music and the meta-data management. This shouldnt be too hard, I already have done this in python for my uni project although its pretty buggy at the moment.

    It should also integrate with beagle and tracker as you mentioned, preferably tracker as there is some other cool stuff going on with that elsewhere on the desktop such as nautilus integration.

  28. David Says:

    The place where Quod Libet really shines is regarding #1. I really like the fact that you are in full control of your metadata, and it allows you to use a rich metadata set, including multiple artists, genres, etc. A metadata index needs to handle this, and most players need fixing too.

  29. joe Says:

    1.Had such thouchts too what about letting e.g. rythmbox index the library as before but populate the data direct to tracker or beagle.
    This would solve the usb-stick problem. So it would be a forced indexing.

    An other idea is to populate also playlists. These could be special
    playlists with some inteligence e.g. a shuffle algorithm or based on
    gnonlin to combine say music with pictures or video. This would lead
    to a combination of some more App and to get a better Mediasystem as
    so called iApps.

    An Example youe have a set of Photos and videos and plan to create some
    sort of a slideshow. The Photo-app could look for some playlists through the tracker. The Pics are arranged and underlayed by some Musicplalist. This will be combined to a slideshow playlist. and is marked as film so the photo-app or the gstreamer based Video-player can find that playlist through tracker an play it. But its no rendered Video which will be done by an other up.

    Just some thoughts

  30. Evan Says:

    Where are you when I need you?

    Death to iTunes!

  31. qhartman Says:

    Great post. I’d love to see this get done.
    I have been thinking a lot about sucbjects related to your points on intelligent random. I use random almost exclusively when listening to music while working or reading, and have often wished for a more intelligent random mode. My two big wishes are:

    1- Exclusive random – Plays back a random track, which will not be replayed until all other tracks in the queue (be it the entire library, a specific playlist, whathaveyou) have played, and is persistent across sessions. IE – When I sit down at work tomorrow and start listening, it picks up where it left off, and I won’t hear any songs I heard yesterday, unless I run through the play queue entirely.

    2- More effective “favorites” and “not heard recently, but I like it” random – Something along the lines of the “smart playlists” that some players use. The biggest problem with this method is that the rating system that most players use is broken to the point of uselessness. Either people don’t rate their songs, or if they are rated at all they all have 5 stars. So, this implies a better rating system is needed. Why couldn’t a system create rating scores based on behavior? I’ve put quite a bit of (informal) thought into how a system like this could work, and believe I have the beginnings of what could become a method to weigh different user actions and relate them to the “liking” of a particular track. If it’s interesting to you, drop me a line, seeing as how I’m supposed to be doing “real” work right now, I don’t have time to go into it…

  32. FelipeC Says:

    Great post. I think implementing your ideas would be really great for the Linux desktop.

    IMHO everything should be just like Telepathy, all those services available as interfaces. So different UI’s can use different implementations of the services. So for example an IM application can query the current playing song trough a certain interface, it doesn’t matter which application or daemon implements it.

    What I would like to see is a way select a couple files from Nautilus and either play or queue them in Rhythmbox or whatever, without necessarily adding them to the db.

    Also an application that can semi-automatically tag my music, probably from, musicbrainz, freedb or whatever.

    Of course, the really important thing is what actually gets done.

  33. jonathan Says:

    I think it would be a good idea to examine some of the underlying assumptions that you seem to be basing your ideas on.

    Monolithic applications are bad? Splitting them up and using IPC between components is better and will fix “sluggishness”? Integrating everything into the desktop (whatever that means) will improve user experience?

    I’m not saying any of these are necessarily false, but it’d be a good idea to think about it before you go and complicate matters like you’re proposing to here.

  34. […] Improving music playback in GNOME (1/2) As a college student studying engineering and music performance, and as a loonix geek, I’ve spent far too much time […] […]

  35. Jonathan Michaels Says:

    The biggest problem I’ve encountered is a way to split out a subset of my music collection from a central media share. I have a shared USB drive with 5300 flac files totaling 100 gbs. That will triple over the next little while as I continue to FLACify my physical CD collection.

    Issue 1: I cannot store 100 or 300 GBs of files on my laptop. I want only a subset of the entire collection for non-networked playback, anything added in the last X weeks plus all 4 and 5 star rated songs.

    Rules and ratings should be user-defined, as my 9 year old girl and I have different yardsticks for determining what a 5 star song sounds like.

    Issue 2: While in range of my home network I use Avahi to connect to the collection but I currently see duplicates of all songs that are both on the music share and my local computer.

    Issue 3: Synchronization.

    Ideally, synchronization would first update ratings and changed metadata from my local copy to my music share. It would upload any new music on my local machine that I’ve downloaded or burned from CD to the music share, remove low-rated music from my local system and download highly-rated music.

    Feel free to write to me if any of the sounds interesting. I’d be happy to provide details and use-cases.


  36. I am an avid user of MPD, and I feel that its independence of gstreamer is one of its strengths.
    My #1 problem with Rhythmbox as the “ultimate” player for the Linux desktop is the fact that it cannot play one single file without adding it to the library. Imagine user John Doe having one small file downloaded from the net, and he tries to fire up Rhythmbox to play the file just as he is used to with Winamp. Instead of playing the file, Rhythmbox greets him with the “configuration guide”, telling him to create a database etc. etc. etc.
    There should be a way to override the music library for such files, which do not make sense to add to a library.

  37. Just to add my 0.02€ to the idea-pool:
    The one big thing that I miss in the current Gnome/Linux music-players is tagging. Meta-tags allow to specify which the genre of a track is, but some tracks need multiple genre’s. An example: I have many different kinds of music in my library. Rock, classic, folk, etc. When I put some music on, I like music that fits my mood. If I’m relaxing, I like calm music, if I’m studying I prefer instumental music, etc. Unfortunately genres don’t fit these moods 100%. Each moods should have a mix of different tracks in different genres.

    One way to do this is to create a playlist for each mood, and add each song to the corresponding playlists. One problem is that this would take a lot of work, another is that these lists are not browsable like a genre is in i.e. Rhythmbox.

    The nice way to do this would be to allow multiple mood: tags to be added to songs automatically using, and make these tags browseable. (Looking for a calm album? Go to calm, check out the album list, and pick one.)

  38. Dafydd Harries Says:

    Interesting, as a Telepathy developer, to see people thinking about applying some of the approaches we’ve used to other problems. Some specific thoughts:

    “Sit (in the panel?) and respond to control and information requests over dbus.”

    To my mind, a panel applet would be a separate component using the music queue/play service.

    “Not need to know anything about music libraries”

    Absolutely right, this is not a UI concern. It’s a matter of the background play service providing a good API for searching music.

    I think many of the benefits that apply to Telepathy apply here too: splitting stuff into UI/D-Bus services wins you desktop/license/language independence, which I believe all lead to better code reuse. It frees UI developers to worry about how the UI works as opposed to the underlying mechanism of how music is indexed/searched/played.

    I think the real distinguishing feature of this approach, though, is improved availability of information/control. E.g. it’s trivial for your IM program to know which track you’re currently playing because there is a standard D-Bus interface for it. Likewise for when your phone app wants to pause your music when there’s an incoming call (the Nokia 770/N800 use exactly this approach to this problem).

  39. sebas Says:

    It would be interesting to have a closer look to Amarok, it seems to provide the stuff you’re looking for. It has Metadata indexing, smart playlists (for example by using’s AudioScrobbler database) and integrates well into the desktop.
    The only thing from your ‘wishlist’ that Amarok does not yet have is: Using the desktop search infrastructure for metadata indexing, but I suppose that’s going to come in Amarok 2 which will base on the KDE4 infrastructure and thus will have pervasive indexing available.
    Another thing someone mentioned in the comments is muting or dimming the music player when a VoIP call (or something similar) needs the attention of the user, that is actually being implemented by Phonon, the KDE4 audio backend.

    Nice post, by the way, I enjoyed reading it.

  40. David Says:

    Jens, you say that you want to mark your tracks to belong to more than one genre. There is absolutely nothing that prevents you from doing that, other than using limited software. I assign multiple genre to my oggs and mp3 without and problem at all.

    I also assign multiple performers and sometimes artists. As I said in an earlier comment, a system that limits this in a fundamental way is seriously broken.

  41. David, I guess I’ll have to look into Quod Libet, thanks. The reason I wrote that comment was to have this kind of rich metadata in all Gnome music players as I think this would ‘improve music playback in Gnome’. 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: