First time beets user here.
I’ve got a mountain of ~2TB of music with inconsistent folder structure, naming and tags before me that I want to conform to the rest of my library with as little manual effort as possible.
I’m trying to achieve that .lrc files that are stored in the album folder are not only copied into the new folder that beets creates while importing but also renamed to preserve the relationship between .lrc file and corresponding song.
For example:
0105 - THE GHOST OF YOU WALKS.flac
0105 - THE GHOST OF YOU WALKS.lrc
should end up as
05 The Ghost of you Walks.flac
05 The Ghost of you Walks.lrc
in my folder structure.
Has anyone achieved that? I don’t want to end up with
05 The Ghost of you Walks.flac
0105 - THE GHOST OF YOU WALKS.lrc
as that would break the connection between song and lyrics and I’d have to go through all of them and rename them.
In a perfect world the plugin would first check if each .lrc file has the same name as a song and if it does, rename the .lrc file using the same pattern that beets uses to rename the song while copying them to the new folder. If no corresponding song is found, ideally the plugin would move the .lrc file into a new subfolder named “LRC_unrel” to make it obvious after the fact that those lyrics need manual work.
Neither
nor
has been updated in the last 2 years. Are there alternatives I’m not aware of? Is anyone still using either with a current version of beets? Can they do what I want to achieve?
Another point I’m uncertain about is errorhandling with either of these plugins. beets-copyartifacts seems to be able to rename file types using a pattern. Log files are used as an example:
paths:
ext:log: $albumpath/$artist - $album
But what happens if there’s a folder with 2 different files with the same extension? If someone kept the original .cue file for an album that was ripped as a single flac file and then also stored a new .cue file after splitting that file into multiple songs, what would happen?
I’ve been tinkering with my config file for the last few days trying to come up with most of the common pitfalls and ways to avoid them gracefully, but some stuff remains unclear to me.
I want to get it right before I work my way through the 2TB musc mountain, any help is appreciated.
As no one ever reacted to my questions I switched over to using mp3-tag and solved most of my issues with actions I created with the help of the very active forum. It’s sad because other than this I was pretty happy with beets.
Everyone who stumbles over this thread: From those two plugins in question, beets-copyartifacts seems to be the one that might be more worth trying at the moment.
I had some very specific needs and did a fair bit of work starting last year that resulted in a fork for copyartifacts, named beets-filetote. One of the features I added directly addresses @Casual_Tea need to bring along files but rename them to match the new name of the media file (look for “pairs” in the README). I’ll soon also be adding pattern-matching (akin to how extrafiles is configured) to provide the best of both of those plugins.
Looks very promising, good job! Sadly I’ve moved on from beets to mp3-tag where I created custom actions to cater to my specific needs. I also process a lot of bootlegs that aren’t in musicbrainz anyways so it’s faster overall if I do it all in mp3-tag instead of automating what I can in beets and then having to finish off the obscure stuff in mp3tag anyways.
Sorry for bumping up this old thread, but just wanted to say thanks for creating this – I just returned to beets after a long hiatus and found extrafiles was messing up my setup. I haven’t tried it yet, but will definitely give beets-filetote a try!
Just for the sake of having all information:
I’ve succeeded in convincing the mp3tag dev to implement the feature that .lrc files with the same name as a song get moved and renamed alongside it in mp3tag versions v3.21h and newer.
So in addition to using beets you can also use mp3tag and be sure that the link between songs and external lyrics won’t break.