Could we consider changes to live bootleg style for recordings?

I’m having difficulty removing comments from the disambiguation field of live bootleg recordings. For example:

“live, 1969‐01‐10, 1st show: Fillmore West, San Francisco, CA, US”

This states the form should be:

“live, 1969‐01‐10: Fillmore West, San Francisco, CA, US”

Where does “1st show” go? If the comment was at the end like:

“live, 1969‐01‐10: Fillmore West, San Francisco, CA, US; 1st show”

which would allow for a regular expression to remove it gracefully when only the comment is wanted. Something like this, but not exactly

$noop(recording disambig? remove search hints)
$set(_comment,$rsearch(%_recordingcomment%,^\(?:\\d{4}-\\d{2}-\\d{2}.*; \){0\,1}\(.*\)\$))
$if(%_comment%, \(%_comment%\))

Also, the use of disambig is a bit old fashioned as we have the ‘recorded at’ and ‘recording of’ relationships in the database. Here’s an example using a direct API call.

browse API call for A Train Kept a-Rollin work to return recordings (page 1)

If I apply this XSLT transform

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xmlns:mb="http://musicbrainz.org/ns/mmd-2.0#">
  <xsl:template match="/">
    <html>
    <body>
    <h2>MusicBrainz browse test by davygrvy@pobox.com</h2>
    Count is <xsl:value-of select="mb:metadata/mb:recording-list/@count" /><br/>
    <table border="1">
      <tr bgcolor="#9acd32">
        <th>Title</th>
        <th>Artist</th>
        <th>Attributes</th>
        <th>Date</th>
        <th>Place</th>
        <th>Disambig</th>
      </tr>
      <xsl:for-each select="mb:metadata/mb:recording-list/mb:recording">
        <tr>
          <td><a href="https://musicbrainz.org/recording/{@id}"><xsl:value-of select="mb:title"/></a></td>
          <td><xsl:value-of select="mb:artist-credit/mb:name-credit/mb:artist/mb:name"/></td>
          <td><xsl:value-of select="mb:relation-list/mb:relation/mb:attribute-list"/></td>
          <td><xsl:value-of select="mb:relation-list/mb:relation/mb:begin"/></td>
          <td><xsl:value-of select="mb:relation-list/mb:relation/mb:place/mb:name"/></td>
          <td><xsl:value-of select="mb:disambiguation"/></td>
        </tr>
      </xsl:for-each>    
    </table>
    </body>
    </html>
  </xsl:template>
</xsl:stylesheet>

I can generate a table like this. As you see, all the info that the bootleg live style asks for is already in the database. The issue as I see is that normal indexed browsing doesn’t add a place column thus keeping the need to have disambig show those search hints.

1st show, 2nd show, matinee, evening - these are important. And has been a convention to add them in there for some time.

And yes, we have a relationship. But the disambigs are clearer and very very widely used by those of us with bootleg collections. It is also often the only thing that stops someone from merging these recordings.

It is a disambig - it literally tells you this recording is different to the studio version.

4 Likes

Currently I do this when there is multiple shows on the same day and additional vital information also exists, which is needed to avoid recording merges from clueless people who merges solely based on recording length (the 3rd one doesn’t exist but you get the idea):

live, 1970-09-19, 1st show: Madison Square Garden, New York, NY, USA; AUD source #1
live, 1970-09-19, 1st show: Madison Square Garden, New York, NY, USA; AUD source #2
live, 1970-09-19, 1st show: Madison Square Garden, New York, NY, USA; SBD source #1
live, 1970-09-19, 2nd show: Madison Square Garden, New York, NY, USA; AUD source #1

5 Likes

@ joiletjake: That’s what I also prefer

3 Likes

https://musicbrainz.org/doc/Style/Specific_types_of_releases/Live_bootlegs

Additional date information can be added before the colon, in the form: “YYYY-MM-DD, additional information: Venue, City, State/Province, Country”. This should only be used to distinguish events that took place the same day or if the event is advertised as such. Typical examples includes early/late show, dinner, matinée.

4 Likes

I can see the logic of putting that before the colon as “1st show”, “matinee” etc are part of the time, not the location.

What if all I want for writing filenames is the actual comment “1st show”? Could I consider this RE a rule? This style of comment in the middle came from bootleg release titles, not recordings

A script for a rare case is always going to be tricky. There are a few different variations that different bootleg collectors attempt to squeeze into the disambig.

For example, I was looking for a Pink Floyd example I know of at The Rainbow Theatre and then spotted these Eric Clapton tracks

Trying to parse Disambigs will always be a bit hit and miss.

2 Likes

Thank you for the example. As you can tell, I just want “live, $(date) :$(place)” to just go away in disambig. I get that there is no performance tag for metadata and a need to show this externally in the filename. I also understand the need for unique filenames. But for me, I just want:

1-01 Train Kept A Rollin’ (1st show).flac

I guess I’m back to hand editing each. If I need those details, everything is associated back to the MBdb with the musicbrainz_recordingid

