This may not be a bug, but I thought I would get input from you guys:
So, if there is a folder C:\Metallica
even if you type C:\meallica or C:\meTallica
the directory will still display because being case specific is not required when you manually type the directory address inside Mp3tag.
In other words, you do not have to type case-specific C:\Metallica to get the contents to display.
However, your Action commands will go off of what you TYPED.
So if you have an Action command to assign Artist from FOLDER NAME... it will be assigned as what you typed, so if you typed meTalLica, that's what would be assigned, not the actual name of the folder Metallica.
As I said, not a bug probably but I just thought I would get your input about the way Action commands work.
It basically assigns the Artist entry by reading the FOLDER NAME. But it could assign anything, it could assign the Album entry from FOLDER NAME too. The point is:
So the action command is supposed to read the folder name, the actual directory name and assign that name to whatever.
It doesn't assign the actual folder name however, it assigns what is typed inside the left center box under Directory.
So if the folder name is C:\Test it will not assign Test, but instead it will assign what you typed under Directory, for example TESt or tEst, the letter case is taken from what you typed instead of what the actual directory name is.
Yes this is complicated, but if you don't understand, look at this screen shot:
See how it says meTallica. The actual folder name is Metallica not meTallica.
So it's fine not to be case strict to get the folder to display.
But any Action commands involving folder name, will also use meTallica not the actual real folder name Metallica.
I took an arbitrary directory and changed the case of one word in the input box for directory in the tag panel.
Changing the case in the tag panel directory input box leads to MP3tag taking that string instead of the actual string/case from the file system.
MP3tag now displays the path with the wrong case in the tag panel and in any column that shows this part of the path.
I would consider that a bug as MP3tag does not take the original information but the internally modified although this information has not been saved yet.
The actualy information could not be revived with F5 (for re-read). Only changing to another directory and back again shows the the case as it is in the filesystem.
Thank you for confirming this.
Yes, if there was a way to make Mp3tag read the actual name instead of the typed string, that would resolve this bug, I just didn't know if that is technically possible or if Mp3tag must read the typed string only...