[SOLVED] Filter for Filenames that are different from Title

I am trying to filter music to find songs where the TITLE is different from the FILENAME.

The FILENAME is in the format: 01 This Is The Title (variable capitalized)
The TITLE is in the format: This is the Title (Mixed Case)

Can anyone show me a (case insensitive) filter that will compare the FILENAME (with the track numbers removed) to the existing TITLE so that I can correct naming errors?

Thanks in advance for responding to my first post.

It would probably be easier to compare with the track number:
"$if($eql(%_filename%,$num(%track%,2) %title%),1,0)" IS 0
and if that does not work
"$if($eql($lower(%_filename%),$lower($num(%track%,2) %title%)),1,0)" IS 0

Thanks, but that returns the files where the truncated FILENAMES are the SAME as the TITLE. How do I filter to show where the truncated FILENAMES are the DIFFERENT from the TITLE?

Thanks again

These (Highlighted with RED arrow) are the files that I would like the filter to show.

Try this:
"$if($eql(%title%,$cutLeft(%_filename%,3)),yes,no)" IS no

That's it - Thanks for all your help.

1 Like

What have you got in the field TRACK? If that is empty then naturally, the title will never be like the filename.
So why don't you fill the field TRACK first before you throw away the existing information?

One thing that may occur with a simple filename to title comparison is when illegal filename characters are stripped, making otherwise identical comparisons different.

Such as in the screenshot above Can I Put You On? has a filename of Can I Put You On.mp3, minus the question mark character, since Windows doesn't support that character in filenames.

Perhaps Mp3Tag auto accounts for that, not sure. If you knew that all such characters were replaced with nothing you could probably add the validate function into the mix to strip the illegal characters from the comparison - $validate(%title%,), IIRC.

The illegal characters are:

< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)

+ all characters whose integer representations are in the range from 1 through 31.

But there are much more reserved names for file names like:

And don't forget:
Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not.

Source and complete list: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

Seem to remember this advice for directories before although for filenames I have plenty of files ending in periods that show normally in File Explorer and are openable in programs (including the command prompt). Perhaps the advice was to ensure cross-compatibility with FAT filesystems?

Edit: probably means following the extension rather than before it, which would make sense.

Why does an empty TRACK field affect the comparison of FILENAME to TITLE? Neither is dependent on the TRACK field since the filename is created external to MP3Tag.

Understand that. Notice that the filenames DO NOT have invalid characters that appear in the TITLE. I just wanted to make sure that the TITLE was correct for the FILENAME. Thanks.

The leading number looked suspiciously like a track number.
So I suggested to use TRACK and TITLE to generate a string that might have looked like the filename.

The thing is, if the goal from the OP is to find songs where the Title is different from the Filename, and the Title happens to have a character such as ? that isn't present in the Filename (due to it being an illegal character not possible to have in the filename and being stripped) then such ordinarily matching results in one's mind would nevertheless be lumped into the non-matching results since they don't literally match.

Example to demonstrate (click to zoom), comparing the exact same Title and Filename in the first two screenshots but first one including the $validate() function to strip illegal characters from the comparison filter, while the latter two don't. We can see that both the second and third results would be both considered 'non-matching' despite the second screenshot being a result you wouldn't want being marked as 'non-matching' (at least based on the red arrows in the screenshot you posted above).

1 Like

Again thank you for the expansive (and very correct) explanation. I did not want to overburden the community with an overly intricate request that wouldn't get answered so I posted for a filter that would show MOST of the dissimilar files. The postings filtered the files down to about 50 (from over 38,000) and I examined them manually.

Again thanks, you really know your stuff.