Adrian Sampson ed51369dce track ordering now always uses bipartite matching algorithm, no longer assumes ... current metadata to be correct if it's complete Previously, we were using the Munkres algorithm (minimum bipartite matching) to order tracks intelligently only as a fallback if the current metadata was paradoxical or incomplete. This was because of a concern about the performance of the potentially-O(n^3) Munkres solver. However, it was found that (a) the performance is actually not bad, taking on the order of 0.02 to perform a matching, and (b) there was no recourse for the tagger to reorder tracks that were legitimately in the wrong order. Now, we get intelligent reordering of badly tagged music even when the metadata seems to be complete. To retain some of the functionality of the old orderer, the track distance metric was expanded to include a component reflecting the track index. In doing this, another bug was discovered in the UI that showed the track name differences based on an arbitrary ordering. Now, the tag_album function returns a reordered items list with every candidate.		2010-05-30 23:52:54 -07:00
..
rsrc	int casting is now more tolerant (allowing "0 BPM" in "It's Blitz")	2009-05-12 19:56:49 +00:00
test_autotag.py	track ordering now always uses bipartite matching algorithm, no longer assumes	2010-05-30 23:52:54 -07:00
test_db.py	track ordering now always uses bipartite matching algorithm, no longer assumes	2010-05-30 23:52:54 -07:00
test_files.py	track ordering now always uses bipartite matching algorithm, no longer assumes	2010-05-30 23:52:54 -07:00
test_mediafile.py	track ordering now always uses bipartite matching algorithm, no longer assumes	2010-05-30 23:52:54 -07:00
test_player.py	change to MIT license	2010-05-28 00:07:11 -07:00
test_query.py	track ordering now always uses bipartite matching algorithm, no longer assumes	2010-05-30 23:52:54 -07:00
testall.py	change to MIT license	2010-05-28 00:07:11 -07:00