# "Tag - Filename" fails with M4A files
**URL:** https://community.mp3tag.de/t/tag-filename-fails-with-m4a-files/46035
**Category:** Support
**Created:** [July 29, 2019, 5:08am UTC](https://community.mp3tag.de/t/tag-filename-fails-with-m4a-files/46035 "2019-07-29T05:08:20Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@TheFeelSage](https://community.mp3tag.de/u/TheFeelSage)
#### Post date: [July 29, 2019, 5:08am UTC](https://community.mp3tag.de/t/tag-filename-fails-with-m4a-files/46035/1 "2019-07-29T05:08:20Z")
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:
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [July 29, 2019, 5:20am UTC](https://community.mp3tag.de/t/tag-filename-fails-with-m4a-files/46035/2 "2019-07-29T05:20:27Z")
> [@TheFeelSage](#):
>
> To reproduce, just use the "Tag - Filename" feature with any M4A file with any name expression
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?
---
### Author:  [@TheFeelSage](https://community.mp3tag.de/u/TheFeelSage)
#### Post date: [July 29, 2019, 6:11am UTC](https://community.mp3tag.de/t/tag-filename-fails-with-m4a-files/46035/3 "2019-07-29T06:11:31Z")
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?
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [July 29, 2019, 6:23am UTC](https://community.mp3tag.de/t/tag-filename-fails-with-m4a-files/46035/4 "2019-07-29T06:23:37Z")
> [@TheFeelSage](#):
>
> Would it help if I provided a sample file?
Yes.
And just to show that I don't get this behaviour:
What you could do:
Close Mp3tag,
rename the mp3tag.cfg file to e.g. mp3tag.cfg\_
Restart MP3tag
try again to rename a test file
---
### Author:  [@TheFeelSage](https://community.mp3tag.de/u/TheFeelSage)
#### Post date: [July 29, 2019, 6:35am UTC](https://community.mp3tag.de/t/tag-filename-fails-with-m4a-files/46035/5 "2019-07-29T06:35:31Z")
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.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [July 29, 2019, 6:36am UTC](https://community.mp3tag.de/t/tag-filename-fails-with-m4a-files/46035/6 "2019-07-29T06:36:52Z")
you can filter for such files:
`%title% MATCHES \r\n`
---
### Author:  [@TheFeelSage](https://community.mp3tag.de/u/TheFeelSage)
#### Post date: [July 29, 2019, 6:43am UTC](https://community.mp3tag.de/t/tag-filename-fails-with-m4a-files/46035/7 "2019-07-29T06:43:26Z")
Thanks. Just made a regex replace quick action to fix all these files for me.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [August 28, 2019, 6:43am UTC](https://community.mp3tag.de/t/tag-filename-fails-with-m4a-files/46035/8 "2019-08-28T06:43:28Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.