History:Getting Rid Of Featuring Artist Style
- 1 Getting Rid of Featuring Artist Style
- 1.1 Problems with the current Guideline
- 1.2 Proposed Solutions
- 1.2.1 Replace "feat." by a Collaboration-Artist
- 1.2.2 Remove "feat." and Store _all_ Performance Roles with AdvancedRelationships
- 1.2.3 Wait for Picard to Be Able to Handle AdvancedRelationships
- 1.2.4 Implement 1:n relationships of Artists to Tracks
- 1.3 Concrete Examples
Getting Rid of Featuring Artist Style
This page tries to sum all problems of and possible solutions to the FeaturingArtistStyle.
Problems with the current Guideline
The current FeaturingArtistStyle has a couple of severe issues. This section should identify them:
- Storing artist information as a section of the Title field is incorrect.
- The Title field should contain a track's title.
- The Artist field should contain a track's primary artist. The primary artist can be a Person, a Group or a Collaboration.
- Any other contributors should be stored as Relationships to the track.
- Currently "(feat. xxx)" can mean one of several things:
- The "feat" artist is providing guest vocals on a track. (eg. http://musicbrainz.org/track/c1b2cea4-b493-4768-acf5-6948a4fe522b.html)
- The "feat" artist is providing guest instrumentation on a track. (eg. http://musicbrainz.org/track/9fa53a14-1028-4e84-8eab-cf1814c38a9e.html)
- The "feat" artist is a primary collaborator on a track. (eg. http://musicbrainz.org/track/ff0df0ce-d49d-491d-9247-1aa2fa0c6df1.html)
- The "feat" artist is a composer of a track. (eg. http://musicbrainz.org/track/9bbe8738-32bd-41e9-acec-bfac9ae62947.html)
- The "feat" artist is a co-producer of a track. (eg. http://musicbrainz.org/track/6db39d74-12c5-4eb7-b4f8-e73d7a97c5d0.html)
- Unless the featured artist is added as an AR in addition to the text in the title field, there is no way to track at a database level guest performances, collaborations, etc.
- A search for A & B doesn't list artists that have tracks Track Name (feat. B).
On the other hand the current Guideline is not completely void of sense. the pro's for it are:
- The hierarchy between the CoreEntities Artist-Album-Track is kept (well, at the expense of one artist being completely dropped out of this hierarchy). Most media players categorize tracks this way.
- This presentation of the 'featuring' artists is often done in this exact format on the real world tracklisting.
- The track shows up in the album listing of at least one of the two collaborating artsts. If, on the other hand, the track is filed under a collaboration-artist, it will only show up in the album listing of that collaboration.
- This system makes a lot of sense where the track is (only) on a single artist album, but the particular track features additional 'guest' performers. Most people wouldn't want to convert it to a VA album in this case.
This section should help to get a clearer picture of the proposed solutions and their pros/cons. Currently there are three proposals, which are tentatively called the "pragmatic", the "correct", and the "conservative" one. These names do not imply any valuation.
Replace "feat." by a Collaboration-Artist
This seems to be the most "pragmatic" proposal. In this solution only the FeaturingArtistStyle guideline would be changed to something like:
- "When two or more artists collaborate on a track or release, file the track/release under the primary artist, and then add Performance relationships to the secondary artists. If no artist can be considered secondary, create a new artist in the form 'Person A & Person B' and add the artists as collaborators."
- Removes cruft from Title fields, since they are no longer cluttered with artist names.
- Stores richer information (what did the secondary artist perform?)
- Creates a more relational and future-proof database.
- Requires no coding changes. (but see con below)
- Secondary artist information will not be added to ID3 tags. To solve this the PicardTagger needs to be able to process AdvancedRelationships.
- Secondary artists vanish from the visible part of the database. The current website design doesn't give visibility into relationships attached to Tracks.
- Current website design to add members to a Group is clunky.
- This increases the number of artist entities in the database to include more collaborations.
- The albums will not show up in the album listings on either of the collaborating artist's artist pages. I do not know how much work would be needed to solve this, maybe the ArtistPageRedesign can easily be expanded to display albums from collaborations of an artist.
Remove "feat." and Store _all_ Performance Roles with AdvancedRelationships
This approach is a more "correct" one. It would mean that the PrimaryArtist field gets a role that is subordinate to AdvancedRelationships. The Primary artist field could then contain anything that (backward) media players need, and the database would know about the artists via ARs.
Of course this requires a massive change to the server and the clients. I am not sure whether the database schema would need to be changed at all, but the display, the underlying queries, and the client APIs would have to be fundamentally changed.
Currently this unapplicable because of such simple problems like:
- The UI to add ARs is too clunky.
- The UI to display performance ARs on a track level is basically nonexistant.
Note that there could be an intermediate stage of this solution, in which AdvancedRelationships get added but "feat." is kept (although I see no benefit in this compromise).
Wait for Picard to Be Able to Handle AdvancedRelationships
This is the "conservative" approach. It would mean to continue without changing the style guide until Picard can deal with giving users options on how they want AR data applied to tags.
- Requires no changes to anything now.
- Will compound the current problem.
- Will make it harder to switch to a "correct" approach in the future.
Implement 1:n relationships of Artists to Tracks
This is a development intensive approach. It would allow to store one to many artists who collaborated on a track in the core database tables, but would not require any complicated styleguide decisions anymore. LuKz proposed a database schema change which could handle the requirements sketched above, and Ruaok agreed that this would be the most satisfactory solution to the problems plaguing us since SG5 was introduced. Please read the chatlog of the discussion about the database schema change.
- Getting rid of unnamed (Artist A & Artist B) collaboration artists and replace them with references to the collaboration participants
- SG5 can be adapted to deal with Guest artist only (which as noted elsewhere, sometimes appear on the tracklisting with feat.)
- Major change to the website
- Has potential to break existing apps using libmusicbrainz/libtunepimp
- Increases number of database joins to display an album track listing. In the vast majority (99%, I'd SWAG) of cases, track:artist will be a 1:1 mapping.
- Increases complexity for adding/importing a Various Artists album.
- Inconsistent with the way we deal with named collaborations (eg. Smokin' Mojo Filters or Band Aid)
- Requires a great deal of planning to generate "correct" display names. eg.
- Putting artists in the "right" order. ('Foo & Bar' versus 'Bar & Foo'. Users will get upset if this is "wrong")
- Using the appropriate "join" ('Foo & Bar', 'Foo et Bar', 'Foo vs. Bar', 'Foo, Bar and Baz', etc.)
- Using the artists' names in the "expected" way (Russ gave the example "William Gilbert & Arthur Sullivan" versus the correct "Gilbert & Sullivan")
- Cannot be re-applied to another track between the same collaboration.
- Significant changes to the documentation
- Wrong data entered by non-habitual users due to misunderstanding of the new concept
Discussions like this often get confused because of referrals to anonymous and generic items such as Artist X and Track Y. It might be worth pointing to actual albums in the DB and showing how different methods would treat them.
Judgment Night Soundtrack
The Judgment Night Soundtrack is an album consisting entirely of collaborations, see album cover with artists This album has the concept of bringing together a 'rock' and 'rap' artist to collaborate for each track e.g.
Track 1: "Just Another Victim" produced as a collaboration by Helmet (a 'rock' group) and House of Pain (a 'rap' act)
The current state (as of 20th Oct 05) follows the styleguide exactly and renders this as:
- Track Name: "Just Another Victim (feat. House of Pain)"
The track also has an AR that claims the track was performed by House of Pain. The track (including a single release and remix) occurs in the database 3 times in total, the other two tracks don't have any AR attached to them, probably a moderator oversight. I assume they should have the same AR.
The rest of the album in MB follows the same format with the 'rap' artist feat.ured in the track title and an AR to the 'rap' artist as performing the track.
My (bawjaws) preference, and following the "pragmatic" sketch of a revised FeaturingArtistStyle given above would be for:
- Track Name: "Just Another Victim"
Artist: "Helmet & House of Pain"
This collaboration "Helmet & House of Pain" would then be listed as an artist and marked as a collaboration via AR to both artists e.g. "Helmet collaborated on Helmet & House of Pain" & "House of Pain collaborated on Helmet & House of Pain"
Pros and Cons
Advantages for this case remaining as is now:
- If you are a fan of, in this case, the 'rock' artists rather than the 'rap' artists then the songs will appear, on the website and in your music app, listed under the artist you like.
Advantages for this case if SG5 was changed:
- The track title field contains what is unambiguously the correct title of the track
- The artist field contains the text of both collaborating artists for use in searching
- This track appears three times, that means 3 AR's. It would seem likely that popular collaborations (that therefore turn up on multiple releases) would result in a forest of ARs on the 'lesser' artist's page. If the track appears once in the DB (i.e. only on version of one album or single) and the collaborators never do anything else together then the current SG5 is less work, as soon as the track or any other by the same collaboration appears on a second release the change is less manual work to set up (for every track: one artist and one performer AR per feat. artist vs. fixed cost of one collaboration AR per collaborator + one artist link per track)
- The two artist are treated equivalently and equally.
- If you wish to consider the collaboration as a separate entity it is difficult to do so under the current system
- This is closer to what a MusicBrainz naive user would expect to find and to enter
- It would be harder for duplicates to be filed in the DB (a reversed "House of Pain & Helmet" artist would show up in searches and be easily merged)
- Is identical to what would be need to be done for a collaboration that had a unique name, therefore requiring less coding and less learning by users, see collaborations such as Saint Etienne Daho or Smokin' Mojo Filters
Other useful examples that could be expanded on:
- Elvis vs. Junkie XL (see discussion and note later disappearance of this collaboration 'artist', the various versions of this track are currently listed, semi-randomly, under both Elvis and Junkie XL, primarily without any credit or AR for the other artist.)
- Tom Jones and friends. Primarily through the album Reload, Tom Jones has performed many celebrity duets/collaborations. As many of these were released as singles and turn up on multiple VA hits albums the database currently has multiple collaborations with Tom Jones as artists.
- Marvin Gaye's duet albums: United and You're All I Need with Tammi Terrell, Take Two with Kim Weston, Together with Mary Wells. Some of these tracks are soul classics, and appear on a ridiculous number of compilations.
- It would be good if someone could propose rap and dance examples as both these genres seem to have embraced the feat. terminology.