Why is MP3 Tag Replacing Chars

Why is MP3 Tag Replacing Chars, specifically when I import a filename with the "/" character, it is replacing it with a ":" character. How do I fix this?

Do you write a new filename or do you import data from the filename?
It is not quite clear to me what you mean by

From Hints for asking Support Requests:

I have a folder on mp4a files on my desktop open on my Mac; I open the folder; select all the m4a files within the folder; I drag them into the Mp3Tag window and all the "/" are replaced with ";" characters.

As this seems to be a Mac problem, I am out.

Still not exactly clear what you mean. Where are these characters being changed? In one of the tag fields specifically, i.e Artist, Album, Title? Or is it just in the filename display? Usually the slash characters are reserved and not used in filenames. A screen shot with an example would really help to clarify this.

It's a thing specific to macOS and Finder. The filenames actually use the colon character : (as displayed correctly in Mp3tag) but Finder does some auto-translation into the forward slash /.

You can verify that yourself by opening Terminal.app, navigate to the Disc 5 folder, and use the command ls -la to list the folder contents.

More on that here:

So, not sure this solves the problem. 1) I'm not changing anything, it is changing when it gets into Mp3Tag window; 2) It's the opposite of what you pointed out. It's not changing colons into slashed, MP#Tag is changing slashes into colons.

So bottom line here is the filenames themselves are showing the colon in mp3tag, as explained by the developer is actually the correct character from the true name. It is Finder that converts and displays the slash that doesn't truly exist.

Most importantly, are you planning on changing these filenames in mp3tag? If you are not, and only expect to make changes to the tag fields like Artist, Album, Title, etc. then there is no concern about the filename changing anyhow. However if you do update the filenames from mp3tag, it will write back the new files using the colon : and Finder will still display those as the slash / character.

1 Like

Ok, so what you are saying is there is no way to fix this? Couldn't I just do a search and replace the colon and replace it with a slash within M3PTag? Does M3PTag have a search and replace feature?

We are talking in circles. There is nothing to fix. It is simply a difference between what you see in mp3tag and Finder for the filename, but mp3tag has not "changed" anything. There is a find and replace feature, but I don't think this something I would recommend as an action.

You didn't answer the question though, are you planning on changing anything to do with the filenames in mp3tag,. or just the tag fields themselves?

I usually use the convert feature to have the filename match the title tag name, then i just modify and or add meta tags

So then try this on a small sample of files that have this colon, and that you have backed up. Make a change to the title fields, then use your typical settings to update the filename. You will still see the colon there instead of the slash. Now use Finder to seek that same new file, and note if it still shows the slash instead of the colon. If yes, you can confidently go forward knowing this difference exists.

Mp3tag replaces : and / from tag values to _ when renaming from tags, as those characters have the special semantics as described above on macOS.

Bottom line, macOS shows a : or a / for the exact same file depending on the context because both characters have been used to indicate directory separators in the two historical OSes that modern macOS is built upon (OS9 and BSD). So, it is a poor decision to use either character in your file names and Florian wisely avoids this issue by having Mp3tag replace both characters in file names as he noted. So sincerely, this is a feature, not a bug. :slight_smile:

If you need slashes or colons to accurately tag songs, use those in the actual tags, but just not in the filenames.

1 Like

TY, it's all really over my head, but at least someone is finally saying find another way.

Yet I have suggested several for you to make a couple of tests to confirm if this issue actually exists. It has been 3 days since your original posts. Have you tried this?

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