Setting recording titles automatically (MBS-4252)

Tags: #<Tag:0x00007f58f695bb58>

Unlike manual edits where the error would be locked in until someone checks it, doing researches again and eventually fixes it, this automatic display does not have to be fixed, without forgetting to fix the bad track data that locked this manual recording data in.

Meanwhile, with the dynamic display: If someone adds a correct track data somewhere or fixes some track data that had to be fixed anyway, the display will update.

I think we absolutely MUST keep this incentive to add original release to a release group.
Once you found the necessary and reliable info to just create an empty release group, you have what is needed to create the original release, in fact.
Creating release groups with unverified dates would be less helpful than no release groups or than empty release group with no dates.
Because when unverified data is set, it is rarely checked later because we think it was reliably referenced, otherwise we would doubt everything and we should better make our own Excel list at home.

How does it create bad release dates?
How would this release date errors not be there if release group was manual?

It’s the same for recording title, it is a human action that defines the display.
If an official original track title is created by a human editor, it will be displayed in priority before VA compilations, bootlegs, etc. (you can participate in defining the priorities, it’s not a matter of how many tracks use this wrong title).


And again I am really not talking about any automation at all.
It is just removing some input field that has to be edited and stored now, replacing it by nothing, just a dynamic display, not by an automation that will set something.


I’m talking about something, recording title, that we could stop working on, like we were suddenly and miraculously able to stop loosing time on recording lengths and like we could also stop wasting time on naming events that don’t have names.

:warning: If later we see that the display algorythm has this or that defect and it displays the wrong title, we just fix the display algorythm, not the millions of bad recording titles.

1 Like

There is even a report to detect this kind of thing:
Recordings with a different name than their only track - MusicBrainz (currently 153816 results)

2 Likes

When we add a gig, we are allowed to add (ETI) to the Track to show the gig details as per cover notes. BUT the ETI is not allowed on the Recording. So we get differences between Track and Recording titles.

I will have a look at that list as it is handy having the Subscribed button on there to filter it.

(I may come back to the rest another time as I need examples as I am not being very clear without examples.)

Edit: Argh - don’t give me lists of things to correct. haha. Will start hitting some of these as I see some funny typos on there.

Okay - what should happen here then? The ETI is supposed to be in the tracks, but the Recording is not allowed ETI. Or have guidelines changed again?

Edit 2: and there are other gigs I cannot fix without the [ Edit All Comments ] button to be back and working. Never thought I’d miss one script so much.

Edit 3: Most of the items in that list for me are under the list of “ETI not allowed on Recordings”. Cleared a heap of obv stuff, and some HUGE multiple fixes in DNA audio books causing hundreds of edits.

2 Likes

Where did you read that ETI was not allowed in recording titles?
If the version info is part of the track titles themselves, it would not be forbidden to have it in the recording title.
It can look better in disambiguation for some, but it’s a matter of taste more than a rule, I think.

2 Likes

Was told to strip ETI from LIVE Recordings by an AE. Instructed to do live tracks like that Radiohead one above. If tracks on the CD shows the ETI then it is allowed on Track title, but recording title must be “pure” and no live information in recording title. Has to be moved to disambig.

If the CD covers a single concert then no ETI on the Track titles either.

If it is version info like (12" mix) then that can stay in recording title. Or that is what I was last told to do.

This is why I am seriously missing that mass comments edit button. That Radiohead example needs disambigs fixed on the recordings. My editing of Floyd bootlegs has ground to a halt without that script.

You script editors are the Heros that make this website usable. :partying_face: YOU save me many hours fixing errors thanks to your tweaks.

that Radiohead Release is a bad example as I see many errors on that release. not one of mine

Always check the doc. :wink:
I found this: Style/Recording - MusicBrainz Wiki

Title

The recording title should generally be based on the titles of tracks using that recording:

  • If the recording has tracks from official releases, choose the most common title from official tracks as the basis for the recording title.
  • Otherwise, choose the most common track title.
  • For standalone recordings, the title should be based on the title given by the original source.

For almost all recordings, extra title information should be kept in the recording title. The exception is live recordings, where any performance information should be transferred to the disambiguation using the Live recordings guideline.

Only live recordings don’t have ETI. All other ETI that are on track titles should also be on recordings. I’ve notice many taking them off recordings, but if all the track titles have it, it should stay. Also, the mass comments works, just keep refreshing your page until it shows up.

I realise I am really rubbish at explaining anything. I am ONLY talking about live as in that example. I do know to keep ETI as per the rear cover on recordings and only move live details to disambig, exactly as that guideline shows. (Maybe you should come look at some of my edit history and see that I have got the hang of this site now :rofl: Or do the training wheels only come off once I am past 150,000 edits :rofl:)

And @tigerman325 Mass Comments don’t work for me in Vivaldi. All scripts in general are a bit crashy currently. Edit: reinstalled a few times and it is working again now. Yay!

No no, the docs indeed day the same as you.
What I meant is that we should look at the docs instead of just do things because an autoeditor told you this or that.
Docs can evolve.

Maybe you have uninstalled them first. So then when you reinstalled them they are now run last after all others scripts.

Since the new release page (with paged tracks), inline stuff and set recording comments will run only if they are loaded sufficiently late after the page has finished redrawing itself:

1 Like

This may be part of it. It wasn’t in the list, and I kept hitting the install button, but it still didn’t appear. And then toggled all the scripts off and then all back on again. We know that is the big secret of IT.
:joy: Maybe that also jiggled the order. Generally inline stuff and others seem to work most of the time. Though some days the monkey throws a total sulky fit and doesn’t run any of them. All seems at peace now and all happy. :slight_smile:

Docs can also be very out of date too in some areas :wink: . From old memory this AE did point at the docs. I wasn’t just taking random advice.