This has been discussed in our Discord server, and it's been in my head for some time now, but we didn't have a issue to track it. Thanks for opening it.

After the integration with TagLib (#480) is complete, I'll be able to start working on improvements in the scanner, including more tags and multi-valued tags, and will probably be tackling this then

By the way, what I currently do in my own library in these cases is to add a disambiguation qualifier in the name itself, like:

$ ls -1d L.*
L.A. Woman
L.A. Woman (40th Anniversary Mixes)

I understand this is not ideal for some people, but I personally prefer to clearly see the disambiguation, as sometimes even the cover art for the albums are the same.

I used to do that, but my library is now at the scale where needs to be managed by beets, so that won't work unfortunately.

Well, I also use beets and I do a beet mod -a album="name" when this disambiguation is required at the moment I add the new album. But my library is only ~4500K albums, I know that some people out there has waaaay more than this :)

Anyway, besides using the MBIDs to disambiguate the albums, do you have any suggestion on how to make them visible distinct in the UI (if the cover art happens to be the same)?

Huh, I didn't know about beet mod. I'll look into it.

Personally, I'd be fine with an extra (YEAR),(COUNTRY), (LABEL) or (CAT) string appended to the album name (or some combination thereof), similar to what Beets does,

Album Name (2003, XW)
Album Name (2005, DE)

If some fields don't exist, then try others, before finally falling back to MBID. e.g, unlikey worst case scenario, in which case someone should submit an edit to MusicBrainz and retag:

Album Name (2003, XW, 7a606fec-9677-4632-890b-5f307005d729)
Album Name (2003, XW, 83c3801f-843e-4787-aa14-6e1c911e49c0)

Or just spit a warning in this situation and retain the current behaviour.

In my beet.cfg, I've got it using:

$albumartist/$album%aunique{albumartist album, albumtype year country catalognum label albumdisambig mb_albumid}/$track $title

So it'll first attempt to disambiguate based on type, then year, then country, etc.

If you wanted to be extra fancy, perhaps some kind of overlay on the album art in the bottom corner:

______________    ______________
|            |    |            |
|            |    |            |
|            |    |            |
|            |    |            |
|       2003 |    |       2005 |
--------------    --------------

Hello, I'm raising back this topic from last year 👋

I've been changing the name of the album in the first place to fit the need, but it starts to be really bothering with my collection. But when I navigate on the album list, that different years are displayed (it's already nice to know) like this:

But I think, what could be a way to display it in album details (when I click on it to 'enter') is to split it, for albums with few CDs. Or to have another entity in the album grid. I don't know what would be good, I just want to reassess the topic 🙂

Very very WIP, but here's initial progress:

@vs49688 Nice! How are you disambiguating the albums? Do you have the code pushed? It would be great to have a Draft PR so I could easily take a look whenever you wanted feedback or discuss any implementation details

@deluan See #1363

With this, would it be possible to have an option to show the catalog number if it exists?

E.g. for Full House, show RLP 434 in the bottom right corner or in the center on mouse over?

With this, would it be possible to have an option to show the catalog number if it exists?

E.g. for Full House, show RLP 434 in the bottom right corner or in the center on mouse over?

The data is already provided by the /api/album endpoint, it would simply require a frontend change.

It would be great to see any progress in this regard, because every automation software(picard, beets) sets the album title back to the original name which then leads to the problems of non ambiguity in navidrome which is very frustrating since there are a lot of artists where this problem occurs.

@HolyMacarony PR to fix it is here #1363. I've been running it since June without issue (except I've hit #1564 hard, but that's unrelated).

thank you very much. i just build your PR and now i have a bigger navidrome file (41mb instead of 35mb). But i dont seem to understand how i can trigger this conversion process towards MusicBrainz-Album-ID. Because i completely rescanned two servers using the new binary file but it does not make a difference. All of my checked Albums have a different MusicBrainz-Album-ID and are shown identically. Can you please tell me where i should look to see whether your conversion script "About to convert database to use MusicBrainz metadata. This CANNOT be undone." is running? Thank you

The conversion is a manually-triggered process:

1. Stop Navidrome.
2. Back up your database. Seriously, do this.
3. Start a FULL offline re-scan. This is in order to pick up the new Musicbrainz tags we're now capturing.
4. Run navidrome use_mbzid. Let it finish.
   • If it fails, please attach a copy of the database backup here so I can have a look.
5. Once it's finished, do another a FULL offline re-scan.
6. Restart Navidrome.
7. ...
8. Profit?

