Seeking suggestions: what MusicBrainz work could benefit from LLM assistance?

Hi all,

We have some spare LLM capacity available and would like to put it toward useful work on MusicBrainz. Rather than picking tasks ourselves, I’d like to ask the community for suggestions.

What LLMs seem to be reasonably good at, from our experiments:

  • Text processing — translation across languages, summarization, cleanup/normalization of free-text fields
  • Web search — cross-referencing external sources to verify or fill in missing information

Workflow options we can support:

  • Fully automated: LLM submits directly (only for low-risk, well-scoped tasks, and only after bot approval)
  • Human-in-the-loop: LLM drafts the change, sends to a reviewer by email, human approves before submission

What we’d like to hear:

  • Which areas of the database would benefit most?
  • Any specific gaps or backlogs where this could help?
  • Any hard “please don’t touch this with an LLM” areas we should know about upfront?

A bit about us. We run a project called Agentic Commons — putting LLM/agent capacity to work on open-data and open-knowledge projects, always with human review and community norms in mind.

On MusicBrainz specifically we’ve been contributing for a while — e.g. CJK aliases (Traditional Chinese / zh_Hant) for artists following the community-agreed spacing rules, and we went through the standard bot approval process earlier this year before scaling anything up.

Happy to prototype small pilots first and share results before scaling. Thanks!

1 Like

One suggestion that I can think of… In French (and probably other languages) there are ligatures that are hard to write with keyboard layouts available. It would be nice if a bot could correct spellings of some words with ligatures.

In French there are words with oe => œ

  • bœuf, garde-bœuf, langue-de-bœuf, œil-de-bœuf, pique-bœuf
  • chœur, arrière-chœur
  • cœur, accroche-cœur, cache-cœur, cœur-de-pigeon, à contrecœur, crève-cœur, écœurer, haut-le-cœur, rancœur
  • fœtus, fœtal
  • manœuvrer, manœuvre, manœuvrable
  • mœurs
  • nœud, entre-nœud, entrenœud
  • œdème
  • œdipe, complexe d’Œdipe
  • œil, clin d’œil, œil-de-bœuf, œillade, œillère, œillet, tape-à-l’œil, trompe-l’œil
  • œillette
  • œnologie, œnologue, œnométrie
  • œsophage, œsophagien
  • œstrogène
  • œuf, mire-œufs, œufrier
  • œuvre, chef-d’œuvre, désœuvré, hors-d’œuvre, main-d’œuvre
  • sœur, belle-sœur, consœur, demi-sœur, sœurette
  • vœu

and words with ae => æ

  • ad vitam æternam
  • cæcum
  • curriculum vitæ
  • et cætera, et cetera
  • ex æquo
  • intuitu personæ
2 Likes

One area where LLMs could be genuinely useful is finding missing external identifiers or references from reliable sources, while leaving the final decision to a human editor.

A few ideas:

  • Detect releases or artists that are likely missing official homepage, Bandcamp, Discogs, Wikidata, or other well-established external links, and prepare suggestions with supporting evidence.
  • Identify entities with sparse annotations and draft annotation text based on reliable sources, clearly citing where the information came from for human review.
  • Find potential duplicate relationships or inconsistencies (for example, artist names that appear to refer to the same person but are missing relationships), without automatically merging anything.
  • Suggest aliases or transliterations that follow existing MusicBrainz style guidelines, especially for languages where there are established community conventions.

Personally, I would avoid letting an LLM make subjective editorial decisions, such as genre assignments, release grouping, artist credits, or relationship interpretation. Those often require nuanced knowledge of MusicBrainz conventions rather than just factual lookup.

In general, I think LLMs are strongest when they act as an assistant that gathers evidence, prepares drafts, and highlights likely improvements, while experienced editors make the final judgement.

3 Likes

This makes me worried. Even with “human review” letting a bot go mad at trying to make links is tricky. It needs to work with more than just matching a name.

