The many aliases of [no label]

Tags: #<Tag:0x00007fa5cabf23c8> #<Tag:0x00007fa5cabf2288>

I happened to discover that the special Label [no label] “(Special purpose label - white labels, self-published releases and other “no label” releases)” has no less than 40 aliases. In the list are such gems as “℗ 2012 Jungle Doctors” and “INDIPENDANT”.

It looks like 16 of the aliases were intentionally added. Some (like “N/A”) appear to be search hints to improve the discoverability of [no label]. Some (like “[самиздат]”, i.e. “samizdat”) appear to be back-door translation of the MusicBrainz application.

Many of the aliases seem to have come when bogus Label entries were merged into [no label]. It seems various editors (and maybe an iTunes import script) created a new bogus Labels in the course of adding self-published Release, instead of discovering and using [no label].

How did I discover this? When I downloaded the XML file of metadata for a [no label] Release, MusicBrainz supplied an XML entity for each alias. Probably correct behaviour, but it is a respect in which these aliases are a little annoying.

Would it be reasonable for me to delete, say, 20 of the aliases which resulted from merging bogus labels? I don’t know enough about the workings of MusicBrainz and of merging to know if deleting a post-merge alias would hurt something.

Or is it wiser to leave this pile of debris untouched, because it only rarely becomes visible and annoying, and because we can’t be sure that deleting it is benign?

Thanks for your wisdom.


Good spotting! Things like [no label] are always a bit of a mess unfortunately. But still -

If anything here:

doesn’t make sense or doesn’t belong, definitely do remove it!


That seems too much to me. I would remove the five aliases, [no label without the closing bracket, and probably demo and the one mentioning George Harrison. The others seem fine to me as either translations (don’t know what you mean by “back-door”?) or search hints.


If the aliases are properly tagged as search hint or translation you can ignore those when processing the XML.

Agreed. And the ones not already marked as search hint or translation should be updated to show their role.

1 Like

I’ve done some cleanup.


Are we leaving the typos as search hints?
Just curious!

ps I really wish I’d started a label called “Not On A Lebel” now :pensive:

Well, people seem to search by them, so yes.

Oh ok, I think I just caught on!
Because they’re added as search hints it means that someone actively added it as a hint, rather than a lazy typo that just got merged in… makes sense

Arguably, typos that got merged in are more useful search hints: they mean the mistake already happened at least once! :slight_smile:


It’s not correct that, if an alias of type=“search hint” is present, it means that someone “actively added it as a hint”. Looking at the merge release edits for [no label], it’s clear that most of these search hints were “a lazy typo that just got merged in”.

I respect what @reosarevok says, [quote=“reosarevok, post:9, topic:5788”]
typos that got merged in are more useful search hints: they mean the mistake already happened at least once!

But if “at least once” means “only once”, then it isn’t really a big problem. Having excess aliases is an enduring — small, but enduring — cost. The metric that really would help us make this decision is the log of what label names users searched for and couldn’t find, and the log of how often each alias helped a user get to the right label name.

But looking at the alias list now, I think @chirlu 's cleanup is good enough. I’m satisfied.

I feel like Sheldon Cooper here: “Was that sarcasm?” :confused:


Haha, no it wasn’t, I just had to do a lot of catching up in this thread :wink: