Track Merging

From MusicBrainz Wiki
Revision as of 15:53, 8 September 2008 by BrianSchweitzer (talk) (Filled in more of the important bits from those same IRC discussions (Imported from MoinMoin))


TrackMerging is a simplified version of TrackGrouping. The basic idea is to allow a single "track" object to be shared by multiple "release" objects. A "track" object contains a collection of "release track" objects. This would clear up a significant amount of redundant data and allow us to pool similar PUIDs into a single object such that there would be absolutely no PUID collisions between the objects. Implementing this concept will be one of the many incremental steps toward the NextGenerationSchema goal.

Unresolved Issues

  • - What do you mean by "linked"? In relation to the editing system where edits are linked to one artist, and may be linked to one release like in 9241406? I would say, link to no releases (expected if we fixed 884). -- murdos 16:05, 02 September 2008 (UTC)
  • How should removing of a track work? Automatic removing when the last "release track" is removed? Only manual removing?
  • - Automatic removing, otherwise we may have a tons of orphan tracks. We might however present a warning if the track has a certain amount of information attached (ARs, PUIDs, ...) -- murdos 16:05, 02 September 2008 (UTC)
  • How do you separate merged tracks?
  • - The same way you merged them: a little check box on the right and a "separate" button on the bottom that activates when at least one track is selected. The selected tracks are separated and merged into a different track object. -- BogdanButnaru 13:37, 17 March 2008 (UTC)
  • When release tracks will have their own titles, and somebody completely changes the title, should it automatically create a new track?
  • - How about a warning on each potentially ambiguous edit, requiring the user to specify with check-boxes if the track should be separated or not? -- BogdanButnaru 13:37, 17 March 2008 (UTC)
  • Should the "release editor" have an option to re-use existing tracks, instead of always creating new ones and then merging them?
  • - Yes. It should even be the default behavior, with AJAX lookups as we do for artist and label. We might add a checkbox in the release editor indicating all the tracks are "new" (e.g. for a new album). -- murdos 16:05, 02 September 2008 (UTC)
  • Should "earliest/later release of" track-track ARs and clusters be converted automatically into track objects? -- BogdanButnaru 13:37, 17 March 2008 (UTC)
  • - Edit: there should be checking for length and title at least. See the last track on this album for an example why it's a bad idea to ignore details. -- BogdanButnaru 14:18, 18 March 2008 (UTC)
  • what happens to AR's like composed, cover of, etc. do they get merged? (Will try this and report back)
  • Can we have aliases for tracks now? (If you merge two artists that are actually the same but with two slightly different names they automatically get added as aliases. The same for tracks would be useful)
  • - It depends if we consider track aliases the same way as artist aliases (i.e. just synonyms), or if a track alias is linked to one (or many) releases? The former is easy, the later is not. -- murdos 16:05, 02 September 2008 (UTC)
  • How does this interact with the search mechanism?


  • "Release track" titles.
  • Disambiguation comments for tracks.
  • Warnings on merge if:
    • Track durations differ
    • Merging tracks from Album/Single/EP/... and Live releases together.
  • - Also for "other", often these are demos. When do we get the demo release type, anyway? -- BogdanButnaru 13:37, 17 March 2008 (UTC)

(OLD) Below is a collection of all the various ideas/notes we've had regarding this feature:

Here are some notes from an IRC conversation we had some time ago (LukasLalinsky, Jugdish and BrianFreud). But I can't remember some details, and somehow find it on chatlogs, so it's possible that something is incorrect. (If somebody can find the IRC log, please add the link here.) -- 16:04, 02 October 2007 (UTC)

  • I don't have the IRC reference, but I've filled in some of the rest from those same conversations, and a few of the relevant details as to how Masters would fit into a structure with the rest of the similar concepts we discussed at the same time (Work and Session). -- BrianSchweitzer 15:53, 08 September 2008 (UTC)
  • Adding new album will always add new master entities - a prompt system could be implemented to try to automate then merging those new Masters into existing ones (based on title + artist + length) to help avoid large numbers of obviously identical Masters being created, but those mergings should be separate voted edits, to avoid accidental merging of non-identical Masters.
  •  ? Significant change to track title will automatically detach the track from the current master (if more than one track is attached to it)
    • Some rare tracks may need support, however, for being the same Master, yet with a different name for a specific instance of that Master. (See Nirvana "Rape Me" / "Waif Me")
  • Masters have no explicit titles, everything is derived from attached tracks. (Does this contradict the above item?)
  • It will be possible to merge masters.
  • It will be possible to split some tracks of a master.
  • The release editor can be used only to edit tracks, not masters or track<->master associations.
  • There are no track ARs, adding an AR to track will transparently add it to the master. (Any case where a track could be argued to have a

different AR than is common to all others for the same Master is an argument that that case should be a new and separate Master for the same track.)

  • Masters should be able to have ARs linking chains of Masters (as well as Master - Work ARs), to handle the cover, remaster, and similar ARs that currently are track - track.
  • PUIDs are attached to masters. (theoretically, no two masters should share the same PUID)
  •  ? Durations are attached to masters, not tracks.
    • Theory was that any Master represents a specific master with a given time (+ or - 5 seconds, due to unavoidable CD mastering issues), so any master with more than a 5 second time difference represented a new Master, by default. (This is also the reasoning behind the above comment regarding PUIDs.) This would allow us to:
      • fill in ?:?? times in an automated way
      • keep consistent times for instances of a Master
      • detect and avoid having 2+ Masters with time differences greater than 5 seconds being accidentally merged as a single Master
  • A theoretical level, proposed for implementation either at the same time, or after, the implementation of track masters, suggests "Session" as a level between Work and Master. Sessions would represent the singular unique performance of a Work, whereas Masters be singular unique mixes and masterings of a Session.
    • Work > Session > Master > Track
      • (compositional data) > (performance data) > (mix/mastering data) > (no AR data, but represents the track instance on a real world actual release (aka LP, CD, tape, etc)).
    • ARs for each level should inherently be inheritable from the above level; example: a track instance inherits composer AR data from the work, recording engineer AR data from the Session, and mastering engineer data from the Master. Any possible case where some such AR data is untrue represents not a flaw in the inheritance structure, but by definition (that all data about any such object should apply to all linked child elements of that object) indicates a Work, Session, or Master which has been mis-merged, and is in need of being split out such that the AR data inherited to the track level is no longer untrue.