not to be the constant source of bad news but if your bot is making 18,000 edits in 24 hours you’ve broken the code of conduct sadly:
There is also mention there on that page, and I believe in other areas that before putting a bot like this into action that a discussion with MBz development staff should happen first. I believe rolling back the database would be very difficult and cause a lot of issues if for any reason your bot went a bit haywire.
I’m all for getting good quality data into the database as quickly as possible (as I am sure everyone else is) but it’s making sure that it is good quality in the first place, which often requires a bit of human intervention to check it over.
Personally, I’m more on the side of automating identification of missing data than automated edits. If a lot more people looked at the MB Reports and cleaned them, we wouldn’t have to deal with it! (i don’t because I cooked my own reporting system but still)
I’d say maybe try to let people do the edits themselves using your list of edits instead?
Something being on a report is indicative of it being on multiple other reports, and having further errors that don’t show up on other reports. I wouldn’t want bots / AI addressing reports since it would only see a tree and miss the forest.
In general, people are going to make mistakes when they aggressively edit outside of music they are familiar with.
While I don’t necessarily agree with the fact that most entities in reports is also in others, I agree with the rest. Only doing one edit because it found something wrong may indicate something even worse.
I would love to have a native way to filter reports based on your subscribed entities (or LB listens), as being more familiar with the subject helps a lot. Guess it’s up to me to implement more reports in alistral…
I’m between runs right now as I make improvements. The next time I will do a shorter run, record it, and then maybe that will help answer some of the worries. I do understand the desire for accurate data, but I think we’re spending a lot of time on arguments without concrete data of what kind of problems my scripts could actually introduce and its not clear to anyone how/when I intervene. Based on my experience, my error rate is much lower with this approach than it is without it, and it appears to be much lower than most editors. I wish I had snapshotted the before state for some of the artists I’ve worked on.
I often forget about MB reports and I appreciate the reminder.
edit: I should also add that these are all artists that are important to me. I don’t want them to be messed up anymore than you do.
Oh I found where it is.
Although I’m more talking about filtering the report page, not individual reports. You need to get on the report page, then filter, just to see if it applies to you.
… And while I’m talking about it, maybe tag based whitelisting? You may have entities falsely flagged, and if enough people add a special tag to the entity, it won’t show up in the reports anymore.
I only had time for a very quick scrub through, but looks very cool! Great to see that all the steps are human controlled, and the tools look very powerful and helpful.
When working at high speed I guess it becomes extra important to make sure artists are the same etc, but that’s up to the human at the controls, not the fault of these tools imo. Unless I missed an actual automated part!
I’m sure there’s more to talk about there but I happened to watch the part re. merging Bandcamp releases - I’m one of those who sometimes votes no on merges, but I don’t mind them being merged if the barcode, label and release date are the same. If label and release date are the same I might overlook no barcode on MB as well. I’m not a big fan of merges in situation like, for instance, if a Bandcamp release is re-released a year later by a label on Spotify etc, and then it all gets stuffed together (a label and barcode are now on a release with a year when that stuff didn’t exist). If anyone cares
P.S. amusing confluence of tool text and album name (possibly NSFW)
“When working at high speed I guess it becomes extra important to make sure artists are the same etc, but that’s up to the human at the controls, not the fault of these tools imo. Unless I missed an actual automated part!”
I didn’t explain this in the video but in general if I run into artist disambiguation issues or cases where I doubt Harmony’s matching, I either put that release to the side or I try to fix the disambiguation (e.g. correcting links, fixing incorrect ACs, etc.). I also tend to work on releases grouped by the artist credited, including featured credits, so that I only have to remember one kind of “this sometimes matches with the wrong person” issue at a time, then move onto the next grouping.
”’m sure there’s more to talk about there but I happened to watch the part re. merging Bandcamp releases - I’m one of those who sometimes votes no on merges, but I don’t mind them being merged if the barcode, label and release date are the same. If label and release date are the same I might overlook no barcode on MB as well. I’m not a big fan of merges in situation like, for instance, if a Bandcamp release is re-released a year later by a label on Spotify etc, and then it all gets stuffed together (a label and barcode are now on a release with a year when that stuff didn’t exist). If anyone cares”
I typically will not merge bandcamp if there are release date differences or if bandcamp doesn’t surface a barcode, because in those cases i’m not confident enough that they’re actually the same release even if the content is basically the same.
Small change to the extension I use to make editing faster: I recently co-opted some logic from chaban’s script for Searching recordings by ISRC in release edit. This means that recording matching can now happen automatically by comparing the ISRC provided by Harmony with the ISRCs available in MusicBrainz (because the extension stores data provided by Harmony, you don’t need to paste in ISRCs to trigger the lookup, instead the ISRCs are automatically read from the stored Harmony data). Of course this requires that one still check to make sure the recordings appear to match but it makes this step much faster than it used to be.
If you see suspicious recording matching in newly added releases I do, please vote down or let me know, but I’ve done some testing and think I’ve caught all the edge cases.
