Encoder detection

Using Codec/Encoder........: %_codec% / %_tool% for the nfo generation returns Codec/Encoder........: MPEG 1 Layer III /
It seems that %_tool% doesn't recognize LAME3.100, but returns LAME3.99r for mp3's that are encoded with LAME 3.99.5
Using v3.22b x64 Portable, also in the GUI:
image
I've tried with 3.22e x64 Portable, same thing, and also when I installed this version the path to the previous installation wasn't detected (I know it's portable installation but with older versions I remember the path was detected - I always installed Portable version).

This is not true for (real) portable installations.

About the %_Tool% property: AFAIK Mp3tag shows that what the encoder has written to the file. So, if the encoder did not add that data, MP3tag cannot show it.
If this should not be the case, then a check of the file with a hex editor would be an idea or a check whether other tools can find the encoder version somewhere.

I've checked with other tools like TrueLame Version or with Audio Identifier 0.7.1 all identify as lame 3.99 or lame 3.10, the same 2 files
image
TrueLame Version App
image

Could you provide a sample song which should show LAME 3.100 (or LAME 3.10) in Mp3tag?

One can check with whatever mp3 that is encoded with Lame 3.100 and other mp3 file that is encoded with Lame 3.99.5/r mp3 file.

I can see LAME3.100:


and LAME3.99r

and LAME3.99

and LAME3.98r

and so on.
The oldest I could find in my test files is
LAME3.90.

Check with Mp3tag v3.22e or 3.22a x64 Portable version
I can't see the version you are using: I am using the version you see in the printscreen


image

My screenshots are from v3.22e (32bit)
image
Just a moment, I just try it with a portable v3.22e in 64-bit...

In your screenshot it's a 32 bit version so... not he same I am using... it's not even a Portable version....

Exactly, that is why I am reporting this issue...

In 64bit-Portable v3.22e the official standard codec column with the Value set as
%_codec%[ (%_tool%)]
looks like this
(not the same sort order, I just made a screenshot from what I got):


Help -> About:
image

There are some tracks WITHOUT LAME version. This is also true for previous versions and my 32bit-Version. But if the LAME version exists in the track, it will be showed, including your LAME3.100.

This is what @ohrenkino wrote in the first answer.

Other tools like MediaInfo or TrueLameVersion or Audio Identifier display the encoder as lame 3.100 or 3.99

I checked 2 files that behae differently in MP3tag in respect to display of tool version:
one says LAME3.100
the other one says nothing.

I checked the 2 files with a hex editor an only the first contains the string LAME.

I then checked both files in Foobar2000.
The first displays in the properties as tool: LAME3.100
For the other one Foobar2000 does not show anything for "tool".

So my conclusion would be: MP3tag shows accurately what has been written into the file as "tool".
If other programs have other means to find out which tools has been used then it would be nice to get a hint how they do it. If it includes the analysis of the audio part then it is currently out of reach for MP3tag.

I also downloaded MediaInfo and checked the file without "tool" in the other 2 programs - and unlike your claim that this program reveals the tool, I do not see anything like "LAME", whereas it shows "Writing library: LAME3.100" for the other one.
So I doubt that the observed behaviour is a bug.

I've also checked my 2 files with a hex editor, and both of them have the encoder:


Could you supply one of these files?

So at least it looks like there are different methods to detect the tool which are shared by different programs. MP3tag, Foobar2000 and exiftool seem to apply one methode, MediaInfo uses a different one.
But if the encoder has not written any information about the tool, then none of these programs says anything.

Not all mp3's are encoded with lame, it can be other encoder like Xing or FhG or others... and ofcourse if the encoder didn't have the parameter to write the "tool" information in the file header - then the information is not available, although I think that lame writes this information by default, and only if one disables this by parameters then the info is not available, and even like this I don't think that you can't detect the encoder, using other tools or other inspection ways (as long as we are inspecting "non-damaged" mp3 files).

Oh yes, I checked these files without information with MP3diags to see whether that program shows more details - and those files were OK, according to MP3diags.

Yes I can provide the files, as long as we are not breaking the rules, we can also exchange the files like the one you say has no "tool" information.

Here is the data from today that does not show any tool info in MediaInfo


And here is one for which MP3tag and Mediainfo both show a tool (writing library):

so it is possible to get files without the writing library information

Thank you for the file links.
I think I found it:
The hex editor reveals that the files that show the tool have the version spelt
LAME

whereas the files that do not show the tool have the version spelt
Lame

I overwrote LAME with Lame in the file which showed LAME3.99r in MP3tag and now MP3tag did not show the tool any more.
So if MP3tag could ignore the case, then the tool - if present - should be displayable.

MediaInfo shows LAME3.99r as LAME3.99r while it shows Lame3.99r as LAME3.99.5.