-
Bug
-
Resolution: Fixed
-
High
-
1.4.1, 2.0.4
-
None
-
Windows 7 (64-bit)
If you unset musicbrainz_recordingid via scripting and use Scan on a song which is slightly mistagged (e.g. uses track number and track name of a different track from the same release), it will not be correctly moved to its respective spot in the right pane according to the Scan, but actually according to its tags. After enabling musicbrainz_recordingid and scanning the files again, the tracks will be assigned their positions correctly based on the scan result. Attaching screenshots (one with musicbrainz_recordingid and one without).
Edit: Found out that the track doesn't necessarily have to be mistagged, it can also just not match any of the track titles from the release it's been matched into. Having a track title written in a different script is enough for it to be assigned to a different track within the same release which does not match its AcoustID. Apparently it picks a track with a title closest to the title of your track. Attaching two more screenshots.
So it looks like if you perform a Scan and you have musicbrainz_recordingid tag unset, the track gets matched to the respective release by its AcoustID, but to the respective recording by its tags.
Edit 2: If you clear the Artist tag, the track still gets matched to the album that contains the track with the matching AcoustID, but instead of being misplaced, this time it gets moved to the "Unmatched Files". After enabling the musicbrainz_recordingid again, the file gets properly assigned to the track with matching AcoustID. Attaching two more screenshots.
- is related to
-
PICARD-1363 AcoustId submission for matched files is impossible when musicbrainz_recordingid is unset
-
- Closed
-
[PICARD-949] Track can be placed in the incorrect spot on the release after using Scan
I am wondering, after the fix you seem to be using the track's original metadata. Does this mean you are using how the track is tagged or what the raw values would be on the right side in Picard? My concern is files that have empty or different musicbrainz_recordingid tags from the recording that they have been matched into after using the Scan function. Same goes for PICARD-1363.
Yes, I can reproduce it in Picard v2.0.4. Do you want me to send you the file?
Ignore my previous comment, I found a way to reproduce it. In my first test the track length was too different, and the length has high influence on the matching. I chose another example with same track length as another track and I can now reproduce the mismatching.
Update: Now I cannot reproduce it again. Sorry for the confusion, I maybe mixed something up in my previous test. Can you test on your side again
Peter, can you still reproduce this with latest Picard 2?
I cannot reproduce this, and looking at the code it should work. Picard does metadata matching, but not against all tracks of the albums but only those recordings which have this acoustid attached.
So in most cases there will be only a single result, and Picard will match against that. Only in the rare circumstance that there will be two recordings with same AcoustId on the same release the metadata matching will make any difference.
Now I get your point 
Yes, you are right, this should actually work independent of the metadata. That probably needs some change in the implementation, because this works on files not tracks, and files get their MB IDs only via the internally stored metadata. I entered PICARD-1363 to track this.
But my point is, if the track is being matched to a recording on the right pane, shouldn't Picard get the recording id despite the tag being unset? For example if I press right click on a recording and select "Lookup in Browser", the recording with the correct recording id is opened in my browser, despite the tag being unset. I was expecting AcoustIDs to work the same way (that unsetting a tag only affects whether the fields are being displayed and saved to the file, other stuff should still work independently from that).
The point of submission is to submit a fingerprint with associated MusicBrainz recording ID (to link a AcoustId to the metadata on MB.org). Submitting without a recording ID is kind of pointless from Picard's point of view, because it will just result in an AcoustId not linked to MB metadata. It is otherwise useless for Picard and does not help getting correct metadata for a recording.
The orig_metadata for tracks is what gets initially loaded from MusicBrainz unaltered by scripts, so this always contains the correct recording_id.
That's unrelated to the files. Files themselves have a similar orig_metadata, in this case this is the data loaded from the file.