Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Wrong 3.98.3 encoder version tag (Read 11228 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Wrong 3.98.3 encoder version tag

Encoding with latest 3.98.3 Lame build writes wrong encoder info to MP3 files.
Checked it twice with Foobar 1.0 and hexeditor, it reports 3.99a.

lame.exe

621,056 bytes
2010-02-27
Intel Compiler 11.1.054

Downloaded from Rarewares.
Or isn't it an offical release?

Wrong 3.98.3 encoder version tag

Reply #1 –
Confirm. Was just a moment too late

Wrong 3.98.3 encoder version tag

Reply #2 –
@john33, the main Lame 3.98.3 bundle at rarewares says it's Lame 3.99a2 - this is the signature on the window when run through commandline (complete with the warning about only using alphas for testing purposes) and also the resulting files show up as 3.99a2 in foobar2000.
Is the version correct and the signature/identifier simply wrong, or is the version actually an alpha?
God kills a kitten every time you encode with CBR 320

Wrong 3.98.3 encoder version tag

Reply #3 –
Quote from: NIN9 on
Encoding with latest 3.98.3 Lame build writes wrong encoder info to MP3 files.
Checked it twice with Foobar 1.0 and hexeditor, it reports 3.99a.

lame.exe

621,056 bytes
2010-02-27
Intel Compiler 11.1.054

Downloaded from Rarewares.
Or isn't it an offical release?


Confirmed. Same with the ACM codec on their site. I guess they compiled 3.99a by accident (instead of 3.98.3)!


Not the first time this happens with Rarewares compiles.

http://www.hydrogenaudio.org/forums/index....st&p=654847

Wrong 3.98.3 encoder version tag

Reply #5 –
Well, it may be that current alpha does write the old version info at some points into the mp3 data, but if you run lame from the command shell and it says 3.99 alpha, then it is just that.

Wrong 3.98.3 encoder version tag

Reply #6 –
Encspot reports "LAME 3.99 (alpha)". Foobar2000: "LAME3.99a".  (also, this version makes *.mp3 files by default, not *.wav.mp3)

Bodhi, maybe you still use 3.98.2?

Wrong 3.98.3 encoder version tag

Reply #7 –
Quote from: timcupery on
@john33, the main Lame 3.98.3 bundle at rarewares says it's Lame 3.99a2 - this is the signature on the window when run through commandline (complete with the warning about only using alphas for testing purposes) and also the resulting files show up as 3.99a2 in foobar2000.
Is the version correct and the signature/identifier simply wrong, or is the version actually an alpha?

You're quite right, I'm afraid. I screwed up the CVS checkout in my rush to get this out!

Humble apologies to all!

New, correct compiles are now available.

Wrong 3.98.3 encoder version tag

Reply #9 –
Anyway, correct LAME compiles are available now...

Wrong 3.98.3 encoder version tag

Reply #10 –
Encspot reads the 3.98 string from the LAME info tag. In this case that tag does not store the last digit. For instance, there is no difference between 3.98.2 and 3.98.3.

You can open a LAME 3.98.3 encoded file in a hex editor and see the difference in the padding area where the 3.98.3 string is repeated a few times.

Even Notepad can show those strings if it is forced to open an MP3 file. (Browse to the end of the file, but select the smallest file you have. Notepad is not very good with big files.)


Edit: added a missing "not".

Edit2: ...and fixed a typo in the above "Edit".

Edit3: added "In this case". The last digit is stored if the string is like 3.97, 3.98, etc without an additional minor revision number.

Wrong 3.98.3 encoder version tag

Reply #11 –
Quote from: Alex B on
Encspot reads the 3.98 string from the LAME info tag. That tag does store the last digit. For instance, there is no difference between 3.98.2 and 3.98.3.

You must means does NOT store the last digit.

Edit: Already corrected.

Wrong 3.98.3 encoder version tag

Reply #13 –
Quote from: Alex B on
Encspot reads the 3.98 string from the LAME info tag. That tag does not store the last digit. For instance, there is no difference between 3.98.2 and 3.98.3.

Good to know, Thank you!

Wrong 3.98.3 encoder version tag

Reply #14 –
No humble apologies necessary. You're doing us all a service! so thanks

One issue I'd still like to raise along these lines. While the encoder windows (in commandline DOS-ish mode) says 3.98.3, the resulting file stays Lame 3.98r (checking using foobar2000, and Audio Identifier).
Is it possible to change to where the resulting file says 3.98.3 - this will be useful to distinguish which files (whether my own or "in the wild") were encoded with 3.98.2 from those encoded with 3.98.3. Doesn't matter at lower bitrates, but more likely to matter at high bitrates and/or large frames.

edit: it seems the  Lame info tag doesn't carry enough digits to show 3.98.3.
- files encoded with Lame 3.90.3 show up as "Lame 3.90." (not the last decimal point) in Audio Identifier.
- updated versions of 3.96 and 3.98.2 show up as "Lame 3.98r"

In the interest of distinguishing files encoded by Lame 3.98.3, is would be possible to write either of these options to the Lame tag:
a) 3.983
b) 3.98u (the "u" meaning "updated" to distinguish from 3.98r)

