History:Object Model/Representing Remixes

From MusicBrainz Wiki
Revision as of 22:28, 25 October 2011 by Reosarevok (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Thoughts on Representing Remixes in the ObjectModel

Remixes make the layers of the ObjectModel between the ../PerformanceObject and the ../TrackObject a royal pain. Actually remixes would be the only reason to use the ../MixObject at all.

The whole issue can be greatly simplified if a remix is seen as a performance. If we define a remix of being a ../PerformanceObject of its own, this has the following consequences:

What gets remixed?

A remix doesn't combine different ../MasterObjects. Only bootleg remixes are based on masters. The majority of proper remixes use one or more ../PerformanceObjects as their source, and a different mix or better a new version of the performance is created. A remix that is created from more than one source is a rare case and usually referred to as a Mash-Up.

So, we should use ../PerformanceObject as source for remix. Otherwise, you will have the problem, that you have to decide which ../MasterObject to use (it's common that there are more than one for one ../PerformanceObject). So we wouldn't fix the "Always link to oldest release" problem.

Normal remixes can be stored without further change to the object chain, which contains inclusions only (i.e.o--> means (1)--(1-n)), and looks like this (Note that we are talking about instances of objects here):

OrigComposition o--> OrigPerformance o--> OrigMix o--> OrigMaster
                        Re-Mix o--> RemixMaster

To store Mash-ups we would either need to allow a ../PerformanceObject(1-n)--(1-n))../MixObject relationship, or relate performances with AdvancedRelationships. the latter would give us:

OrigComposition1 o--> OrigPerformance1 o--> OrigMix1 o--> OrigMaster1
                          | AR: is a remix of
MashUpComposition o-> MashUpPerformance o-> MashUpMix o-> MashUpMaster
                          | AR: is a remix of
OrigComposition2 o--> OrigPerformance2 o--> OrigMix2 o--> OrigMaster2

The above means that we can create a new ../CompositionObject for a remix, if we want to (e.g. because the change was so large and 'artistic' that the result should have a composition of its own). The resulting relationships look like this:

OrigComposition o--> OrigPerformance o--> OrigMix o--> OrigMaster
                           | AR: is a remix of
RemixComposition o--> RemixPerformance o--> Re-Mix o--> RemixMaster

Where to relate the Artist

In the ObjectModel only the ../PerformanceObject and the ../TrackObject are related to artists (how exactly we do not know yet). That means that a remix can be represented as a performance done by the remixer, that combines audio material from different original performances. The original performers are not related to the performance representing the remix, but only to the performances that the remixis based on. Uh that was a complicated sentence. Basically we have a concatenation of ../PerformanceObjects done through AdvancedRelationships as described above.

 OrigArtist(s)        RemixingArtist
      |                     |
      |          AR         |

The performing or remixing artists are all related to their appropriate level of performance. No confusion here.

At the end of this chain, we have a ../TrackObject[1]. This is the point where things get confused, but this has nothing to do with the way we represent remixes. The confusion comes from the ../TrackObject!

People expect the properties of a track (the TrackTitle and the displayed TrackArtist) to document in a condensed form what we have ripped into pieces with the ObjectModel. There probably is no simple way to condense this information, but this is not a problem of this way of representing remixes.

  1. To be precise, it is a tree and has several ends, but they all are ../TrackObjects