This is great! thank you i just tried it on all ABBA and AC/CD albums, worked flawlessly! But first i only did ABBA as offline scan. After that i added AC/CD and did an online full scan, which worked, too. So does that mean, it does not need to be a offline scan at all? So i can just always make the full scans online as usual? Thank you so much. This PR makes my collection usable with navidrome, thank you very much!

You're welcome, am glad it's being used.

You can do online scans as usual, the offline ones were just to minimise the risk of anything going wrong during the conversion.

@vs49688 sorry for being a nag, but is there a built winx64 version of this?
I won't be able to build it, and 70% of my library are multiple editions of the same album..

No sorry, I don't use/have any Windows machines.

@vs49688 Nice! How are you disambiguating the albums? Do you have the code pushed? It would be great to have a Draft PR so I could easily take a look whenever you wanted feedback or discuss any implementation details

Whilst using MBID is great it's limited in usefulness because it relies on 1) the album version being present in Musicbrainz and 2) the user's tags including the pertinent Musicbrainz info.

Reference should also be made to folder name in which an album resides (as the folder name may contain disambiguating information) and reference should also be made to a specified tag e.g. "version", which if present serves to disambiguate one release from another.

Per MusicBrainz the the correct tagname for this is _releasecomment and Picard can be made to pull it when it exists - see https://community.metabrainz.org/t/add-album-version-tag-using-picard/539876

Given users of at least one software player have taken to using a version tag for this purpose, having the option to map version (or any other user named tag) to _releasecomment would be useful. This way Navidrome maintains alignment with MusicBrainz whilst accommodating users coming from other software.

@vs49688 Nice! How are you disambiguating the albums? Do you have the code pushed? It would be great to have a Draft PR so I could easily take a look whenever you wanted feedback or discuss any implementation details

Whilst using MBID is great it's limited in usefulness because it relies on 1) the album version being present in Musicbrainz and 2) the user's tags including the pertinent Musicbrainz info.

Reference should also be made to folder name in which an album resides (as the folder name may contain disambiguating information) and reference should also be made to a specified tag e.g. "version", which if present serves to disambiguate one release from another.

Have you looked at the PR? It falls back to the existing behaviour if there's no MusicBrainz tags.

210eed7

Have you looked at the PR? It falls back to the existing behaviour if there's no MusicBrainz tags.

I've not looked at it. My comment is intended to address the existing behaviour rather than your PR, which by all accounts does a great job leveraging MusicBrainz when the relevant metadata is present. It's when the metadata required for your PR to do its work is not present that my earlier comment applies.

I use a tagged called Release Type which works really well locally using MusicBee. I populate it with things like 'UK, Re-issue' etc. I use another tag called 'Source Medium' to differentiate vinyl rips from CD rips.

I then use a script within MusicBee to move my library items and create my desired folder structure. Eg:
Metal\Metallica\1984 - Ride The Lightning [Japanese; 1st Press] [Vinyl]

I'd love to see the option to be able to actually configure UI elements to display based on tags. This would enable users to set it up in their own way. There's never going to be a way that suits everyone.

Hello @deluan i'd like to ask whether there is any other official way we are supposed to use navidrome without having this pull request merged? I mean there are countless bands in my collection which have exactly this problem of X Albums of the same name. look at ABBA or ACDC e.g. Without this PR navidrome renders itself not useable because of the lacking folder support. So what is the supposed alternative if this great PR which solves this problem is not going to be merged in navidrome? How does anyone use navidrome without this feature? i dont understand how it is supposed to work otherwise. Hearing every song of an album multiple times before the next one starts is not really an option imo. Thank you !

without this PR

with this PR

Deluan has proposed this: #1976 (comment)

Which I agree with.

In the meantime, use this: https://github.com/vs49688/navidrome/tree/v0.49.3-mbz

I'm maintaining that fork until something is merged. I usually update it within a few days of a new release being tagged.

EDIT: I don't provide binaries though, so you'll have to do that yourself (unless you use Nix).

Splitting multiple releases of the same album, based on the Release Date tag (i.e., different Release Date = different Album) will hopefully come in the next release once the last wrinkles are ironed out of this PR #2162

(this even works with the non-standard way that Picard uses the Original Date & Date fields).

This should already fix nearly all of the "difference versions" cases in practice, except if the different versions were released on exactly the same date.

This is now merged and implemented - can be closed? Or do we keep it open to discuss disambiguating based on mb_albumID?

The solution proposed in #1976 (comment) is a generalisation of both #2162 and #1363, so I'd say keep it open until something like that is done.

#2162 is insufficient for my needs unfortunately, I'll have to keep using #1363.

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Navidrome team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.