I had heard a lot about beets, but only started trying it out now. I’d been a loyal picard user, but looking for a change due its inability to update large collections.
I am thinking of two ways to do the transition from Picard to Beets. I have not been successful yet though and struggle to import my library:
Importing my library (import -A, -M, -W, -C, --group-abums followed by mbsync)
Import “as is” largely works. However, struggle with
— Folders that include 2 albums (with same album name, but different release ID or release group ID)
— Path song name to $disc_and_track does not seem to work for some albums
— Mbsync makes things worse. I thought it may be help to fix the issue that I was having with two albums with same name (as they have different MBZ release ID). But somehow, it changes the release ID to make them the same. Not clear why
Going forward, adding new albums to the library and let Beets do the tagging instead of Picard
I haven’t reached this stage yet, but believe this may work with an easy “import -i /music” command?
Sounds about right! In general, however, I would recommend against using --group-albums except in specific cases where multiple albums are mixed together in a single folder. I assume that’s not the usual case? If not, I’d use it only on specific directories where this happens.
And no, mbsync will not attempt to split or combine albums—it assumes that the album grouping you have is already correct.
I struggle quite a bit to get the “multi-album-in-same-folder” issue solved.
My library is very large and I have quite a few albums with same album name (single and album with same name, different releases of the same album).
Mbsync even makes it worse. I was hoping that it would take the album grouping from the mbz release ID, but it doesn’t. It seems to instead pick it up from the recording ID? For example, I have two releases with same name in the folder (one with 14 tracks and the other is the Japanese version with 15 tracks). Both releases have different release IDs in the tags. Running “import -A” keeps the mbz IDs intact, but both albums in the same folder. After running mbsync, the first 14 tracks of both albums now have the same release ID, while only the 15th track still has a different ID. I was hoping that mbsync just relies on the mbz ID to update the rest, but this doesn’t seem to the case and it also updates mbz release IDs.
Can you think of any easy way to deal with my situation? Would need a way to split the albums - it seems necessary at import? Can be done with -A somehow not to lose my existing tags?
Here’s one crazy option: does your music have release MBIDs in the tags? If so, try using $mb_albumid in your path format. Then, beets should organize your music into folders by album, even if those albums aren’t terribly sensible. Then a (second-stage) standard import should be able to import individual albums separately.
Thanks a lot for your quick replies. Hugely appreciated to see live help from the developer himself!
I like your thinking. So, I’d be importing once with “import -A” to put them into separate folders based on their release ID. And then run an “import -A -L” (removing $mb_albumid" from path info), which should then import them in separate paths with the ambiguity info. And once all of this is done, I’d run mbsync to update the tags?
On separate note, I tried many ways to add _releasecomment to the path and/or album tag. But not successful. Is this not supported or what do I do wrong? I’ve seen some notes online that seem to indicate this should work.
And lastly, what’s the right command to include disk and track number for multi-disk albums. I somehow also failed to get this to work.
When you just say something didn’t work, it’s difficult to tell what to suggest. We might be able to help if you say what you tried, what the output was, and what you mean by saying that the change “wasn’t successful.”
There is an FAQ about “Disc N” paths. Have you tried that?
Hmm, can you include some verbose output of import runs where you only try importing those problematic albums? Doing so might reveal why they’re being “skipped.”
We might be able to help if you say what you tried, what the output was, and what you mean by saying that the change “wasn’t successful.”