XMMS2 vs MPD
From an MPD (Music Player Daemon) user's perspective, XMMS2 does not seem very different. That is true, to a certain extent - both MPD and XMMS2 are daemons that play music files and can be controlled remotely over a network. Read on for more details..
Generally obvious similarities... Both XMMS2 and MPD:
- have a metadata database or library.
- can be controlled remotely over a network, by multiple clients.
When we started to work on XMMS2 we didn't know about MPD. If we had known, maybe XMMS2 might have been developed differently. But when looking at it retrospectively, we have adopted fairly different programming philosophies. While the user experience might generally be the same, the programming and internals are very different. If you are not interested in the internals, skip this section.
- both MPD and XMMS2 have a sophisticated notification system where updates are sent to all clients that subscribe to those notifications.
- MPD clients are given the choice between communicating directly with the daemon using the plaintext MPD protocol, or using one of several client libraries available in various languages.
- XMMS2 has a single well-tested and very well implemented clientlib that supports all the features. This clientlib is also available wrapped in Python, Ruby, Java and C++.
- MPD uses their own database format to store metadata.
- XMMS2 uses SQLite which gives a very flexible medialib accessible via fairly standard SQL queries.
Note that XMMS team has had discussions with the MPD author and we all agreed that goals for MPD2 are very similar to those of XMMS2. A collaboration might be possible in the future.
This list taken from the MPD feature list (GFDL)
XMMS2 supports icecast via the ices output plugin.
XMMS2 can currently play MP3, Ogg Vorbis, FLAC, MP4/AAC, Mod, Musepack and wave files as well. Other formats can be supported via appropriate decoder plugins. See also: Media formats
XMMS2 can be controlled via UNIX sockets or TCP sockets. IPv4 sockets are known to work.
XMMS2 can play, for example, MP3 and Ogg Vorbis streams over various transport protocols: HTTP, Samba, as well as a few others accessible via GnomeVFS. More can easily be added by writing another transform plugin.
XMMS2 has not had any stable releases yet, therefore this cannot be easily compared.. The installation procedure is fairly straightforward when working with the source tree, and some binary packages are also available for download for various distributions and platforms.
Stores ID3 (id3v1 and id3v2) tag information (MP3s, FLACs, and AACs); Stores Vorbis Comments information (Oggs and FLACs); Stores apev2 tag information (musepack); Stores MP4 metadata information (MP4/AACs)
Various transform plugins pass metadata to the daemon to be stored in the Medialib when playing files.
All the metadata in the Medialib can be searched using Collections.
MPD can check for new songs in the given 'music directory' after starting up. This is not comparable to XMMS2, as XMMS2 only knows about URLs added to its playlist, not whole directories of music files. This is however something planned for the near future.
XMMS2 supports this.
Works on plugins and files that support gapless playback.
XMMS2 does not support crossfading yet.
Works in XMMS2, as well as any decent music player out there. ;)
XMMS2 can load playlists in the following formats: M3U, PLS, HTML, XML, RSS, XSPF, CUE, ASX. More playlist formats can be supported via appropriate plugins. XMMS2 can also save playlists to the Medialib and reload them.
Works in XMMS2, as well as any decent music player out there. ;)
XMMS2 can output to the following: ALSA, OSS, Disk, Jack, Sun, coreaudio. More output methods can be supported via appropriate plugins.
So far, development of XMMS2 has focused on making sure things work as they're supposed to, and on ensuring a consistent design of the system. There have been no real optimisations to make things run as fast as possible, but that can probably be achieved before a stable release. xmms2d is known to have worked on a Pentium 133MHz machine with 48MB RAM (running Debian Stable).
XMMS2 is known to work on Linux, Mac OS X, various flavours of BSD, Microsoft Windows, and client library support for some mobile devices.
This list taken from Music Player Daemon Version 2 Plans (GFDL)
XMMS2 is written in C.
Not comparable.
XMMS2 uses threads to run the main components: Transport, Decoder, Output. See also: Design of XMMS2
XMMS2 uses plugins to read data, decode it, output sound data, read and write playlists.
Playlists; Allow creation of playlists* on the fly; Allow attaching a playlist to an audio device or stream; Playlist plugins to get different types of playlists
(No idea what 'creation of playlist on the fly' means..) XMMS2 only has a single playlist. XMMS2 can also save playlists to the Medialib and reload them.
By "creation of playlist on the fly", I'm fairly certain that the MPD2 roadmap means creation of playlists from dynamic data. For instance, all songs which haven't yet been played, or all songs with "fnord" in the cached lyrics. Matching on metadata and creation of a playlist, but dynamically, not run-once-and-store-the-output. Whether XMMS2 is planned to have this feature, I don't know - but I do know that many other library-based systems (AmaroK, rhythmbox, iTunes) have it, and that I find it useful. -- michael@slashhome.org
In XMMS2 "creation of playlist on the fly" is supported by Collections.
Queue playlists are described as being "temporary playlists: when you have a playlist in the correct order you might want to play some songs in a special order. So you queue these songs, and the player will play them in that order, and then continue as before." This could be implemented client-side, with XMMS2. The XMMS2 playlist itself is just that - an ordered list of streams to be played, as far as the daemon is concerned. Clients may use the medialib and more sophisticated manipulation of playlist data for a different user experience.
A queue playlist as in a playlist that removes its played entries is supported since Collections. Also there is the so-called jumplist attribute that tells the daemon to start a different playlist on finishing this one. Using these a queue playlist as probably meant above can be constructed.
The Medialib in XMMS2 is not as flexible as the DB planned for MPD2. At the moment, there is only one SQLite database always located at $XDG_CONFIG_HOME/xmms2/medialib.db. It is tightly coupled with Collections and there is currently no modularity, though Collections offer that possibility. Modular backends pose another problem where certain databases may simply implement something that other databases have not, which poses significant added complexity to the client developer, who is no longer guaranteed that a certain collection operator exists and is usable. Collection plugins, for example, to support TopicMap (XTM) metadata storage may be possible, but will require a fair bit of work, and no one on the XMMS2 development team is sufficiently interested at this point.
See Design of XMMS2
learning of playlists: whenever a song is played in full length it is rated up, when it is skipped it is rated down. Highly rated songs should be played more often in shuffle mode.
XMMS2 keeps track of the number of times a song is played, but does not currently use this in partyshuffle mode (although it is possible to filter on it.).
XMMS2 does this, and adds the files' metadata to the Medialib.
XMMS2 can play Audio CDs via the cdda decoder plugin.
Add support for audioscrobbler's feature "Recommendation" - appends songs that are similar to the one playing at the moment
This can be implemented client-side. See XMMS2-Scrobbler or the Last.FM view in Esperanza
Content is available under GNU Free Documentation License 1.2 unless otherwise noted.
- Community
- Development