Stylized album/band names and tags (★)

Tags: #<Tag:0x00007fea5751b820> #<Tag:0x00007fea5751a588> #<Tag:0x00007fea5750b718>

This post is the result of trying to autotag David Bowie’s last album: Blackstar (★).

This release group was edited to have as the album name a symbol and title track as well. I get it, it’s art. But I am baffled by this kind of tagging style. How am I supposed to search for this track or album? Sorry, I don’t know the unicode numbers for ★ and I also don’t have it on my keyboard.

The file cannot be searched for, the tags cannot be searched for. It’s exactly the opposite result of why I use musicbrainz to organize my music data… It’s incredibly frustrating for some lofty goal. If “Blackstar” is good for wikipedia, it should be really good for musicbrainz too I think.

Same with “a‐ha” which is an even worse offender as the hyphen character is some obscure unicode version of the normal hyphen that looks exactly like a hyphen, but it makes it impossible to search for “a-ha” with a normal hyphen.

Can someone please enlighten me?

1 Like

This is intentional and the preferred character. See also STYLE-721

To undo it use the “Convert Unicode punctuation characters to ASCII” option in Picard or the “Hyphen unicode” plugin


MB is a music database first, a tagging database second. So if someone has convincingly argued that it was artist intent for the album to be called ★ then someone’s tagging preferences don’t trump that. Also, other people might prefer to tag it another way - so ‘artist intent’ is how we try to conclusively enter things, instead of endless back and forth between editors.

Sometimes artists use annoying characters, to be sure.

Chaban beat me to the Unicode plugin, but your player really shouldn’t be missing that search result!


thank you for the extra information and context

i am not a picard user so these solutions do not help me but help me understand the attitude.

i dabble in typography, and i disagree that particularly the “a-ha” / “a-ha” case (can you even tell the difference?) would pick the non-ascii version. i don’t see a clear justification to use the non-ascii character over the ascii one and i think it does more harm than good. at least in the other cases (single quote, double quote, etc) the difference is clearly visible and serves a purpose (opening/closing quotes, etc).

i didn’t even realize it used a different dash until all my searches came back empty, then i investigated. i hope it gets reconsidered.

Chaban beat me to the Unicode plugin, but your player really shouldn’t be missing that search result!

i would get back the search result if i used the other dash character. it didnt even occure to me it was a non-ascii dash. and now that i know the situation is not much better because i need memorize this special case and find a way how to enter that other dash character. how would i even do that on my phone or wherever my music collection is? i think it’s user hostile for no gains.

Just thinking out loud, but I wonder if a “search hint” might be beneficial, similar to what is done for artist records?

1 Like

Whatever program you’re using should return all hyphen types on a search for ‘-’. Rather than ask MB to dumb down its data to suit I would chuck those devs a bug report/feature request :+1:


how do you know the artist did not actually mean/write ascii dash?

Unless there is a clear indication of artist intent (the onus would be on the editor to show that), we apply generalised styleguide/language rules so that it’s consistent across the database.

Don’t get me wrong, I understand why it’s annoying. But the reason it’s this way is also because it’s easy to programmatically change every special character into a standard ASCII equivalent. But it’s not easy the other way round. You can tick a plugin box to fix your problem. But if we changed all hyphens in the database to a ‘-’, and someone does want the typographically correct one (for whatever reason), then there’s no way to automate that with accuracy.


Would any of picard’s settings/plugins help with the Blackstar album?

I do have this edition of the BLACKSTAR album.

Except the removable hype sticker, the packaging only mentions ★, not BLACKSTAR anywhere.
The spine says:


So I am happy having ★, not BLACKSTAR, in my MB collection.

Thanks to release group search hint alias and release search hint alias*.

I do find a-ha. :thinking:

* We see there that the release search should really use the release group aliases too.

You are on a loosing battle on that question. I think there are about a dozen different dashes that get used (hyphens, dates, ranges, etc), “speech marks”, apostrophes (think there are three of them), and many others. For me I first spotted it when my EAC ripped an album and made a new A-Ha folder. Couldn’t work out how it was sitting there next to another identical looking folder in the OS.

EAC has features to swap these prettified Unicode items out. So has Picard. Any app that uses MusicBrainz data will have to just adapt. We have to just accept that the database wants to use Unicode and then adjust our own files as we need for our own uses.

MP3TAG is excellent for bulk fixing stuff like this. You can load up ALL of your a-ha tracks and change all of them back to ASCII in a couple of button presses.

Even this forum is messing with the hyphens and apostrophe’s you are typing. This isn’t just a MusicBrainz thing - Discord and others also do it.

As to ★ - well, that has to be manually corrected.

MB search is blind to the dashes. OP is talking about searching his music collection. Though I have problems searching for p·u·l·s·e at MB now as I have to remember to type “p u l s e” as it doesn’t seem to find the alias “pulse” in a normal search.

1 Like

MB search works fine, mostly.
I think OP meant searching from the file system of their own computer or some other device. Just need to use Picard’s scripting or any alternate tool to suite their requirements.

1 Like


1 Like

Your script would rename all albums to “★” :wink:


This is by far not the only entity name consisting of only (one) emoji. Maybe some feature to replace them by their Unicode name (or alias) is needed?

The formal character name for ★ is BLACK STAR


Could a pseudo-release be used in the Blackstar case?

:rofl: That would certainly make local search an interesting challenge.

Manual edits are king for these rare cases… I like my unicode to appear for ½ or Japanese titles so the odd funky star is easy to catch. On my PC the album is called ★(Blackstar) and I hand typed that.

The disambiguation “Blackstar” is available in a hidden variable (see documentation).

So you can use the short length of the title or other logic to decide whether to add the disambiguation to your file naming string.


Isn’t that disambig on the Release Group? I already use Release disambigs (cos I like the delux edition text)

Too rare for me to need, so I hand type. But would fit neat in the new rdswift Options Settings thing.