• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • None

      There seems to be significant confusion with respect to submitting AcoustID information using Picard.  The process is not intuitive (at least not to me).  Perhaps consider enabling the "Submit" button once files have been matched up on the right-hand side of the display (even if they haven't been scanned earlier), and then scan (if required) and submit selected files from there.

          [PICARD-1413] Submitting AcoustIDs

          Robo Tardis added a comment - - edited

          One thing that I think would help improve the quality of the AcoustID submissions a lot is if there were some visual indication of WHICH tracks don't match an existing AcoustID for the given track.

          Update: I didn't realize that an AcoustID status column was recently made available until I read about it in a different ticket.  That's great, but it could be made better by also having some indication of how many AcoustID's already exist for a given track (especially if there are none).  This would help users determine if one track might have just had a rip error (in which case I might not want to submit a new one), or if there just aren't any known AcoustID's for a track yet, in which case I probably do want to submit them.

          It would also be good to allow an option (perhaps added to the right-click context menu for a track) to submit only the AcoustID for that track, so users can be selective about which to submit.

          Perhaps I should create these as separate issues tho?

          Robo Tardis added a comment - - edited One thing that I think would help improve the quality of the AcoustID submissions a lot is if there were some visual indication of WHICH tracks don't match an existing AcoustID for the given track. Update: I didn't realize that an AcoustID status column was recently made available until I read about it in a different ticket.  That's great, but it could be made better by also having some indication of how many AcoustID's already exist for a given track (especially if there are none).  This would help users determine if one track might have just had a rip error (in which case I might not want to submit a new one), or if there just aren't any known AcoustID's for a track yet, in which case I probably do want to submit them. It would also be good to allow an option (perhaps added to the right-click context menu for a track) to submit only the AcoustID for that track, so users can be selective about which to submit. Perhaps I should create these as separate issues tho?

          Bob Swift added a comment -

          You both make very good points, and I agree that this requires a bit more thought before we take any sort of action.

          One scenario that I encounter is that I will try to scan my freshly ripped files and they will match up to the wrong release.  I either locate or add the correct release and select it manually, but Picard won't let me submit the AcoustIDs because they already exist (but are not associated with the correct release).  Perhaps it's a case of (slightly) different recordings needing to be merged.  I don't know.  Because of this, I've basically given up on submitting AcoustIDs with Picard.  My process now is to make sure the files are properly tagged and then use AcoustID Fingerprinter to scan and submit.

          Bob Swift added a comment - You both make very good points, and I agree that this requires a bit more thought before we take any sort of action. One scenario that I encounter is that I will try to scan my freshly ripped files and they will match up to the wrong release.  I either locate or add the correct release and select it manually, but Picard won't let me submit the AcoustIDs because they already exist (but are not associated with the correct release).  Perhaps it's a case of (slightly) different recordings needing to be merged.  I don't know.  Because of this, I've basically given up on submitting AcoustIDs with Picard.  My process now is to make sure the files are properly tagged and then use AcoustID Fingerprinter to scan and submit.

          Yes, that is basically the reason why this so far was not possible. It is also the reason why Picard does not resubmit AcoustIds that are already merged, as this would increase the submission count and emphasize bad matches.

          We have a bit of dilemma here between preventing bad submissions and allowing people to submit.

          1. We want avoid people submitting bad data, so we have the AcoustId methods limited. This makes it harder to submit bad data, but also harder to submit good data
          2. People actually want to contribute AcoustIds, but they find it difficult to do so
          3. AcoustId matches are often tried on very bad data, because that is where they are most useful. But this makes it harder to put any automatic checks in place (e.g. existing metadata needs a certain similarity to matched metadata)
          4. We also have to rely on humans to do the matching and submission, because in case there is not AcoustId only this can give us good results.

          Not sure how to solve this. We could add some warning message, but usually those get ignored. Or only submit cases, where there is no other AcoustId for this recording and also no other recording already for this AcoustId. Maybe we need some review screen before submission?

          Philipp Wolfer added a comment - Yes, that is basically the reason why this so far was not possible. It is also the reason why Picard does not resubmit AcoustIds that are already merged, as this would increase the submission count and emphasize bad matches. We have a bit of dilemma here between preventing bad submissions and allowing people to submit. We want avoid people submitting bad data, so we have the AcoustId methods limited. This makes it harder to submit bad data, but also harder to submit good data People actually want to contribute AcoustIds, but they find it difficult to do so AcoustId matches are often tried on very bad data, because that is where they are most useful. But this makes it harder to put any automatic checks in place (e.g. existing metadata needs a certain similarity to matched metadata) We also have to rely on humans to do the matching and submission, because in case there is not AcoustId only this can give us good results. Not sure how to solve this. We could add some warning message, but usually those get ignored. Or only submit cases, where there is no other AcoustId for this recording and also no other recording already for this AcoustId. Maybe we need some review screen before submission?

          Peter Culak added a comment - - edited

          I really like submitting fingerprints to be separate from matching existing ones, but it could cause some issues with the data in mb such as fingerprints being linked to incorrect recordings. I'm listing one such example scenario that could occur:

          Many people who use Picard have lot of files that they want to tag, usually from some bootleg various compilation albums that they downloaded one day. Some of the tracks might be slightly misstagged, e.g. radio versions, single edits, etc. missing from the track titles. Currently, they could run it through Lookup, match it to an album and tag it (it will be mistagged anyway, but they won't be submitting any data to mb, so it's not that big of a deal). They could also run it through Scan, which will (hopefully) reveal that the track is actually a radio edit (or similar variant) and it will automatically be moved to another release where its recording matches the fingerprint.

          With your proposal, they could match it to the incorrect release and then attach the fingerprint to an incorrect recording, which would not only be incorrect in this case, but also for other people matching this file in the future. I'm not saying you can't attach fingerprints to incorrect recordings currently, but you have to move the files manually into the incorrect recording before submitting them, while in your case you just need to submit them after pressing the Lookup.

          As I said in my first sentence, I am not against this idea, I'm just highlighting one of the possible issues that came to mind so we are aware of such issue.

          Peter Culak added a comment - - edited I really like submitting fingerprints to be separate from matching existing ones, but it could cause some issues with the data in mb such as fingerprints being linked to incorrect recordings. I'm listing one such example scenario that could occur: Many people who use Picard have lot of files that they want to tag, usually from some bootleg various compilation albums that they downloaded one day. Some of the tracks might be slightly misstagged, e.g. radio versions, single edits, etc. missing from the track titles. Currently, they could run it through Lookup, match it to an album and tag it (it will be mistagged anyway, but they won't be submitting any data to mb, so it's not that big of a deal). They could also run it through Scan, which will (hopefully) reveal that the track is actually a radio edit (or similar variant) and it will automatically be moved to another release where its recording matches the fingerprint. With your proposal, they could match it to the incorrect release and then attach the fingerprint to an incorrect recording, which would not only be incorrect in this case, but also for other people matching this file in the future. I'm not saying you can't attach fingerprints to incorrect recordings currently, but you have to move the files manually into the incorrect recording before submitting them, while in your case you just need to submit them after pressing the Lookup. As I said in my first sentence, I am not against this idea, I'm just highlighting one of the possible issues that came to mind so we are aware of such issue.

          This is somewhat an alternative proposal for PICARD-991

          But I like your proposal very much. But maybe users would prefer having scan and submission separated, so just allowing a scan on matched files would probably solve this, it would highlight the submit button afterwards. Or we actually allow both:

           

          1. Enable scan button on matched files. The scan would generate AcoustIds without new matching and without submission. The submit button is available afterwards if applicable.
          2. In addition also enable the Submit AcoustIds button if there are unscanned matched files. Hitting the button would first scan any files which have not already been scanned and afterwards automatically submit.

          Philipp Wolfer added a comment - This is somewhat an alternative proposal for PICARD-991 But I like your proposal very much. But maybe users would prefer having scan and submission separated, so just allowing a scan on matched files would probably solve this, it would highlight the submit button afterwards. Or we actually allow both:   Enable scan button on matched files. The scan would generate AcoustIds without new matching and without submission. The submit button is available afterwards if applicable. In addition also enable the Submit AcoustIds button if there are unscanned matched files. Hitting the button would first scan any files which have not already been scanned and afterwards automatically submit.

            Unassigned Unassigned
            rdswift Bob Swift
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:

                Version Package