Inconsistency in Live recordings style guideline examples?

Tags: #<Tag:0x00007f2a546e4030> #<Tag:0x00007f2a546f3eb8> #<Tag:0x00007f2a546f3d78> #<Tag:0x00007f2a546f3c38> #<Tag:0x00007f2a546f3af8>

When reading https://musicbrainz.org/doc/Style/Recording#Live_recordings and https://musicbrainz.org/doc/Style/Specific_types_of_releases/Live_bootlegs I see some inconsistency.
It seems we should do as:

A: B

Where A is how and when (live or not, dates) and where B is where it took place (with optional parts).

live, date: event, place, area, country
live: event, place, area, country
date: event, place, area, country

But in the guideline, I see this number 2. example that contradicts this — it was pointed out to me by @samni698 in Edit #59514386:

  1. Train in Vain (live, 1998-12-14: Telewest Arena, Newcastle, UK)
  2. Wake Up (live, Los Angeles, CA, USA)
  3. The Dance (live, 2002)
  4. Candle in the Wind (single edit) (live)

Is it not a mistake? Is it purposely different from below?

  1. Train in Vain (live, 1998-12-14: Telewest Arena, Newcastle, UK)
  2. Wake Up (live: Los Angeles, CA, USA)
  3. The Dance (live, 2002)
  4. Candle in the Wind (single edit) (live)
2 Likes

Isn’t it following the same pattern, though?

live, date: event, place, area, country
live, event, place, area, country
date: event, place, area, country

Which means the colon ( : ) is always between the date and the event.

2 Likes

Ah we can see it like that, indeed, and maybe it’s why…
It looks strange to me because colon “:” is not a basic separator like comma “,”…

If it’s like that, if colon “:” is not separating the how/when from the where, then why don’t we just use comma “,” everywhere? :thinking:

A comma is nicer for filenames. The colon always needs swapping out.

I think a comma is cleaner too. Consistent if all dividers are the same. I generally always use commas.

I thought a colon was mainly for sub-titles? Volume names as part of titles.

Good catch, for me it’s clearly a mistake.

Especially since https://musicbrainz.org/doc/Style/Recording#Live_recordings says:

If the date and/or location is known, this should also be added to the disambiguation comment following the same format as used on live bootlegs.

It should be “Wake Up (live: Los Angeles, CA, USA)” for the sake of consistency.

@reosarevok ?

3 Likes

The bootleg format is “YYYY-MM-DD: Venue, City, State/Province, Country”. If there’s no date, that’d leave us with “live,: Venue, City, State/Province, Country” which is clearly silly. So it makes sense to drop the colon. I think it makes sense the start is consistently "live, " but I honestly don’t care either way - I haven’t bothered to add this to live recordings now that we can properly specify the place and date they were recorded at with an actual relationship, and I’m not sure it makes any sense to ask users to enter it, given how much of a pain it can be to edit disambiguations en masse.

2 Likes

Comments are still quite vital to avoid bad merges.
And eh, removing a part also remove its related punctuation:

Without event

live, date: event, place, area, country

Becomes

live, date: place, area, country

Not

live, date: , place, area, country

:slight_smile:

1 Like

I would agree that we should drop the comma, not the colon. To my eyes the colon is the primary separator, and the comma secondary.

Agreed, but as jesus2099 points out, the disambiguation is more helpful in preventing improper merges than the relationships. It would be great if there were a way to batch generate disambiguation comments from those relationships, though!

1 Like

The point is the colon is part of the bootleg formatting, while the comma isn’t, so the actual bootleg formatting for a case without a date would have no colon :slight_smile: But I’m not against keeping the colon either, we’d just have to amend the guideline a bit.

2 Likes

Why not just drop the colon and use commas for separating every type of different information? This way people wouldn’t need to think about where exactly the colon needs to be and the formatting would just be the same for both live official and live bootlegs.

1 Like

Yes why not…
I initially wondered about that colon among many commas.
I then got used to it and we have many such comments everywhere.
But it could be more simple as a guideline to only separate everything with commas.

Note what @reosarevok said about Bootleg formatting. Remember that this data is used in other places, and the original source of that format was a standard adopted from the bootleg world. That seems a logical enough reason to keep it as it is.

It is how other people are used to reading concert details. Yeah, our collective database OCD wants to make the colon conform and become a compliant comma, but then it won’t look at clear to read as now. When looking at a page of gigs the colon adds to the readability.

Please also remember that the colon is the standard for the Title of a live release too. Again an old standard used outside of MB, but helps massively on the clarity to read it.

A random example here under live releases of the Pixies https://musicbrainz.org/artist/b6b2bb8d-54a9-491f-9607-7b546023b433?all=1 IMHO think the colon makes that much more readable.

1 Like

An example of how it would look like with only commas (left) side by side with semicolons (right):

Yeah - that looks a mess. Please lets not start renaming everyone’s live bootlegs out there. It is very likely that other people are already processing bootleg titles knowing the date follows a standard.

Colons make the dates look more “squared off” and how my bootlegs have looked on my computers for many many years.

Colons are also used in subtitles. So there are other places multiple types of punctuation are used. Using different types of punctuation aids reading clarity.

Lets break down the original question in a different way.

live, date: location

The "live, " is only tagged on there as an extension from how bootleg titles were standardised. The location field can have zero or more commas. The date could be just a year. The colon is showing a divider in a standard way.

live, 2002: London
live, 2001-10-01: Brixton Academy, London, UK
live, 2001-10-02: Brixton Academy, Brixton, London, UK
live, 2018-06-07: Barclaycard Festival, Hyde Park, London, UK

The colon allows the human eye to divide the text cleanly. Also anyone processing the text through a computer elsewhere has an easy divider to work with.

(Darn it - I need to not keep getting into these debates :rofl: )

2 Likes

Just a side‐note as I don’t really care about ripping and tagging:
You can have those in your file system folder names?

You forgot the point of my topic, the example with no dates. :slight_smile:

I am talking about seeing the titles on the releases in the tags. And therefore in other databases that refer to my music collection.

I’m trying to avoid the tagging debate here. Not what I meant. It is the data use outside of MB. So my media centre reads the title from MB in a standard format. And the titles are in that format, so the disambiguation text should be in the identical format. Especially as the location part can have a variable number of commas.

So a sample with no dates would just be

live, London
live, Brixton Academy, Brixton, London, UK

The colon is part of the date.

So that means that the following could be argued as wrong

live: Los Angeles, CA, USA

BUT there is a valid argument to say that is a sub-title. I can see how someone could try and argue it from that formatting rule. Though generally I think it should be a comma there.

Exactly and FWIW, for me, I got used to the colon by reading it as « at/in » …

live, 2002 at/in London
live, 2018-06-07 at/in Barclaycard Festival, Hyde Park, London, UK

live at/in London → live: London

But OK, if this discrenpency is not a mistake then it’s not a mistake and we can keep the guideline as it is.

Yeah - that makes sense. Which also means live: London scans correctly to.

It is why the style guide is guidelines as strict rules don’t work for everything. Data is used by humans as well as machines. :smiley:

1 Like