Strange behavior when submitting acoustIDs

MusicBrainz Picard
1

Picard 2.13.3 on Windows 10 Pro fully updated, I think this is some kind of bug but hard to say where so I’m asking before ticketing. (I have some screenshots but no log because I didn’t expect this to go wrong.) Sorry this is long, don’t know how else to describe without narrating.

Scanning a release that had apparently not been scanned before, but that as a frequently-reissued set of albums has many potential matches, I moved all results to the new release and submitted acoustIDs, then saved the tracks. Was going through tracks one by one using the AcoustID right-click “Lookup in Browser” shortcut to make acoustID-based merges and soon hit a track that hadn’t yet appeared on the AcoustID site. (This has happened a lot in recent years, as the link between MB and AcoustID sometimes doesn’t get refreshed, others have referred to this as a “hung” submission.) So I went to verify that this track was acoustID-less, but it wasn’t; it had another ID instead, not the one showing in Picard. Strange. So I dragged the track back to “unclustered” and scanned it again, and now got… the ID showing on the MB page? And indeed, can no longer get Picard to produce that first ID. I went ahead with the merge, and noted the behavior on the edit.

I restarted Picard just in case I was seeing things, and two tracks later it happened again. This time I got receipts. Screenshots showing 1) just before the lookup, 2) the non-matching IDs, and 3) the pending merge. Can someone explain how this happens (and therefore is not a bug)?

image
image1112×816 48.5 KB

image
image801×902 40.1 KB

image
image1247×709 27 KB

(highlights and arrow from greenshot)

2

for completeness, here’s what it looks like when I rescan in picard (no other modifications made to the file, just dragged left and clicked “scan” again)

image
image1078×752 50.5 KB

3

When you lookup an AcoustID fingerprint on AcoustID it compares this to existing fingerprints. If it finds matches that are close enough above a certain threshold it returns those results. Often there is exactly one result, but AcoustID can also return two or more close matches, ordered by most similar first.

Picard uses all those returned results from AcoustID. It combines the similarity score of the AcoustID fingerprint lookup with the metadata similarity to select the best match.

In your case when you did the original lookup, AcoustID returned f0f071f6-4b93-4976-9e94-2e991311b4bf. Either only this single result, or at least that was the best fitting result.

But when you submitted your fingerprint and it was processed by AcoustID it considered this new fingerprint just different enough from the other fingerprints on the existing AcoustID to have it assigned a separate AcoustID 13453667-e042-49fe-80bf-3f6110eebcc2.

If you look at the visual comparison this actually makes sense. Below is the comparison between the most submitted fingerprint for the first AcoustID against the fingerprint of the new AcoustID (which I guess was submitted from your file):

image
image618×727 29.7 KB

Similar, but different enough for AcoustID to assign it a new ID.

If you repeat the fingerprint lookup in Picard now then the new AcoustID is the better fit. AcoustID will now likely return both in the lookup result, but the new one will have the higher similarity. If you are interested, turn on debugging in Help > View Error/Debug Log. Then do “Scan” on the file and share the output here. One part of that debug log should contain the response from AcoustID.

5 Likes
4

Thanks, very clear and super-interesting! Especially as I’ve scanned tens (or hundreds?) of thousands of tracks and have never seen this before. I suppose a recording that has seen many many releases, as is the case with Nina Simone in Europe (OT but rights ownership must have dropped), is more likely to have more nuance in the IDs associated with it as any two may be mastered differently? Anyway the picard response makes sense now, though has no UI feedback for such a rare case. (Makes people like you have to respond to forum posts like this :upside_down_face: ). It would be cool to have some at-a-glance ability to know that the two IDs are that close by comparison, but maybe only cool to me.

For completeness, here is the log reflecting a new scan of that answer, in its entirety

 D: 12:54:37,518 ui/itemviews.dropMimeData:797: Drop target = <Cluster 'Unclustered Files'>
