This is becoming OT and should be split, but: artist credits being auto-set from tracks almost certainly won’t happen because it would completely mess up the entirety of our classical music data 
5 Likes
That artist list could also show performers from recording-artist relationships too:
But let’s stop this off topic, yes.
It’s not that important.
How would an automated tool work that out? A human would need to flag the original single and or albums causing more work that making the few rare corrections. The first release in the database is not always the real original.
Thank you. 
Humans are always better to trust than automation. I think this area works brilliant the way it currently is.
It’s how these elements already work:
- Recording length (which favours Disc ID based length over manually set)
- Release group release year
- Release front cover (which takes the first Front cover of the list)
Usually, if someone is concerned about these to be wrong (they are correct based on known data), they just edit or add track times, Disc ID, an original release, some cover art, etc.
It’s not an automatically set field, it’s a dynamic display, always up to date, according to known data.
3 Likes
Happy to see this topic comic back as I really love the concept and it makes sense considering the current guidelines and that a majority of those data come from edits made on Release level and not on Recordings one.
Then as spotted the ticket would need some further clarifications and testing to guarantee it do not create more rework than the saved time. In other words machines make errors on complex cases and humans on repetitive ones so partial automation with a “Red button” could be discussed 
Happy to help on it if needed.
Some points for instance:
- Taking in priority Official releases upper compilations: Rely on Secondary Types?
- How should be handled the “Red button” process for standalone recordings and special cases ex: Allow manual edits?, Allow editor to tick one release to force the name? (or the contrary: allowing to tick releases to ignore),…
- How to avoid unseen consequences at release date? ex: Could it be applied only to new recordings creations? ex: Replacing the current tickbox “Update the recording title to…” by a “Rely on automatic mode” one which will be ticked by default only when creating a new recording?. Then editors to tick it manually for already existing recordings. Or maybe even better by showing it only on Recording page (cf. comments regarding the required knowledge to apply changes on Recording level)
Then would also be interesting on other fields:
- Release Groups
- Fingerprints/ISRC: Keeping those information on track level will simplify the merge process and remove issues created from wrong merges (Fingerprints not disabled, Not able to spot wrong inputs since cannot see from which release comes a fingerprint,…). ex: When unmerging a recording the fingerprint/ISRC will automatically appear on the new one and removed from initial one.
- Artist: Tricky one but solutions could be found. ex: As we set which script to rely on at release level we could set a field for which guideline should be applied: “Standard as on cover” or “Classical” then the algo could ignore those releases flagged as classical.
3 Likes
Was going to not post this, but now it is written I’ll hit post. Don’t trust computers to get things right.
Not great when you know an early 7" was released, but don’t have a time for it. Impossible to guess it as it may be a different edit to the album track on the CD. (Yes, I have bought 12" vinyl just to check lengths - but that can’t always be done 
)
This is a classic one that causes troubles on older releases. Extra work needs to be done to import new releases, or manually make something up to chase the numbers. A manual edit marked as estimated or “manual entry” would be a cleaner way to solve many older releases.
This is more exaggerated with Recording dates. Release dates are very skewed on recordings when an edit gets onto something like a Greatest Hits or a VA collection. If it is of different length to the original it can never get a correct release date. A manual edit field would solve that.
Example: a 7" Xmas release in the database without a time. We don’t know if the VA track is coming from the single, or if they are different edits from the album that came out the next year. So the VA stays hanging never able to get a true release date linked.
An excellent example as this allows the user to override it with a better quality image. Or point to the common release image and not an early promo. This automation is usually good, but allows for an override when good art is not available for the first release.
Maybe we edit different types of data. Sometimes stuff I am editing does not have a clear way to locate an earliest single without guessing a date. Guesses are not allowed. So a dateless release cannot be selected as first.
To me your suggested automation has too much of a belief that data is perfect and all Artists have perfect and complete catalogues. This is not the case. And certainly not with some of the odd stuff I listen to. Or bootlegs I collect. I spend many hours adding extra releases, filling in gaps, but sometimes it would help if we could just tell MB it is wrong due to the history printed in a book.
I enjoy puzzles like this, but I can’t see an suggestion beyond “first is right”. I’ll be back when I find other examples like the Ian Dury ones. I know I have had some where the first official single release had errors and was withdrawn. This is human created data and there are always cases that won’t fit
For now you are asking for a system that will require people to cheat by adding fake or pseudo releases to fill a “first” slot instead of the superior version we have now that allows a human to over-ride the few examples that fail to fit.
I probably spend a majority of my time on the Relationship Editor on a release page. This is editing Recordings, not the Release.
Red buttons. The good thing about those is they allow accuracy and a human override. See choice of covers. That is a “pick the best option” method.
But recordings need ability to manually edit the title as bootlegs of concerts will have various (ETI) about the gig location which guidelines make us remove from the Recording title.
Back to GUI confusion… those tickboxes need pop-ups warnings for noobies. An “are you sure?”
On a new release with new recordings it is automated. That second release with LP, CD, DIgital version we often are selecting the Recordings on the track page anyway.
I link this point. Often I am finding big heaps of finger prints attached that are clearly wrong, but one or two stand out with huge lists of attached sources. A better link of “it originally came from here” would be neat, but not sure how technically possible.
Not sure where this one is going. Or is that aiming at “Ian Dury & The Blockheads” vs “Ian Dury and The Blockheads” type swaps?
I believe too much automation and complexity leads to more confusions. Automation to some level, but there is a point where a human really does know best.
Personally I find the current data base does many automated things very well. Though comedy errors show faults - like search always picking “money, money, money” instead of “money” when trying to Link Works for “Money”. A computer algorithm is only an attempt at fixing how stupid an computer is. They are good at repetition, but dumb at the finer details.
(Sorry - I have a boring day and too much time to think… 
)
1 Like
I think we must strive to reduce the time required to edit stuff on MB for same results.
MB is so time consuming.
The less edits/checks/fixes are necessary, the best.
When you cannot know if it’s the same recording, you use a new recording (with no length if you don’t know the length for this edition).
It’s great to favour the add of the original release.
It’s not hard to do.
On the contrary if it was possible to input release group year manually.
Errors would not be auto-corrected, it would be a great pity, errors would remain or you would be always forced to check dates to make sure they are not wrong.
I didn’t know this existed (recording date) it must be a display recently added.
Again, if it was a redundant manually input field instead of the dynamic display it is now, it would be awful: Adds editing time and redundancy, adds check time each time you come across (or ignore it).
It’s just the release date of the oldest known release.
No, I meant Release front cover, not Release Group front cover.
3 Likes
Agree, but don’t cause more work by locking in errors caused by automation.
I know that. The point was the auto-guess is going to fail and use duff data. And the VA collections released ten years later cannot now link a release date of any form.
We both know how to do edits quick. Use imports. Type fast. But this is massively time consuming and sometimes a date would be good to fill in a skeleton of a release group. For example if half of an artist’s discography is missing and you only have a list of titles and release dates.
For reference, I have added many singles for many lesser know artists to just “fill the gaps”. Even when I don’t own the works myself. Not many people are this mad and dedicated to the data.
Because of the random incompleteness of MB I will always look on Wikipedia for a discography and never trust MB to be complete or accurate on date.
What we have now causes errors and incorrect release dates. Kinda funny when you look at some artists and see the orders of some of the singles. An (e) for estimate or something flagged in the GUI would be useful. Reset every time a new release is added (just like editing artwork, etc)
It has been there all the three and a half years I have been editing for. Maybe it is more interesting to me due to much of my time spent with concerts and bootlegs. Look at a Recording page and you see various dates. One date of release, one for recording (studio\concert). The latter is manually filed in.
Trouble is the track release date is auto-generated from the main Release and leads to errors on VA collections. Impossible to fix.
Here is an example of how VAs can fail to connect to originals - Thubthumbing by Chumbawamba https://musicbrainz.org/artist/7b7b1e6f-e73e-41a0-9d72-8f0b30c6992d/recordings?filter.artist_credit_id=&filter.name=tubthumping
Single is 3:33, album is 4:39, but the versions on many VAs are 3:23 and 3:58. So how do we get a Release date associated to those VAs? And that page also shows another common hiccup - the DJ Mix albums are never going to be able to find a release date for the Tracks.
(I have spent many hours cleaning that page up… So yeah, I notice the South African releases do just squeeze a date into those common Va collections. But that is more by luck than anything else.)
This date issue is going to become “a thing” as Picard is starting to make these values available and people want to know when Elvis released the track on their Hits CD. In my own collection I have been going through a number of my own VA CDs attempting to merge recordings back to the original releases, but often it is not possible due to doubt of which mix was in use. I can see some people being less careful and just merging those big heaps of VA edits into the single.
Again, perfect in the current database as this is automation than a human can tweak. Only if it is marked as Front, and shuffled to first place will it appear. It is possible to have multiple fronts (boxsets, stickers, etc) so a human choice can be made.
I know we are wondering around a bit from original ticket, but it is the “automation without human correction” that I think is a bad idea. Automation good in 99% of cases, but I often am in that 1%. Currently a recording automatically gets that first track title unless someone changes it. That is good automation as it then allows the complex Classical crowd to have perfect continuity to a recording. And us Bootleg fans to have track titles (with ETI) and pure recording names cleaned up to compliance with a nice disambig
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.
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.
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. 
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. 
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.
The docs indeed agrees with what you said, @IvanDobsky!
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 
Or do the training wheels only come off once I am past 150,000 edits )
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 random kinda working again now. I have to hit lots of reloads, and more likely to work if no artwork to load. So really still very broken.
No no, the docs indeed agrees with what you said!
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.
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.
Docs can also be very out of date too in some areas . From old memory this AE did point at the docs. I wasn’t just taking random advice.
1 Like