User:LordSputnik/Track System Redesign
This page is a constantly evolving work in progress. It will never be finished! But hopefully it'll get to a point where the ideas are coherent enough to be implemented!
If you have comments on the ideas in this page, please email me using the email link at my MB user page: .
The aim of this wiki page is to present a comprehensive, clear and purposeful system to replace recordings.
Why Recordings are Bad
Consider this: A release is audio that you can buy or obtain in some format in some country. A work is an audio composition. A label is an organization which publishes audio. An artist is a person or group which creates audio. All MusicBrainz entities relate to something concrete and real. All except the Recording entity. A recording is defined as "representing distinct audio". It is an abstract, conceptual entity. This is why it should have no place in MusicBrainz.
What exactly is meant by "distinct audio"? This could refer to the audio created when a performance is recorded in a studio. It could just as easily refer to the audio on a CD track. Both interpretations are equally valid, but the Recording guidelines have nothing to say as to which interpretation is to be used. The recording level is a mixture of two more realistic levels - the mix and the master.
This proposal creates these two new entities to replace the recording with more meaningful levels. It also creates unique track entities which cannot be merged, to remove the need to deal with cases of "unique audio".
A work is an artistic creation. It is the highest level entity of the four. Examples of a work include a song or some form of classical piece. Works are near enough perfect in their current form. They are well defined and already serve the intended purpose.
A mix is a version of a performance of a work. A mix can be made of a studio performance or a live performance. A mix does not refer to changes to the way the audio sounds. It refers to major, structural changes to the audio. For example, the removal of half of the song to create a radio edit, or the separating of instruments into two channels to create stereo audio.
Mixes can be merged, but this will hopefully happen less frequently than for recordings, due to the more objective nature of a mix. An editor must make an edit to associate a track with a mix, and this edit is subject to the voting process, like any other non-auto-edit.
Performance ARs should be attached at the mix level. These relationships will need to be duplicated if parts of the performance feature on two separate mixes.
A master is a mix which has been edited or altered to change the sound, in preparation for the creation of a release. This entity isn't as common as the others mentioned here - relating a track to a master is optional, and should only be done where documented evidence supports the relationship being made.
Mastering ARs should be attached at the master level, and not at the release level.
A track is the master after it has been copied onto a particular release. It is the lowest level entity of the four. It is unique to the single release it appears on, and lives and dies with that release. When a release is added, tracks are created, assigned MBIDs, and given titles. The track names are displayed on the release main page. Clicking a track name will take the editor to the track.
AcoustIDs should be related to tracks, and can be related to more than one track (but generally shouldn't be shared between tracks of different mixes). It is likely that the links between the AcoustID database and MusicBrainz would need to be reset.
Works, mixes, masters and tracks can all be related to each other. There should also be some way of lower level relationships overwriting higher level relationships. For example, both a track and a master are related to the same work. If an editor creates a relationship between the track and the master, the track's work relationship should somehow disappear and be replaced by the master's work relationship. In other words, a relationship on a higher-level entity should be inherited by a lower-level entity. Higher level entities can be related to multiple lower level entities, but lower level entities should generally only be related to one higher level entity.
Tracks will be stored on releases, as in the following example of an EP added to the DB:
"Some Songs" by "RandomBandom"
- An Old Song
- A New Song
- A Borrowed Song
- A Blue Song
Then four tracks will be created:
The release will store tracks like this:
When tracks are reordered on a release, the MBIDs are simply swapped. For example, swapping track 2 with track 3:
If a track name is changed in the release, it simply updates the name on the track:
1. An Old Song -> 1. Ye Olde Songe
- Title: An Old Song | Ye Olde Songe
All of these tracks will automatically link to works, selected when the release is added. Tracks using a work will be stored in a tab, on the work itself. They will be grouped by release group, and all release groups should be collapsed initially:
Ye Olde Songe
- Some Songs by RandomBandom
- 1/4 - Ye Olde Songe on Some Songs
- 1/4 - Ye Oldey Song on Some Songs
- Longer Songs by RandomBandom
- 1/14 - Ye Olde Songe (single version) on Longer Songs
- We Made an Awesome Cover by Band on Tandems
- 1/1 - Ye Olde Songe on We Made an Awesome Cover
- Create a track entity. Replace all tracks in the db with this new entity, and relate them to recordings attached to releases through the current system.
- Track Groups