6 ms·

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 contex

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. 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 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 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.

derefr 10y ago
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.
- nosuchthing 10y ago
  format-standardized-algorithm audio fingerprint Assuming that's not available on stock Android/iOS/etc a quick hash like md5 should suffice.
  - lucasgonze 10y ago
    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.
    - nosuchthing 10y ago
      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?
      - derefr 10y ago
        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.)

derefr 10y ago

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.

nosuchthing 10y ago
format-standardized-algorithm audio fingerprint Assuming that's not available on stock Android/iOS/etc a quick hash like md5 should suffice.
- lucasgonze 10y ago
  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.
  - nosuchthing 10y ago
    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?
    - derefr 10y ago
      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.)