When using "Tag - Filename" to bulk rename M4A files, it looks like MP3Tag puts a line separator before the extensions and the rename fails because Windows rejects the illegal characters. This issue is not present with other types such as MP3 or MP4. To reproduce, just use the "Tag - Filename" feature with any M4A file with any name expression. Screenshot of the issue, note the preview output:
Did it, cannot reproduce it.
I used 2.97a, so perhaps it is gone with that version.
Or you have to show us which format string you used for the converter and the contents of each tag field that is referenced in the format string.
Does it help to enclose the whole format string in a $validate() function?
Tested with version 2.97a with just "%title%". The title field is visible in the screenshot I posted. Enclosing the expression with the validate function gives me an filename of just ".mp4", completely stripping whatever data I give it. Even just using "%track%" gives me the same behavior.
I don't think this is just an issue of my files having some messed up metadata from one source, I've seen the issue on purchased music and things I've ripped myself. Would it help if I provided a sample file?
And just to show that I don't get this behaviour:
What you could do:
rename the mp3tag.cfg file to e.g. mp3tag.cfg_
try again to rename a test file
Resetting the config didn't help, but I found the problem. Opened the files in a hex editor and discovered a rogue carriage return in the title field that didn't show up when viewing the metadata in any media tools. Thanks for the help. It's probably still a good idea to check for and remove these characters before trying to rename the files. Now, time for me to go figure out why so many of my files have this at the end of the title.
you can filter for such files:
%title% MATCHES \r\n
Thanks. Just made a regex replace quick action to fix all these files for me.