D: 12:54:37,520 ui/itemviews.drop_urls:754: Dropped the URL: "<path-redacted>/1.05 - Love Me or Leave Me.wav"
D: 12:54:37,522 file.move:641: Moving <WAVFile '1.05 - Love Me or Leave Me.wav'> from <Track be898d44-7d68-4220-af9f-69c99ff1c17d 'Love Me or Leave Me'> to <Cluster 'Unclustered Files'>
D: 12:54:48,605 acoustid._lookup_fingerprint:185: AcoustID: looking up the fingerprint for file 'D:\d-m\rrippinn\simone, nina - nina's blues 1959-1962.flacf\1.05 - Love Me or Leave Me.wav'
D: 12:54:48,607 webservice.post_url:684: POST-DATA 'meta=recordings%20releasegroups%20releases%20tracks%20compress%20sources&fingerprint=AQADtCITKRyR00j2JDj6Bj_OFn5y_MTTB7GZB2WYw8AB7XiPH3GG4y_aHyf8o3ZsPLnwB_pxJR3h93im1fixJzmoKutw5RrGxJaORyLcbDPyQRWDqMlaBfcTNEed4zuO8I7RHNnzDM-F6w6ugM_QSJHoINR3SD3SL2pwfEfobA2a5eA16PiP78GV5IKm62jopJgLHTme48rxjHg-DY6oHZcqnLGR80j2wkcf_KGCNYTjcHiLZlQiJPuCXAyeGhevoJEeTiiPP8GlE7Ny4duJMIeGMYry4HvBE-KXHJck9PmgSVmeBFFz_MeNeiyafwk-XAkeBmGsKCy0LyzyCFfwF83yozIz7MqPH9kfaM-K8AefSXgkXBJBLuGNJy_yQ8uTI8SPJ8eVJT0uY8wTVC-ax_iDPlcR5mGM7xCTJDpiJ8OTYOeDPxWYI022H8mj4g6aMXjgi8pwinHwJTkOP8U_cMmDjzvmb0HTKEftDD_M4ynTBJeUckHqQzdyEn6W4s9wyRac9MIzYfrQdOzxg_8jjJZIJE5n5EmOSwt2-ugV3HCOl2CMX7heTAyPX-iqFPGhL-h_pBWm51HAOR_i9BL24VugJzs-5qiVoDlwyUTPj9CyVPFxZo2wC8ZxcujBJI9wRD-uZc7wNBGRhl8E_UdO-Ef_EE1T45x0PETyLDme8KjMo3keJA-OXngUGefx5MEbKwm6J6nQhMrRxzpyH-Kf4UFoZTkMP0Of4znycoW66YjM9LiP5qFk3Eg-7Uh_HDdlZJKO5EOtog9HbJNy9OHRL0dz_PhS5HFy6HhkQd2Pv1Cp4ytcjsR1I18O38Kj4wkaN0O7KCpOGmFSK9Ce6EEtJouEMGPGIYdOIPdhhzkupUYeDVq-H-GNMwkmZVoa9CID9iTyB3qQ42PQRm3wZMetobmyxth1XMePxmFC9MizA8l-2FtxJYGXYyJxHfmh6TqYaEK2F38wZdlmlM0e5IZ2F3l6XAxKBmWawxfqPcR9PDz-FEd-6AlVhPlRGs8ePMaZ0PiR-AjlYUqV4RmF_LiOJ82VQG8eaGKSGWGm48FvPJEyKsP0MBHxCyde-MeVIIkiDXlwPSmYu8EllOTRLFGWB9NLPFxwZ0TPBI0iWklwRczRZ2ie4DTyPNDJq4h74UHF40dzSQrOpPhyJD9yPMZ3PDucP7iNXBl0SUf4MD2mHPnBY0efG9P1QHqO6AuOh89x50fTEcU_6BXewsvxREmwX-nAWcem8jGSvsiTi7ieCE-EJ12R8FKQKzrxZOoWPMcP9xR-XCGJPkeYx8UZTFceME8NhYs4IWdjnD-aM6icESfj4GuGf8QL7YSP_riIV8mDY9yRXJ2CbM4XWAe-5vibog2jgXqiNOioYzRwxnhN1A6uH8155JCRTx_hPFGCZ5uCPhrRXAreFl4eJM8R0VfAZckPVy3wYD7y9FBFRUecsZiP8N3RVEygJj1G_DiUMyHyhuPAKfoSdGFwCj247_gfTJ8TNE-QeM7xIM_RRET7D6_gJEkcbjjF4yV-uMqg5zjeHI-jRXCyTDnO5-hJTHla8D2iX4ImJXkQ5sSv49VxSdEmlNTh5SOas8KRFwnz4xF_HD_6o3HjETn04zj1BPIrRBK8RmBq4SKe8MPFJgl-4QejD0apH0n3B_l6DfmUhdhxPZPhJT7uo0-OVCGDliNxnbhyhPG2xegP_QjTo8eXHKMSfcgfiHl45EqI7zi1GV_A2ahyNKePOcklQtcxlzu8nMI-1M_QND7-4kSjOEX4LEfSH1dy_BH6jGjWhbgsJP8R6sSUZCf6HM3CNZhyRUSo65Cfw2lo6CbSZS0l_PgCN49xJjyuwU-N5IgfrDPs5uDwGc3To8_x4vwIL8sxNubwHLty5IuRPMeFsiGaF8e_JsObD_WWHVbiwJF11HdC9E11NJMONkcfhHmQPIku4ZIe3BOe5guuLBf4g3tQZRvsI2UOZVcX9FEyCT9OHpqPJpqOZFOUkGgiKgl-9D-a4ZOOMwsxXqhyI-EQMjuYg0knMRkeSsKPJ_heeL2CPC--KMcoJ4eWRMsRksIvDk9znMW5KsVvuMlw2ngrpHFy6AyiOwevjLiyPNj24e2CR8cuwvkOLuGV4UnOYb_QnCjyjB-eE7qcEXWqwxemBz_xg-wT7KmFtDtx4yG-LCHC5CIRWjl--BZOpsnxJR9-NJ4-9MeoPA2eHdkOd9CBkIc55thHwg4N78F9NN8YPMU9ItmPME5yvPjQnOLRM7iPJuNzdNolJNWPfPCOXyiTM4KbI3xI3B--JJKOk-XhS_gHLQ8R2scVNSGeH37y4U9oPNKL4TwocjlO3TirMJgWo9qyoT_C7Ay0Zwjz4H4xJRkzlFMeNIwelEdzhA-SKzyYOGyI2k5CVF84UErhJb8QPsMdyL0g5QnCPOLR7AbzYOeHPvARf0h2PPhxvUdi5kOeC-fxC01_9JWNXEoeJD_2bRmqC9RFDY2WZCYuZkfDBb2R52OQPFqOkccP5zlOmugUNNGSdMK7aoOXHpfy4Y0DdzN-Qs-fYUr0lKjiPAGf41QyPImC58J1JhCpT7gkPF1EojljMMyCK9g_PEdP9IlioRaPSAlzQ-JzRPqNJuqCFz-anUIv4Z9w5RHx8JoQmqug5UeOv8FlE9_xe0aYhxUKHeEpo4mZZniY4MjFozn6o5yOZpme4E2DB1qeGOHxJLjkNLhkBY-O5Ec6PJcynE4TPIePjziS5wpyKdnxdD_eB76CdxT-FB9G6oIyHT_uZWieEG0oyXhi_GgeJPOPOM3x7Cg3pULz7AEjQDOIMcAMQIAYhQQQpiHgCBOKCGoAYoIQKwBAgBlgEEaQKgoYI0BAAQQRJBFjABAOIUIE4CIphAgQCCkDCMUAGWIQEEAAgAAEghOCAEAIKOIUMAAID4RAiEDghDDKAkeFIpABAoRHQCtkEIAAIeSAAcQpZgQwmACAGAKCAOQAA84YAgwADChgIBBMAQUAAIQQI4yQTEliDHCIAGKEAAJBQAniCABAhGwESCUEQooQrBQRiEhAgCKCIJgQIAIQIAEyRiBxgCIMCaOAMBYQAhBwFBBllBCEC2KQA4AoSwRgAhnEiBDKG8MIJgAIIASBSBmAgDBGQSKIoMohwIQEACCkgBSGIQAQUAAhAJZChhBCAUIAUUUVEEJQBgwASBpoCFTEACgAhUAAoQATDgDEDOJEIQoQM0QBYARWRAEgADcIGCMQQQYgAAhgDBGAhBECEYUMg8AYwwzDxgojBEIGCAAMAkAZ5hRpDAInGBHUAUIAZAoIJhgAyiEBCEDGKOCKEgICQZmBAhFgEhAACMCQgkRYYKg1xKCCCAPECMCAMAwwQYwBEBBFjQNCoDCMk8g6gAxRAAEnMDACCCGAAQIACwxgTBFALGJEKkCNMQwhA4UgwBFiEgCaEWIEYYgJZAQBRikoICCKKG2QgQBRp4gRzhFgAFNIIQMRIwAQAwAADigKADFAAEAoMoQRwSwEwFBCgDGAACCUQgQAQwxAzACEkCKGGCCcdAAgIA0DBgmBiLBICCaAAIYIAIgQ2BDBEEQEGESAkAYIZEFnwmFAAGBMQASAIIYAQQx3zgBNgBAECOgUIkAIAAQgShACiACCGKoAAAZ8RRAQRlEhCDEaQEsRgRACQpACwFECFBACGSYBMgoQAogYBhEkCFFMACAEUAoRBhAQAAAinCRKKEeAAtQ4IQBBAgDhhGFAICAAUgBCQoRSAlEgAGCMMEcQAA46FpgAQABgCDGMOAowNAoJqoRkhgA&duration=200&client=v8pQ6oyB&clientversion=2.13.3.final0&format=json'
D: 12:54:48,614 webservice/ratecontrol.get_delay_to_next_request:127: ('api.acoustid.org', 443): Last request was 77582804 ms ago, starting another one
D: 12:54:48,614 webservice/ratecontrol.increment_requests:147: ('api.acoustid.org', 443): Incrementing requests to: 1
D: 12:54:48,800 webservice/ratecontrol.decrement_requests:155: ('api.acoustid.org', 443): Decrementing requests to: 0
D: 12:54:48,802 webservice._handle_reply:559: Received reply for https://api.acoustid.org/v2/lookup -> HTTP 200 (OK) 
D: 12:54:48,803 webservice._handle_reply:572: Response received: {'results': [{'id': 'cff6e3bf-9dce-4226-b4dd-90a00d59944b', 'recordings': [{'artists': [{'id': '2944824d-4c26-476f-a981-be849081942f', 'name': 'Nina Simone'}], 'duration': 200.0, 'id': 'be898d44-7d68-4220-af9f-69c99ff1c17d', 'releasegroups': [{'id': 'dd6aa5da-d99f-454c-8a63-a7241d3a9620', 'releases': [{'country': 'FR', 'date': {'year': 2021}, 'id': 'bc3c4953-b4ea-424f-86a2-1eaf2260e1d1', 'medium_count': 4, 'mediums': [{'format': 'CD', 'position': 1, 'track_count': 23, 'tracks': [{'id': 'f31025b4-0251-4c9e-a8f9-8cd471694d18', 'position': 5}]}], 'releaseevents': [{'country': 'FR', 'date': {'year': 2021}}], 'track_count': 77}], 'secondarytypes': ['Compilation'], 'title': 'Nina’s Blues 1959–1962', 'type': 'Album'}], 'sources': 1, 'title': 'Love Me or Leave Me'}], 'score': 1.0}], 'status': 'ok'}
D: 12:54:48,806 acoustid._on_recording_resolve_finish:159: AcoustID: Lookup successful for 'D:\d-m\rrippinn\simone, nina - nina's blues 1959-1962.flacf\1.05 - Love Me or Leave Me.wav' (recordings: 1)
D: 12:54:48,822 ui/mainwindow.set_statusbar_message:471: File 'D:\d-m\rrippinn\simone, nina - nina's blues 1959-1962.flacf\1.05 - Love Me or Leave Me.wav' identified!
D: 12:54:48,824 tagger.load_album:1061: Album bc3c4953-b4ea-424f-86a2-1eaf2260e1d1 already loaded.
D: 12:54:48,829 file.move:641: Moving <WAVFile '1.05 - Love Me or Leave Me.wav'> from <Cluster 'Unclustered Files'> to <Track be898d44-7d68-4220-af9f-69c99ff1c17d 'Love Me or Leave Me'>
D: 12:54:48,849 webservice/ratecontrol._out_of_backoff:231: ('api.acoustid.org', 443): oobackoff; delay: 333ms -> 333ms; slow start; window size 3.000 -> 4.000
5

Thanks for the test. Interestingly this only returns one AcoustID (https://acoustid.org/track/cff6e3bf-9dce-4226-b4dd-90a00d59944b). But this is also for “Love Me or Leave Me”.

Could you retry the same, but for “He Needs Me”? Because we have both the originally found and the new AcoustID documented for this in the initial example. I would be very interested to see, whether AcoustID now also maybe only returns the new result, or actually both.