Avoid clearing the `comp` flag on non-autotagged imports

[guibog]

In beets/importer.py an align_album_level_fields method tries to guess values for albumartist and comp attributes. But this do not work in some cases. For instance, if I import only one file from a compilation album, it will think it is a single artist album, and the path where to move the file will be wrong.
I commented out the changes in my local version of beet (which is very nice, by the way) so I can continue working, but to me it is better to not overwrite tags by guessing.

So maybe comp can be kept like this, but then add a compilation tag which has the real original value.

(Note about what I'm trying to do, which might be unusual: I have a few hundres of GB of media files, most properly tagged and organized qith Picard. I'm trying to replace picard with beet, and first step is to import my full media lib without writing any tags, and without changing the layout)

[sampsyo]

Interesting issue; thanks for reporting. To be clear, this is mostly an issue for non-autotagged imports like the one you're doing.

It is possible that we should make this kind of "guessing" optional. The reason it exists in the first place is because missing comp and albumartist fields are far more common than your well-tagged situation. People tend to get (understandably) confused when their albums get misfiled because they're missing comp.

In any case: we have to guess something for the albumartist field for each album, so we'll probably need to leave that logic in place. One possible new policy could be that the comp guessing would only go missing-to-true but never true-to-false. Would that help in your case?

[guibog]

"comp guessing would only go missing-to-true" seems to make sense, and would certainly fix my issue.

Not sure why you say "we have to guess something for the albumartist". It seems MB is also feeding this data correctly. [After a random exiftool check on a couple of brained files, it seems I have AlbumArtistSortOrder and UserDefinedText = (MusicBrainz Album Artist Id), but no AlbumArtist, which is weird...] In any case, maybe it is better to only fix it when missing (or maybe when "missing or incoherent", e.g. not identical among tracks in an album)

I have very often the issue you are fixing: tracks from the same album being spread across many dirs. A reason can be a path using "$artist" but another reason in my case is that my path is "$albumartist/$year - $album/$track $title". Then if each track has a different original year or release year, as it is often the case in compilation, I have the issue. I used the album_fields config of inline plugin, and it seems much better. But maybe a warning could help: if beet detects that some files from same album are saved in different dirs, ask: "confirm this time, confirm always, skip this time, skip always".

[sampsyo]

"comp guessing would only go missing-to-true" seems to make sense, and would certainly fix my issue.

Great! I'll make this a feature request. I'd be interested to hear from anyone else about whether this policy makes sense too (it's possible I've missed something).

Not sure why you say "we have to guess something for the albumartist". It seems MB is also feeding this data correctly.

This is for the situation when auto-tagging is not running (i.e., no information from MusicBrainz). We need an albumartist because it's one of beets' album-level fields, which need to be filled in to create the database row.

I have very often the issue you are fixing: tracks from the same album being spread across many dirs.

Yeah, a more general solution would be nice. I'm not quite certain if a new prompt is the right way to go though.

I'm actually surprised you're seeing this with $year. In beets, that is an album-level field, which means that path formats should pick up a uniform value for the entire album—it should not be possible to have the different tracks sorted into different folders. There may be a bug here.

[guibog]

I'm actually surprised you're seeing this with $year

Sorry, I have seen the issue but I am not sure I was using beets, maybe I was using Picard, or $original_year, or a special item_value I wrote with inline plugin (which was not a good idea, now I know about album_value). I'll tell you if I find some concrete bug. However, it shows that when moving files beets should be careful to not spread files in a way that the user might find difficult to recover (even if the user did a mistake in config).