[Playlist] question about the XSPF specs

Benoît Gréant gordie.lachance at gmail.com
Sun Oct 18 19:04:24 UTC 2020


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

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


Le ven. 18 sept. 2020 à 01:51, Benoît Gréant <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> 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> 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:
>>> <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>
>>> wrote:
>>>> +1 from me on a JSON version.
>>>> On Tue, 24 Mar 2020, 17:13 Lucas Gonze, <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 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.
>>>>> 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> 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.
>>>>>> 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
>>>>> http://lists.xiph.org/mailman/listinfo/playlist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/playlist/attachments/20201018/3476d5b0/attachment.html>

More information about the Playlist mailing list