Difference between update and mbsync


I’m wondering: what is the difference between update and mbsync? I have a music collection that is tagged uniquely using musicbrainz (as far as I know) but if I run beet up and beet mbsync after one another they find discrepancies.
As an example, this track was tagged with beet up and then with beet mbsync, that’s what mbsync modified:
Isaac Albéniz - Albéniz: Iberia / Granados: Goyescas - Iberia Suite, B. 47: V. Almería
albumstatus: official -> Official
original_day: 00 -> 15
composer: Albeniz (1860-1909) -> Isaac Albéniz
tracktotal: 10 -> 19
albumartist_credit: -> Albéniz, Granados; Alicia de Larrocha
original_month: 00 -> 01
composer_sort: -> Albéniz, Isaac
original_year: 0000 -> 1996
language: -> spa
work: -> Iberia, B. 47: Book II: II. Almería
label: -> Decca Classics
albumtype: album -> compilation
artist_credit: -> Isaac Albéniz
I don’t specify any source for the musicdata and I don’t use any plugin for discogs or similar, what is happening?

Edit: I use a slightly different version of beets (with parentwork plugin and additional work and work_id tags), but this shouldn’t change anything and I noticed this also on the regular beets.


This is an extreme example, most of the time, there are only minor changes (like adding a dot in a title) but it still is a change.


Hello! The update command detects changes to files’ tags on the filesystem, while mbsync fetches new data from MusicBrainz.


Thanks! Now I understand it better. I’m also wondering: on MusicBrainz, there are very regular merges of recordings and albums (I have a 40k music collection and I get 50-100 merges every day) that change the mb_trackid and mb_albumids of the recordings. Does mbsync see and reflect an eventual change in mb_trackid and mb_albumid ? This is not a problem as far as fetching the data is concerned, since the old mbids redirect to the newer ones, but it doesn’t interact well with the duplicates plugin, since he uses the mb_trackid and mb_albumid as default keys. That could mean trouble if one adds a recording to the database that is already in the collection, but after some process the mbid of the recording changed. Then they wouldn’t be recognized as duplicates anymore. On the other hand mb_trackid is the most sensible choice for tracking duplicates if one uses MB as a metadata source.
Do you know if this could be a problem? I’m asking because I never noticed a change in mb_trackid fields and I noticed today that I have quite a few undetected duplicates and I wonder if it might be because of that.


Good question! I’m not 100% sure—it might be worth doing some experiments with manually-set IDs to find out.


I finally found an occurence of
mb_trackid: 33f1f557-d44b-4c5d-9087-5b6539f18843 -> d49b09ef-3771-4d6d-8111-1f3a3f72ca58 so I guess this is settled.