[mb-users] Feedback/testing: track merging

[Lukáš Lalinský]

On Po, 2008-03-17 at 13:47 +0100, Olivier wrote:
> > 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.
> 
> Just wondering: if pweeds would remain attached to "release tracks",

Note that I'm not changing the DB schema at all (for now). It's just
that "release tracks" are more visible now, but PUIDs were and are still
attached to master tracks.

> splitting a track out of a group also would have the benefit to split
> the pweeds out - while if all pweeds are attached to the master track,
> this is somewhat irreversible.

On the other hand, PUIDs are easily recoverable data. If there is any
doubt about splitting or moving PUIDs, they should be simply deleted and
the next person tagging the tracks will add them again.

> Not too sure how much extra complexity handling this that way would
> require, but I can sure see a benefit in it...
> 
> > Are EditTrackTimeEdits and EditTrackNameEdits linked to no releases or all attached releases, now that there can be more than one release?
> 
> Not too sure I correctly understand the question...

I meant it more UI-wise. For example can't
http://test.musicbrainz.org/show/edit/?editid=859 see the release title,
like you can on the live server (but on the other hand it has 5 attached
releases on the test server).

> So far, all merged "release tracks" share the same title (and same
> track time) and the corresponding edits alter all releases.
> 
> This is not ideal: EditTrackTimeEdits won't cope well with discids...
> And for EditTrackNameEdits probably it causes problems as well
> (trans-stuff as mentioned earlier).
> 
> I guess in the ideal world (apparently, part of this is planned, right?):
> - each "release track" could have its title and time edited/set on its own:
>  * with a "reminder" containing the current "master" information (if
> there is more than one release track in the group)
>  * with some warning about time variation (above a given threshold)
> between the "master" and the "release track" (if there is more than
> one release track in the group)
> - the "master" also could have its title edited independently,
> possibly with a check box or something like that to "also set 'release
> tracks' titles"
> - the "master" track time should not be editable, but be the median of
> times of all attached tracks
> - the merging dialog may present the ability to change the title/time
> of the tracks once merging, or not

I don't agree with track times here. If they differ (+/- 5 seconds, like
we currently do for release merges) the tracks shouldn't be merged.
Merging makes only sense if they have exact the same audio. 

> > How should removing of a track work? Automatic removing when the last "release track" is removed?
> 
> Automatic removing sounds ok I guess...
>
> > How do you separate merged tracks?
> 
> UI-wise?
> Maybe on the given track page, add a "split it out" button next to
> each "release track"?
>
> > When release tracks will have their own titles, and somebody completely changes the title, should it automatically create a new track?
> 
> I don't think so.
> It's not uncommon to see the same recording have completely different
> titles (also, as mentioned, trans-* stuff)

The problem is, if somebody enters a wrong track listing, how to fix it
in a way that might add data duplication, but never causes even more
incorrect data (e.g. release track "Foo" attached to completely
different master track "Bar").

> But maybe this is about the definition of track merging then...

> > Should the "release editor" have an option to re-use existing tracks, instead of always creating new ones and then merging them?
> 
> I would say if such a possibility exist, it should be made (very)
> discreet. Adding a release is already a quite rich/complicated task
> for the complete newcomer, and there are already a good number of
> mistakes to make. Making this new UI too obvious will make the process
> more complicated, and more prone to generate tons of bogus merges.
> 
> I would even suggest to not add it at all, at least until we see how
> all this goes.
> 
> About the comments down the page:

> > Adding new album will always add new master entities.
> 
> Yes, I agree with that.
> 
> > Masters have no explicit titles, everything is derived from attached tracks.
> 
> That doesn't work quite well as soon as release tracks can have
> different titles...

The idea was to display all of them, but that will make identification
of master tracks much more complex than it needs to be. Explicit title
for the master track with optional disambiguation comment is probably
the best solution.

> > It will be possible to merge masters
> 
> That's the case right now as far as I can tell?

Yep.

> > 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.
> 
> Sounds reasonable
> 
> > Significant change to track title will automatically detach the track from the current master (if more than one track is attached to it)
> 
> How much "significant"? soundex? Levenshtein?
> I don't think this is that much a good idea...

That's the trick, I somehow feel it's necessary to prevent incorrect
track merges caused by editing only release track titles, but I'm not
sure what would be the right solution.

> 
> > There are no track ARs, adding an AR to track will transparently add it to the master.
> 
> Sounds good.
> 
> > PUIDs are attached to masters. (theoretically, no two masters should share the same PUID)
> 
> Yes, but see above. Maybe it's still a good idea to maintain pweeds
> attached to release tracks instead, so that spliting them out will
> split the pweeds as well.
> 
> > Durations are attached to masters, not tracks.
> 
> Not sure I like that...

I personally do, since they are properties of the audio data (like
PUIDs) and tracks shouldn't me merged if the audio differ.

> And last, what will happen to track annotations?
> IMO, they should be unique, attached (and merged) to the master track,
> not the releases tracks (like ARs).

Again, what you see on the test server is without any DB change, so
annotations are attached to the master track.

> In the hope I understood all that enough to write meaningful
> comments :]

Yes, thanks for the comments!

Lukas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Toto je =?ISO-8859-1?Q?digit=E1lne?=
	=?ISO-8859-1?Q?_podp=EDsan=E1?= =?UTF-8?Q?_=C4=8Das=C5=A5?=
	=?ISO-8859-1?Q?_spr=E1vy?=
Url : http://lists.musicbrainz.org/pipermail/musicbrainz-users/attachments/20080317/a0bcbed4/attachment.pgp