Urk. The Filter Field drop-down has gone!!

How now do I Filter on _ALL??

If you enter a simple string in the filter, it is searched in all tags and file path.

Thanks but my string a regular expression.

I think regular expressions are not supported.

YOU HAVE GOT TO BE KIDDING!!!

Florian, if you have indeed made such a massive messup as to lose regular expressions from the Filter, please fix it ASAP.

That can't possibly be correct. Or if it is, then this is a very large mistake. What use is this? If I want to find all tracks where DISCNUMBER is 1, I'm going to get every track where YEAR is 19xx and where TRACKNUMBER is 1 and a whole lot of other stuff.

As it stands now, I couldn't even figure out how to use it. When I realized that Field was missing, then I really couldn't figure it out.

Please read the help file (press F1 when in the filter)

Maybe not fitting to the topic ... but I want to mention ...

The new filter section does not work properly in all cases.

I have three tracks in the list view which have no character "7" in any tag field, but when typing in one character "7" into the filter edit line, the list view gives back the result of same three tracks.
After typing in two characters "77" the list view gives back the result of one track.
After typing in three characters "777" the list view is empty.

So why Mp3tag finds three matches for "7" resp. one match for "77"?

What additionally hidden information fields are involved when using method " Simple filtering. Returns only files that have all words from the specified string in their tags or filepath."?

There is a quirk given by a discrepancy between the help file documentation "Filtering files and tags (Searching)" and the content offered by the "RightArrowButtonMenu" of the Filter dialog.
Help files says "Filter expressions are simple expressions that consist of tag field names, filter keywords and text."
Contrary to the documentation and the presented examples the filter dialog's menu offers tag field placeholders, e. g. %year% instead of year.

The documentation annotates "If in HAS/IS/GREATER/LESS/EQUAL contains $ or % it will be treated as a format string instead of a tag field name. This will decrease search speed on large libraries since the format strings need to be evaluated before filtering."

DD.20091007.0900.CEST

If I want to find all tracks where DISCNUMBER is 1, I'm going to get every track where YEAR is
19xx and where TRACKNUMBER is 1 and a whole lot of other stuff.

"%discnumber% HAS 1" solves the problem, but though the result correctly includes "1", "1/2" etc, it messes up on e.g. "11/20", and on all discs in a 10-disc album, marked "2/10", "3/10" etc.

This was not problem on the regexp-capable Filter of the previous version.

If anyone knows a workaround, please do tell.

If anyone knows a workaround, please do tell.
"$num(%discnumber%,1)" IS 1

You can use the scripting functions if you surround them with quotation marks.

Another example: Check if artist and album are the same:
"$if($eql(%album%,%artist%),yes,no)" IS yes

You can use the scripting functions if you surround them with quotation marks.

Thanks. That's the opposite of the V2.44 Filter elsewhere in the program. Florian, wouldn't consistency be better??

Dano, how did you discover this?

And how does one disable this e.g. if one is searching for a literal string including quotes?

Another example: Check if artist and album are the same:
"$if($eql(%album%,%artist%),yes,no)" IS yes

OK thanks, but I suggest %album% IS %artist% would make much more sense.

I asked Florian why $num(%track%,1) IS 1
does not work so he told me it needs quotation marks.

The syntax is IS and in there's no support for scripting.
But " are used for terms with spaces e.g. "Hello world"
So to find a literal " we need escaping which currently seems not possible.

I got it from the help file:
If in HAS/IS/GREATER/LESS/EQUAL contains $ or % it should be enclosed in double
quotation marks and will be treated as a format string instead of a tag field name.

May I asked which version? Because that's not anywhwere I can see in V2.44d.

to find a literal " we need escaping which currently seems not possible.

OK, thanks.

This new interface for filtering is just plain silly. You can't expect users to be programmers and worry about the syntax of what is essentially a programming language. IMO, it's become unusable for the majority of Mp3tag users.

Put in an option to get the old behavior back (and make the old behavior the default):

Filtering Interface:
(*) Basic
( ) Advanced

I don't see why this is "plain silly". I think entering a search string is quite straight-forward to novice users and using the filter expressions should not be too hard to learn (since the language is also oriented on simple English wording).

Kind regards,
Florian

I think entering a search string is quite straight-forward to novice users

But entering a straight-forward search string doesn't necessarily work. If it contains a word like IS which the non-programmer user has no idea has special meaning, the result is wrong.

and using the filter expressions should not be too hard to learn

Most users will want to not use it, and that is harder to learn, because one has to remember all the reserved words.

We'll see how it gets accepted. I like it a lot (although my opinion might be biased due to the effort I've put into that feature).

I like it too, but I just don't think it's intuitive, particularly for beginners and for users who have used filtering with the old interface. That's why I suggested a 'basic' and an 'advanced' option.