History:Getting Rid Of Featuring Artist Style: Difference between revisions
From MusicBrainz Wiki
Jump to navigationJump to search
(additional 'pro' for sg5 (Imported from MoinMoin)) |
(No difference)
|
Revision as of 17:02, 20 October 2005
Getting Rid of Featuring Artist Style
This page tries to sum all problems of and possible solutions to the FeaturingArtistStyle.
The idea to create this page comes from a post from DonRedman on mb-users (start of discussion here).
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. (TODO: Find example)
- The "feat" artist is a primary collaborator on a track. (eg. http://musicbrainz.org/track/ff0df0ce-d49d-491d-9247-1aa2fa0c6df1.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.
- ...
Proposed Solutions
This section should help to get a clearer picture of the proposed solutions and their pros/cons.
- Change the style guide. Strawman: 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.
- Pros: Removes cruft from Title fields. Stores richer information (what did the secondary artist perform?) Creates a more relational and future-proof database. Requires no coding changes.
- Cons: Secondary artist information will not be added to ID3 tags. Current website design doesn't give visibility into relationships attached to Tracks. Current website design to add members to a Group is clunky.
- Continue without changing the style guide until Picard can deal with giving users options on how they want AR data applied to tags.
- Pros: Requires no changes to anything now.
- Cons: Will compound the current problem. Will make it harder to switch to a "correct" approach in the future.
- Store all performance roles with AdvancedRelationships of the PerformanceRelationshipClass.
- Pros: This is a more "correct" approach.
- Cons: This requires a massive change to the database schema, the server and APIs in currently-shipping tools.
Now we would need to describe these proposals in detail and then sum up all arguments for and against them.
Authors: RodBegbie