# Idea: list candidates in relation to path formats

**URL:** https://discourse.beets.io/t/idea-list-candidates-in-relation-to-path-formats/1511
**Category:** Development
**Created:** [September 19, 2020, 11:30pm UTC](https://discourse.beets.io/t/idea-list-candidates-in-relation-to-path-formats/1511 "2020-09-19T23:30:58Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![RollingStar](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.beets.io/rollingstar/32/728_2.png) [@RollingStar](https://discourse.beets.io/u/RollingStar)
#### Post date: [September 19, 2020, 11:30pm UTC](https://discourse.beets.io/t/idea-list-candidates-in-relation-to-path-formats/1511/1 "2020-09-19T23:30:58Z")

</div>

Beets is built around finding the _exact_ release a user has. But is that always necessary? My path format is pretty minimalist. An album might look like this:

Broke For Free - 2012 - Gold Can Stay

Currently, I have some additional descriptors at the end. But I haven’t thought about it lately. Right now it looks like:

Michael Jackson - 1982 - Thriller (1999 SACD)

But if I only have one release of Thriller, I might not care that my one and only release was 1999 or that it was SACD.

If the importer choices were aware of my path formats, it could cut 10 choices down to 5. In cases where hyper-popular bands like The Beatles have 100+ releases, it might cut down to 10-20. Beets could store this list of potential choices (i.e., 5ish MBids) and untangle it later if the user imports a dupe and has to resolve how one relates to the other.

I further discuss reworking the import flow [here](https://discourse.beets.io/t/project-roadmap/1291).

---

<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: [September 20, 2020, 2:26pm UTC](https://discourse.beets.io/t/idea-list-candidates-in-relation-to-path-formats/1511/2 "2020-09-20T14:26:06Z")

</div>

That’s an interesting idea! To clarify, there are actually two things going on here:

1. Simplifying the _display_ of candidates, perhaps using templates.
2. Actually trimming the _list_ of release candidates by “de-duplicating” ones that match on certain metadata.

The latter would be somewhat complicated to implement, because it requires thinking carefully about how the configuration should work and finding the right place to drop duplicates, but it’s feasible.