[Playlist] question about the XSPF specs

Tue Nov 24 23:42:18 UTC 2020

Hey what’s up

Obter o Outlook para iOS<https://aka.ms/o0ukef>
________________________________
De: Playlist <playlist-bounces at xiph.org> em nome de Lucas Gonze <lucas at gonze.com>
Enviado: Tuesday, November 24, 2020 7:12:23 PM
Para: Benoît Gréant <gordie.lachance at gmail.com>
Cc: playlist at xiph.org <playlist at xiph.org>
Assunto: Re: [Playlist] question about the XSPF specs

Sorry to be slow. I am thinking about the place of the open web, open standards, and openness in music, as a prerequisite to thinking of what I want to achieve with open playlists.

On Tue, Oct 20, 2020 at 2:54 AM Benoît Gréant <gordie.lachance at gmail.com<mailto:gordie.lachance at gmail.com>> wrote:
So, what do you think of it ? :)

+, I still would like to know how to add "regular" links (not audio sources, not identifiers) to an XSPF track with the current specs.

4.1.1.2.14.1.1.1.11 link
The link element allows XSPF to be extended without the use of XML namespaces. xspf:track elements MAY contain zero or more link elements.
<link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link>

Let's say I have this link

<a href="https://fr.wikipedia.org/wiki/Karma_Police">Karma Police on Wikipedia</a>

How should I convert this to an XSPF track link ?

Well, that page doesn't have a duration, so it can't be a location. But I wonder whether it can be an identifier.

4.1.1.2.14.1.1.1.2 identifier

Canonical ID for this resource. Likely to be a hash or other location-independent name, such as a MusicBrainz identifier. MUST be a legal URI. xspf:track elements MAY contain zero or more identifier elements.

How come you feel that wouldn't be a good fit?

Thanks !!

Benoît

Le dim. 18 oct. 2020 à 21:04, Benoît Gréant <gordie.lachance at gmail.com<mailto:gordie.lachance at gmail.com>> a écrit :
Lucas,

Here's some of my thoughts.  Most of them are related to the new way people do listen to music : often from Spotify, or on some other services, where the playlists are constantly updated and don't have audio files but stream links.

Stream sources
There is something to do about the location and the links attribute.
A track could have some locations (audio files) and links (eg. wikipedia entry), but where should I put stream sources (links to spotify, youtube, apple music, ...) ?
It looks like they don't fit any category.  + sometimes, a stream source is available in one country but not in another.
Maybe we would need a new attribute here for those stream sources.
Also, it would be great to be able to set not only URLs for them (files/links/streams), but a title.
It's a bit weird to display some URLs without knowing what will be opened behind.
I could have a script that would request every URL to get a title, but well, that would be a lot of requests for a playlist.
So maybe all those attributes (location/link/stream) could have both an URL and a title. And why not even more...

Total tracks
When I fetch a playlist (eg. Spotify API), i will get X tracks back, depending of their API. Spotify has a 100 tracks limit.
But they do return the number of total tracks.
So we could have an XSPF playlist that contains 100 tracks but  knowing that there is more to load.

4.1.1.2.8 date
Creation date (not last-modified date) of the playlist, formatted as a XML schema dateTime. xspf:playlist elements MAY contain exactly one.

The current attribute is for the creation date, but it would be useful to have an updated date.  Most playlists now, on Spotify or such, are constantly updated.  It would be nice to have their creation time but also their last modified time.

In the same idea, I would personally like to have an attribute for expiration date (time).
Why ? My app (for instance) currently loads XSPF playlists and do refresh them every X time.
A playlist generated from a radio station would refresh after 5 minutes because it contains only 5 tracks.
But a curated playlist on Spotify would be refreshed every, let's say, 1 day; depending on its activity.
It would be cool to be able to set an expiry time.

That's all I see for now, what do you think of it ?

Thanks for your interest.

Benoît

