Poll: What's your expected behavior of set_fields and --set?

Hi everybody,

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?

Please share your thoughts.
Thank you!

PS: Also posted on github.

1 Like

I assumed it tried to set the values on each individual track and when it didn’t seem to work I always just thought this was a bug.

1 Like

With the merge of https://github.com/beetbox/beets/pull/2988, that’s no longer true.

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. :smile: 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.


How would a user then set fields on the album only during import?

I think it would be a mistake to break backwards compatibility with current behavior, while also making that behavior more difficult to achieve.

What would happen to singletons imports ?

How about keeping set_fields and --set as they are, and add set_fields_track and --set-track ?

The Singleton import is unchanged. It still writes fields to the track, as it did before the change.

--set-track was one of the options discussed that was not implements in the end.