Request for clarification: ETI removal when printed consistently in digital tracklists

MusicBrainz
,
1

Hello everyone,

I’d like to ask for broader community input regarding the removal of Extra Title Information (ETI), such as “(Live Version)” or “(Studio Live),” even when these are explicitly included in the official track titles across an entire digital release.

This came up in this edit ( Edit #110144909 - MusicBrainz), where the original tracklist (as shown on Spotify and in the digital metadata) included “(Live Version)” on multiple tracks. I preserved this ETI in my edit, but it was voted down based on the current practice of omitting such data when applied uniformly.

I understand this convention aims to avoid redundant information — for example, when a live release already has its type set to “Live,” adding “(Live Version)” to each track may seem repetitive.

However, I’d like to respectfully ask:

  1. Is this convention clearly documented in the official style guidelines? If so, where?
  2. If not, is it appropriate to systematically remove visible and verifiable data purely based on long-standing community practice, especially when this creates a disconnect between the source material and the database?
  3. Doesn’t this contradict the stated goal of MusicBrainz: to be “as complete and accurate as possible”?

My concern is not about the musical or technical meaning of terms like “(Live Version)” — but about removing information that is actually printed on the tracklist. This can be particularly problematic when:

  • The same recordings are reused in future releases that may omit the ETI,
  • Different platforms (Spotify, Apple Music, etc.) show the ETI explicitly,
  • And users expect the database to reflect what they actually see when viewing a release.

I understand that disambiguation fields can be used for live information, and I have already included the specific tour dates there. But the presence of “(Live Version)” in the digital release metadata seems like something that, in the absence of a rule forbidding it, should not be removed based solely on internal interpretation.

I’m not trying to ignore past consensus, but I do want to clarify the rationale and explore whether current practice could be improved or better documented.

Thank you for your time and insights.

1 Like
2

imo - Regarding live releases - information like “(Live Version)” after the track title is useful for users of streaming providers to not get “confused” in playlists with the versions.

I would say in nearly all the cases, where there is a physical issue of a live release, you don’t see the attribute “(Live Version)” added to tracklist on the printed artwork.

Take this for example and check the Spotify link and compare it to the back artwork.

So imo cleaning up “(Live Version)” is smiliar to cleaning up spelling errors in the tracklist.

I am not too familiar with the style guide, but of course it would be useful being written down there.

5 Likes
3

The edit in question is here:

This is a CD\Blu-ray set of discs for a tour. The album title makes it clear this is a live tour disc. So you would not expect anything else.

I’ll repeat my last comment from there:
I edit a lot of live releases. And there is sense to MB guidelines. They have taken many years of community discussion to reach that level.

What you are asking is that every shop is exactly copied. But what happens when different shops use different text? Different typos and errors? Or the habit of adding “(remastered)” to tracks? Musicbrainz represents the actual music and titles as given by the artist.


We can see by looking at the CD artwork that this ETI is clearly not there. It is something added by the shop.

This database has the ability to store “live” in an actual relationship to the Work. Store artists, performers, instruments. Recording locations and much more. In real useable database relationships. A digital shop is trying to hack all of that data into a single title field. Which leads to a mess that MB is taming back towards the original artist’s intent.

8 Likes
4

Thank you for the thoughtful explanation — I appreciate the clarification and the link to the packaging.

I understand the concern about shop-added metadata and the importance of reflecting the artist’s intent, especially when it’s clearly documented on physical media like CD/Blu-ray.

To be clear, while the current example involves live-related ETIs, this discussion is not only about “(Live Version).” This edit simply happened to be the starting point that raised the broader issue. The question applies equally to other types of ETIs, such as “(Acoustic),” “(Remastered),” or named remix versions, when they are included consistently in official metadata.

I’m not suggesting that every minor metadata difference be preserved, nor that typos or shop noise be blindly copied. But when an ETI is applied consistently and intentionally across an entire digital release, and no conflicting physical source exists for that version, should we not at least treat it as valid data — especially in the absence of a style guideline that explicitly excludes it?

More broadly, I’m asking whether there is room to refine the guideline or make the logic behind this specific ETI-removal practice more explicit in documentation. That would help prevent misunderstanding and ensure all editors are applying the same standards transparently — rather than relying solely on unwritten conventions.

5

The core of my argument is not about whether “(Live Version)” or similar ETIs are meaningful metadata — it is about whether MusicBrainz should reflect the actual content of a release as it is officially presented to the public.

When a release explicitly includes text like “(Live Version)” or “(Studio Live)” in its digital tracklist, that is a part of the observable release metadata, regardless of whether the same appears on a physical version or not. Whether we consider it useful, redundant, or standardized is beside the point; MusicBrainz’s role is to document what is present, not to decide which parts of that documentation are worthy.

Tracklists may differ between formats — physical releases may omit information that digital platforms display, or vice versa. These differences should be preserved as they are, not normalized or overridden for the sake of consistency across formats. Doing so introduces subjective judgement into what should remain objective data.

Ultimately, the database’s trustworthiness depends on its ability to reflect releases as they are, not as we believe they ought to be. What’s visible to users on official storefronts, packaging, or streaming services should be what’s recorded — no more, no less.

6

I again will point to one main advantage MusicBrainz has over the online shops. Shops only have a single data field to put across everything. They have a title to tell you everything about the track. MusicBrainz is a rich relational database that give all data a home to be easily searched and found and used and cross referenced by third parties.

If you want to keep your tags as the shop supplied them, then that is a simple task of telling Picard to preserve them on your files.

See also “feat. artist” discussions. Another area where shops and MusicBrainz differ in how data is stored.

I don’t understand your attack at MusicBrainz’s trustworthiness. MusicBrainz is a very trustworthy database specifically because it treats all parts of the data with respect. Applying quality guidelines to make sure the data is clear and useable. It is not just trying to hack out titles to sell a track.

4 Likes
7

Thank you for your response. However, I would like to offer a few counterpoints and clarifications.

It’s true that MusicBrainz, unlike online shops, is a structured relational database where various metadata can be stored and cross-referenced. But precisely because of that, I believe there’s value in preserving the actual titles as they are printed on the release.

When something like “(Live Version)” is consistently included in the track titles across a digital release, it is a meaningful distinction presented to the listener. If MusicBrainz removes such ETIs from the titles, we risk losing the contextual and descriptive information that the original release intentionally provided.

You mentioned the “feat.” discussions. Indeed, MusicBrainz uses artist credits to handle featured artists in a more structured way. But this is not the same as removing information — the original credit is preserved and then enhanced structurally. In contrast, stripping ETIs removes visible information from the title field altogether, even when it was deliberately printed on the release.

As for my comment on trustworthiness — I did not mean to question MusicBrainz as a whole. I deeply value its role as a reliable, community-driven database. My concern lies in the consistency and neutrality of how we interpret and apply style guidelines. Altering what is clearly and consistently printed on the release can undermine data fidelity.

Even if a shop presents data in a commercial context, when that data is printed consistently and intentionally, omitting it becomes a form of editorial modification. If MusicBrainz aims to be fact-based, then the priority should be to record what’s actually there — and leave the interpretation, filtering, or presentation preferences to applications or scripts that consume the data.

1 Like
8

No information is removed. “(Live version)” is just moved to the more relevant place. A property of the Work - Recording relationship.

I’m going to stop typing now and let other people reply. You have said the same thing a dozen different ways and it won’t convince me that MusicBrainz has things wrong.

9

Thank you again for the reply. I understand you’ve made your position clear, and I respect your decision to step back from the conversation.

Still, I’d like to clarify one last point — not to convince you specifically, but for the benefit of others who may be following this discussion.

My concern isn’t only about “Live Version” or any single ETI term. It’s about consistency in how MusicBrainz handles titles when releases clearly and uniformly present certain information in the title field — especially when that information is user-facing and intended by the label or artist to appear as part of the official presentation.

While I acknowledge that certain data can be stored more structurally elsewhere (like relationships and attributes), this does not necessarily mean we should strip it from the title field when it’s an intentional, consistent part of the release’s design. The presence of that data in the title may serve a practical role for users, taggers, and digital archivists, even if it is technically redundant from a schema perspective.

Ultimately, I’m advocating for a more consistent and fact-based treatment of track titles that prioritizes fidelity to the actual release. If we remove such information because it’s redundant, but still retain other types of ETI that are equally redundant structurally, then we risk creating ambiguity and inconsistency across the database.

I’d still welcome feedback from others on this broader issue of how much editorial interpretation is appropriate when it comes to faithfully representing what a release actually shows.

10

A related question I’d like to raise is about single-track releases — such as this one on Apple Music.

If there’s only one track and its printed title includes “(Live)”, should we treat that as a reason to keep the ETI (since it’s explicitly shown and there’s nothing to compare against), or to remove it (on the grounds that it applies to the entire release by default)?

This edge case illustrates how unclear the current guideline is. Without a clear rule for such scenarios, we risk inconsistent editing across similar cases. I think this shows why a more robust, fact-based approach to title transcription might be necessary.

11

Do you have any evidence to show that this extra information is in general an intentional part of a release’s design? To me it seems it’s just a workaround to cram as much information into the title and album tags as possible because most streaming sites don’t show more than those two tags. E.g. Release group “01011001: Live Beneath the Waves” by Ayreon - MusicBrainz only has “(live)” added to titles on streaming services. If it was such an important part of the titles why would it not be on physical releases?

edit: Maybe if there are enough examples of live albums on streaming services that don’t add such information to title tags could indicate that it is an intentional decision to add them and not just general practice on those sites.

2 Likes
12

Thank you for the discussion.

I’d like to clarify something important: my concern is not whether the ETI (e.g. “(Live Version)”) is redundant, or whether it is useful or meaningful metadata on its own. Those are subjective assessments, and different editors will see different value in such information.

What I’m questioning is whether we, as editors, should be removing data that is explicitly printed on the official tracklist of a release — particularly when it is applied consistently across all tracks. For example, in this digital release, every track clearly and intentionally includes “(Live Version)” in its title.

It’s not uncommon for physical and digital releases to have different tracklists or formatting. That’s exactly why MusicBrainz treats them as separate releases, to preserve these distinctions. If the digital version displays “(Live Version)” across all tracks, that is part of its visible, verifiable design — and removing it, without a documented, objective rule to support that action, introduces subjective interpretation into what should be a factual transcription.

In short, the issue here isn’t whether ETIs like “(Live Version)” are redundant or useful, but whether we are justified in removing visible, release-specific information from the database. Until there’s a clear guideline that defines such removal criteria, I believe the most consistent and reliable approach is to reflect the tracklist exactly as it appears on the release in question.

13

It’s the same reasoning, 100% of the tracks (1 track) has the same live ETI as the release.

1 Like
14

“Additional information on a release or track name that is not part of its main title, but intended to distinguish it from different releases or tracks with the same main title … should be entered in parentheses after the main title”
I would say this is clear. “live version” added to all track titles does not help to distinguish from any other track, thus it is not a valid ETI and should be removed.

5 Likes
15

My point is that it doesn’t seem to be intentional design, but a workaround for simplistic user interfaces. You claim it is intentional, but don’t show evidence to support that claim.

Another example: The digital release of Release group “Sleepy Buildings – A Semi Acoustic Evening” by The Gathering - MusicBrainz adds “(live)” to the title and includes “(Semi‐Acoustic Live version)” (or “(Semi-Acoustic) [Live]” for Apple Music) after every track. None of that was necessary on the physical release, indicating to me that the only reason it was added was the need to cram information into title tags because it can’t be shown otherwise on those sites. I.e. a workaround for technical limitations, not an intentional design decision (especially since it differs depending on the site), and as such, no problem in moving that information to a better place in a database that has that capability. Particularly when capable tagging programs like Picard can re-add that info to your tags if so desired.

You do have a point regarding documentation of digital releases. On physical ones we can have cover scans to document mistakes that are corrected in the track list, the ephemerality of the digital world makes that harder. Certainly worth considering if and how that could be done, but imo the track list is the wrong place for that.

6 Likes
16

It’s usually not. Rather the streaming providers have guidelines that state that such information must be added to the titles. Essentially instead of providing some more structured way of entering this data they just put it into the title. MusicBrainz on the other hand does have proper structured way to handle this.

There was a recent discussion about this in these forums as well.

2 Likes
17

Hang on… so you were repeating your same edit as last time?

And the same thread as before?

1 Like
18

Thanks for the reply.

In the case of a single-track release, I think the reasoning that “100% of tracks have the same ETI as the release” becomes circular and doesn’t hold up as justification for removal. There’s no “comparison” to be made when there’s only one track — so we should instead focus on what is actually printed.

If the title includes “(Live)” or “(Live Version)” and there is no documented style guideline telling us to remove it in this context, I believe we should preserve it. Otherwise, we risk overriding factual information with subjective assumptions about what is “redundant.”

19

Thank you for your thoughtful reply.

I’d like to clarify that I’m not making a claim about the artist’s “intent” in a speculative sense — I fully agree that we should avoid assuming intent unless clearly stated. My point is more basic: if a digital release visibly and consistently includes ETI such as “(Live)” or “(Semi-Acoustic Live Version)” in the tracklist presented to the listener, then that is the presented reality of the release, and that’s what we should reflect in MusicBrainz unless there’s a clear guideline that tells us otherwise.

The fact that these additions may be “workarounds” due to interface limitations does not automatically make them invalid. MusicBrainz has long documented tracklists as released, even when those reflect errors, redundancies, or technical constraints. For example, we’ve preserved “Remastered” tags or format-based quirks when they’re part of the official release presentation.

What I’m asking for is consistency:

  • If physical releases get to be documented “as printed,” even with imperfections,
  • then digital releases should be documented “as displayed,” even if the interface influenced that presentation.

Otherwise, we are editorializing based on why we think something was added, not whether it was added. That introduces subjectivity and undermines MusicBrainz’s strength as a documentation-first database.

I’m very open to a larger discussion on how best to document digital metadata long-term. But in the meantime, removing consistently applied ETI from an official digital tracklist — just because we suspect it was motivated by technical constraints — seems like a judgment call beyond what the current guidelines support.

20

Thanks for your reply.

I don’t dispute that many streaming services have internal guidelines that encourage putting this kind of information (e.g. “Live”, “Acoustic”) into the title field due to limitations in metadata structure. But the key point is: those guidelines result in an official, visible tracklist that is consistent and intentional within the context of that release.

MusicBrainz should reflect the release as it exists in the wild, not based on what we believe would have been a better metadata design. Just like we preserve incorrect capitalizations, stylized punctuation, or even errors in physical releases because that’s what was printed, we should treat the visible digital tracklist as authoritative for that particular release format — unless the guidelines clearly say otherwise.

The fact that MusicBrainz can store structured metadata is great — and that’s exactly why the ETI can be supplemented in relationships and annotations. But it’s not a justification to remove visible ETI from the title field when that’s part of the official release presentation.

If we start disregarding release-internal consistency based on assumptions about why something is there, we risk introducing inconsistency between digital and physical releases. MusicBrainz doesn’t currently require all platforms to conform to a single metadata standard — it reflects what is officially shown.

So my question is:
Should MusicBrainz be a documentation-first database, or a metadata-optimization layer?
If it’s the former (as the style principles suggest), then removing ETI from a tracklist that visibly includes it — consistently and without contradiction — goes against that philosophy.

While I understand the desire to present clean and consistent metadata, I believe it’s important to distinguish between the roles of documentation and optimization. MusicBrainz, at its core, is not a metadata optimization layer — it’s a database that aims to reflect releases as they actually appear.

Tools like Picard exist to optimize, reorganize, or enrich metadata for end users. That separation of responsibilities allows MusicBrainz to serve as a factual source of record, while still enabling flexible metadata output elsewhere. Altering or removing data like ETIs based on assumptions about their usefulness or origin risks crossing into editorial territory, which undermines that goal.

Even if some ETIs originate from platform limitations, when they become a consistent and visible part of a release’s tracklist, they become part of the release’s identity — and I believe MusicBrainz should capture that.

1 Like