Yes, I repeated a similar edit — but not out of disregard for the community. I did so because I believe the discussion remains unresolved, and I hoped a broader audience might bring new insights or perspectives. This isn’t about pushing a personal agenda; it’s about seeking clarity on a guideline that is currently interpreted in contradictory ways.
If we are to rely on “established consensus,” then we need to ensure that consensus is actually documented, consistent, and rooted in the style guidelines. Repeating a good-faith question or edit should not be seen as defiance, but as part of the process of collaborative refinement.
I’d like to take a moment to step back and clarify what I’m really aiming to address with this discussion, since many replies seem to focus on specific examples rather than the broader issue.
This thread is not meant to argue for the preservation of “(Live Version)” in every case, nor to challenge MusicBrainz’s support for structured metadata. I fully understand that MusicBrainz offers more powerful tools for representing relationships like recording type and location than streaming services do. However, I believe we must be cautious when removing data that is explicitly and consistently shown in a release’s official tracklist — even on digital platforms.
Let me summarize the concerns:
The current guideline lacks a clear, objective rule for when ETIs (such as “(Live Version)”) should or should not be stripped — especially when they appear consistently in a tracklist.
This leads to subjective editing based on interpretations like “it’s redundant” or “we assume the artist didn’t mean it that way,” even though the text is there in the release.
Physical vs. digital releases often present track titles differently. MusicBrainz supports multiple release formats precisely to handle such differences, so why should we force a digital-only presentation to match a CD edition if the digital release was clearly authored that way?
Removing visible information without a consistent standard puts editors in the role of deciding what counts as “real,” which can lead to contradictory outcomes across releases and editors.
This is not just about “(Live)” — this question applies more broadly to how we treat any ETI that’s systematically presented in a tracklist, even in the absence of ambiguity or alternate versions.
Ultimately, I believe MusicBrainz should prioritize reflecting what users actually see when they experience a release. If the tracklist says “(Live Version)” for each song, even digitally, we should treat that as valid unless there’s a clearly documented rule to the contrary.
Thanks to everyone who has participated so far. I don’t expect everyone to agree, but I hope we can all agree on the importance of clarity and consistency in our style guidelines.
Thank you for the reference to MBS-4501 — it actually helps reinforce the point I’m trying to make.
While it’s true that a recording can only have a single title, MusicBrainz’s current data model allows each track (i.e., release-specific instance of a recording) to have its own title. That means we can — and should — reflect release-specific differences like the presence or absence of ETI, even if the underlying recording is the same.
In the case of digital releases, if the track titles consistently include “(Live Version)” or similar ETIs, that is not just metadata stuffing — it’s part of how the release is presented to the listener, and should be preserved as part of the title. Stripping that out based on what another release (like the CD) shows ignores the fact that MusicBrainz is capable of distinguishing between them — and should, for the sake of accuracy.
This isn’t about valuing one format over another, or about how streaming platforms work. It’s about accurately reflecting what is actually shown on each release, using the tools MusicBrainz provides.
I’ve encountered similar situations where ETIs are consistently present in digital tracklists. In my experience, if the ETI is part of the official release metadata, it’s best to include it in the track titles. However, if it’s merely a stylistic choice or branding element, omitting it can lead to cleaner and more standardized entries. Consistency across the database is key, so aligning with MusicBrainz guidelines ensures better data integrity.
I mostly see that the digital distributors are just dumping the release data there, hardly caring how it is presented and how many errors it may contain.
Basically, some intern has added the information to the file tags, and that ends up for the whole world to wonder.
I doubt there are any guides for the distibutors or labels how to tag properly in-house.
I give little value for the streaming sites and stores, as the metadata is usually very crappy.
Some downloads may have a booklet or pictures to further confuse the “what is the correct title” decision.
And with the whole “(Live Version)”, that should anyway be in small letters if it was to be on a track title.
For a recording a disambiguation comment should be enough.
But it’s exactly that, shop noise. It’s not even consistent between the streaming services. Each has separate guidelines, so it’s not uncommon that this marketing fluff differs for a single release between shops.
Tidal does not have that extra “live” on each track. iTunes and Deezer use “(Live Version)”, while Spotify uses “- Live Version”. Why this difference? Because it follows the respective guidelines of the shop.
It’s not actually part of the tracks title. It’s that the services store this live information in the title in addition to the actual title.
There are other such cases. E g. “featuring”, where MusicBrainz has an actual concept of storing this.
it does not help your point. actually it tells you, that this issue is already well thought about and the community of MB decided to use designated fields for specific metadata. but imo it would solve your problem. an alternative tracklist could allow you to use shop metadata (maybe for every shop you can find in the interent differing data?) while having tracklists according to MB style as main releases.
i think at this point every position should be clear.
from my side just one more note: if you think that streaming retailers use correct or “intended” metadata, eg you also have to enter dates like 1973-03-01 for the spotify issue of Dark Side of the Moon.
Thank you — I think your comment touches on an important nuance.
I agree that consistency and accuracy are key. My point is that if the ETI is printed consistently as part of a digital release’s official tracklist — not just as tag metadata, but in the visible titles shown to listeners — then that reflects how the release is actually presented to its audience.
MusicBrainz isn’t just a backend metadata tool for editors — it’s also a resource used by countless end users through players, taggers, and other applications. When we remove consistently shown ETIs from digital releases, we risk presenting something that no user ever actually sees on their platform of choice. That undermines user trust in the database.
So while I support cleaning up poor metadata, I think we must be careful not to override what the release actually shows, especially when MB allows us to capture such differences per release.
I appreciate your comment — and I think MBS-4501 actually strengthens the case for documenting visible differences between releases.
The key point for me is that MusicBrainz serves not only editors, but also a large number of everyday users, who often expect track titles to match what they see on streaming platforms or stores. These users rarely look into disambiguation comments or recording-level metadata — they just want a tracklist that matches what they see.
When digital platforms consistently show “(Live Version)” in their tracklists — regardless of why — that becomes the de facto presentation of the release to its audience. Using MB’s release model to reflect that presentation (while keeping CD versions separate) is not misuse of the data model — it’s a way to make MB more accurate and relevant to all users, not just data purists.
As shown by @outsidecontext, the shops are not consistent at all as to how they write titles.
I find your writing style “interesting”. You are cherry picking a few words from replies and ignoring every statement that does not match your viewpoint.
I think there are many users who have much more trust in this database than the average streaming shop.
As far as I know (and I might be wrong), there’s no difference. The tracklist on digital services is autogenerated from the metadata of the music files (or the other way around), after adjusting them according to the site’s conventions.
A nitpicky reading of the extra title information style, “intended to distinguish it from different releases or tracks with the same main title (such as version/remix names or live recording info)” could interpret “live recording info” as “information on where the live recording happened”, similar to “version/remix name” which indicate one specific version or remix for the recording, while just “(live version)” could indicate as many recordings as an artist had live performances.
Thank you for your thoughts. I agree that metadata on digital services is often adjusted according to each platform’s style guide, and the displayed tracklist is derived from the metadata provided by distributors.
However, from what I understand, the process is not as automatic as it may seem. In many cases, distributors submit structured metadata—including the track titles—as part of their release package, and this metadata is then adapted by each service to fit its own display standards. So while platforms may format things differently (e.g. using “(Live Version)” vs. “- Live Version”), the underlying title data usually comes from what the distributor or label officially submitted.
In the case of the release I mentioned, nearly all major services (except Spotify) consistently display “(Live Version)” in the title. That suggests it was part of the original submitted metadata, rather than a formatting artifact. This is why I see it as an intentional part of the release design, rather than just “shop noise” or accidental redundancy.
Of course, each case may differ, but I think this shows why it’s important to evaluate whether such additions were part of the official release metadata and not automatically dismiss them as unnecessary.
As a Japanese user, I’d like to add a cultural and guideline-based perspective.
According to the official Japanese style guideline on MusicBrainz (Style / Language / Japanese - MusicBrainz), editors are explicitly encouraged to preserve the printed titles exactly as they appear on official releases. This reflects a strong expectation in Japan toward faithful representation of published information—including what may be considered extra title information (ETI), such as “(Live Version)”.
When editing Japanese releases, I often see that this kind of ETI is consistently used in digital metadata as part of the official tracklist. From a Japanese perspective, removing this detail—even when it seems redundant—feels like a loss of fidelity. It’s not just metadata optimization; it’s erasing something that was intentionally presented in the release.
I understand that MusicBrainz is a global database and practices vary, but I wanted to share why this issue feels particularly important to editors like me who focus on Japanese music and data.
yakumo0209: I like capturing exact metadata too, but I’d gently suggest to just agree to disagree until the alternative tracklists feature is in. The time otherwise spent on these discussions could be at least enough to enter a few releases, which once that feature arrives will be all ready and waiting for you to fill in the exact shop metadata, with a win-win outcome!
Thank you for the thoughtful and respectful suggestion — I genuinely appreciate that.
The idea of alternative tracklists is indeed promising. However, since there’s currently no clear roadmap or commitment to when (or if) it will be implemented, it’s difficult for me to simply “agree to disagree” and wait. This isn’t just about a future feature; it’s about how we handle actual releases in the present, especially in regions where consistency in digital tracklists is seen as intentional and worth preserving.
I completely understand the desire to avoid prolonged debate. But for editors like me who prioritize preserving what’s actually published — especially in the Japanese context, where such fidelity is culturally important and even reflected in our official style guide — this feels less like a debate and more like defending a core principle.
Thanks again for the dialogue — I know this isn’t an easy issue, but I do believe these discussions help shape better long-term solutions.
