The first time I imported all my music as albums I had a problem, in the way I personally tag my songs particular songs of an album often have a lot of different genres and when imported as an album beets assumes all the songs in an album should have a single genre. So the solutions it seems is to import every song as a singleton. Should I expect any problems when doing this or is there a better way of doing this?
The bottom-line consequence is that the beets library won’t “know” how your items are grouped together in to albums. In practice, this might not matter! All the tags can remain the same, for instance. Two high-level differences come to mind:
- The autotagger won’t be able to fill in some album-level metadata. For example, you wont get the
$albumartistfield, which tells you who is the name on the release (independent of the featuring artists, etc., who are on the track). - If you have two albums with the same artist and same name (e.g., there are several albums by Weezer whose title is technically “Weezer”), beets will have no way to put those in separate folders on your filesystem.
I hope that helps!
I see, thanks for the answer 
Wouldn’t it be possible to prevent the second issue/ difference by using the following paths entry in config.yaml?
paths:
singleton: $albumartist/$album%aunique{}/$track $title
Alternatively is there a way to only share certain metadata between tracks in an album? For instance only sharing $albumartist, $comp, $album and probably some other relevant things which I can’t think of at the moment.
Both of those things (%aunique and sharing values across the tracks of an album) are only possible for tracks that are part of an album structure in the database. FWIW, it’s also not currently possible to configure which fields are considered album-level vs. track-level fields.
Good to know. Although some tags being album-level are deal breakers to me I’d still really like to use beets. Could you point me to the part of the beets code where the distinction is made? I’m fine with making some changes locally for myself and merge further commits locally. I suspect it’s quite hard to make this configurable so I don’t think it’ll lead to a PR but I assume it must be doable for me personally if the distinction between album- or track-level fields stays te same.
Furthermore I wonder if I can completely disable beets from doing any moving around, changing tags or mutate my files in anyway without my consent? If modifying the code to fit my personal needs isn’t feasible I might still be able to use beets and it’s plugins such as edit if I’m able to disable any automatic changes. To illustrate it a bit more, what I would want in that case is to still use beets for editing tags, the wealth of plugins beets offers, its fantastic hook system and potentially manually moving tracks but I wouldn’t want beets to do any of this automatically or to have beets write these album-level or for that matter item-level tags if I’m not manually doing it.
Sure; the list of album-level fields is listed here:
And definitely; you can stop the importer from moving or writing to files with the move and write config options in the import: section (see the configuration docs). Then you can beet write manually to change files’ tags (and beet move to move files around).