we are discussing the expected behavior of the set_fields configuration, which uses the set_fields configuration file block and the --set command line option.
Question: Should fields be set on the imported album only, or also on each individual track?
In the current implementation, fields are set on the imported album only. Hence beet list won’t let you filter for those fields unless you provide the -a flag. With -a, however, you will see a list of albums instead of individual tracks.
There are some discussions on the board (e.g. here or here or here) and on the internet (e.g. here) where people expect that fields are also set on each individual track. In particular, this would imply that the fields are also written to the metadata of the track files instead of only beets’ database.
Main question: Would changing the implementation from album in database only to write each individual track file break your setup?
However, it is still true that e.g. beet info on a track won’t list the track’s album attributes.
Still, my vote is to keep the current behavior. As a programmer, I am highly resistant to duplicate data structures, since they introduce a chance for “data skew” and make maintainability (of both code and music libraries) more complex. Keeping fields on the album only reduces duplication. You can always add them to all the tracks after import, if that’s what you want.
That said, I doubt you will get any consensus from the community. Even if more people reply here, opinion will probably be split. So maybe a new command line flag to introduce the new behavior would be best? That would keep backwards compatibility, while making it easy for people to tell beets otherwise if desired. And then maybe make the documentation print some message about it during import, so that people are aware of which choice they made?
thanks. Yes, we have discussed different options to solve the issue. From discussions throughout recent years and from the issue, we have concluded that setting fields on tracks is the expected behavior for most people and hence the change is acceptable.
Let’s see if there will be more opinions and what they are.
So maybe a new command line flag to introduce the new behavior would be best? That would keep backwards compatibility, while making it easy for people to tell beets otherwise if desired. And then maybe make the documentation print some message about it during import, so that people are aware of which choice they made?