Difference between revisions of "History:Calculate Track Times"

From MusicBrainz Wiki
m (4 revision(s))
m
Line 47: Line 47:
  
 
It might also be handy to have new [[Edit Type|EditType]] to SetTrackTimesFromDiscID to allow manual selection of the correct [[Disc ID|DiscID]].  
 
It might also be handy to have new [[Edit Type|EditType]] to SetTrackTimesFromDiscID to allow manual selection of the correct [[Disc ID|DiscID]].  
 
==Discussion==
 
 
When you say "setTimesFromDiscID(findMedianDiscID())", do you mean that one of the 2-or-more disc IDs is selected as the median, then the times are set from that (thus, the track times exactly correspond to one of the disc IDs)?  Or, do you mean that for each track, the median track length (based on each TOC) is calculated?
 
 
If it's the former (pick a disc ID, use that), how exactly is the disc ID selected?
 
 
If it's the latter (average for each track separately), what happens when the number of disc IDs is even (e.g. 2)?
 
 
- [[User:DaveEvans|DaveEvans]]
 
----
 
 
Ok, maybe I didn't think that through far enough.    I said in Proposed Algorithm above that one of the [[Disc ID|DiscID]]s is selected as the median, and that's used for the track times.
 
 
But have to say I didn't think of what to do if you have 2 discIDs :)
 
 
Shall we abandon the idea of automatically choosing the right [[Disc ID|DiscID]]?  Since we only have to pick for releases with 3+ [[Disc ID|DiscID]]s (which according to [http://musicbrainz.org/stats.html http://musicbrainz.org/stats.html] is about 3% of releases), is it worth the complexity?  If a [[Disc ID|DiscID]] is completely wrong, it should be deleted, otherwise, it doesn't matter so much if it's a second or so wrong.  In any case, it's not like the number of discIds on any one release is statistically significant!
 
 
How about: Only auto-update the track times when there's 1 [[Disc ID|DiscID]] (when [[Disc ID|DiscID]]s are added/removed or there's a merge), but add the moderation type to allow users to choose the "correct" [[Disc ID|DiscID]]?
 
 
'''(now changed proposal to reflect this)'''
 
 
--[[User:ZeroGravitas|ZeroGravitas]]
 
----
 
 
The new simpler proposal is definitely better.  Note that there is already a "one-off" script (it runs every night) but it only changes the times if they are ''all'' undefined (?:??).  I still have a problem with the fact that your proposed change to this script would blindly use a (possibly incorrect) [[Disc ID|DiscID]], and thereby lose (permanently, modulo re-importing) the [[FreeDB]] track times, which might well be correct.
 
 
My preference is just for a SetTrackTimesFromDiscID [[Edit Type|EditType]], together with a report that lists releases where the track times and the disc ids differ greatly (> 5 seconds) - moderators can then look and decide whether to (re)move the disc ids, or reset the track times.
 
 
[[User:Dupuy|@alex]]
 
----Authors: [[User:ZeroGravitas|ZeroGravitas]]
 
  
 
[[Category:To Be Reviewed]] [[Category:Development]]
 
[[Category:To Be Reviewed]] [[Category:Development]]

Revision as of 19:06, 15 March 2009

Proposal for a better Track Times Calculation

There is a need to improve the mechanism that calculates the release track times. See also:

Current Mechanism

  • If a release is imported from FreeDB, the track times are imported with it.
  • If a release is added manually, the track times are set to ??
  • If a DiscID is added to a release with all track times set to ??, the track times are set from the DiscID.

Causes of Incorrect Track Times

  • AutoInsertFromFreeDB MultiSessionCDs affected by the MultiSessionCDBug.
  • Releases which were manually added and then given the wrong DiscID.
  • FreeDB imported releases (with track times) that someone has later done a AddTrackEdit (aka FrankenAlbums!!). These will have time ?? for the extra track, but adding a DiscID will not set the track time, since the other tracks have a time.

Problems with Current Mechanism

  • Currently the only way of fixing an incorrect track time is an ugly, time consuming workaround - reimporting the disc from FreeDB with the correct times, then merging the old release into the new.
  • It's not easy to audit the source of track times (e.g. due to moving DiscIDs or merging releases).

Proposed Mechanism

I propose a very simple change to the code:

When a release has exactly one DiscID, recalcuate the track times.

So this would be triggered:

  • When the first DiscID is added to any release.
  • When the second-to-last DiscID is removed from a release.
  • When two releases are merged (though assuming the first two rules have been applied, this would be redundant, since the track time the merging release already overwrites the "mergee").

Features

  • Nice and simple to code (and test)!
  • Track times from TRMs are still ignored (they're unreliable anyway).
  • DiscIDs trump FreeDB import in calculation of track times (but since we've got the DiscID, we don't need FreeDB).
  • Moving DiscIDs to or from a release automatically recalculates the track times.

Enhancements

In order to clean up the existing track times, could we have one-off script run to recalulate the times for all releases with a single DiscID?

It might also be handy to have new EditType to SetTrackTimesFromDiscID to allow manual selection of the correct DiscID.