Configurable Filter

Hello

I would like to make a motion for enabling a configurable list of expressions for the filter

Right now, under the icon next to the filter field there, is a predefined list of basic tags. Some of that tags I don't use at all, so there are just wasting space. And that space could be filled with whatever the user would want to. For example some new user-made tags or some complicated code like
"$ifgreater($strstr($lower($left(%TITLE%,6)),$lower($left(%ALBUM%,6))),0,1,0)" IS 1

The usage of filter's history for this purpose is limited, because the list in history can be easily overcrowded when the user often filters and doesn't clean the list. And if a user makes a misake and clicks "Remove all from history..." then there is no way of recovering a list like that

This idea came up at the end of discussion in this topic: /t/16590/1

I find the help quite useful to get the field names of fields that I do not use so frequently or those names of information fields. So the interpretation of wasted space looks to me like a very individual point of view.
As the current behaviour of the filter history is too error prone for the OP I wonder which user interface concept would make it more foolproof.
The idea to use an external textfile that allows you to add descriptions looks like a good idea to me. And that feature is available right now.

Of course the waste o space is debatable

Just like the question, why is there in the first list a ready to use code for "year", but not that for a "date"? Some people will use the first, but some the oter. [I know the difference; but shouldn't the <b>MP3</b>tag support <b>FLAC</b>s at the same level of attention?]

There is aub-menu of "Extended fields", "Information fields" and "Functions", so why can't there be a sub-menu constructed by the user? Or why shouldn't the user be able to change the "main" menu [the default list]?

We can add and save user defined export codes and actions groups, but not ready to use filters. And that is simply inconsistent

It has been almost 5 years since

So I would kindly would bring the attention of the community to this idea

Date is no standard id3 field but a user-defined one.
If you have Date as a field in flacs, you should map it to YEAR - as it already is, I think, check Tools>Options>Tags>Mapping. You should then see the contents of Date in any MP3tag field called YEAR.

As usual- you are helpful

But as often- you are missing the point


Me resurrecting of this was not because of issues of the supposedly unbeknownst to me problems with mapping

The core issue here is the proposition of configuration of yet another portion of Mp3tag; as over the years more and more thing have been upgraded and more control was given to the user