CIP-0060 | Music Token Metadata

[AndrewWestberg]

The music community on Cardano is still working on this actively, but I wanted to get this placeholder PR up to hopefully grab the CIP-60 number.

[sean118]

Great proposal. Some first thoughts:

1. CIP 25 uses snake case formatting for keys, so I'd prefer to see "album_title" or "song_duration" in the fields column.

2. It might make sense to define an artist object instead of having strings for the artists. There can be multiple artists with the same name, making attribution of a song difficult. An artist object would allow you to add other identifiers, DID references, social media handles or similar to an artist.
   The same goes for album details, where "total_tracks", "release_date" and cover image fields might be great for additional context.

3. For simplicity I would also prefer to see an "artists" field (plural, instead of "artist") that is always an array, even if there is just one artist associated with the song. This is also how the Spotify API works, which might be a great reference for these types of definitions.

4. Also an array for "genres" might make sense, since a single genre string is hardly enough to classify songs or albums; there can also be multiple levels of sub-genres that might make sense to have in the list to simplify discovery when the catalog grows.

5. A boolean field for "explicit" lyrics might be useful for certain apps to reduce unpleasant surprises when exploring the catalog.

6. The naming of the field "Track" might not be optimal. Maybe "track_number" (see Spotify) is a better fit.

[AndrewWestberg]

@sean118 I have implemented your suggestions.

[sean118]

Looks great, thanks! What would you think about describing artists as objects instead of strings, so they can easily be extended with other attributes, for example:

"artists": [
  {
    "name": <string>,
    "image": <uri | array>,
    <other properties>
  }
],

For the album it could look like this:

"album": {
  "name": <string>,
  "release_date": <string>,
  "total_tracks": <int>,
  "image": <uri | array>,
  "type": <string>,
  <other properties>
}

(For both objects "name" might be the only required field, while the others are optional)

[kieransimkin]

Have had a quick scan through - looks good. I'm working on a CIP-54 Smart NFT demonstrator that would look for music NFTs in your wallet and do some cool things with them.
I know that some audio NFTs can contain stem files for the purposes of remixing and suchlike. For my purposes, and integration with CIP-54, it would be really nice if you defined a standard way to specify which file represents the main original track, which files represent stems, samples or remixes of the track etc. I suggest just adding an parameter within the files array, specifying what type the file is. Here's some suggestions for possible options for that type:

• original
• acapella
• instrumental
• VIP (variation in production by the same artist)
• remix (by another artist - maybe an extra way to specify information about who?)
• stem
• sample
• commentary (the musician talks about their work?)
• cover art

But yeah, mainly I want a way to be able to easily identify stems and samples please :)

Also perhaps this is a pointless thing to raise - but I would tend to refer to them as "Audio tokens" rather than "Music tokens", since they could also contain spoken word etc. For example, an mp3 is referred to as an "audio file", not a "music file".

[AndrewWestberg]

@kieransimkin For your use case, it seems it will be specific to your particular application. This CIP is designed to be more generalized for music and music players. Yes, it could be used as a basis for your NFTs that add stems and samples, but it's designed so that you can just add your own necessary fields for your own applications. For example, nothing in this cip prevents you from adding "audio_type" under each file.

[rphair]

I had a question around today's CIP meeting that may be silly and/or outside the scope of this proposal. If this is based on CIP-25, and given that NFT's representing musical works should have an expandable supply, that means the minting policy would have to be unlocked & that anyone or anything (e.g. a third party distributing music) would have an opportunity to make changes to all this metadata at each additional minting transaction.

Would this be considered a security risk, or harmless, or maybe a valuable opportunity to correct the metadata of those tokens (e.g. number in circulation)? Perhaps it's wrong to assume that these tokens reflect music as a commodity (e.g. as purchased on iTunes) but then again this discussion has referenced Spotify which also takes a commodity approach to music distribution.

If these are legitimate concerns or open for debate (i.e. not easily dismissed by common sense & a better understanding of the commercial context) then perhaps this issue can be addressed in the CIP itself.

[KtorZ]

Small-note: I believe this is more than informational and fall in the category of processes.

[AndrewWestberg]

@rphair
Issues about intellectual property and streaming rights don't belong in this CIP. That needs to be addressed by the individuals or companies minting the NFTs.

At NEWM, the security risk/issue of a forever-open minting policy is mitigated by utilizing a plutus script to mint instead of a simple script. The plutus script enforces that nothing can be minted with the same name as a previously minted NFT. These contracts are still under development, but are open-sourced at https://github.com/projectNEWM/contracts

[rphair]

@AndrewWestberg thanks for answering the question about the minting policy, although I wasn't at all enquiring or saying anything about intellectual property or streaming rights.

[KtorZ]

Approving assuming those follow-ups:

• Change the type to Process (sorry, bad suggestions from my end.
• Change the status to proposed or active, depending on the actual status (I.e. Is this already in use by various actors of the industry?)

[AndrewWestberg]

@KtorZ Updated to Process and Proposed for status. It will begin being implemented in NEWM in October, but until then, I think Proposed makes sense.

[rphair]

thanks @AndrewWestberg ... merging as per resolution at last CIP meeting.