-
-
Notifications
You must be signed in to change notification settings - Fork 799
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Navidrome shows different versions of the same album in one list #1976
Comments
Wouldn’t naming your album with the version work? I.E.: Tusk (Vinyl) |
Oh, sure it would. But it would just be circumventing the bug. If you're trying to manage a music collection programmatically, clean tags are essential. This is why there are other tags like release year or catalog number that can be maintained to make a release unique. In my case, all releases are properly linked to discogs, which also adds all kinds of release specific metadata. |
I see. I came from other music players where not every tag was honored, so I came up with this as well as a tagging structure from classical which is way not a nightmare as well as to help searching for music easier. The requirements where to be able to see version and conductor on an iPod gen 2 screen as well to find quickly in search. I would love it off music players honored, indexed, and played all tags, as everything would still organize correctly via tags but can also be backwards xonpatable with other players. Amazon music tags for instance is a nightmare. |
Yep. By now it should be clear that albums in multiple versions are a thing for people who maintain a local library (otherwise you could just use Spotify). The current behaviour is inconsistent, too - Navidrome ignores folders (which some may consider a feature) and relies on tags, but then does that only well enough to go for album and artist, apparently. |
Yeah I also noticed that but I usualy simply add the Media Type to the Abum Name and move on, because i'm currently re-tagging my multi TB Music Library for Navidrome and I just reached "G" after two weeks and can't/don't want to let things like that hold me back for too long. I also coded some Scripts for MP3Tag that tremendously help me to save time, but with the amount I have to re-tag, sort, cleanup etc. It will still take months, but at least it's done and clean afterwards. The Issue is that essentially:
CATALOGNUMBER, MEDIATYPE, PUBLISHER, COUNTRY and YEAR is ignored for sorting. So if you want the same ALBUM to be split eg. the Tracks to appear separately, add CATALOGNUMBER, MEDIATYPE, PUBLISHER, COUNTRY, YEAR to ALBUM. Or another possibility is to keep the same ALBUM and split them up with DISCNUMBER and SETSUBTITLE like:
If done so, they are all sorted into one Album but differentiated internally, which I personally prefer, especially if more then two different dupe Albums, EPs, Singles etc. Because it doesn't clutter the List with duplicate Albums. The only issue I have currently with this is that Navidrome doesn't display different Covers for different SETSUBTITLE, it would be nice if at least a little pic would be shown along with DISCNUMBER, SETSUBTITLE etc. If you only have some hundred of Albums split them up with ALBUM may be ok, but if you have ten thousands of Albums then it looks a bit different and it gets a bit tedious... |
Well, I get ALBUM and ARTIST (as well as many other tags) from the Discogs Release that I tag it with. This allows me to go back, pull the data from Discogs, and re-write tags as needed. Right now I'm putting that part into the VERSION tag - roon will display that in the album list. SETSUBTITLE is actually being used in many of my albums, where different discs will get SETSUBTITLE through Discogs data (like here https://www.discogs.com/release/11149783-Queen-News-Of-The-World "New pure analog cut" etc.) which is needed to differentiate different versions of a sing within a single "album" box set. I've looked at many of those issues recently, and VERSION seems to be the best bet. |
Just adding on that this is a showstopper for me. Like @koehntopp I've taken to using VERSION for this (and use discogs too!). That said, it'd be great if we could specify a 'decider' tag - be it VERSION or whatever else that someone might have used. This would just be the last level of deciding how to organize. At the least, leveraging the folder structure is a passable solution (and what i was using with airsonic advanced), but having the ability to specify a tag for this delineation would be perfect. Retagging my library just for this is not an option - the size of my library makes this all but impossible and i like how i've organized and tagged my music. All that said, navidrome is impressive and for me, is soooo close to replacing airsonic (and getting rid of java 🤮 - no offense to my java friends!) |
I also pull the data from Discogs or MusicBrainz and then manually adjust it to my needs. I especially manually adjust every cover (Get the best Quality one, Adjust Size to Square, Adjust Contrast, Exact Crop etc.) but I also adjust the Metadata if wrong which sadly happens a lot (Type Errors, Wrong Tracknumbers(1.1, A1 etc.), Wrong Album Titles, Wrong Artists, Wrong of missing (Discoq never sets it if not Various...) Album Artist etc.) While MusicBrainz always use the same clean format for Tracknumbers, Discogs is notorious for messing up Tracknumbers, they sometimes use 1.1,1.2,.. or A, B or A1, B1 etc. which Navidrome doesn't recognize and so I also need to correct them. I made a special Discog Fix Script for that purpose which handles all Discogs issues (Yeah there are many...) at once. So yeah cleaning up all that mess takes a lot of time even with sophisticated scripts I still need to accurately check every Album. |
Ah, yeah then #1363 won't do you much good. |
I just had an idea how Navidrome could cleanly handle that once and for all: Why not just create a hash of (MUSICBRAINZ_ALBUMID + DISCOGS_RELEASE_ID + CATALOGNUMBER + ASIN + BARCODE + MEDIATYPE + PUBLISHER + COUNTRY + YEAR + ALBUM + ALBUMARTIST) and use that hash to always split albums cleanly, guaranteed? All the Tags I choosen for that hash are expected to be Album specific and missing tags would also not be a problem for the hash, because they would not be taken into account automatically. The only problem would of course be if an album contains files with different album specific tags eg. files from different Albums compiled into one Album etc. but that would be something the user would have to fix either by re-tagging correctly or deleting the tags etc. And the nice thing about this solution is that it takes into account a large number of combinations in order to always split albums correctly and only a small hash (32-128bit) has to be stored in the database for this. But if implemented I suggest to add an Option to the Navidrome Config to define which Tags should be used for the Hash like:
The above example would result in the same behavior as it is now and could be the default so that nothing changes for current users. And users who need more or want to differentiate more finely can simply add some more and do a Full Rescan. |
#1363 supports migrating from the current behaviour to using Musicbrainz tags. It would be relatively trivial to adapt it for any arbitrary identification scheme. I was under the impression that Discogs is a proprietary site (and thus would put in no effort to support it), but it appears I'm mistaken after a quick search. Another thing to think about is artists, track IDs, etc. MusicBrainz has unique IDs for each "entity". Does Discogs? Supporting this generically would get a bit nasty. You'd have to have (using your example) Instead, perhaps supporting certain indexing "modes" is a better option. E.g.
@deluan Any opinions on this? |
That idea is not all bad. It would cater to most of the different approaches here. The only issue may be people mistyping tags, so maybe a list of checkboxes for all tags that the libraries used can recognize (and help for the purpose) would be easier.
That's slightly problematic. Not all directories support all releases. Both Musicbrainz and Discogs rely on users creating the releases, and most will be happy enough if album title, artist name and track names match. That's probably the extreme, though, but if I have the original CD or Vinyl rip, and the 5.1 Blu-ray, it would be great to be able to see them as different albums. VERSION so far looks most promising, which is why my little Python script (my personal version of beets, basically) will write them as "2005 DVD-Audio 192kHz HDAD 2011" and "2018 Blu-ray 5.1 96kHz RGM-0725" respectively. Maybe we should collect starting tags that "matter" for those cases? |
Navidrome has traditionally aligned with MusicBrainz tagging. The the correct tagname for this is Given users of at least one software player have taken to using a I like the idea of defining a hash based on user specified criteria, and it'd easily handle My tagger (puddletag) is set to name folders using %albumartist% - %artist% %version% and that's enough (in my case) to create a unique folder name, so I'd simply configure it to hash the folder name assuming it's exposed in Navidrome. All told though, relying on MBID is not a sufficiently robust solution because there simply are not enough albums in the MusicBrainz database. |
Like I said earlier, you'd need to support more than just albums:
Which is why I suggested having preset modes that we can guarantee are supported properly.
MusicBrainz can be updated ;) |
That setting would be done in the navidrome.toml file which you edit with a texteditor, so forget checkboxes.
Yeah and doing #1363 would be as easy as that...:
MusicBrainz has unique IDs for Albums, Tracks and Artists I also don't exactly get what you mean with Because Artists are or should be unique anyway and so the same Artists will always result in the same hash if you mean also hashing Artists? And I dunno if it makes any sense to split by MediaType without Album? Also only to clarify, the Hash I mean would be builded by concatenating all Tags contained in AlbumSplitHashTags and not hashing each one separately. This is either done by adding up all tags (in the defined order) into a string and then hash the whole or via serial adding each Tag as Data to the Hash, both results into the same hash. And if a Tag doesnt exist in file it also won't get added and so automatically doesn't matter for the hash. So to also split up Albums by Mediatype would be: Someone wants to split them up by Publisher? Split up by Country? And koehntopp probably would use: That way it's up to the user to decide what he wants or needs and it is also the user's responsibility to tag their files accordingly. Personally I probably would use: Also speaking of Discog's quirks, there's the issue with the track numbers: Discogs uses A, B, A1. B1, A2, B2 for Vinyl Albums and 1.1, 1.2, 1.3,.. for Albums where all tracks are unsplitted on CD and sometimes also 1a, 1b if they differentiate two Titles within the same Track etc. Navidrome doesn't handle them and I always need to re-number them with MP3Tag's Auto-numbering wizard. Here also some of the Tags that Navidrome already reads...: And here the Tag Field Mappings that MP3tag uses (Perhaps a good Idea to use the same, because they are humanreadabler): |
Whatever the solution, ideally it should be based on standard tags from one or more of tags received from Musicbrainz or Discogs.
I could easily "fill" '_releasecomment' from my VERSION, but that's hardly a good general solution
Yep. I just went through 600+ Discogs tags albums, I could not find suitable Musicbrainz releases for about 10% of them, and compromised on others (data OK, year off by 1 or similar) Discogs and Musicbrainz aside, even if albums are manually tagged with enough data to keep them separate should appear properly... |
Unfortunately, catalog numbers are not always unique, there are a multitude of different albums that have the same catalog numbers. Sometimes even Vinyl and CD releases have the same catalog number. Or purely digitally distributed albums sometimes have none at all, sometimes the same as some CD etc. So the catalog number is not such a good unique identifier. |
I've only been using the Docker version so far, so I have not used navidrome.toml at all
That's.... not really true....
It may be my tagger (Yate on Mac) takes care of this. But it would be great if there was support for other numbering schemes. There's information in those tags that currently get lost when tagging. In The Alan Parsons Project – Tales Of Mystery And Imagination the B-Side only has two tracks, the first one being a long one with subtitle, that may get lost when tagging. |
Before we go any further, do Discogs tags map to Navidrome's data model? Here's what it is currently, with Musicbrainz tags.
If they don't map directly, is there some combination of fields that can be used to munge a unique key? The main ones to be concerned about are "Track" and "Album", as they all need to globally unique. An earlier version of #1363 didn't handle "Track" properly and it manifested as tracks missing from albums when they were also present on another. |
AFAIK that's something for the tagger to solve - Navidrome should be looking at "Artist", "Album" and "Track", which may or may not be set by Discogs or Musicbrainz? I don't think Navidrome should care how files got their tags. If there are tags for well known databases it can show an icon or link to them, but for normal operation this should not make a difference. |
That's the way Navidrome currently works now, and the reason this whole problem exists. The track/album/whatever hierarchy cannot be uniquely represented using the standard tags alone (without putting all the disambiguating information in them, which is kind of gross). The only reason it works as well as it does, is because it uses In order to support this use case, Navidrome needs to support some way of uniquely identifying each album, and each track within an album. Same with artists and album artists, but they're somewhat less noticeable. I solved this problem for the Musicbrainz case by utilising the Musicbrainz tags. This allows everything to be globally, uniquely identified by tags alone. Using this, I can run This would work similarly for the Discogs case. |
Maybe that's why we're discussing it as a bug ;)
Are you sure it does? All my albums are in single folders, so how would two get into one album?
Does anyone know how other players do this? I'm using the exact same library on roon, Jellyfin and USB Audio Player Pro (Android), and they all get it right. I just tried Swinsian, which also puts them into one album.
Again, more than 10% of my albums do not have a correct MB release. I like the idea of a hash. I think it's safe to assume that we can come up with quite a lot of tags that should be identical for a release (album artist, album title, year, catalog number, discogs release url, musicbrainz album id, label, publisher, disc count, release country and many others). |
Indeed :)
If Navidrome didn't use
It's quite possible it's only using the file path to build the hierarchy, and only using the tags for display purposes. I'm also using the exact same library for both Navidrome and Kodi. Both get it wrong.
Yep, and that's why I suggested implementing a similar thing for Discogs.
A hash would work, but like I said, this would have to be done for tracks, artists, and album artists too. And even then, you'd lose the guarantee that moving files around on-disk won't affect Navidrome. EDIT: This would also break if you updated the tags, e.g. adding missing information. A rescan would think they're new files as the hash is different. |
The Filename is also part of the Filepath and so also part of the MD5, and try to copy two files with identical names into one Folder and look what happens. xD
Copying 1000 Albums into one Folder doesn't change anything if filenames are unique (OS limitation) and all Files are tagged correctly. Currently Navidrome splits by Albumtitle, Albumartist, so files to belong to the same Album must at least have the same and unique Albumtitle set or if same Albumtitle each one a unique Albumartist set. If that's the case and all filenames are unique, copying all into one folder is no issue and shouldn't change anything. Also why do you think Navidrome uses MD5(Filepath) as Database Key? For then sorting and splitting them into Albums Navidrome reads and uses Albumtitle, Albumartist and to work properly, every single file belonging to this album must have the same album level tags. Also for me sorting my Library with Folders only, isn't doable because it currently consists of: This also includes CD1, CD3,.., Disc1, Disc2,.. and whatever album unique Folders and Jpegs, Pngs,.., Textfiles an whatever album unique files. I also normally don't touch the filenames while tagging, so that I don't need to also change the .m3u files. I only rename files when they don't contain any valuable infos at all like (only Track1, Track2, Track3,.. or 1,2,3,.. etc.) only then I rename them into a fixed format (%track% - %artist% - %title%) or (%discnumber%-%track% - %artist% - %title%). One could now ask why Navidrome doesn't simply use the album directory as the album identification, because two identical directories cannot exist either. Well, what works best for files doesn't necessarily work for directories. As these examples show:
What exactly should Navidrome use as the album directory? |
Say you had the following:
You need the file path here in order to disambiguate. If it didn't, all three versions would be collapsed into one. Using the path works because they're individual files, and can't have children. Using the path for albums only really works if your library is sorted correctly on-disk, which I'm pretty sure isn't a requirement of Navidrome.
I didn't mean for Navidrome, I meant for the other players to see their behaviour. It was just conjecture.
Yep, never said it wasn't. I said it's the only reason Navidrome can uniquely represent every file. We're agreeing here.
Because Navidrome isn't meant to care about the directory structure in order to sort them. Directories, names, and paths should be immaterial for sorting, they are (and imo should only be used for) uniquely representing each file. |
Well, I have this And the Navidrome result is So please allow me to remain sceptical about the file path MD5 thingie. |
Hm? It's working as-intended, using the file path. If wasn't used, there'd only be a single copy of From func (s mediaFileMapper) trackID(md metadata.Tags) string {
return fmt.Sprintf("%x", md5.Sum([]byte(md.FilePath())))
}
func (s mediaFileMapper) albumID(md metadata.Tags) string {
albumPath := strings.ToLower(fmt.Sprintf("%s\\%s", s.mapAlbumArtistName(md), s.mapAlbumName(md)))
return fmt.Sprintf("%x", md5.Sum([]byte(albumPath)))
}
func (s mediaFileMapper) artistID(md metadata.Tags) string {
return fmt.Sprintf("%x", md5.Sum([]byte(strings.ToLower(s.mapArtistName(md)))))
}
func (s mediaFileMapper) albumArtistID(md metadata.Tags) string {
return fmt.Sprintf("%x", md5.Sum([]byte(strings.ToLower(s.mapAlbumArtistName(md)))))
}
|
Irrespective of which direction one takes on this the fact is there isn't a silver bullet in leveraging Discogs, MusicBrainz or any other metadata source. They can lend metadata to help, but 1) none are complete and 2) not all users resort to tagging leveraging either source. On the other hand, every user that has multiple releases of the same album, has in one way or another created a means of discerning one release from another in the players they use. Accept there is no universal standard and that a Navidrome specific decision needs to be made, communicated and then allow mapping of tags to that implementation. This is the only way Navidrome (or any other player) will arrive at a universal answer that works for any user's music that is currently capable of being disambiguated, regardless of what tags, folder names or combination thereof a user has ultimately adopted. Working on the notion that users must enrich the likes of MusicBrainz in order to be able to make use of a tool like Navidrome is to my mind flawed thinking in that it caters only for like minded people that are prepared to enrich their existing metadata with identifiers from those metadata sources. I'd hope that a solution would aim to solve the problem for all users, irrespective of whether or not they use discogs, musicbrainz or another metadata source. |
Any updates...? |
Easiest fix for this is just use the Disc Number/Disc Subtitle tags for reissues/etc, this will nicely show the different versions as different discs under 1 master album. If this is deemed to much of a "hack", another way to do this in an easy way for MB-tagged albums is to use the MB Release ID or Catalog Number as a splitter for "discs" (i.e. in the Web UI album tracklist, sort first by MBID/CAT#, then by Disc Number, with separators in between), this would have the same effect, should be fairly easy to code. Would all be client-side too, only thing the ND API would have to do is pass on the MB Release ID and Cat# for each song of the album. |
Yeah or simply add something after Albumname like [CATALOGNUMBER], (MEDIATYPE), (YEAR) or whatever you like.
Not really, I just ReTagged 207 Albums and out of the 207, only 15 were on MB, 190 were only on Discogs and 2 were nowhere and had to be custom tagged. What I also dislike about MB is the fact that they don't provide any Genre/Style tags. Overall Discogs also provides the better Tag-Quality. The only thing where I prefer MB is the quality of the covers, especially the "XW" and "Digital Media" ones, when available, but unfortunately the limited availability puts a spanner in the works. But Discogs also sucks, especially with their Tracknumber fckups like sporadic (1.1, 1.2; 1., 2.; A,B,C etc.) instead (1, 2 or 01, 02). So yeah unfortunately none of the TagSources are foolproof, all need custom fixes and additional work. Sometimes there are even big fckkups like totally bugged DiscNumbers like (1;1;1;1;1;1;1;1;1;1;1;1;,1,1,1,1,,1,1,1,,1,1,1,1,111111111111) instead (1) or absolutely wrong Titles or Years (2002//2002//2002//2002//2002//2002//2002//2002) instead (2002) and whatever, so unfortunately checking everything carefully is still required even with custom fixes. Guess with the amount I ReTag I probably meet every bug lol |
I think the ideal UI route would be to have one entry for the album in the albums grid/list, but individual editions to be separate when you navigate to that album, right? |
I don't think there is such a thing as 'the ideal UI route' ;) Allowing for a hash by user defined tags would most likely be the most versatile solution. Anything that can be done within an album, like creating virtual discs, can already be done today. Having separate top level albums based on tags can't. |
It is precisely that, a workaround that will at some point rear its ugly head and get in the way of other things one might want to get done. Rather than fudge it, fix the data model. |
just wondering, any progress on this "bug"? |
Wow! Don't know how I missed this whole discussion, sorry for that. I tend to agree with some here that there is no silver-bullet solution. I also use both MB and Discogs, but mostly try to use MB and update their catalog whenever I have time :) The solution I've been thinking since @vs49688 introduced #1363 is to allow the IDs to be configurable. So each of these functions could be configured to generate a hash of specific tags:
These functions could be configured to use a combination of any tag. This is basically the I think this is a mix of #1363 and the I'll think more about it and maybe work on that (based on #1363) for next release. |
Hey folks, I'm doing some work towards a solution for this. Can someone send me a couple of "duplicate" albums, with Discogs and VERSION tags? Preferable one FLAC and one MP3. If you can help, send it to deluan @ navidrome . org
@koehntopp Where is this code snippet from? |
Really nice idea! This would really help both supporting multiple album versions, and being able to ignore file paths entirely so you can rename files and directories without losing metadata. Is there any chance this configuration could allow for simple Boolean logic? (e.g. use MusicBrainz album ID IF present ELSE fallback to Album+Album Artist) |
@deluan you have mail. Same PW on both archives. |
Thanks @audiomuze and @flemmingss. Which taggers did you use? @flemmingss , I don't see any I still need one mp3 album or at least a couple of mp3 songs from the same album, with the tags above, so I can see how the same tags are stored in ID3v4. @certuna any ideas? |
Yep 😎. This will also allow multiple artists with the same name
I though about this, but I don't see a situation where it would be better than just doing Album+Album Artist+MusicBrainzAlbumID. |
Yeah I guess the only benefit I can think of is if you added an album that was mistagged and you could later correct the title/album artist without Navi seeing it as a new album. But this shouldn't come up often. |
Picard and puddletag. |
Hello, friends! |
In #1036 it is mentioned:
But this does not seem to be actually used. If it would it probably already would solve the issue for many cases, at least for re-releases. |
@VlaK0r I'm working on this, but the current "solution" is to make album names different ("Low Life" and "Low Life (Deluxe Edition)") or using different release dates. @phw See the 0.50.0 release notes about "Album splitting by Original/Release date" @audiomuze / @flemmingss Sorry, but I changed computers last month, and I lost your files. The links you both sent me are expired. Do you mind sending me the files again? Thanks! |
@deluan Yes, saw it. For my use case this already solves separating the albums. Thanks a lot for this. |
For the folks using discogs metadata, do you recommend any macOS tagger that gets info from Discogs? @koehntopp / @K4r0qtuYNE5G4qgZ which taggers are you using? |
|
I've been using Yate https://2manyrobots.com/yate/ forever for Discogs and Musicbrainz tagging. Happy Christmas! |
Description
I have several albums in more than one version - Qobuz Download, CD Rip, extended version....
On the file system, they are stored in separate folders. ALBUM and ARTIST tags are identical, YEAR, CATALOG and many others totally different.
Expected Behaviour
Make albums show up in different versions.
Additional desired behaviour: Show the VERSION and/or SUBTITLE tag in the grid to allow easy selection of the different versions.
The text was updated successfully, but these errors were encountered: