[X] File Name Case Conversion

I have noticed that lately, the command I created to change the filename to all Uppercase text and Lowercase extension is not working for all the files. It used to work perfectly a couple updates back (not sure what update number).

Has anyone else encountered this issue?

Could you show us the function (command) with which you rename the files?
Also, could you show us the original filename and the result that you expected and that you got?
Also, please tell us which filesystem you use.
Otherwise it is a little hard to see if there is an issue.

1 Like

The Action I have used is: Case conversion "FILENAME": UPPER case

When I select all entries and run the action most of the files will have been edited, but not all when I look in the file folder.

Eg: Bruno Mars - 24Karrat.mp3 would change to BRUNO MARS - 24KARRAT.mp3 but this is not happening to all the files.

running Windows 10.

To me it looks ok.
The exceptions would be interesting.
It could also be that some of the files are write protected or that you are not the owner.
Or that you have entered a couple of characters to define the word borders.

Just guessing, as I do not use it: maybe it is the case of the Library feature not upgrading the case of letters?

Can you please provide a little more information on which files are not renamed properly?

Contrary to what is written above, I'm assuming that you've used _FILENAME (instead of FILENAME) for the case conversion action.

yes. that was a typo. _FILENAME is the field used in the action.

And now for the missing information:

Not sure what missing information you are looking for?

I use the action command to make the Filename all capitals. It shows that it did it in the Mp3Tag program, but when I go to the file folder where the files are, the file name did not change to all capital letters?

Here is a video of what I am talking about.


Thank you for the effort to create a video - but sorry, I cannot decipher anything that happens.
I can see that folders are opened and a file gets treated with an action, probably "Case conversion", then a message box appears telling that something has happened - just don't ask me what.
I just tried to rename a file
Action of the type "Case conversion"
Conversion: CAPITALS
Word starting after:
(left empty)

Filename before the conversion:
Ambient Diary.one _ 101 _ Babel _ The Return Of Babel.mp3
Filename after the conversion:
I would say that this worked as expected.
I copied the filenames from the explorer, so even that shows the files as intended.

What is different to your approach?

Thanks for the video. I can see that the case conversion fails at
Big Sean & Metro Boomin ft. Kash Doll - So Good.mp3

Can you go to Windows Explorer and copy the file name here (via F2 and Ctrl+C) just for me to see if there are some special characters involved.

Can you also give some details about the filesystem that is used on you E: (SHARED) drive? Is it normal NTFS or something else?

This is the file name copied.

Big Sean & Metro Boomin ft. Kash Doll - So Good

The Drive is formatted as FAT32. Its been the same drive used for a few years and with MP3Tag for many years which used to preform the action using _FILENAME command with no issues.

As you saw in the video, some of the files in the folder did change when using the action with the _FILENAME command. I usually highlight all the tracks in the MP3Tag list and apply the action for the conversion. Just some change, and some do not change. Very weird.

Applying an action of the type "Case conversion" leads to:
What about access rights? Read-only? Such things?
Does renaming on a different storage medium work?

I think the magic word here is "FAT32". Fat32 knows no access rights.

And FAT32 is case-insensitive, other than NTFS, wich is case-sensitive.
To my knowledge it is not possible to change the writing of a file on FAT32 from lower-case to upper-case or the other way round. To do so you have to change at least something else of the filename to make a change of the case happen.

When you execute an case-conversion action of FAT32-file with MP3Tag, MP3Tag shows the expected result and the conversion, because it obviously does not pay attention to the case-sensivity of the file-system.
If you then reread the files with MP3Tag it shows again in the former case.

If this is a bug of MP3Tag?
I don't know. Perhaps it should not show a wrong result of the action if in fact there were no changes possible because of a FAT32-Drive. To change this behaviour could be a bit tricky because is is only relevant for case-changes without renaming.

1 Like

FAT32 is case-insensitive but case-preserving, which basically means that you can change casing of filenames.

I've just tried renaming of files with a USB drive formatted with FAT32 and it worked without problems.


  • After the failed renaming and closing of Mp3tag, what are the contents of %APPDATA\Mp3tag\Mp3tagError.log

  • Are there any other programs accessing the file at the time of renaming?
    You can check with Microsoft/SysInternals Process Explorer
    Go to Find > Find Handle or DLL. In the Handle or DLL substring text box, type the path to the file (e.g. E:\path\to\file.mp3) and click Search. All processes which have an open handle to that file should be listed.

Before I wrote in this thread I tried it too and it did not work with MP3Tag.
Using an action format value or the converter Tag -> Filename or simply the case-conversion for the filename does not change anything if the filename stays the same inspite of case-conversion.

That is why I started this topic because it used to work all the time.

  • The contents of the error log were;

Mp3tag v2.86 - 07.03.2018 - 20:09:08
OS-Version: Windows 10, 64-bit
Build: Jan 24 2018 09:10:25
AppPath: 363.950.649.344 Bytes frei (C:\Program Files (x86)\Mp3tag)
DataPath: 363.950.649.344 Bytes frei (C:\Users\VazMain\AppData\Roaming\Mp3tag\data)
TempPath: 363.950.649.344 Bytes frei (C:\Users\VazMain\AppData\Local\Temp\Mp3tag v2.86)

  • There were no other programs accessing the file at the time.

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