For example a fingerprint might or might not need to draw these distinctions:
- Clean ("Walmart") and dirty (profanity) mixes of the same recording
- Amount of opening and closing silence (often varies across releases)
- Different masterings
- Fidelity of the source recording (e.g. 64K Real Audio vs uncompressed PCM)
In addition, fingerprint developers are constantly improving on their algorithms.
format-standardized-algorithm audio fingerprint
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?
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.)
The UPF "ids" field maps to the XSPF "identifier" field: http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.2
XSPF is not M3U in any way. From the spec: http://xspf.org/xspf-v1.html#rfc.section.3.4
3.4 Content resolver
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.