# Finding files with missing values if other are present

**URL:** <https://community.mp3tag.de/t/finding-files-with-missing-values-if-other-are-present/17048>\
**Category:** Support\
**Created:** [July 12, 2015, 2:23pm UTC](https://community.mp3tag.de/t/finding-files-with-missing-values-if-other-are-present/17048 "2015-07-12T14:23:35Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![Zerow](https://community.mp3tag.de/user_avatar/community.mp3tag.de/zerow/32/11379_2.png) [@Zerow](https://community.mp3tag.de/u/Zerow)\
**Post date:** [July 16, 2015, 9:31am UTC](https://community.mp3tag.de/t/finding-files-with-missing-values-if-other-are-present/17048/11 "2015-07-16T09:31:30Z")

</div>

> [@DetlevD](#):
>
> [...]
> 
>  
> 
> **[color="#000000"]This is an AND case ...**
> 
> **"$if($eql($sub($len($trim(%GENRE%)' '),$len($replace($trim(%GENRE%)' ','##0 ',,'##5 ',))),$len('##0 ##5 ')),1,0)" IS 1**
> 
> DD.20150715.1744.CEST, DD.20150716.1316.CEST

Strangely, this shows me around 10% of what is should. And I don't know what the pattern is, because there are so many ##numbers and ##words arranged differently, that I won't be able to figure it out

> [@ohrenkino](#):
>
> The keyword PRESENT checks if a field is there at all.  
> You use a filter like  
> **correct:** ##0 is not present and ##5 is not present  
> NOT GENRE HAS ##0 AND NOT GENRE HAS ##5  
> **correct:** ##0 is present and ##5 is present  
> GENRE HAS ##0 AND GENRE HAS ##5  
> **incorrect:** ##0 is present and ##5 is not present  
> GENRE HAS ##0 AND NOT GENRE HAS ##5  
> **incorrect:** ##0 is not present and ##5 is present  
> NOT GENRE HAS ##0 AND GENRE HAS ##5

> [@zerow](#):
>
> OK
> 
> But that would leave me with 4 different filters, one for each of the variations  
> [...]

> [@ohrenkino](#):
>
> Exacxtly - on the other hand: why filter for tracks that are already correct?

Well, I was just thinking in a way similar to the [solution of my last problem](https://community.mp3tag.de/t/17047/9)

But now I came to the conclusion that that had to show me specifics and will be used often, and this latter will be used rarely [and can be cut in half, leaving me with just 2]

> [@ohrenkino](#):
>
> I am still not sure whether you fully grasp that concept of the filter.

I do

It just that some stuff I do with codes for filters and some with code applied to columns

Additional columns are always there [available when I turn them on] and [long / comlex] codes for filters I have to copy from a TXT file [which I do with CTRL+1 shortcut via Tools]

> [@ohrenkino](#):
>
> If you filter for files then you see only the files that match the criteria - and therefore still need treatment.  
> No scrolling and visually checking for "error".

Yes

But clicking a column [to sort the full list out] is just quicker than writing down a filter or pasting it from an outside source

And if I see an error I can select it and then rearrange the list of files by other means [for example by FILENAME / TITLE and thus quickly checking if a similar / same song was GENRE-ised by me and how]

> [@ohrenkino](#):
>
> And as the "HAS" has to be emulated with $strstr() and probably with nested $IF(), $AND(), $EQUL() statements I still do not see the reason for the reluctance to use filters.

I tried and failed. This code that I wanted to have is just from the stuff way over my head

So in this case I'll have to stick to the filter [in this case quite easy] filter code, it just takes too much of my time

I've just ran it and is shows that I've made errors of such kind in 0.35% of the already GENREised files. So I think we can stop now

And once more: thank you both

---

_[View the full topic](https://community.mp3tag.de/t/finding-files-with-missing-values-if-other-are-present/17048)._