Hi Melissa - Thanks!
Building on that here’s a hypothesis, reviewing:
- Where we would like to be
- Where we are now
- Possible roadmap
…each of these from the viewpoint of two different key stakeholders: Music distributed by a label / distributor and new music from direct artists. The ‘roadmap’ piece is a suggested set of iterations of the services we have already (tracks api) and possible new services (metadata api / third party service)
Labels/Distributors and Resonate - Where we would like to be
Resonate is a community streaming platform, not a label or distributor. It needs to scale massively compared to today in order to be considered useful or relevant. There is a distinction between what Resonate as a DSP needs to hold, and what it needs to display. According to the standards, the relationship for a distributor to a DSP is based around the ERN - release notification - to the DSPs and Music Stores who load what they need from it into their many and various streaming and sales platforms. Just like Spotify, Resonate already gets ERN information from distributors like FUGA as a DDEX ERN feed, for example, and stores it. Potentially we will have to add code to the new player to display the rights, according to listener territory.
When / if we process those files it isn’t necessary to copy everything from them and put it in a back-end service - the tracks API - behind the player. We can keep the last file sent to us (or have someone else keep those files for us). We must of course update the data we DO use and display, especially for updates and takedowns. Processing of those files has been manual in the past- that’s clearly unsustainable. The planned bulk uploading work is meant to address that. Kendraio already have good tooling for this so it is still hoped that our association with them will deliver on this.
An artist who comes to us via a label or distributor does NOT want to have to re-key all the metadata already provided to a distributor or to a industry metadata aggregator. They’d want us to get it from them automatically in the IDOL, FUGA feed or similar. They would simply tell the label or distributor to ‘turn on’ their data in the feed sent to us. Having an accurate and reliable key in that data, like an ISRC would be helpful, and indeed essential for later sales reporting.
In the player we should really be displaying ‘p-line’ and ‘c-line’ information according to the territory of the listener so that we respect rights. Spotify and other big streaming services do this, but Bandcamp don’t seem to do it on their sample/promotional plays. There’s another explainer here: What do the P Line and C Line mean in music copyright? - RouteNote Blog
Resonate sales reporting will one day require the creation of standard sales report files based on the standards. We will need a proper reporting service to do this instead of the current spreadsheet. If we need to add further industry metadata to that file we can build a metadat service to merge ERN-sources data with our playstats and income data. Downstream of us, distributors or PRO’s may then use that as input to a separate service (or a third party) on their side to calculate the splits and distribute the royalty payments.
Direct Artists - Where we would like to be
As an artist with new music, I might not be very aware of music industry standards, bodies and ways of working (see Kavan’s primer link above). Resonate has a friendly community of folks who can help educate newcomers, about the metadata they need to maintain as an artist, but as a streaming service Resonate needs to focus on the data it needs to display to listeners and provide later to the indusrtry in sales reporting.
We don’t have the resources or expertise to act as a substitute for a good label or distributor - educating the artist and checking all the data about the artist’s release / track, registering it with the appropriate industry keys (UPN, ISRC) and adding other relevant keys like ISWC and ISNI if available. making sure they are allocated and on the DDEX dataset in the right place.
‘Upstream’ of Resonate, I’d imagine that Kompakt’s process is: 1. to collect metadata from artists and labels in that spreadsheet (with its embedded guidance). 2. use that data as input to create a DDEX ERN file or similar for standardised distribution, using IDOL 3. IDOL distributes to DSP’s, retailers or any industry partner able to accept the standard electronic (XML / flat file) they create. 4. DSPs / retailers import what they need from it into their streaming or sales order processing system.
Resonate might one day seek to operate a co-operative / community label / distribution arrangement, but as far as I know that is a delicate matter - why would we compete with trusted and experienced independent label partners to do that? Far better to introduce the newcomers to those partners via our forum and enlist their help in that?
So our own Resonate ‘direct’ upload tool or ‘dash’ would have three main use cases for direct artists:
- newcomer self-uploading - could be simple and focused on just that which is necessary to showcase the new music as a try-out on the platform - basic minimum release / track information plus any special Resonate-specific tags they might want to add to assist discovery
- fallback route for artists with labels / distributors who can’t get their data to us via an ERN feed, but have the validated metadata and industry keys available and have it themselves or with a label/distributor
- label wanting to update Resonate-specific discovery tags on behalf of their artist
Where we are now: Labels/Distributors and Resonate
Our work with Kendra.io is stalled. We had hoped to try to get work going on tracks API v2 and v3 and the User API plugged in to their tooling. This still seems a good idea, but we need to work together with them on the tracks API v3 design.
Where we are now: Direct Artists
Once we have the fixes done on the existing upload tool / dash and some interim technical work done on tracks api V2 we are in good shape to release a simple ‘newcomers’ self-uploading tool on the back of the artist sign-up flow. It might also be of interest for a small label adding a number of profiles on artists’ behalf.
Unfortunately we would have to continue to collect ISRC’s, ISWC’s UPCs and any other mandatory reporting data separately and add them to our sales reporting process and files. (Still spreadsheet-based).
Roadmap - APIs
v2 tracks API as above.
Capture industry identifiers in migration files
v3 tracks API - add industry identifiers, document it properly, provide a good developer environment
Prepare for migration of existing metadata for 15k tracks.
As a design principle it would be good to our internal tracks API metadata set as focused and clean as possible, focused on what we need for the player, reporting and community/socials, holding the keys to original / source metadata rather than all the metadata. A separate metadata service could then be created to handle the external interaction with other services. This could be a specialist partner-provided and hosted service, part of our ecosystem.
There also needs to be a sales reporting API. Previously we have pointed to the Open Music Initiative APIs as a possible solution, when we have significant sales
Roadmap - Metadata Standards
The comment about the ‘gravy-train’ was not meant to be distrespectful of all those who care about the vital importance of metadata and attribution: I’m referring to the industry dominance of the majors in standards-setting who resist open-source approaches, leaving us with a set of clumsy industry metadata standards and protocols that act as a barrier to new small label entrants and artists alike.
There are alternative open-source alternatives rooted in W3C standards like json-ld that would be preferable for a community music ecosystem with enhanced attribution and discovery - in the longer term, IMHO:
…possibly working in collaboration with specialist open-source encyclopaedia projects like: About - MusicBrainz
But…as Kavan points out, there is no globally standardised all in one place store of all the source metadata for a track, just the data standards and the industry protocol for exchange, with many folks who use it. Our metadata service will have to support many standards, starting with the ones that are rooted in law.
Footnote: …One day in the long-distant future we might combine the open data approach of the music ontology with our verifiable credentials and become an issuer of truly verifiable rights ownership, without depending on a host of centralised intermediary services, who make money out of shovelling metadata from place to place.
sorry for the long answer… trying to be as thorough as I can in the time available