mbsync: Faster/simpler re-tag just for synchronizing with MusicBrainz

[GoogleCodeExporter]

The "re-import" functionality added in 1.0b10 can be used to update files' 
metadata to make them reflect changes in the MusicBrainz database. However, it 
can be a little bit flaky and slow for this purpose: it reevaluates every 
match, not assuming a priori that the MBIDs on the files are correct.

A plugin command could be provided that *just* walks through files with MBIDs 
on them and makes sure their metadata is in sync with MusicBrainz.

Original issue reported on code.google.com by adrian.sampson on 9 Aug 2011 at 5:59

[GoogleCodeExporter]

Original comment by adrian.sampson on 10 Aug 2011 at 10:44

• Added labels: Milestone-1.0b10
• Removed labels: Milestone-1.1

[GoogleCodeExporter]

Original comment by adrian.sampson on 29 Aug 2011 at 12:36

• Added labels: Milestone-1.1
• Removed labels: Milestone-1.0b10

[GoogleCodeExporter]

I'll look into this one. What would the main functionality be?

Get the Album object, grab the Release info from MusicBrainz and overwrite all 
the fields that don't match?

Would this require user interaction to accept changes (like the import 
functionality?)

Original comment by jvandertil on 21 Nov 2011 at 9:56

[GoogleCodeExporter]

Cool! I'm glad you're interested in adding this plugin; it would be a very 
useful thing to have. I'll try to answer a few questions:

1. The main functionality should almost certainly be shared with the current 
"update" command. That command reads new metadata from disk, this new plugin 
would read new metadata from MusicBrainz. Other than that, they're very 
similar: they walk though the database's albums/singletons, *show the user the 
modifications they're going to make*, update the database, possibly write new 
tags to the files, and possibly move things around in the directory to match 
the new tags. The mbsync command should also support a "pretend" mode, just 
like update.

2. Probably no user input here; just preview the changes.

These questions are from your email:

3. It is possible for there to be non-album-associated tracks (beets calls 
these "singletons") that have MBIDs. These will satisfy the condition 
"item.album_id is not None and item.mb_trackid" or something along those lines.
I'm thinking that this command should operate in two phases: one that does full 
albums and one that does singletons. This is because MusicBrainz supports more 
efficient queries for full albums and it would be unnecessarily slow to treat 
everything as an individual track, but we're forced to do so for non-album 
tracks.

4. The result of album.items() is not currently guaranteed to be sorted in any 
particular order. We could certainly change this, however -- in fact, that 
would probably be a good idea. Probably want to add "ORDER BY track" or "ORDER 
BY disc, track" or something here:
http://code.google.com/p/beets/source/browse/beets/library.py#1164

Original comment by adrian.sampson on 22 Nov 2011 at 6:46

[GoogleCodeExporter]

I decided to wait until the multidisc support is committed. I'm not sure how 
this plugin is affected by those changes. I have a feeling that this will be 
added shortly (right?).

Original comment by jvandertil on 23 Nov 2011 at 4:58

[GoogleCodeExporter]

Original comment by adrian.sampson on 19 Feb 2012 at 10:46

• Removed labels: Milestone-1.1

[GoogleCodeExporter]

Decided to comment here instead of opening a new issue.

I just started to use beets on my well-organized, 100% Picard tagged music 
directory. 

When importing files, I found that beets does not take into consideration the 
mbids already embedded in the files being imported, and will often choose 
incorrect releases by default, only allowing me to choose the correct release 
if there seems to be collisions. 

This behavior is especially bad because by default, beets will associate albums 
to the wrong release, overriding a user preference (tagging with Picard) 
previously made. 

My own preference here would also be a flag available in the config file that 
would use the mbids embedded in files -- not just for "resync", but also for 
initial import. 

That way, the import is always safe, and will overwrite only updated tags 
associated to the correct mb release. 

Original comment by yoa...@gmail.com on 16 Dec 2012 at 10:03

[GoogleCodeExporter]

@yoasif: Such a config flag is an interesting idea. Since it's a separate 
feature, can you open a new issue with that idea?

Also, BTW, beets *does* currently take existing MBIDs into account. The default 
behavior is to weight those against "plain" metadata matches. Switching to 
purely MBID-based would be useful in situations like yours.

Original comment by adrian.sampson on 16 Dec 2012 at 10:39