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):

https://gitlab.com/universal-playlist/pls2upl/