Amarok/Proposals/FuzzyPlaylist

From KDE Community Wiki
Revision as of 16:56, 12 December 2012 by Mayankmadan (talk | contribs) (Created page with "Category:Amarok Category:Proposals ==Introduction== This page is a place to put ideas for implementing amaroK's "fuzzy playlist". Most playlists use paths to files on ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Introduction

This page is a place to put ideas for implementing amaroK's "fuzzy playlist". Most playlists use paths to files on your computer, as they have done since the beginning of time. However amaroK is much more powerful than XMMS especially in terms of the collection.

Wouldn't it be nice if amaroK could use your collection to load a playlist even when the file path was incorrect? This could be used for repairing playlists after reorganizing your files, or maybe even after mounting your music drive on a different directory. Please put your ideas here on how to bring playlists into the 21st century.

M3U Playlists

The default playlist format for amaroK is extended M3U. A specification can be found here: http://forums.winamp.com/showthread.php?s=dbec47f3a05d10a3a77959f17926d39c&threadid=65772
The extended M3U playlist format contains:
1) The file path (absolute or relative)
2) The song title
3) The song length

If file path cannot be found, the idea is that we query the database for anything matching the title and the length. If we find only one match, we assume it is the right one, and add it to the playlist.

XSPF Playlists

XSPF playlist is a XML-based playlist specification. A specification can be found here: http://www.xspf.org/xspf-v1.html

The XSPF specification has built in support for fuzzy names, from the specification:

Any given track can be identified in a number of ways. We provided means for absolute identifiers like URLs, filesystem paths and secure hashes, but also for query-based identifiers -- free text fields like artist and work title and numeric fields for song length, all of which together should be enough for a good content resolver to turn into files.

Things to think about

  • When we query for a song, do we try to find it with using all the possible data from the playlist?
    • I (Balloob) think we should try first with (if possible) title, artist, album combination and if that doesn't give any results try it with only the title and artist (or maybe make it an option?).
    • We should use all data available to prevent us from accidentally adding a song with the same title, but wrong artist. Also I don't think there should be options as this process should be totally hidden from the user.--Laszlok 17:08, 18 April 2006 (EDT)
  • When we find a song by querying for it, do we use info from both the collection and the playlist?
    • I (Balloob) think that we should get all data from the database and then replace the data where possible with info found in the playlist
  • When we have parsed a playlist do we notify the user if some songs could not be found?
    • I (Balloob) think a notice is indeed needed, maybe in the future we could include support for plugins that provide integration with an online music shop to buy the missing songs.
    • I think we should just have the playlist entry turn grey to show that it can't be found. Also maybe a passive popup on the status bar but nothing too obnoxious --Laszlok 17:08, 18 April 2006 (EDT)
  • When we have parsed a playlist do we update the playlist file on the disk with the locations we found to speed up feature loading?
    • I (Balloob) think that this could be useful but when sharing your playlist there will be a privacy issue: you could give away where the music is stored on your computer which could be an issue for someone. Maybe we should provide an option to clean a playlist from locations.
    • I don't really see a privacy issue. The only problem I see is that some people might complain about amaroK messing up their playlists. Maybe we should only write to disk when the user does right-click->save in the playlist browser? --Laszlok 17:08, 18 April 2006 (EDT)