Filter files where <field> HAS <anotherfield>

I want to filter songs that are from albums containing the publisher name, is that possible? Couldn't figure it out using filter expressions alone.

e.g. ALBUM = Noisekick Records 007
PUBLISHER = Noisekick Records

e.g. ALBUM = Noisekick Terrordrang
PUBLISHER = Noisekick Records

Preferably both examples should be matched with the filter. The latter seems like it would be too complicated to create, so if just the first example gets matched that's alright too...

You could try it with this filter:
ALBUM HAS Noisekick Terrordrang AND PUBLISHER HAS Noisekick Records

Try
"$ifgreater($strstr(%album%,%publisher%),0,yes,no)" IS yes

Since the complete field for PUBLISHER in your second example isn't part of the ALBUM, you would have to resort to limiting the search in that case to just the first word. Or remove some text like the word "Records" since it is common in many Publishers. This is more complicated as you suggest, but can be done. However since this seems to be a pretty rare and unique search, it may be more manageable from the existing filter option such as suggested by @LyricsLover.

Oh yeah I actually tried that one already, but it filters nothing for some reason :confused:

You could try it with this filter:
ALBUM HAS Noisekick Terrordrang AND PUBLISHER HAS Noisekick Records

That misses the point. I need the filter to reveal all occurrences based on the pattern illustrated in the examples (i.e. where publisher is contained in album).

Could you show a screenshot of the filter?
"$ifgreater($strstr(%album%,%publisher%),0,yes,no)" IS yes
checks if the shorter string %publisher% can be found in the longer string %album%.
Spelling and case has to be the same in both fields.

Nevermind I'm just a silly goose, turns out I didn't copy the first quotation mark. :man_facepalming:

Omitted them fully on my separate attempt before making this post, so that's why it wasn't previously working either.

Thanks

Right but this won't work for example #2.

Since the string "Noisekick Records" does not appear in the Album "Noisekick Terrordrang" it will fail to come back as true.

Yeah obviously. Just in this example alone the publisher string would have to get split by the first occurence of space and then get matched with the album field, which I think is getting too complex for Mp3tag filter. Not even mentioning most publishers' names are not in this format (e.g. Who Done It? Recordings; Raver Baby), so that would require further exceptions.

As I said though, having resolved at least the first one works too...

I may not be understanding the question correctly, but if you want to filter both scenarios

Would then

ALBUM HAS Noisekick AND PUBLISHER HAS Noisekick

not match both?

Yes. This would match if the string is fixed.
But then you would have to type in each name that you find in PUBLISHER.
The original problem was:

which means that the publsher name could be anything but should be part of the string in ALBUM.

I suspected it wasn't that simple, it needed to match regardless of what is in both fields, so any word present in PUBLISHER that also matches a word in ALBUM... yeah, that's not gonna be a straight-forward filter given the second example doesn't match a part in the ALBUM name other than a single word

This is a complex filter but not impossible. It will require some thought on just how much of the Publisher name is required to be found within the Album title to be considered a match. The first word or complete string may work in some cases. But there will still be exceptions for Publishers with an Article (A, An, The, Le, La, etc) as the first word.

Sometimes the concept though functional requires more time and effort than the time to manually process these types of searches. Even in a very large library these types of rare use cases are a good example of this.

Sometimes the concept though functional requires more time and effort than the time to manually process these types of searches.

Precisely. I ended up making an assumption that these albums are Various Artists (my guess is that 95 % of them are), which narrowed it down enough and I just went through the results manually.