Disambiguating multiple items with the same name

MusicBrainz Picard
,
1

Hiya!

So sometimes I have multiple Releases with the same name. By default, this is a bit of an issue, as it means my music player interlaces them, trying to play the first track from all matching Releases, then the second, and so on. Sometimes they’re from the same ReleaseGroup (say, the DAT prototype, regular, and Super Deluxe versions of Dubnobassiwthmyheadman); sometimes they’re from a different ReleaseGroup (say, Future Sound of London’s Lifeforms album and single).

A quick fix

I can use the %_releasegroupcomment% and %_releasecomment% disambiguation fields to differentiate them, but I can’t simply use them globally, because a lot of the time, they’re used for other things (as I mentioned in a previous thread). I don’t need my only copy of Orbital’s lime green album to be disambiguated as “Made in Germany by Warner Manufacturing Europe”.

For now, I’m maintaining a script that checks the Release name against a custom list of values and tells Picard to only pay attention to those particular Releases’ disambiguation comments. So I’m manually telling Picard which Releases I happen to personally have multiple versions of, which works, but it’s messy and arbitrary:

$set(album,$if($eq_any(%_releasegroupcomment%,single),%album% \(%_releasegroupcomment%\),%album%))
$set(album,$if($and($eq_any(%album%,Dubnobasswithmyheadman,Movement in Still Life,The Bitter End,The Downward Spiral,We're in This Together,Zeroes & Ones),%_releasecomment%),%album% \(%_releasecomment%\),%album%))

I’m guessing some other people have done something similar, each with their own idiosyncratic lists.

A hypothetical better fix

What I think would be ideal is some way of telling Picard more generally “if I personally in my own music collection have two Artists, ReleaseGroups, or Releases with the same name, then please disambiguate them, otherwise please don’t”.

What would make the most sense to me is if a function was added to Picard that returns true if the passed value is ambiguous. Something like $is_ambiguous(), which you could for example send an %album% to, and it would return true if, looking at all matching %album% values in your collection, any one %musicbrainz_albumartistid% value within that subset had multiple %musicbrainz_albumid% values (so a Release name is deemed ambiguous only if you have multiple Releases of the same name by a single Artist, regardless of whether they belong to the same ReleaseGroup or not).

Or you could feed it an %albumartist% instead, and it would tell you if you have several distinct %musicbrainz_albumartistid%s in your collection with a matching name.

So if this function returns true, I could then tell Picard to pay attention to the relevant comment, be it %_albumartistcomment% (which doesn’t seem to exist?), %_releasegroupcomment%, or %_releasecomment%, and otherwise to ignore them.

I think this would be really useful, so everyone would be able to automatically disambiguate only what they personally need to, leaving everything else uncluttered, with a simple script like this:

$set(albumartist,$if($is_ambiguous(%albumartist%),%albumartist% \(%_albumartistcomment%\),%albumartist%))
$set(album,$if($is_ambiguous(%album%),%album% \($if2(%_releasecomment%,%_releasegroupcomment%)\),%album%))

So if you have CD 1 and CD 2 of a single, or the deluxe and regular versions of an album, or two artists of the same name, then they’d be kept separate. But if you have just one, any one, it would keep things terse and tidy. Nice and simple.

But I’m not sure if this would be near-impossible to implement… I’m guessing so, as I’d imagine Picard’s functions don’t have the ability to look at other items? Picard would have to keep track of a user’s whole music collection at once.

Anyway, that’s what to me would make sense as a possible feature request for Picard, but perhaps I’m missing something… Is this a terrible idea? (The work to payoff ratio certainly wouldn’t be great, unless keeping track of a whole collection at once has other benefits.) Is something similar already implemented, and I’ve simply missed it? Please let me know your thoughts!

Cheers!

2 Likes
2

I am watching the answers here too. I’ve also been looking for a solution to a similar issue. I have about a dozen different copies of Dark Side of the Moon. So I’d also like to be able to spot the 30th Anniversary edition from the original CD etc.

I do like the fact that KODI Media Centre does know to list all my Dark Side of the Moon copies separately as long as I have the MusicBrainzID in the files. Only thing there is me the human still has to guess between the versions sitting side by side. (The different looking covers helps there)

-=-=-

One point to add - Picard already DOES know about your whole collection. Do you use Collections on the main Musicbrainz website? When you have your release on the RIGHT hand side, right click and check the menu. You will see COLLECTIONS here. This is the same COLLECTIONS as you find in the main MB database.

In my setup I have multiple collections depending on my source material. Example being CDs, FLACS from other sources, LOSSY from other sources, Bootlegs, etc. This means that Picard could check a list for a duplicate like you mention…

But does it need to check the whole list? Wouldn’t just checking how many items you have from a single Release Group also get that answer?

Agree that is a messy answer as it dramatically changes Picard from a single release tagger to having to check collections… quite a different idea. Lots of complexity there to make the decisions. release+artist will have to be used as a pair. Then you need to find the matches… and what happens when you do have that match and there isn’t any disambiguration value anyway?

-=-=-

Here is a plugin suggestion that expands on your current quick fix: Maybe having a user created exceptions list that we can add to Picard. A list that is stored as a text file on the local PC alongside Picard settings. In that text file is a simple CSV list where we have MBID, TagName, Alternate Tag Value. This would allow us to keep a local list just for our personal use which lets us set our local alternatives for certain tags.

There are already plugins that are looking for instrument names and making changes. So it would work similar to that, but more specific to a MBID.

I know I’d also use this as a way to tweak names of certain albums. I could also see it being useful when an album is credited on the MB Database in a way that I want different on my PC. Or where a release is credited to a group that I know by a different name, etc. This would help with those arguments where you see people trying to change the MB DB because “it breaks their tags”.

2 Likes
3

Hi Ivan! (And Mr. Hoppy…)

I’d recommend adding a single-line script like I did, if you’d like to see the disambiguation comments just for a few particular albums you have multiple versions of:

$set(album,$if($and($eq_any(%album%,The Dark Side of the Moon),%_releasecomment%),%album% \(%_releasecomment%\),%album%))

Just replace “The Dark Side of the Moon” with a comma-separated list of all the albums you need to split out.

That’s a good point, thanks! I’m not sure how much Picard knows about collections, beyond the ability to add to them and remove from them. If it could fetch the data about a whole collection (or the relevant parts), then that would presumably help with my ambitious proposed function. Though I realise it’s a bit of a pipe dream.

Well sometimes multiple Release Groups by the same Artist have a similar issue of ambiguity. You’re right that you’d only need to look at a single Artist, but in terms of Picard being able to find everything you have by that Artist in the first place, it would either need to look at your whole collection, or it would need a way of requesting a single Artist’s contributions to it. So yes, doing the latter would be ideal, but I don’t think functions can make API requests, so I’m guessing it would probably need to look at everything and do its own filtering.

Yeah, this is more an ideal solution that’s probably far too impractical due to how radical it is, so I’m trying to think up alternatives in the meantime. For now, manually maintaining a list of relevant albums in the above script seems to work well.

When you find an album without a disambiguation value, you’d probably want to add one in the database. :slight_smile: This would presumably help out other people who also have multiple versions of that album.

In the meantime, it would also be possible to tweak the script to show the medium format (vinyl, CD, etc) for particular albums only. I think Release comments, ReleaseGroup comments, and medium names cover all the bases with ambiguity, but I could well be wrong…

As far as a plug-in goes, I think it would need to be easier for people to use than a one-line script to really warrant being a plug-in. So if it was a textbox listing one album per line, say, that might be less intimidating to people who aren’t comfortable writing scripts.

You could always have a long script consisting of lots of simple find and replace requests:

$if($eq(%album%,Official Name), $set(album,My Nickname))
4

@ZoeB Mr Hoppy says “Hi” (You are in a very small group of people who have recognised us…)

I have a few scripts of my own already messing around with my album titles in a far too unpredictable manner. Trying to add all the different album names into the script window gets too messy for me. I end up manually changing titles by hand while tagging.

If I was going to use your script, I’d adjust it to work on MBID instead. (How many “Greatest Hits” albums are out there… words are just not unique enough) And once I am up to 50 albums that script would get undreadable.

Trying to maintain a script is especially messy for me as I run Picard on three different computers. This is why a single text file holding the substitutions would be a simpler solution to share between instances of Picard. That can be updated through the Picard GUI or Notepad. Less of a change to the overall product.

I am already getting lost at the number of permutations a collections search script would require. I can’t see the time being available for the already overworked devs to get into something so different.

Some points you mentioned -

Are you aware that there already is a plugin that adds Single, EP, etc to titles?

This doesn’t always work. Sometimes what I want as a disambiguration does not follow the guidelines and someone else deletes it. Or you get albums where there are dozens of different variations, but no official disambiguration for them. Have you seen how many copies of Dark Side of the Moon that MB lists? https://musicbrainz.org/release-group/f5093c06-23e3-404f-aeaa-40f72885ee3a

And that is only a fraction of them… the Discogs list goes to 667 editions. Problem is releases like this get messy for albums like DSOTM as people want to spot their differently manufactured copies. So a copy with a UK manufactured disk and Dutch paperwork is different to the one with UK disk and UK paperwork, different to the ones with and without barcodes… all kinds of mad variations, especially in the 1980s, but not something that gets put into the disambiguration field.

Variations that are important to select the right one in the database to get the correct MBID in the tracks, but not important enough to have as disambuiguratyion data. So we are back to those multiple uses of disambiguyratitation data ahain.

(I really dislike that word - disambiguation - before MB I had never heard of it… and my fingers just can’t type it… :rofl: too much back and forth between the hands)

I can see many problems with trying to get your idea to work fully automatically and cleanly. I don’t know where the amount of time would come from as it would involve too many changes to the core. Trying to automate it will be too complex.

So keep it simple. Expanding the idea of your script should be more achievable as a plugin. (Especially as there are more plugin devs). Something under the user’s control to pick out their own specific edits. Keep it simple. Keep it to specific items chosen by the user. Searching collections just adds too much work for the results achieved. I can’t imagine how the GUI would have to change too…

I’m going to let some of this settle around my head. Your comment at the end about a substitution script may be ready for some kicking and tweaking around. You’ve got me hooked now. Need to change to spotting Release MBID’s and then do the substitutions - otherwise how would you spot each different version of the album?

If I wasn’t so busy in RL, I’d maybe even experiment with creating this plugin… lets see what happens this weekend. You’ve already sparked me up to look at kicking a variation of your script around. :laughing: The more script examples we can tweak in here, the closer we get to a requirements spec

I’ll have to check with Mr Drummond as to my availability… :wink:

5

Oh wow, yeah, I vastly underestimated the complexity of your setup there!

Thanks! That looks nice, but personally, I only want to use it on the two pairs of releases in my collection that happen to be ambiguous (because the single and album have the same name). When it comes to all the other singles, I don’t need to be reminded that they’re singles.

Hmm, that’s a good point, thanks. I guess I’d assumed that any different versions of the same album one person would have in their collection would be different enough to warrant adding such a comment. I could see someone having, say, the stereo and quad versions, and the quad one being commented as such… or the first CD re-release and the 30th anniversary edition, and the anniversary one being commented as such… Again, I think I underestimated the completeness of some people’s collections!

(Incidentally, I kind of love the idea of someone whose music collection is just one album, but in every possible format available… And always imagined it with Dark Side of the Moon… But I digress…)

Ah, yes, that whole issue I was hoping to sidestep in a simpler way… This idea backfired then, ha!

Hehe, I only mentioned Mr. Hoppy because I’d finally given up waiting for the opportunity to “subtly” slip into the conversation “…only I never done it, I only said I’d done it so they’d stop…”

I’m glad you’re excitedly looking into related bottom-up possibilities now, even if it is coinciding with me giving up on my lofty top-down ideas again… Good luck!

1 Like
6

One of the things here… is that Picard has no idea what all files you have available locally. Yes, you can hook it up with a MusicBrainz collection, but Picard won’t know if that collection is or isn’t up-to-date with your local files. This could be good enough to work though, if you’re aware of the potential pitfalls.

Another option could be to look into using an actual music library organiser tool, like beets. beets has an %aunique{} “path format function” that does/is pretty much what you’re requesting from Picard.

3 Likes
7

Thanks! Beets sounds like what I’m after. I’ll look into it.

8

Haha - only the two? Yeah… I think the dev may swear at you a bit if this is only two releases that are clashing and he has to do months of work to “fix” that. :rofl:

I used to be a developer, now more of a system engineer\support trouble shooter. But I have a head for testing and thinking out all the possibilities. I’m not trying to upset your plans, but opening up what it may mean to others. Any plan has to cover the “awkward cases” as there is no such thing as a “normal” collection.

My setup probably isn’t as complex as some people - I’m just on the start of that slippery slope. I was showing some examples so you can see how mad some people will get.

Jumps onto sideways conversation - if you want to achieve your secondary challenge of a “collection of a single album” then Discogs will help you put that together as I misquoted the total earlier. They actually have 828 different editions… but these will mainly be little artwork changes. https://www.discogs.com/Pink-Floyd-The-Dark-Side-Of-The-Moon/master/10362 so that would be at least 43mins x 828 approx 25days of non stop dark side

Comically… just looked down and realise I have DSTOM T-Shirt on.

Haha… nothing is “simple” when you are trying to throw a big standardised net over all the loonatics who collect music. Everyone uses these fields in different ways. Especially as we have this mad overlap between Music Collectors and Database Geeks all with a different idea of “standards”.

@freso’s point about the collections not being perfectly in sync, and the lack access to local files, all adds to the levels of complexity you have requested. There are probably more error cases to handle than simple code.

I have to admit when I saw “beets” I thought that was the Apple thing and recoiled in horror (and confusion). Then saw it was an open source tool. Phew. Was worrying that @freso had been kidnapped and dragged over to the Apple Dark Side. :wink:

Personally I use KODI, it is a weird media centre as it is also trying to be all things to everyone, but it is really handy that it indexes so much of the music side around the MB Release ID. The new v18 release has a massively overhauled music library built around Musicbrainz database. If it find the MBIDs in the files then it works rather well (and still improving)

Really it should be the job of the Media Player to make it clear which version you are choosing. Picard “just” adds the tags so that Media Player can make a sensible decision.

There are so many ways that I could reply to that one… but I’d get locked up again. :see_no_evil::hear_no_evil::speak_no_evil: Or banned from the forum. :rofl:

Instead I’ll answer that by way I am going to be messing with scripts on this. You’ve got my head going as it can solve issues for both of us. And once I have scripts going I’ll look at the plugins at a later time. This should be a fairly straightforward mod of some other plugins. This would solve problems for many people who disagree with the style guide and don’t like how their favourite album gets renamed to fit someone database rules.

Ultimately we need to think about how to get the core of your idea massaged into something that fits Picard current design and abilities. “Picard uses an online database to update some data in files it is given”.

So ultimately I can see a rule of:

If MB Release ID = xxx then (do these tag substitutions, use this specially mangled title, etc)

A script can do that, but scripts get lost in this forum. So a plugin would be a more sensible option in the longer term.

I’ll be back… (assuming Mr Hoppy behaves)

(You also know I want to take this massively OT and talk about Monkey Dust… a ton of it is on YouTube and people need educating :D)

1 Like
9

Well that’s another thing, Picard’s scripting abilities are great, but it took me forever to find existing examples that already did things I was starting to work on. Things like having a set of outer directories for the first letter of the artist name are great! In my opinion, it really should come with some good all-purpose scripts like that built in but turned off by default.

At least, when I see a plug-in with a single line of code in it, it seems the main reason it exists as a plug-in rather than a script is simply so people who have Picard but don’t know about the community can actually find it…?

Anyway, I’d best be going, I spent all my money on cola cubes and now I feel sick… :smiley:

1 Like