Le ven. 18 sept. 2020 à 01:51, Benoît Gréant <gordie.lachance at gmail.com<mailto:gordie.lachance at gmail.com>> a écrit :
Hi Lucas,
First, thanks a lot for your kind reply and interest.
Maybe the best would be that I take some time to compile all my questions.
I don't really know how I can help, except by giving some feedback.  Just thought that it would be nice to update the standard since the music industry changed a lot those years with the streaming industry.
A chat would be easier for me since i'm quite OK to write english but it's more difficult for me to speak :)

Thanks !

Benoît

Le ven. 18 sept. 2020 à 00:50, Lucas Gonze <lucas at gonze.com<mailto:lucas at gonze.com>> a écrit :
Benoît, how can I help you out with this? Would a real time chat or zoom be helpful?

If so, is anybody else interested in participating?

On Mon, Sep 14, 2020 at 2:22 PM Lucas Gonze <lucas at gonze.com<mailto:lucas at gonze.com>> wrote:
I agree. It would be a productive project, and probably not too hard.

On Benoit's ideas about how to do what he's thinking about, I wonder if other people think that it would be wise to have a track with multiple location elements, each pointing to a different streaming service. That would function similarly to the sources idea:

"sources": [
'https://open.spotify.com/track/3FgDF8tNn6aqB7ycygy7ch',
'https://www.youtube.com/watch?v=PA3P1-aSvKQ',
'https://www.youtube.com/watch?v=vUes9-tFWm4',
]

Then, Benoit brought up the issue of having different metadata for each track.location or track.sources[i], like this:

>>
     "meta"          : [
       {'wpsstmapi/input_url'=> 'myvalue1'},
       {'wpsstmapi/xspf_url'=> 'myvalue2'},
       {'wpsstmapi/importer_slug'=> 'myvalue3'},
     ],
In the specs, the keys are urls like http://example.com/rel/1/. Should this point to an URL that exists or can I use what I want ?
<<

The URL does not have to exist. This is legal, even though there is not actually any domain at example.org<http://example.org>:

<track><meta rel="http://example.org/meta/track/vendornick">Spotify</meta></track>

Over the years I have softened up quite a lot towards namespaces, and don't think something like this would be a bad thing:

<track><location ns:vendornick="Spotify">https://open.spotify.com/track/3FgDF8tNn6aqB7ycygy7ch</location></track>

On Mon, Sep 14, 2020 at 2:01 PM Martin McEvoy <martin at weborganics.co.uk<mailto:martin at weborganics.co.uk>> wrote:
+1 from me on a JSON version.

On Tue, 24 Mar 2020, 17:13 Lucas Gonze, <lucas at gonze.com<mailto:lucas at gonze.com>> wrote:
Benoît, it's excellent to meet you. I am CC'ing the XSPF list at playlist at xiph.org<mailto:playlist at xiph.org> and copying this answer to the Stack Overflow thread.

The info element is designed to do what you need:
http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.6

However, there can only be one info element per track.

Regarding the many years since the last update of the spec, maybe it's time to do one. A blessed JSON version would be useful.

-Lucas

On Tue, Mar 24, 2020 at 1:38 AM Benoît Gréant <gordie.lachance at gmail.com<mailto:gordie.lachance at gmail.com>> wrote:
Hi guys !

I love your XSPF thing :)
Have been playing with it since several years, using it as base for my website (&API<https://www.spiff-radio.org/wordpress-soundsystem-plugin/soundsystem-api/>, &WP plugin) spiff-radio.org<http://spiff-radio.org>.

I have a small question.  I want to attach (several) links to a playlist track (eg. spotify/youtuble/apple music...); what tag should I use for this ?

Well, I posted the complete question on Stackoverflow<https://stackoverflow.com/questions/60822682/xspf-xml-playlist-specifications-how-should-i-format-links-to-one-or-several>.

Thanks for your help.

Benoît
_______________________________________________
Playlist mailing list
Playlist at xiph.org<mailto:Playlist at xiph.org>
http://lists.xiph.org/mailman/listinfo/playlist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/playlist/attachments/20201124/2a3e1f3f/attachment-0001.html>