An example. I tried to use Navidrome. Only to find it is awful at matching artists when names are shared. It uses a hopeless source called “Last FM” and decided my “2K” (an alias of KLF) was some band from the US. And “Ian Curtis” is some other random American instead of the guy from Joy Division. (Even Wikipedia gets that search first time…)

An AI making a decision needs checking. But it needs checking by someone who can say “no, this is a guess” and not just “maybe, kinda looks right, but I don’t know the band”.

The above errors are easily solved by a human as we will not just match a name, but we will look at the artist and see if they performed that album\song\etc.

I don’t know how the LLM matches but it needs to do more than a name match. It needs to dig deeper and find an actual common connection on an album name or recording name. It needs at least two reference points to be happy. Three or four to be sure.

The trouble with a “human review” is you are assuming the human knows the answer too. :slight_smile: There are barely enough humans reviewing the current MB edits, so who will review this LLM?

6 Likes

Thanks for the detailed list — perfect candidate for a narrow pilot! We’ll start by running the ligature substitutions as a dry run on a small set of French annotations/comments to see how it behaves before anything gets submitted.

Thanks — this is super helpful, both the suggestions and the “don’t touch” list! Really agree on genre / release grouping / artist credits — when the standard itself gets fuzzy, that’s the worst place to hand it to an LLM.

The missing external links idea (official homepage, Wikidata, etc.) sounds like a great first pilot. We won’t just match on names — we’ll cross-check a few signals to keep accuracy up. Keeping it small to start :grinning_face:

Thanks a lot for sharing this — really valuable, and we take the concern seriously.

You’re right that even human review only works if the human can actually judge the answer. To your points:

  1. Subjective calls (genre, artist credit, relationship interpretation) — we’re not touching those with the LLM for now, exactly because they’re hard to judge confidently.
  2. For translation / info-gap-filling, we’ll follow your advice and match against multiple signals before deciding whether to fill anything in. If the evidence isn’t strong enough, we’d rather leave it blank than push a wrong match.

Across the board we’ll pilot in a small scope, and keep the human-review part to areas we ourselves can actually judge — so far most of our work has been on translations into our own native language, which is a good place to start.

Thanks again — this kind of pushback is exactly what makes the community better :blush:

1 Like

As there are not enough experienced eyes to validate the changes, I fear all the LLM bot’s edits would not be checked by people in the 7 days they stay open. Expanding the edit time or setting those staying open indefinitely may not be good either. Maybe if there are enough subscribers on the entity it could be ok.

If going forward with this kind of LLM assistance, I would recommend getting a new external link relationship type for artists.
Then you could create a web site and populate artist page there with any changes the LLM finds.
Then people could import/seed the changes from the page or discard and give feedback of errors.
I bet there would be some userscripts quite soon to implement all that to the MusicBrainz site and editing flows.

2 Likes

Could be nice if a bot could convert twitter links to x.com links

1 Like

I tend to agree: any edit made by LLMs should be validated by humans, we need something like a “suggested changes queue” that editors can accept or not, then it goes to normal vote period.
When an editor open an entity with such “suggested changes” they are displayed for quick review/accept/deny.
I don’t think that’s possible for now, but it shouldn’t be too hard to implement.

@Bitmap what do you think? The idea is a kind of “bot-only” queue, not direct edits. We could provide an API for it, so submissions to the queue can be automated, but acceptance cannot.
If nobody accepts the changes, they stay in the queue until they conflict or whatever.

Bot submission → bot queue → human accept/deny → normal edit
If no accept → keep in the queue for a while (or define a max size for the queue per entity and drop oldest non-accepted entries), dunno.

Just ideas, I think LLMs can help a lot with data quality, but only if humans supervise the changes. Accepting unreviewed changes from LLMs is a recipe for disaster.

LLMs should assist human editors, but not replace them (else the database will lose in value).

1 Like

No need for LLMs. This just requires a small script.

I could do it… If I had a local MB server…

And same. This is a script. Not a AI agent. Just select the recording containing the word and submit the edit

Guess case function is regex based and doesn’t work for languages with complex grammar rules such as German

2 Likes