# Encoder detection **URL:** \ **Category:** Support\ **Created:** [October 21, 2023, 8:57am UTC](https://community.mp3tag.de/t/encoder-detection/62486 "2023-10-21T08:57:43Z")\ **Posts on this page:** 7\ **Page:** 2
**Author:** ![chrisbxc](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/c/919ad9/32.png) [@chrisbxc](https://community.mp3tag.de/u/chrisbxc)\ **Post date:** [October 23, 2023, 11:21am UTC](https://community.mp3tag.de/t/encoder-detection/62486/21 "2023-10-23T11:21:28Z")
Yep, it seems so, I just tried what you found out and it's same here for me... ---
**Author:** ![chrisbxc](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/c/919ad9/32.png) [@chrisbxc](https://community.mp3tag.de/u/chrisbxc)\ **Post date:** [November 10, 2023, 1:36pm UTC](https://community.mp3tag.de/t/encoder-detection/62486/22 "2023-11-10T13:36:10Z")
any chance for a fix from dev? ---
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [November 10, 2023, 1:44pm UTC](https://community.mp3tag.de/t/encoder-detection/62486/23 "2023-11-10T13:44:57Z")
AFAI understand it, the LAME folks say that LAME should be in capitals. If that is so, MP3tag shows it. If you don't see LAME, then it is not clear: is it just in non-standard case or is there no information at all - which could also apply. If you see LAME then you can be sure it is encoded with LAME. In all other cases, you would have to investigate anyway. ---
**Author:** ![chrisbxc](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/c/919ad9/32.png) [@chrisbxc](https://community.mp3tag.de/u/chrisbxc)\ **Post date:** [November 12, 2023, 2:53pm UTC](https://community.mp3tag.de/t/encoder-detection/62486/24 "2023-11-12T14:53:21Z")
Further analyzing with HxD hex editor mp3 files that have this issue (Lame instead of LAME) I found that the first reference of "Lame" is spelled like this which Mp3tag does not recognize but after the first "Lame" reference there are tens of other reference spelled like this "LAME" which Mp3tag should recognize but since it's not the first reference Mp3tag seems to ignore. Changing the first reference of Lame to LAME - now Mp3tag recognize it - as we already established. Maybe Mp3tag doesn't look in the correct location for encoder? since other software like Audio Identifier (software from 2008) / TrueLameVersion (also very old utility) / Media Info - recognize the encoder regardless of how it's spelled the first reference for Lame in this case. ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [November 13, 2023, 12:31pm UTC](https://community.mp3tag.de/t/encoder-detection/62486/25 "2023-11-13T12:31:41Z")
Mp3tag reads a correctly written LAME header and makes the whole thing available via %\_tool%. Other encoders (including other encoders that use LAME internally but do not write a LAME header) are not recognized by Mp3tag. I am very surprised about the lower case of Lame in the example file, because all LAMEs I know actually use LAME correctly (except LAME 3.99.1, which I think used L3.99.1). At some point I decided against recognizing encoders, because the whole thing can only be solved heuristically and there will always be an edge case which is then reported as bug (as this example shows). If you can point me to an official version of the LAME encoder that writes "Lame" instead of "LAME", I might add support for that. Otherwise, I'd like to encourage you to use the tools that detect encoders in a for you sufficiently acceptable way. ---
**Author:** ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)\ **Post date:** [November 14, 2023, 2:05pm UTC](https://community.mp3tag.de/t/encoder-detection/62486/26 "2023-11-14T14:05:04Z")
> [@Florian](#): > > because all LAMEs I know actually use LAME correctly (except LAME 3.99.1, which I think used L3.99.1). Just for completeness: According to [this information](https://wiki.hydrogenaud.io/index.php?title=LAME_version_string) about the "LAME version string", LAME was written in uppercase at least since version 3.98 back in 2008: ```auto 3.98 = 3.98.0 = "LAME3.98" followed by a space character (byte 0x20) 3.98.1 through 3.98.4 = "LAME3.98r" 3.99 alpha versions = "LAME3.99a" 3.99 beta versions = "LAME3.99b" 3.99 = 3.99.0 = "LAME3.99" followed by a space character 3.99.1 = "L3.99r" followed by three null characters (byte 0x00) 3.99.2 through 3.99.n = "LAME3.99r" 3.100 alpha versions = "LAME3100a" ``` There was only one exception for v3.99.1: _(between November 05 2011 and [November 18 2011](https://www.videohelp.com/software/Lame-MP3/version-history) until v.3.99.2 was released)_ > For LAME 3.99.1, the format was changed such that release versions with a patch version \> 0 would be identified with the following format: > > "`L`" + major version + "`.`" + minor version + flag + patch version > > However, the new code contained a minor error which resulted in the patch version being omitted, **and the change of "`LAME`" to "`L`" proved to be problematic for hardware and software players which failed to recognize the LAME tags as such** , adversely affecting [gapless](https://wiki.hydrogenaud.io/index.php?title=Gapless) playback and encoder identification, **so the new scheme was abandoned for 3.99.2 and up.** ---
**Author:** ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)\ **Post date:** [December 14, 2023, 2:06pm UTC](https://community.mp3tag.de/t/encoder-detection/62486/27 "2023-12-14T14:06:00Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed. [Previous page](https://community.mp3tag.de/t/encoder-detection/62486.md?page=1)