I would like to know, how to make a way to distinct certain files:
those that have one of the values from first group while not having values from other, in the GENRE tag field
Let's say the first group consists of:
##01
##02
##03
And the second group consists of:
##51
##52
##53
##54
For example; if there is ##02 in GENRE, and at the same time there isn't a ##51, ##52, ##53 or ##54, then I need to know of this; because it is an error
But if there is no ##01, ##02 or ##03, then the lack of ##51, ##52, ##53 or ##54 does not concern me at all; because it is a correct situation
[And the other way: if the file has for example a ##54, then it needs to have ##01, ##02 or ##03]
How to find such files, most preferably in form of a sign showing up in a column in the main window? And could it be done without listing 51 / 52 / 53 / 54 and just by writing down range of 51-54?
I gave you already "list oriented" respectively "set oriented" algorithms, which should be applicable for this new question too.
See there ... Moving part of TITLE to GENRE
But you can also apply standard functions, for example $strstr(x,y).
I've looked at all those codes that I use and I just don't see a possibility to rework the for this purpose
Unfortunatelly, this is not an automatic situation like
IF there is ##02 THEN put ##53 in the GENRE tag
or IF there is ##53 THEN put ##02 in the GENRE tag
I have to [automatically] single out those of files, which are having only something from ##5X group or only from ##0X group; and then listen to those files in order to [manually] put a value from the missing group. [I have also other possible errors like that, but that is the most common and the most significant; and if successfully dealt with it, I could work on others, taking those basic steps further / elsewhere]
Or did I simply misunderstood you're remark on previous codes?
This implicates making a separate version for every ##0X?
And thus when adding in the future a ##04 or ##55, would require even more versions?
If you treat these strange strings as some kind of word that acts as a substitute for contents, then every variation has to be treated like a word and therefore, probably needs its own treatment.
Or you have some kind of generation algorithm that lets you calculate the next value (which then would make it superfluous to be added hardcoded).
I think this task, given that the all of my data of such kind will be in proper format, can be easily narrowed down
The hypothetical code would only have to look in GENRE tag for >>##0<< and >>##5<< [while not treating it as a whole word] and sound the alarm if one is present and the other is not
correct: ##0 is not present and ##5 is not present correct: ##0 is present and ##5 is present incorrect: ##0 is present and ##5 is not present incorrect: ##0 is not present and ##5 is present
And as so this whole group issue would not be important anymore
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
Exacxtly - on the other hand: why filter for tracks that are already correct?
I am still not sure whether you fully grasp that concept of the filter.
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".
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.
.. because this expression does not follow the syntax for filter expressions.
For example ...
Mp3tag Filter
This is an OR case ..."$ifgreater($len($trim(%GENRE%)''),$len($replace($trim(%GENRE%)'','##0 ',,'##5 ',)),1,0)" IS 1This is an AND case ..."$if($eql($sub($len($trim(%GENRE%)''),$len($replace($trim(%GENRE%)'','##0 ',,'##5 ',))),$len('##0 ##5 ')),1,0)" IS 1This proposal works with a tagfield GENRE, which has a string value like ...'##0 ##1 ##11 ##23 ##4 ##5 ##53 ##61 ##54 ##2 ##007 ##221 ##7'
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
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]
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]
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]
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
Hmm, there is no variance in the result of the filter expression, it does show 100% hits or 100% nothing, the result is 1 or 0.
How to understand the system of ... "patterns, where so many ##numbers and ##words arranged differently" ... is up to you.