# RFC: Proposed new penalty/distance: tracktotal

**URL:** <https://discourse.beets.io/t/rfc-proposed-new-penalty-distance-tracktotal/956>\
**Category:** Help\
**Created:** [October 3, 2019, 8:51pm UTC](https://discourse.beets.io/t/rfc-proposed-new-penalty-distance-tracktotal/956 "2019-10-03T20:51:21Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![kergoth](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/kergoth/32/240_2.png) [@kergoth](https://discourse.beets.io/u/kergoth)\
**Post date:** [October 3, 2019, 8:51pm UTC](https://discourse.beets.io/t/rfc-proposed-new-penalty-distance-tracktotal/956/1 "2019-10-03T20:51:21Z")

</div>

This penalty shows up when the tracktotal doesn’t match up. Either  
`missing_tracks` or `unmatched_tracks` is likely to _also_ trigger in  
such a case, but it’s useful to distinguish the case where we’re  
matching an album where I don’t have the whole thing (tracktotal  
matches) from ones where it’s matching what’s probably the wrong album  
release (tracktotal doesn’t match).

This would only have an effect when both the items have a tracktotal and  
we have medium\_totals for the info, and would check against both the  
current disk medium\_total and the total across all disks, since we don’t  
know whether the imported tracks use per disc numbering.

This would let me bump the distance weight to move albums with  
mismatched track totals down the candidates list for cases where it’s likely  
not the same album release, while letting incomplete albums with the  
same total stay farther up the list.

Thoughts? Too much complexity? Could it be optional, or allow plugins to  
extend distance calculations? I’m playing around with a prototype now.

---

<div class="post-metadata">

**Author:** ![adrian](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/adrian/32/4_2.png) [@adrian](https://discourse.beets.io/u/adrian)\
**Post date:** [October 3, 2019, 10:34pm UTC](https://discourse.beets.io/t/rfc-proposed-new-penalty-distance-tracktotal/956/2 "2019-10-03T22:34:05Z")

</div>

It’s a good idea! However, the bad news is that I think it is surprisingly hard to implement. The track matching mechanism uses the “Hungarian algorithm” for the weighted bipartite matching problem (implemented in the Munkres Python module, if you’re looking).

This setup sort of bakes in the assumption that the match will use all of the tracks, if possible. To set up the ability to leave tracks unmatched even when matches exist, we would need to modify the problem formulation, possibly with additional “dummy” graph vertices that signify the lack of a match.

This is all to say: it’s definitely possible, but I don’t know how to do it easily. If you’re motivated, I recommend you jump into the matching code to see if you can sort out how it all works currently.

---

<div class="post-metadata">

**Author:** ![kergoth](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/kergoth/32/240_2.png) [@kergoth](https://discourse.beets.io/u/kergoth)\
**Post date:** [October 3, 2019, 11:41pm UTC](https://discourse.beets.io/t/rfc-proposed-new-penalty-distance-tracktotal/956/3 "2019-10-03T23:41:01Z")

</div>

Hmm, I’m okay with it using all the available tracks, I just don’t want to apply any candidate that’ll change my tracktotal fields, since it’s probably not the right release (i.e. bonus track editions for itunes or amazon are often missing from musicbrainz). I think what you’re discussing is worthwhile, but independent of and future enhancement of what I’m proposing.

---

<div class="post-metadata">

**Author:** ![adrian](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/adrian/32/4_2.png) [@adrian](https://discourse.beets.io/u/adrian)\
**Post date:** [October 4, 2019, 1:44am UTC](https://discourse.beets.io/t/rfc-proposed-new-penalty-distance-tracktotal/956/4 "2019-10-04T01:44:54Z")

</div>

Oh wow, I’m sorry about that! I read your original post too quickly and thought this was about something else entirely.

Yeah, this makes sense to me. To clarify, the `tracktotal` for the penalty would come from the metadata, right? Not from the actual number of files we have?

This sounds perfectly reasonable and sounds like a pretty straightforward thing to do. Sorry again for not getting it the first time around!

---

<div class="post-metadata">

**Author:** ![kergoth](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/kergoth/32/240_2.png) [@kergoth](https://discourse.beets.io/u/kergoth)\
**Post date:** [October 4, 2019, 2:35am UTC](https://discourse.beets.io/t/rfc-proposed-new-penalty-distance-tracktotal/956/5 "2019-10-04T02:35:35Z")

</div>

Exactly, yes. tracktotal in the item metadata compared against medium\_total from the track info, with a bit of finagling to deal with per\_disc\_numbering, basically.