This is what I tend to do when there is only a very small sample of files. If it takes longer to write a script than hand edit the handful of files - then hand editing wins. Just remember to the set the files to Read Only to stop you accidentally “updating” them at a later date.

2 Likes

I’m thinking about a regular expression all wrong. I shouldn’t be trying to look for a comment, but remove everything I don’t want to reveal any commentary :light_bulb:

2 Likes

I knew I had seen this discussed before:

1 Like

IvanDobsky,

Those are release-groups. My concern here is recordings and the use of disambig to store info that is already in database entities.

For example, if I use Picard to write the first track, I will get this

Music/Led Zeppelin (bootlegs)/1969-01-10: [untitled] (2nd gen ZD): Fillmore West, SF, CA, US/1-01 Train Kept A Rollin’ (live, 1969‐01‐10, 1st show: Fillmore West, San Francisco, CA, USA).flac

when using recording disambig like so:

...
%_title%
$if(%_recordingcomment%, \(%_recordingcomment%\))

Not only is the contents of the recording disambig already in the ‘recorded at’ advanced attributes for the recording, but I write it to the directory name from the release title which already has this. All of this is in the database already.

This doubling of info bothers me, but I do want “1st show” for being the actual comment in %_recordingcomment%

If most of the use of disambig is for searching hints, shouldn’t we address the columns used in what indexed searches return now that we have advanced attributes that can duplicate what the live bootleg style for recordings says what we should put in the recording disambig?

No, I am talking of Recordings and so was that thread. Us bootleg collectors need the tracks named correctly and able to quickly spot them appart in the database. Searches and merges being a couple of obvious places, but also in general use. Also when one bootleg release includes a mixture of many shows. The whole point of disambig is to tell one version of a recording from another.

You also seem to have intentionally picked a bootleg that doesn’t have a name. Many bootlegs released from bootleg labels have no trace of the show details in the actual release title.

Guidelines as they currently stand have built up from many years of bootleg editors adding releases and looking for clarity. Yes many bootleg editors fill in the relationships, that’s how we can look at the places and see things like this:

And look at Works and see this:

A Recording gets a clean name, and the specifics as to why that recording is different to the next gets disambig. Just like when you disambig a Single, 12" or Album versions.

The use of disambigs is a visual thing allowing us to quickly spot one recording from another in all areas of the database.

I am also a little confused. You are choosing to add those disambigs to your recordings by using a script to display them. Turn off your scripts and the disambigs will go away. Or hack a clone of the script to display the disambigs in a way you want to see them.

4 Likes

Yes, via coding he could achieve what he wants…

1 Like

Just in case anyone is as dozy as me and doesn’t spot this, everyone should note that this is about:

  • Bootleg live recordings from concerts; and
  • Recording disambiguation fields; and
  • Not about Releases or Release Groups for bootleg live recordings; and
  • Not about Release or Release Group disambiguation fields.

Do the style guidelines you linked to actually stop you from adding the show number? The page you linked to (Recording Style Guidelines for Live Recordings) actually links to a page specifically for Live Bootlegs which says that they need to be in the form: “YYYY-MM-DD, additional information: Venue, City, State/Province, Country”.

So as far as I can see a recording disambiguation of “live, 1969‐01‐10, 1st show: Fillmore West, San Francisco, CA, US” is entirely conformant to the Style Guidelines for live bootleg recordings.

1 Like

Except that “1st show” is the part not able to fit in the database and the only part I want from %_recordingcomment%

It could have been “taped by Joe from the balcony” or “soundboard” or “1st gen cass” or whatever. This is the gold, not aspects that have a database entity already.

That is for release titles, the guide for recording disambig doesn’t show that

or you could move the contents of the disambig to relationships and then have a blank disambig (which wasn’t done here)

edit1: Yes, let’s do this

edit2: and now by shear magic, the recording shows in a performance search for the Waldorf Astoria

  1. My point is that 1st show CAN be fitted into the existing style guidelines, exactly as you suggested. “1st show” is the additional information allowed for in the style guidelines.

  2. We need to separate Picard requirements from Musicbrainz. Musicbrainz is metadata in its own right and its structure and style guidelines exist for data management purposes in its own right and not to serve the needs of Picard.

  3. I am prepared to bet that a Picard regex could be used to separate out the additional information. Off the top of my head (and I haven’t tested this): (?:[^,:]*,\s*)[^:]*(?:\:) should select the additional information. Or if you only want additional information which is about 1st show, then you can tweak the regex to give only that: (?:[^,:]*,\s*).*\s+show(?:\:)

The style guidelines say that the recording disambig is based on the rules for release titles, and in release titles additional information is part of the style guide. So it is IMO already allowed.

This is also allowed by Style Guidelines, but it might be a bit more complicated to get it into a Picard naming script.

BUT, in the end, whatever approach you want to use requires consistent data usage across Musicbrainz and that is what the style guidelines are intended to encourage - so we come right back to my opinion stated in the edit notes that kicked off this discussion 1) that the style guidelines should be followed by editors to try to ensure consistency across musicbrainz, and 2) that debates like this discussing changes to style guidelines to fit a new requirement are the way to reach consensus on how to proceed.

3 Likes