The thing is that Picard does not allow you to resubmit already existing AcoustIDs. I actually would like to have this in Picard, too, but it is probably not quite clear how this can be done.
I don’t remember the details, but we had a short discussion about this on IRC some years ago. The main fear was that if you would just be able to submit fingerprints for existing matches, that quickly would turn into a self-fullfilling prophecy: User use AcoustID to match songs in Picard, and then submit the matched IDs to AcoustId and increase the count. That way Picard would introduce a bias into the data. I still think this could be done somehow, maybe keep track of the files that where not matched by AcoustId.
It took me a bit, but I think I see what you are saying. The issue is the user, lets say me, submitting my release with acoustIDs. Then, submitting my release again. This is really one submission and not 2, so the intent is/was to prevent duplicate user submissions. Am I understanding this correctly?
If so, I had mentioned having submissions logged/tracked by API key and/or ID, just like MB edits for example. If this were possible, you would have the ability to restrict one submission per recording per user, since you need your API key to make a submission.
No, not exactly. I mean actually different users. Currently if you use the AcoustId scan in Picard two things can happen:
You don’t get a match. In this case you can use the other options Picard provides to match a release and then submit the AcoustId. This is the first submission for this AcoustId ↔ MusicBrainz recording match
You get a match. In this case Picard will load the matching release and will not allow you to submit this match again, because it is already in the database.
Let’s say we allow resubmission in case 2. Then let’s say I do case 1 for a certain track, but I get it wrong and match to the wrong version of that song, then submit the AcoustId. Now you have the exact same track. You are in case 2, Picard will see the match and load the wrong track. As it looks ok on a quick look you trust it and resubmit the AcoustId, thus confirming and emphasizing the wrong data.
Ok, I see. It is opposite as I was looking. The concern is letting bad data spread vs tallying proper data. Assuming I am with you this time, that makes total sense.
Thank you again for the info. I have a few topics on similar topics in the forums and the info I am getting is great and very useful to me.
I wanted to add an example of where this might be useful. I just entered artist information and added data to an existing release:
Now on this release, track 3 had an existing acoustID, none of the others did. I added my acoustICs via Picard, and it is not a match to the one on track 3 existing on the MB release.
So… I can only speak to what I know, and that is my release is a copy of the original release back in 2012. Given that the release came from her and all the recordings match in content to what they should be (ex matching to YouTube video, matching the lyrics, etc), I can be certain that my acoustID is correct.
Now, this does not mean the other is incorrect. I don’t know where it came from or anything, but I can say that it was tied to only one recording on the release whereas my IDs are all from the release as a whole, as it was released. Personally, I an highly suspicious of the existing ID assigned to that recording, but I cannot delete it as the duration is a match (within 1 second) and there are no other recording names tied to it, so there is nothing obvious telling me that it is in fact wrong.
So my point of stating all the fact above is that this information would be useful to others to see. The fact that the IDs I submitted were all submitted together as a whole release, and the other ID was submitted to the recording and only the one recording. So removing a right or wrong mentality, there is knowledge in the facts of ID acquisition and submission even at a submission count of only one per. Additional submissions, should the feature be there to tally duplicate submissions, would further highlight this data.
Sorry for the long post, but I wanted to express in detail a realistic example of how more data can be useful vs just saying it would be useful.
If you have this album and as the recording only appears on this release (it was not a NAT / SAR beforehand, for instance) maybe you can unlink the other AcoustID as they really don’t match. IMO Compare fingerprints #32321958 and #63069758 | AcoustID
Yeah, I saw they do not really match. Only match is the time and assigned recording. I hesitate to remove data that I do not know for sure, or at least have a solid base for assumption, to say it is wrong. The problem is I have no idea where it actually came from, and there is no way to “reverse engineer” the fingerprint.
One of the main reasons I hesitate to remove such data is I also enter a lot of data that is difficult and in some cases I would say impossible to reasonable verify. The artist in question here is also not a top mainstream artist, so there exists a lot of dual releases (both paid like Amazon and iTunes as well as free promo and DJ types) of the same release. This also means there is not a large amount of data on the artist either. For example, I do not think anything online (officially) actually references her real name and birthdate. If I needed to show proof of what I entered, I would have to use something like an article from the university she attended that would tie it all together… as an example. So I would hate for someone to delete such things simply because there is no evidence of it.