Quarter centuries index for classical music?

[Wolfgang]

I've started tagging my classical recordings also with the year of composition. For this I have included an additional decade index on my tree, built from the compositionyear.decade.index.
This works fine but is not practical in the way that it is too fine of a time step for grouping compositions on the timeline. For this purpose something like quarter centuries or - maybe even better - half centuries would be ideal.
Is there any way to arrange for a bigger time step on the index than the decade?

best regards,
Wolfgang

[stefano_mbp]

You could use the classical music eras criteria defining it into, for example, Period tag and add Period to indexTags.
This is what I get in this way:

[Wolfgang]

Very well made, Stefano. I like your tree presentation.
But to get what you have, this would require another tag to be filled for me. I'm already tagging each track with the composition date. So I would like to derive this kind of index from this date.

(18-02-2023 07:58)stefano_mbp Wrote:  You could use the classical music eras criteria defining it into, for example, Period tag and add Period to indexTags.
This is what I get in this way:

[stefano_mbp]

I do understand … anyway my suggestion can be used to classify Composers too (and I use it for that)
I’m not aware of the possibility to have a 1/4 century or 1/2 century aggregation criteria …

[stefano_mbp]

… using tagUpdate file you could reach your goal, this is an example using Period tag :

@DATE=1754
+PERIOD=Late 1700
@DATE=1810
+PERIOD=Early 1800
@DATE=1820
+PERIOD=Early 1800
@DATE=1851
+PERIOD=Late 1800

and so on … it is a little bit tedious to set it up but once done it is forever, and with a little Excel skill you can do it easily and faster

[simoncn]

Decade is treated specially by MinimServer because it is an important category for pop/rock music (1970s, 1980s, etc.)

[Wolfgang]

is it possible to name ranges of years as the match criteria?

eg

@DATE > 1750 AND @DATE < 1800 PERIOD=Late 1700

or maybe

@DATE>1750
&DATE<1800
=PERIOD=Late 1700

[simoncn]

You can only test for exact equality, as described in this section.

[Wolfgang]

As I would need to handle all years between 1600 and 2000 for a tagupdate process based on my WORKYEAR tag, it means that my tagupdate file would be 400 lines or more...
Do you think this can be handled by Minimserver reasonably? Or would the result be endless rescan times..?

[simoncn]

The current approach of equality testing only has been chosen to ensure no noticeable impact on rescan times. Going further than this would make rescans slower, even for those who are not using extended comparision logic.

A better approach would be to automate this computation using a tagging program. For example, Mp3tag provides scripting and formatting functions that can do this (see this page).