[Playlist] question about the XSPF specs

[Benoît Gréant]

Hi,
Yes, I know (knew) Tomahawks, I was a huge fan.
At the beginning, Spiff was just a "backend" project made to feed Tomahawk
with XSPF playlists...

Thanks!

Le lun. 30 mars 2020 à 02:34, Pushtape <pushtape at gmail.com> a écrit :

> Hi Benoît, your idea reminds me a bit of the Tomahawk Player from a few
> years back...sadly it looks like the project stalled. I recall the program
> could parse XSPF, but not sure exactly how their multi-source resolver
> worked. But perhaps worth examining their code and approach if you haven't
> already.
>
> https://en.wikipedia.org/wiki/Tomahawk_(software)
> https://github.com/tomahawk-player/tomahawk
>
> On Sun, Mar 29, 2020 at 4:45 PM Lucas Gonze <lucas at gonze.com> wrote:
>
>> I appreciate where you are going with this. Godspeed.
>>
>> You are correct that an identifier is not necessarily playable, but this
>> doesn't disqualify playability. That flows from a subtle point of XSPF's
>> design. It is fundamentally a query language enabling user agents to get
>> something played that matches the user's expectations. The user agent is
>> free to resolve a YouTube link with a Spotify track and vice versa, but it
>> is certainly welcome to play a Spotify link within Spotify.
>>
>> On Thu, Mar 26, 2020 at 1:54 AM Benoît Gréant <gordie.lachance at gmail.com>
>> wrote:
>>
>>> If I understand correctly, that's exactly what i'm working on:
>>> I want to attach several music services links to a track; hoping that
>>> maybe the user can (because he's subscribed or something) play at least one.
>>> That's why I think this is not the same than a file location (which is a
>>> file everybody can play) or an identifier (which is not especially
>>> playable, like musicbrainz)
>>>
>>> B
>>>
>>> Le mer. 25 mars 2020 à 23:48, Lucas Gonze <lucas at gonze.com> a écrit :
>>>
>>>> Speaking of user agents, as always the issue is that music nowadays is
>>>> tightly held in deliberately non-interoperable pools. Is there hope for
>>>> loosening that grip?
>>>>
>>>> On Tue, Mar 24, 2020 at 10:26 AM Lucas Gonze <lucas at gonze.com> wrote:
>>>>
>>>>> You could put a YouTube link in the location element, or have multiple
>>>>> identifier elements, each one with a different YouTube link.
>>>>>
>>>>> The important thing is for user agents to support the convention.
>>>>> You'd want to put a little work into adoption in things like VLC.
>>>>>
>>>>> -Lucas
>>>>>
>>>>> On Tue, Mar 24, 2020 at 10:19 AM Benoît Gréant <
>>>>> gordie.lachance at gmail.com> wrote:
>>>>>
>>>>>> Hi and thanks for your kind reply.
>>>>>>
>>>>>> I understand why the identifier can work for a spotify track, but is
>>>>>> it relevant for a youtube link too ?
>>>>>> I mean, there might be several different Youtube videos for a same
>>>>>> track.  Which, then, is no more an ID, is it ?
>>>>>>
>>>>>> Thanks !
>>>>>>
>>>>>> B
>>>>>>
>>>>>> Le mar. 24 mars 2020 à 18:17, Lucas Gonze <lucas at gonze.com> a écrit :
>>>>>>
>>>>>>> After reading your more detailed issue description on Stack
>>>>>>> Overflow, I have posted this answer there.
>>>>>>>
>>>>>>> You should use the identifier element (
>>>>>>> http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.2) for
>>>>>>> things like Spotify links.
>>>>>>>
>>>>>>> The info element can also do what you need (
>>>>>>> http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.6), but
>>>>>>> you can only have one per track, so you couldn't cover more than one
>>>>>>> streaming service.
>>>>>>>
>>>>>>> Regarding the many years since the last update of the spec, maybe
>>>>>>> it's time to work on one. A blessed JSON version would be useful.
>>>>>>>
>>>>>>> It's productive to discover that the spec is not clearly
>>>>>>> communicating this information. In the time we wrote the spec most
>>>>>>> functioning Internet music was an MP3 on a web server. Now streaming
>>>>>>> services do the job. We could possibly fix this with an update to the
>>>>>>> documentation. For example, the sample playlists at
>>>>>>> http://xspf.org/quickstart/ could show how to do it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 24, 2020 at 10:05 AM 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.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> 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/20200330/5363c8c9/attachment.html>