• and similar characters in titles and artist credits

Tags: #<Tag:0x00007f0ea2a310a8> #<Tag:0x00007f0ea2a30fe0> #<Tag:0x00007f0ea2a30f18>


I know of certain artist credits or song titles that have • characters embedded in them.

Example of artist credit:

(cover scan: https://ia801301.us.archive.org/13/items/mbid-bbe6fee1-4934-4d1c-a128-1b997210271f/mbid-bbe6fee1-4934-4d1c-a128-1b997210271f-11774658611.jpg)

Example of titles:

(back cover scan: https://ia802801.us.archive.org/11/items/mbid-7388c8e8-dafe-4637-bf60-1e79c71c5e7e/mbid-7388c8e8-dafe-4637-bf60-1e79c71c5e7e-20856234292.jpg)

To me both these cases look like adding • was a choice of the graphic designer. So it’s just a graphical decoration, not really a part of the title. I think trying to represent these characters in artist credits or titles is going too far. But I understand this is just my subjective opinion.

For the artist credit I would use “Lydia Lunch, Zahra Mani & Mia Zabelka” (per https://musicbrainz.org/doc/Style/Artist_Credits “No printed join phrase”), and for the titles I would rather use “Ектения I: Очищение” (per https://musicbrainz.org/doc/Style/Titles “Subtitles”).

I would change these, but the last thing I want is to start a pointless edit war. So I thought I’ll ask here first. What do you think?


There was at least this discussion whether a bullet (•) is a valid separator for series numbering:

1 Like

Just because we have Unicode support it doesn’t mean that we should always attempt to find a symbol similar to what the graphic designer happened to like and use.

In the discussion @chaban linked to, there is even some unceartainty about which Unicode symbol is supposed to be used: • (bullet) vs. · (interpunct). In examples from my previous post, looking at the relative size of the character and letters, it seems like bullet should be used for Lydia Lunch et al. artist credit, and interpunct should be used for Батюшка titles. Or maybe not? Do we really need to have such discussions on case-by-case basis?

The Style/Titles guideline begins with a following sentence:

When entering a new release into MusicBrainz, the titles should be normalized by following these guidelines.

To me getting rid of such Unicode characters (or not using them in the first place) falls under “normalization”.


I would leave it as credited as much as possible personally. And just update the recordings.

If it’s a metal or ‘heavy’ genre release I would say the way they’ve credited it on the digital release is more appropriate/common:
e.g. split release style: Lydia Lunch / Zahra Mani / Mia Zabelka

1 Like

This is also my opinion.


But we should not either always try hard to find an ASCII equivalent for each printed characters. :stuck_out_tongue_winking_eye:

There is often a lack of hyperlinks. :sob::stuck_out_tongue_winking_eye:
And please cite the text where it’s said we should try to remove unusual (?) characters.


I don’t see a contradicton here. It’s a matter of finding balance. :slight_smile:

Well, that’s my point - apart from the mention of “normalization” there are no detailed rules. This is up to interpretation, and my opinion is that we shouldn’t use these characters.

This is the reason I started this thread - I wanted to know the opinions of other people.

1 Like

It says:

the titles should be normalized by following these guidelines.

So if you find nothing in the guidelines saying this middle dot or that curly brackets or whatever should be transformed, it means there is nothing to do, just keep it as printed.

At least with your two examples, it’s what I would have done (like their editors did) for the release and track titles.
And for the release group and recording titles, it would be same except if inconsistency, choose the earliest and most official styling.

I don’t think unusual/creative punctuation is such an issue for these example.

IMO the subtitle guidelines is great for when we only have prints like this:


So we have to add some separator to put that on a single line, and the guideline says how to.
But when the package shows how they see it, we don’t need to transform.

Same for the AC. You say there is no printed join phrase but there is one with middle dots, specifically. :wink: