# Add \* to filter field list to make it more public

**URL:** https://community.mp3tag.de/t/add-to-filter-field-list-to-make-it-more-public/69417
**Category:** General Discussion
**Created:** [August 15, 2025, 7:06am UTC](https://community.mp3tag.de/t/add-to-filter-field-list-to-make-it-more-public/69417 "2025-08-15T07:06:18Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [August 15, 2025, 7:06am UTC](https://community.mp3tag.de/t/add-to-filter-field-list-to-make-it-more-public/69417/1 "2025-08-15T07:06:18Z")

</div>

While trying to deal with the problem in this thread:

> [@Strange result after using the filter](https://community.mp3tag.de/t/strange-result-after-using-the-filter/69410):
>
> Hi everybody I’m new with mp3tag, so I need help for a little problem. I used the Filter function to display informations about a precise singer. This musician has two mp3 files on Windows explorer, each of them on two separate directories, with one named from the complete name of the singer. But the name of this musician also appears in the comment section of another mp3 file, which is a song from another singer. The problem is that when I type the name of the artist (the first cited), mp3tag…

which in the end used the `*` in the filter to address any field.  
It took me a while and several failed attempts (with \_ALL or \_TAG) until I finally consulted the documentation.  
Apparently, the filter behaves differently from other functions like "Case conversion" or "Remove field".  
So my suggestion would be make the `*` as universal field place holder more public and add it to the field list that opens if you click on the right-arrow-button.  
I would prefer it in the list of "extended tag fields" as it refers only to them, and perhaps a dividing line to the rest of the fields would make it stand out from the specifically named fields.

---

<div class="post-metadata">

### Author: ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [August 15, 2025, 7:26am UTC](https://community.mp3tag.de/t/add-to-filter-field-list-to-make-it-more-public/69417/2 "2025-08-15T07:26:55Z")

</div>

> [@ohrenkino](#):
>
> So my suggestion would be make the `*` as universal field place holder more public and add it to the field list that opens if you click on the right-arrow-button.

+1 👍

Perhaps an additional hint in the documentation that some **Special Fields** \*\*, such as \_ALL or \_TAG do not work, but that `%_FILENAME%` and `%_PATH%` do?

 ![image](https://community.mp3tag.de/uploads/default/original/3X/6/3/637470f566fc78ac6c44f3edfca1e098432011a1.png)

\*\*

 ![image](https://community.mp3tag.de/uploads/default/original/3X/1/b/1bc0ad3ffb6a7ccf9a6f6b9710094b83f2a8fdc7.png)

> [@ohrenkino](#):
>
> I would prefer it in the list of "extended tag fields"

You mean **"Extended fields"?**  
 ![image](https://community.mp3tag.de/uploads/default/original/3X/c/9/c9a56a2e339ee402e5724fb2bd8fd0679f960d0b.png)

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [August 15, 2025, 7:39am UTC](https://community.mp3tag.de/t/add-to-filter-field-list-to-make-it-more-public/69417/3 "2025-08-15T07:39:01Z")

</div>

I prefer it as is, because the wildcard is supported for `HAS` and `MATCHES` only (and is documented for those) and, thus, adding it to the list of extended fields would suggest that it's generally available for all filter operators.

Support for format strings like `%_path%` and `%_filename%` is mentioned in the [Notes](https://docs.mp3tag.de/filter/#notes) section:

> If `<field>` in HAS/IS/GREATER/LESS/EQUAL/MATCHES contains `$` or `%` it should be enclosed in double quotation marks and will be treated as a [format string](https://docs.mp3tag.de/format) instead of a tag field name.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [August 15, 2025, 7:53am UTC](https://community.mp3tag.de/t/add-to-filter-field-list-to-make-it-more-public/69417/4 "2025-08-15T07:53:28Z")

</div>

Then 2 entries might save the idea:  
instead of a single `*`  
`* HAS`  
`* MATCHES`  
(... and these separated with a line in the list).  
These 2 entries would insert exactly the expanded string with the `*` plus the filter keyword to start a correct expression.

I admit, I do see this as a clutch to save my initial idea. It is a break in concept to offer more than just a variable name.

The dilemma right now: have a more or less hidden but good function or risk a misuse a few times (which even now cannot be ruled out).

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [October 29, 2025, 10:29am UTC](https://community.mp3tag.de/t/add-to-filter-field-list-to-make-it-more-public/69417/5 "2025-10-29T10:29:15Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
