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!
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.
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.
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. There are barely enough humans reviewing the current MB edits, so who will review this LLM?
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
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:
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.
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
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.
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).
I would love an API for suggesting edits and having the edits in a bot queue. I recently chatted with the maintainer of another event database and they would like to create an event in MB after it was created in their database. But I was forced to say that there is no API for this because of human review and stuff. A seperate queue would also fix that problem.
But, have you considered this for all edits or just for the small ones discussed above?
Or maybe having a queue for seeds instead for edits can also be helpful. Usually the edit my event bot creates are not easy to edit/approve because we have just the artist name instead of a matched mbid. And I assume a potential bot queue requires valid edits which can be finished with just clicking “Enter Edit”.
Sorry, that was a little bit off topic, but I just want to mention, that such queue could serve other use cases as well.
Wikidata has a useful tool called Mix’n’match (described here). It’s used to match entities in one database to entities in Wikidata. MB has no equivalent, but it could use one. This is something that could be vibe-coded.
Let’s say you have a table of all the master release entities in Discogs (like this master release). These correspond to release groups in MusicBrainz. The tool gives you a list of entities, and through the interface you compare metadata, and you have links to each entity. Here’s how it looks in Mix’n’Match when the entities are pre-matched. Human editors then decide whether the pre-matched entities describe the same album. Clicking “Confirm” adds the Discogs ID to the Wikidata item.
Of course, it would not be limited to Discogs master releases. If MusicBrainz had something like Mix’n’Match, we could use it associate MB entities with any site that we have a dataset for. It would also show us how close we are to matching 100% of the dataset. This applies to all MB entity types that have URL relationships.
TBH I think 2, 3 and 4 in your list can’t and shouldn’t be done with AI
Particularly artist merging/splitting can be a laborious and complicated process. Often there is no streaming service or other database with the information required, and you end up with a lot of open tabs, scouring misc forum and youtube comments, and listening to music.
Even 1, record matching, could lead to really bad trouble if there have previously been incorrect ISRC/fingerprints assigned.
Merges I definitely wouldn’t want to see. Too destructive and a lot more work to undo. Those should be done by people who understand the music they are working on IMO.
The only additional things I can think of, could be accomplished by a simple python script and don’t need the overhead of an LLM. Language related things are probably the best case for LLMs as it’s not uncommon for people to edit music in languages they do not speak and might get names and translations wrong, and LLMs seem quite good with that. Could maybe create pseudo releases where none exist?
That said, I have no issue with such a bot editing in my niche(KPop) as long as edits are votable. I read through every votable edit that happens(even if I don’t vote on them all).
I am confident that majority of merging issues are trivially solvable by AI who can also get into checking many more pattern and have a confidence level. And it could also flag/recommend without action and give reasons for doing so.
To be honest, what you said only strengthen that.
if there have previously been incorrect ISRC/fingerprints assigned.
which is sometghing AI can check in thousdans per sec in ISRC databases and by comparing fingerprints…
I am also against letting a bot enter merges of any kind, unless those edits get placed into a special queue that NEEDS votes / edit notes to pass, unlike regular edits that pass even if no one votes on them after a week.
Last year, another editor was using AI tools to enter a lot of edits, and there were just not enough people looking over those edits, I voted on a lot of them, but I literally couldn’t keep up with the vast amount of edits that needed to be reviewed. Some of those edits were actually wrong (they have been fixed by now) and either no one voted on them, or I made the mistake of voting incorrectly on some of them, because I wasn’t thorough enough checking the details. (to be clear, that editor learned from those mistakes and they make good edits now!)
There are barely enough humans reviewing the current MB edits, so who will review this LLM?
