Style Guides

Users of MusicBrainz and the members of the Style Council put some great efforts in working out detailed style guidelines, which state how data should be formatted.

The Style Principles

Status: Official Style Guideline

If you ask yourself in what style something should be entered into MusicBrainz, the following principles apply:

  • Follow Artist intent.

  • If no definite proof can be found for the correct spelling/punctuation, the most common version should be used.

  • Follow the style guidelines.

Alternative phrasing

This can also be explained from the bottom upwards:

  • Usually you stick to the style guidelines.

  • If you are still unsure how to enter something because it is labelled inconsistently on official sources, use the most common version.

  • Finally there is the notion of Artist intent. If you can show that the artist intended something to be stylized a special way, then you should enter it like that into the database.

Error correction and artist intent

As a general rule, MusicBrainz editors should correct spelling and punctuation and, to a lesser extent, grammar errors in artists’ names, as well as the titles of works, recordings, tracks and releases. However, this rule does not apply if it can be shown that an artist intentionally used unorthodox spelling, punctuation or grammar.

Error Correction

There are many cases of record companies incorrectly reproducing titles or even artist names, or breaking generally accepted rules of usage for stylistic purposes. In such cases it often makes sense to fix errors and standardize irregularities, valuing correct spelling, punctuation and grammar over faithfulness to the printed release cover. When the correction might be confusing, adding an annotation is encouraged.

A common example of error that should be fixed is tracks being printed in the incorrect order on a release’s packaging. The release tracklist should match the real (rather than printed) order, and a note explaining the issue should be added to the release annotation.


Artist Intent

Artists sometimes choose to present names and titles in ways that deliberately contradict the rules of the language they’re in (e.g. unorthodox spellings) and/or the MusicBrainz Style Guidelines. To describe the way we handle such choices, we use the term “artist intent.” The general idea is that if an artist intended something to be written in a special way, then MusicBrainz should follow that intent.

Unfortunately, it can be difficult to find out what an artist intended. If you want to claim that some deviation from the Style Guidelines should be considered artist intent, the burden of proof lies on you. A seeming error may be considered evidence of artist intent if it is consistently found on all of an artist’s official releases. The best evidence would be a statement of intent by the artist (e.g. edit 6892422).

Words in Latin script used in Japanese releases present a special case and are generally treated as artist intent; see the Japanese style guidelines for more information.


Old style practices

This section talks about the things we used to do, but no longer need to now that the data can be entered properly.

The limitations of the structure of the database has often meant that we couldn’t enter data in the most logical way and we needed to find other ways to enter the data. Since the database is very large, it can take quite some time for the data to be fixed when guidelines change or new features are added, so you may come across some of the things described on this page. If you do, feel free to help fix it.

There were a few things which were particularly problematic in the past:

  • A release couldn’t contain more than one disc. That meant that each disc had to be entered separately.

  • Each release and track could only only be linked to one artist. One-off collaborations had to be entered as separate artist entries.

  • Releases with the same track listing weren’t separate releases, but were instead different release events in the same release. There was no way to specify exactly which version of a release information belonged to.


To handle releases with multiple discs, we developed a style (Disc Number Style) to standardise the disc numbers and disc titles. People would also often add links to the other discs in the annotation. Later, a “part of a set” relationship was added to link the discs together. You may still see releases using “(disc n)” in the title, with links to the other discs in the annotation or with those relationships if they haven’t been fixed yet.

Examples of Disc Number Style:

  • “Release Title (disc 1)”

  • “Release Title (disc n: Disc Title)”

  • “Release Title (bonus disc)”


Originally, in order to reduce the number of one-off collaborations in the database, we had a style guideline which said to enter a track such as “Song Name” by “Artist A & Artist B” as “Song Name (feat. Artist B)” by “Artist A”. This was particularly controversial and was eventually removed, but you may still find collaborations credited in this way.

After that, we allowed people to add collaborations as new artists with a name such as “Artist A & Artist B”, and had a “collaboration” relationship to link to the artists involved.

With the introduction of artist credits, we can link to multiple artists and we don’t need to use separate collaboration artists. Many of the existing collaborations with collaboration relationships were converted into artist credits, but you may still see some which couldn’t be automatically converted. You may also see ones that didn’t have the proper relationships at all.

Release events

At first, instead of having a separate entry for each release, every version with the same track listing was part of the same entry and that entry had multiple release events which consisted of both a date and a country. Later, support for labels, catalogue numbers, barcodes and formats was added and the date and country were made optional.

The way the data was stored also meant that a release could only have one release title, so if a later version had a slightly different title, we couldn’t store that information. Releases also only had one status, so we couldn’t mark certain release events as promos or bootlegs either.

Lastly, release relationships also belonged to the release and not to specific release events. There was no way to say which release event that relationships such as cover art, ASIN, Discogs or purchase relationships belonged to, so you may find releases where these links are on the wrong releases.


We often use annotations to store information which doesn’t fit into the database at the time. There are far too many things to list here, so this is just a list of some of the most common things you’re likely to see. Of course, once data has been entered properly, it can be removed from the annotation.

Some things which annotations have been used for include:

  • Labels, catalogue numbers, barcodes and formats (see the “Release events” section).

  • The release country or the release date, from the time when a release event had to have both a date and country.

  • Whether some releases were bootlegs or promos.

  • Which version of a release an ASIN corresponded to.

  • “iTunes”, “limited edition”, etc. These can now be added to release comments.

  • Links to the other discs in the set (see the “Discs” section).

  • Credits which couldn’t be added because there wasn’t an appropriate relationship (e.g. instruments which weren’t in the list).

  • Clarifying credits where the relationships weren’t flexible enough.

Earliest release relationship

Originally it wasn’t possible to share recordings (then called tracks) between releases. If a recording was identical, they could be linked with the “earliest release” relationship. Most of these were automatically merged, but there were some which weren’t. Now that recordings can be merged, if they’re the same, they should simply be merged.