[F] Invalid character shown at end of LAME encoder version


Mp3tag 2.87 on Windows 10


  1. Add a new column using the new %_tool% information field.
  2. Scan some MP3 files (in my case, the files were created using LAME 3.100)


As shown in the screenshot, the %_tool% column shows "LAME3.100" with a strange square character at the end (some kind of invalid character).

If I click on any row, this invalid character disappears. In the screenshot, you can see that I've clicked on three rows in the middle of the list.

However, if I close Mp3tag and open it again on the same folder, the invalid character is displayed again for all of the files in the list.


No invalid characters.


Update: if I scan a different set of MP3s, which were created using LAME 3.99, they show a different invalid character at the end of the LAME version. They should just say "LAME3.99r":


I can confirm that. V2.86e did not show these characters.

Thanks for confirming!

Same here. Didn't need to create a custom column - the invalid characters are also in the Codec field:


The gibberish is different in each folder, but stays the same whenever you enter a given path.

It looks a s though it has to do with the library:
If you toggle the settings for the library and re-read the files, the garbage characters vanish.

I don't use the Library on my Mp3tag, and never have, and yet I still got the invalid characters on mine.

Will this still be fixed? I think it's still a bug, because it's not reasonable to expect all users who upgrade to 2.87 and use the new %_tool% field to have to toggle their library settings in order to get it to display the info correctly, right? :wink:

What I found:
Library off:
Reading the files initially: garbage characters
Moving the selection along the files list: garbage characters vanish

Library on:
Reading the files initially: garbage characters
Moving the selection along the files list: garbage characters vanish
Now the contents of the library is read, no more garbage characters.

So yes, there it does not look right...

No library here... :wink:

I tried that. The garbage characters stay the same. :astonished:

I switched off the library.
the short picture shows the initial situation
the longer picture shows the situation after I moved the file selector a couple of files to the top.
For those files the tools column got updated and the garbage characters disappeared.

That there are garbage characters in the first place looks indeed not right.

You're all way too fast in talking to each other :slight_smile: It's not IRC or WhatsApp here.

I can confirm the issue and it has nothing to do with the Library (but with certain memory initialization situations, which will differ from instance to instance).

I'll fix it later today and will release a new version (most likely as hotfix to v2.87 and not as beta).

Thanks for reporting (and double-checking)!

1 Like

Thanks so much @Florian! :slight_smile:

Can you please try this version and let me know whether it fixes the issue for you?


If you have the Library enabled with your Mp3tag, please also ensure that you don't look at outdated data by reloading via Ctrl + T.

trying to keep up the whatsapp spirit here :wink:

I checked it with libray first switched off, then enabled:
In both cases just the pure name, no more gargabe characters in %_tool%.

1 Like

Excellent, that's needed now :grin: Thanks for confirming the fix!

Let's see if @Jezz and @ralph have the chat window also still open.

After some further testing, I've now pushed the change to the main site and released v2.87a as hotfix.

Thanks again for reporting!

Just installed 2.87a from the main site, and I can confirm - all fixed now and working fine!

Nochmals vielen Dank!

1 Like

Yup. I also tried v2.87a - it is fixed now! Thank you very much! :grinning:

And sorry for not being online for the last three hours... :sunglasses: :wink:

1 Like

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