Nothing's wrong per se (and it has roughly the same goals as mine), it's just that it's pretty much the XML equivalent of M3U, and doesn't have any provisions for stronger identification (it relies on titles), at least as far as I know.
I would really like the MBID to be the main way of identifying songs throughout the industry, and possibly the AcoustID fingerprint, as that's more specific. I think it would be fantastic if each song had its own UUID that computers could refer to, and this spec tries to incorporate that.
Since I don't really gain anything from reusing its format (most players won't support the strong IDs), I thought I might as well create a new format that was better suited to this task.
XSPF is a format to enable sharing, AKA universality. It does this by defining a list of metadata fields to be used for resolving each track in the local context of the listener.
On a surface level you can use XSPF like any other playlist format. Drop a bunch of filenames into an XSPF document, prepend "file://" to each, and you're ready to go. Under the surface there is much more.
The guiding design principle was to separate the functionality of a catalog of files from the functionality of a list of songs. Most software music players on the PC have some sort of cache for file information. This cache stores a list, or catalog, of available files and metadata from ID3 tags and other sources. XSPF is not a catalog format. XSPF exists only to say which songs to play. Almost everything in XSPF is for the purpose of answering the question which resource, rather than the question what is this resource.
If XSPF is not a catalog format, what is it? XSPF is an intermediate format. We expected a new kind of software called a content resolver to do the job of converting XSPF to a plain old list of files or URIs. A content resolver would be smart enough to keep your playlists from breaking when you move your media from /oggs to /music/ogg. It would be able to figure out that a playlist entry by the artist "Hank Williams" with the title "Your Cheating Heart" could be satisfied by the file /vorbis/hankwilliams/yourcheatingheart.ogg. It might even know how to query the iTunes music store or another online provider to locate and download a missing song.
The content resolver maintains the catalog of your songs in whatever format it prefers. It might use a flatfile, a file in the Berkeley DB format, or a SQL database. It might use only ID3 metadata, but it might also know how to query MusicBrainz or another metadata service.
All XSPF user agents are content resolvers, in that they have complete leeway to turn the contents of a track element into a specific set of bytes.
3.5 Fuzzy names
Any given track can be identified in a number of ways. We provided means for absolute identifiers like URIs, 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.
That sounds like a noble goal, but in a "modern" format designed for the same thing, I'd expect the role of the "identification key" for the files to be played by a format-standardized-algorithm audio fingerprint. Audio fingerprints are the only thing you can really expect to be "portable" between music libraries, when people can put arbitrary things in the ID3, and both combined tracks and compilation albums exist. And then, as long as you have such a key, the format doesn't need to consist of much else. It's just a list of keys.
MD5 fails many common use cases and sees differences where there are none. The result will be frequent failures to identify potential matches between different files for the same song.
Ah, yeah if ID3 tags change after the initial md5 ran than it would not be recognized. Good point.
The trade off would seem to be if the audio analysis hash needs to scrape though a huge playlist and it's running on a slow arm processor than it would be impractical and no one would want to use it.
MD5 might not be ideal, but how often do people edit their files after making one of these playlists?
This design assumes a bit of standing infrastructure around it: namely, that you have a "music library manager" program, all your music is in it, and it fingerprints tracks on import and keeps a fingerprint-keyed index.
If that's true, then nothing has to happen on export. You just dump the hashes you already know.
And then, when you try to load someone else's playlist, all you're doing is a bunch of hash-table lookups against the index you already have, to see if you have tracks with matching fingerprints.
(And the initial generation can also be made cheaper, if online music stores also adopt the fingerprint format, such that tracks you buy come with their fingerprints pre-calculated and embedded into the ID3 metadata. Then you can just dump those straight into your index on import.)
Spot on on everything, except the "assumes" part. I'm writing a utility that will convert to/from PLS/UPL without the infrastructure (granted, it will do it on the fly, and it will require some tags to be in the files):
We have enough playlists formats to support already (and most of them are half-baked/half-broken already). There is no good reason to not reuse and extend xspf.
(Last time I counted 16 major playlists formats in VLC...)
Isn't one good reason the fact that you avoid the whole confusion of "I imported my XSPF playlist with all my IDs but my player didn't find any songs!" "Oh, that's because your player only supports XSPF 1, not 1.1"?
There is a version 0 and a version 1. They are identical except for minutiae related to date formats.
In version 0 of XSPF, dates were specified as an ISO 8601 date. In version 1 dates were specified as xsd:dateTime. This is the same thing (with better documentation) for almost every date in history, and as there are no playlist creation dates that might be different, there are no real world playlists that would be incompatible.
https://en.m.wikipedia.org/wiki/XML_Shareable_Playlist_Forma...