I've noticed on Windows, when using the Tag -> Filename feature, if the song title has a Backslash ( \ ) in it, it will incorrectly move that song to a sub folder instead of replacing the Backslash character similarly to how it treats other invalid or undesired characters.
Action:
When using Tag -> Filename on an album where one of the songs has a track name with a Backslash in it (40 Years Back\Come) using the string %artist%\%album%\$num(%track%,3) - %title%
Current Outcome:
Only the song with the \ in the name gets moved to a subfolder, while other songs get correctly processed.
Expected Outcome:
All the songs would be in the same folder, and the \ is either deleted from the file name, or replaced with some other placeholder character.
The converter replaces invalid characters with some other character.
But the \ is a valid character for the Windows file system.
The use of the \ to create new folders is actually a feature, see here:
So if you have files with the \ in the tags then either replace it with a similar looking character that does not have the same function for the OS or add $replace() to your format string.
See e.g. here:
See also here (and you are free to search for more threads about the \ in format strings:
Windows states that \ is not a valid character for a file name. So why should we expect that it's treated differently from any other invalid file name character?
I'm willing to bet that 99.9% of the time where there is a \ in a Track Title, the user is not expecting to have it be put in it's own special subfolder, that just doesn't make sense. Because it's part of the file name, it should be treated the same as any other invalid file name character.
Unfortunately, you do not pick up the discussion that has already taken place.
The converter interprets a format string which gets checked for invalid characters after all components have been stitched together. In that state, it cannot be determined where the backslash originated: user-input to define a path or from data in a field.
If the backslash should be excluded, then it is the task of the user to treat the fields in which it may be an unwanted character.
This format string may also contain path components (which is a described feature) and in a path the backslash (and the the colon) is a valid character it therefore it does not and will not get removed.
That sounds to me like there needs to be a seperate check for the tags to determine if it's an invalid file name character that is independent from the main check at the end.
So your solution is to rely on each end user to one-by-one, sanitize each tag so they behave how a normal user would expect them to behave by default? $replace(%artist%,\,)\$replace(%album%,\,)\$replace($num(%track%,3),\,) - $replace(%title%,\,)
While technically correct, that sure seems like a lot of faffing about for something that a normal user wouldn't think they would need to do in the first place.
While I'm sure that probably works (assuming I got the syntax correct), that is pretty intimidating to normal users than them just being able to click some tag values, put in \ to make their own folders, and have it just work as expected out of the box.
The OS doesn't ask how one expects them to behave. If the back slash exists in any string used in a directory it separates it into folders. My suggestion is to consider using alternative Unicode characters that look similar but are not reserved by the OS.
I've addressed this with Mp3tag v3.35-beta.1, which now prevents the creation of subfolders at Convert → Tag - Filename if a referenced field value contains the backslash character \.