I suspect this is not a function of compiling, but rather a result of the encoder build.
What do people think of this proposal?
God kills a kitten every time you encode with CBR 320

Wrong 3.98.3 encoder version tag

Reply #15 –
(Note that this post is largely reiterating my most recent post in this thread in the Mp3-Tech forum)

I think it's a problem that the signature of files encoded by Lame 3.98.3 being indistinguishable from 3.98.2. It would be nice to be able to distinguish files from these two encoders, whether those that I encoded myself, or those "from the wild". Some mp3-purchasing sites, notably eMusic and Amazon, use Lame 3.98.2.

The Lame info tag doesn't store enough characters to show the full version. For example, files encoded with Lame 3.90.3 show up as "Lame 3.90." (note the last decimal point) in Audio Identifier and presumably EncSpot etc.
This is presumably why updated versions of 3.96 and the recent 3.98.2 show themselves as "3.96r" and "3.98r"

In the interest of distinguishing files encoded by Lame 3.98.3, is would be possible to write either of these options to the Lame tag:
a) 3.983
b) 3.98u (the "u" meaning "updated" to distinguish from 3.98r)

I suspect this is not a function of compiling, but rather a result of the encoder build.
What do people think of this proposal?
God kills a kitten every time you encode with CBR 320

Wrong 3.98.3 encoder version tag

Reply #16 –
I believe this issue actually goes way back, it was a point of contention with the 3.90.x derivatives.

Wrong 3.98.3 encoder version tag

Reply #17 –
Quote from: john33 on
I believe this issue actually goes way back, it was a point of contention with the 3.90.x derivatives.

I'm curious what robert or other Lame devs think about this
God kills a kitten every time you encode with CBR 320

Wrong 3.98.3 encoder version tag

Reply #18 –
Well, at some point in time there may very well be a version 3.100

If you look into the very last frame of each mp3, it is very likely to see the complete version string there.
If you add id3v2 tags via LAME, you'll get the complete encoder version info there too.

Wrong 3.98.3 encoder version tag

Reply #19 –
thanks robert.
do you think there's any viability to my proposal of 3.98u or something similar? Since it appears there are some legitimate/significant improvements as a result of bit reservoir rules in Lame 3.98.3, being able to distinguish the encoder used to create the files (without opening the final frame in a text editor) could be useful.
God kills a kitten every time you encode with CBR 320

Wrong 3.98.3 encoder version tag

Reply #20 –
Please don't change the build again. 3.98r is fine.

Wrong 3.98.3 encoder version tag

Reply #21 –
Ah crap, I archived tons of Music with that build and havent the original cds anymore.
I figure it out after encoding.

Is 3.99 Alpha that bad?

Wrong 3.98.3 encoder version tag

Reply #22 –
No, in this case, it should be fine.

Wrong 3.98.3 encoder version tag

Reply #23 –
I'm sure Robert will correct me if I'm wrong, but I believe 3.99a2 and 3.98.3 are, at this time, pretty much identical.

Wrong 3.98.3 encoder version tag

Reply #24 –
LOL, a weird thing just happened. I encoded some files with this latest LAME build, using -b 320 -q 0 settings, and when I looked up the info in MediaInfo under Encoding settings it showed: -m j -V 4 -q 0 -lowpass 20.5.    It says, correctly, that the bitrate is 320 kbps, but I have no idea how it 'decoded' the settings in this way...

And Writing library field appears as 3.98r.