Since @mschuerig specifically requested that beets shouldn’t be discussed in his thread How to update a large collection?, I thought it would be nice to continue the discussion from @Freso’s post:
I’m thinking of using beets to update my entire (already MBID tagged) collection, so I was wondering if you could share some tips and tricks. I assume you would use the MBSync plugin? Does it fetch the same tags as Picard would? Any other recommendations?
Of course, any beets discussion is welcome.
(Note that beets also has their own Discourse instance at http://discourse.beets.io/ )
beets recognises (and thus sets) less tags than Picard. (This is one of the reasons I run files through Picard first.) (Also note that beets’ file naming is less flexible/“powerful” than Picard’s, so if you’re doing very intricate filenaming, beets may not be able to replicate that.)
One thing I really like about beets though is its “flexible attributes”, allowing you to define custom tags etc.
I am interested in this discussion. I’m not ready to work hard on beets yet, but I expect to be later, once I am done with my first pass of ripping everything.
I have a collection of about 400 albums (mostly classical and opera, several with multiple CDs), ripped, and tagged with MusicBrainz IDs, in a 134GB directory tree on my file server. Right now I am still trying to work through my backlog of CDs to rip properly. For now, I only retag the ripped audio files when something is clearly wrong or changes. I retag using Picard, a subdirectory at a time, corresponding to an album or an album-artist.
I would like to use beets to manage the whole thing. I anticipate having to help write several plugins to make it work. Among them:
- A beets plugin to import a full-CD unitary FLAC file, and split it into per-track FLAC files according to a CUE sheet (I rip first to a unitary FLAC file for a CD archive)
- A beets plugin to replicate the tagging Picard does for me now. And, it want it to do better; for instance, to reliably populate the Composer tag, and Artist tags for the various performers, in my audio files.
- Better yet, a beets plugin which lets me make local overrides for the MusicBrainz metadata. For instance, I would rather use “Don Giovanni” in my track titles than the CSG-approved Work name Il dissoluto punito, ossia il Don Giovanni, K. 527. I want to have these overrides in a static file, so I don’t need to keep retyping them as I take advantage of the better metadata from MusicBrainz over time.
- A beets plugin which is a better version of “export to MP3, with total size budget”. I want the export to select the most-liked tracks by tags and ratings, and sync them to a target directory (my laptop, my other laptop, my phone, my spouse’s phone) but making clever use of a second directory tree as a tagged MP3 cache. The better export will skip converting audio data from FLAC to MP3 if the existing MP3 audio data match the current FLAC data. The better export won’t bother updating files in the target directory if they are already there and still current. The better export will ensure that the target directory is no larger than the size budget, while being sure that only full albums get exported.
- A beets plugin which is an ISRC submitter
- A beets plugin which is a to-do list and metadata bug tracker. I want to configure it to know what metadata I want MusicBrainz to have for each album in my collection, then give me a prioritised list of tasks I could do to improve my collection’s metadata using the physical Releases I have on hand. For instance, it could list for me the Releases which have no cover art; my task would be to scan my physical Release and submit to the Cover Art Archive. Or, it could tell me which audio files lack a Composer tag and should have one. Or, I could say that I a particular music file is lacking an Artist tag for one of the performers, and that turns into a task for me to improve the Release metadata, and let the improvement percolate back down to the audio file.
Their tagline is, “Beets is the media library management system for obsessive-compulsive music geeks.” I apparently am in the target market!
That’s a shame. I would have liked to get my entire library updated just as I want it (as of this particular moment…). I guess it’s still more feasible to get beets to fetch more tags than it would be to make Picard support large amounts of files.
I’m not sure what you’re saying about beets recognizing less tags. Wouldn’t the flexible attributes solve that problem?
You have some interesting ideas, though I’m not personally interested in any of them save from tagging And maybe the last two. I should look into writing beets plug-ins.