[Playlist] Mission questions

Pushtape pushtape at gmail.com
Tue Dec 1 02:58:13 UTC 2020

I think interoperability has two use cases: commercial and noncommercial.
The noncommercial use case is easy to argue: libraries, startups, and
research institutions all benefit from greater interoperability of data.

For the music industry either you have large players with huge music silos,
or smaller players curating more exclusive silos, but the goal is the same
-- to control and monetize access to the music. Interoperability does not
usually make sense here, since the goal is vertical integration. This is
nothing new.  Musicians and listeners using these platforms must accept
non-negotiable terms and conditions or find some (less popular)
alternative.  Yes, someone is certainly getting paid, but it isn't the
musicians. Decentralized currencies and blockchains could change things
dramatically, in which case openness might mean musicians getting paid
directly and thus drive a greater need for interoperability, but that
remains to be seen. And for that to happen, musicians would likely need to
form some kind of cooperative alliance or union.

Should non-siloed music should exist? I don't know if that's the right
question to ask. By default all music starts off as non-siloed, right?
Tragically a lot of music is lost forever, either because it is never
documented or never becomes part of a catalog. In my opinion, this is
enough of a reason to continue to push for openness and interoperability
even if large commercial players wish to stand in the way. A better
question might be, does interoperability help with the world-historical
project of documenting and preserving music for future generations?

On Mon, Nov 30, 2020 at 7:40 PM Rob Lord <rob at roblord.org> wrote:

> Serializing playlist, track, et al. music-related metadata is an essential
> tech to an open music value chain.
> The long, er, open question remains, “what would reify a stakeholders’
> mutually accretive open value chain and platform for music, how does it
> compare to the silo value chain(s), and how does its tech compare to silo
> platform(s)?Yeah?
> Seems like all active open music heads, that is both Lucas and Robert,
> might publish an “indie web”-esque (sub-section?) doc to centralize current
> best ideas and implementations of the manifold options. Is there such a
> root doc I am unaware of?
> https://indieweb.org
> FWIW, open or closed, if a sol’n is succeeding and innovating slower than
> the average velocity of its competitors and substitutes, it will
> necessarily lag and fail. I dunno what “techlash” means, but the fail of
> open isn’t that proprietary  is inherently better, only that open is
> currently worse.
> You guys know Jason Wohlstadter of Proton? He’s successfully worked
> closely with both Apple and Spotify to add creator attribution and
> compensation to mixes and mixes to their silo services.
> https://link.medium.com/rTEN3wOJQbb
> Bonus:
> https://twitter.com/chrisalbon/status/1332459255371218944?s=21
> Rob
> On Mon, Nov 30, 2020 at 3:44 PM Lucas Gonze <lucas at gonze.com> wrote:
>> MP3 is a great approach to interoperability, but punting access to
>> Funkwhale means giving in to silos like Spotify and Apple Music. There
>> needs to be some open strategy to provide for files in cooperation with
>> musicians and rights holders. If openness means not getting paid, they'll
>> continue to stand in the way of interoperability.
>> On Sun, Nov 29, 2020 at 4:56 AM Robert Kaye <rob at metabrainz.org> wrote:
>>> On Sat, Nov 28, 2020 at 10:30 am, Lucas Gonze <lucas at gonze.com> wrote:
>>> After long consideration, I believe the question that matters is the
>>> existence of non-siloed music. Should it exist? Why?
>>> Yes, they should.
>>> As you said, techlash is one aspect and the other is that music tools
>>> are finally being worked on again. MusicBrainz Picard is seeing an uptick
>>> of activity, we recently discovered and are embracing Funkwhale (federated,
>>> self hosted music collections with streaming) and I've started paying
>>> attention again to my own music collection. I'm growing disenchanted with
>>> Spotify -- tracks appear, I fall in love with them and then they disappear
>>> without notice. Large chunks of what I love are not there and the utter and
>>> complete lack of interoperability, is the ultimate lock-in. I'm starting to
>>> get fed up.
>>> With the ListenBrainz project we've been working flat out on building
>>> the a recommendation engine toolkit. Track similarity, collaborative
>>> filtering, super easy to use toolkits with the heavy lifting already done
>>> -- we're hoping to kick-start open source music recommendations. We're
>>> starting to produce results that are quite listenable, after only 5 years
>>> of working hard. ;)
>>> And to deliver generated playlists, we needed to add playlist
>>> capabilities to ListenBrainz. Last weekend we had an online hack-day where
>>> we had 5 people work through the weekend to add collaborative playlist
>>> support to LB. We'll deploy this before year end and then we'll start
>>> generating playlists (similar to discovery weekly and daily mixes) for
>>> users who scobble their listens to ListenBrainz (if you scrobble to us or
>>> import your last.fm history, the next monday we'll have some
>>> recommendations for you) We're working hard to become an open source mix of
>>> the Echo Nest and Last.fm and we're making great strides finally.
>>> We realized we need a transport layer playlist format and we quickly
>>> agreed to use JSPF for this! We're using it as an exchange format and as
>>> our internal format as well --
>>> we've defined two extensions for JSPF for our internal fields. I'll post
>>> a request for feedback in the coming days, to make sure we're on the right
>>> track.
>>> Given techlash, what is the point of interoperability?
>>> We've also been working on our mapping game and making it super easy to
>>> take an artist name and a recording name and to find a suitable release in
>>> MusicBrainz. Have a look at our latest iteration on what will soon be the
>>> MusicBrainz ID mapping tool:
>>>   https://datasets.listenbrainz.org/acrm-search?query=sun+shines+tv
>>> For some tracks you don't need a lot of metadata to get the right
>>> release, for others you need to give more. The text -> MBID mapping is our
>>> first effort and MBID -> Spotify mapping will be the next. These mappings
>>> will prove to be important for getting out recommendation work exposed in
>>> tools like Funkwhale, which is sorely lacking recommendations and
>>> intelligent playlists.
>>> I think sometime in 2021 we'll see a point where open source tools for
>>> federated music networks will reach some level of parity with the likes of
>>> Spotify.
>>> Unsurprisingly, we hope that MBIDs will be the point of interoperability.
>>> -- --ruaok Robert Kaye -- rob at metabrainz.org -- http://metabrainz.org
>>> _______________________________________________
>> Playlist mailing list
>> Playlist at xiph.org
>> http://lists.xiph.org/mailman/listinfo/playlist
> _______________________________________________
> 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/20201130/a2e3a6e1/attachment-0001.html>

More information about the Playlist mailing list