Open 0xNF opened 2 weeks ago
There seems to be a lesser known but standard IDv3 UFID tag taking the form of ufid:$source $id
, for example
ufid:http://musicbrainz.org 126cc184-b2a6-4743-803b-0953c85f7b0f
Maybe ufid:spotify.com
would be a better tag to use.
The tag is defined as such:
4.1. Unique file identifier
This frame's purpose is to be able to identify the audio file in a
database, that may provide more information relevant to the content.
Since standardisation of such a database is beyond this document, all
UFID frames begin with an 'owner identifier' field. It is a null-
terminated string with a URL [URL] containing an email address, or a
link to a location where an email address can be found, that belongs
to the organisation responsible for this specific database
implementation. Questions regarding the database should be sent to
the indicated email address. The URL should not be used for the
actual database queries. The string
"http://www.id3.org/dummy/ufid.html" should be used for tests. The
'Owner identifier' must be non-empty (more than just a termination).
The 'Owner identifier' is then followed by the actual identifier,
which may be up to 64 bytes. There may be more than one "UFID" frame
in a tag, but only one with the same 'Owner identifier'.
<Header for 'Unique file identifier', ID: "UFID">
Owner identifier <text string> $00
Identifier <up to 64 bytes binary data>
I think I'd have preferred the key to not be a URL, but since its defined as being one, possible key values could be:
Spotify.com sounds reasonable.
See also: https://developer.spotify.com/documentation/web-api/concepts/spotify-uris-ids
This field is formatted like such:
spotify:track:6rqhFgbbKwnb9MLmUQDhG6
It would be nice to have this as a tag in the downloaded audio files. This would enable extra utility like faster scanning for already-downloaded files without wasting API calls, allow users to do better lookups back into Spotify with other API-enabled tools, and just be better, more complete record keeping.
I've experimented with adding this in using the IDv3 Extended Tag WOAS ("SourceURL"), and the custom ogg tag "SOURCEURL", and it works nice in my own fork, but I'd like to hear others' input.