Music Player Daemon Community Wiki


522pages on
this wiki
Add New Page
Talk12 Share

Introduction Edit

Some people at the MPD IRC channel have been talking about if and how album cover support should be in MPD. For now, there are only ideas, described below. Join us and tell what you think of everything.

Fetching Edit

This hasn't been discussed a lot. Currently, we're thinking of using the Amazon service for getting the covers, like other programs do, but some users seem to have loads of vinyl rips, and they need perhaps a way to fetch covers trough the Discogs Database/API.

I don't think mpd should do the fetching -- you never know whether the machine running mpd has internet connection, besides it needs a graphical display to check if it's the right cover. Instead why not use an external program like [Cover Art Downloader] or better yet program a specific mpd client that uses the mpd database and fetches the covers, allows a selection and stores them on the server ?

MPD is not the kind of program that should handle album art. It is a music player daemon: it runs in the background, without a gui, and plays music. Besides, clients can handle the album art. And for those who want all the bells and whistles: Rhythmbox ans Amarok are at your service. MPD is not a desktop music player.

Personally, I think album art would be a great addition to the MPD protocol, and definitely something that fits MPD's purpose. It is not MPD's job fetch the album art, or to offer features to manage album art though. In my view, album art falls in exactly the same category as ID3 tags: If they're there, the MPD protocol allows clients to display the information contained therein. If they're absent, tough luck, you'll have to find a way to add them using something other than MPD. Jeroen94704 13:44, February 24, 2010 (UTC)

I agree with you here. I've stored an album cover art in each album folder because almost every music player expect them there. MPD definitely should do the same and provide the cover art to connected clients. 07:01, July 20, 2010 (UTC)
My thoughts exactly. MPD should not fetch or store albumart, other programs are much better suited for that. But MPD does (and should) provide all kinds of info on the music it is playing. An albumart-tag is part of that information and if the audio-file is not accessible to the client the only way for it to retrieve that information is through MPD. Why include additional text info such as comments and exclude graphical information such as albumart? (Coon, Nov 18 2010).
I also agree with you. Just reaching the information from the id3-tag and/or albumart.jpg to the clients, if they ask for it. I thought about encoding the id3-tag via base64 or so to meet utf-8 or ascii transfer (as an implementation detail). 22:19, January 28, 2011 (UTC)

Storing Edit

We want to use a clear and standard method of storage, so we won't reinvent the wheel and also others programs could use our covers. But currently, these methods have been presented:

  • Using mp3v2 and mp4 metadata.
    • Advantage: easy to maintain, many editors allow to modify the metadata.
    • Disadvantage: not available for all formats supported by mpd.
    • Disadvantage: people won't expect a music player to change their music files without user interaction.
    • Disadvantage: Covers have to be stored repeatedly, not just once per album.
  • Using the standard of desktop icons.
    • Advantage: a lot of other programs, including cover downloaders and music players, already use it.
    • Disadvantage: some people don't have write access for their music library. Also, this format requires that you have each album in a separate directory.
  • Using a database file, like Muine does.
    • Advantage: single organized file and no headaches about writing and retrieving the covers.
    • Disadvantage: no other programs (or even the users) would be capable of viewing or changing the database.
      • Has SQLite not been considered for this? It negates the above disadvantage by being quite accessible.
  • Using a directory for storing the covers image files and an index mapping each file to an album.
    • Advantage: anybody can view the database and the storing is human-readable and simple.
    • Disadvantage: no other programs would understand this format.
  • Store the cover images in the associated album folder where the music is. MPD would check for the existence of a cover image within an album folder looking for a pre-defined filename (ie front_cover.jpg|png|bmp etc).
    • Advantage: Simple human and computer readable solution.
    • Advantage: All data pertaining to an album would be encapsulated in one folder.
    • Advantage: Cover arts easily can be changed by users.
    • Advantage: Other music applications can easily access and add cover images.
    • Disadvantage: Only works when albums are in folders.
  • Store the cover images using the method described in the Thumbnail Management specification, possibly modified slightly.
    • Only one or two changes should be necessary; first, create a "fullsize" folder, and secondly (possibly) create a separate folder, to store album cover art separately from "standard" thumbnails (eg: ".covers", instead of ".thumbnails"). This could even be done in a manner that permits the user to change cover art independently of the server (by checking first the server store, then the user's home for a ".covers" directory).
    • Advantage: Widely used by existing applications.
    • Advantage: filesystem exposure is relatively flat, with thumbnails stored in a shallow folder structure.
    • Advantage: with the above modification, the user can change cover art, without affecting the server store.
    • Disadvantage: not trivially human-readable. Thumbnails are easily viewable, but it is not trivial to identify which thumbnail matches which item, except by sight. Of course, this could be fixed by using a standardized album name, rather than a hash value for the stored thumbnail, but that might have other consequences.

Sending to the Client Edit

After fetching and storing the covers, the MPD clients should be able to get the cover from the server. Currently, the following changes are proposed:

  • The song's metadata would have a new field, saying if there's a cover avaiable for that song or not.
  • If true, the client would be able to get the cover using a command, like "get_cover". The response would include the mime-type and the image encoded as base64.

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.