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: Lame 3.100 has been released (Read 124998 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Lame 3.100 has been released

Reply #50
I assume LAME v3.100.2.0 is the newest LAME build? ; I ask because that's whats included with the newest Encoders Pack for Foobar2000 which was updated on Oct 15th 2017.
For music I suggest (using Foobar2000)... MP3 (LAME) @ V5 (130kbps). NOTE: using on AGPTEK-U3 as of Mar 18th 2021. I use 'fatsort' (on Linux) so MP3's are listed in proper order on AGPTEK-U3.

Re: Lame 3.100 has been released

Reply #51
I think john33 made a new version because there was an issue with some DLLs and I believe that's just the CLI/.exe version for him for reference, last version of LAME is still the one in the first post.

Re: Lame 3.100 has been released

Reply #52
From libmp3lame\version.h:
Code: [Select]
# define LAME_MAJOR_VERSION      3 /* Major version number */
# define LAME_MINOR_VERSION    100 /* Minor version number */
# define LAME_TYPE_VERSION       2 /* 0:alpha 1:beta 2:release */
# define LAME_PATCH_VERSION      0 /* Patch level */ 

So 3.100.2.0 means "release version of 3.100.0"

Re: Lame 3.100 has been released

Reply #53
I'm so mad I never got into programming, one new thing, thanks for that.

Re: Lame 3.100 has been released

Reply #54
So 3.100.2.0 means "release version of 3.100.0"
I'd rather say: 3.100.2.0 means "first release version of 3.100" (since you've included the 0 at the patch level).
3.100.0 means it's the alpha of 3.100.

Technically the major number is being changed, when things get incompatible with the prior version, minor versions are: things are still compatible with one another, but internals have changed (these might be quite extensive, including a full rewrite, but as long as it's all the same to the user, eh).
Patch levels are pertaining to a specific version and are not really sub-minor versions, rather they signify a consecutive number of bugfixes, and are generally thought of as assets that are in some form finished and can become exposed to the userbase.
Alpha. Beta, and release are cycles usually used for each version, and usually each of those has their own set of patch levels.
In that regard, the structure of LAMEs version numbering makes sense, although I think using the word "alpha", "beta" or "a", "b", or - my favorite - "α" or "β" in the version number field is more desirable.

Version numbers should be skipped if development of an intermediate version has been dropped. For instance let's assume you have Software Program "X", currently at version 3.141.59-beta. Now the developers decide, even though the beta has been rolled out for a while, it makes no sense to finish this version as it is hated by the userbase and making that version into a release would be a waste of time. So instead they keep everything compatible, but basically quickly pivot their design ideas, rewrite large portions of the code, change the interface, here and there, and release 3.142.0-alpha, and ask the userbase for test reports. If they like it, that version will get an increasing number of bugfixes rolled out as patches (third number after the last dot), and will eventually be upgraded to beta, and after that, the release will drop "alpha" or "beta" and just use the version number on its own.

Version numbering is all about the userbase, not the developers. Developers use subversioning internally, which is an ever increasing number of code commits to some sort of version tracking system. Except if you're from the 60's then you probably use a crayon to mark the number on your batch of punched cards or fan-folded 1" paper tape…

Some software projects, mainly geared towards professional users, kinda push this a little further into basically a joke. LaTeX for instance approaches π, currently at version 3.14159265-2.6-1.40.17 (TeX Live 2016). Each time they release a new version they add another digit to the first number after the first dot.

You always include as many numbers as needed to be unambiguous, but as little as it is convenient, when referring to it.

For instance, when you're encoding MP3 with LAME (not how I didn't use any numbers here), it makes sense to put the entire version number into one of the ID3 tags.

Re: Lame 3.100 has been released

Reply #55
I found that I had not been running the latest binary in my post earlier in this thread. Once I discovered the error I also found the binary would not run on the older machine/OS anyway.

Thanks to john33 I was able to run LAME 3.100 on the same machine. If it matters, the output MP3 (at setting -V2) from version 3.100 was identical to 3.995 except for the tag which displayed the version.

I still appreciate this project. Thanks goes to the LAME team and an additional thanks to john33 for his continued efforts towards providing consistent compiles. :)
"Something bothering you, Mister Spock?"

Re: Lame 3.100 has been released

Reply #56
Congratulations on the new release, Devs! It's beeb a long long while since I last visited HA, but I'm glad to see some old faces still hanging around.

Re: Lame 3.100 has been released

Reply #57
d4k0: That's an innerent problem of old programs assuming that the tag was going to be 8 characters always. The problem is that LAME3.100 is now 9 characters, and in C, the strings are terminated will a null character (code 0). Due to this discrepancy, now the string is not being terminated at the correct position with programs that didn't get around this possibility.

Well, Lame 3.95.5 is reported as "LAME3.99r" which is also 9 characters long (I have some C/C++ knowledge so I know what a null-terminated string is). Or is the the second digit (= 100) the problem as it now contains 3 characters?

What I also noticed is that files that were encoded with Lame 3.95.5 also showed some encoding settings:



This is how Lame 3.100 looks:


Re: Lame 3.100 has been released

Reply #58
what tool are you using?

Re: Lame 3.100 has been released

Reply #59
For the screenshots I used PotPlayer, but I get the same results with other media players like "Light Alloy" or "MPC-HC". I think they all use MediaInfo which could be the "culprit" (the stand-alone MediaInfo program has the same output). With AIMP2, Foobar2000 or MP3Tag I don't get any information about the encoder.

Re: Lame 3.100 has been released

Reply #60
foobar2000 shows me the version.



I tested with the lame build published on the foobar2000 website as part of the free encoder pack and also the 64bit version from rarewares.




Re: Lame 3.100 has been released

Reply #61
Ah, I somehow missed the details tab. I now get the same result. So this is probably an issue with MediaInfo?


Re: Lame 3.100 has been released

Reply #63
Thanks robert, I created an issue on their github repository and linked your response there.

Re: Lame 3.100 has been released

Reply #64
Thanks robert, I created an issue on their github repository and linked your response there.

Thanks for the report about this bug in MediaInfo.

Fixed, Windows snapshot available.
Note: this is an hot fix, there is a debate about how to detect new LAME versions and corresponding Info tag, discussion is not closed in case a better method for detecting new versions is found.

Re: Lame 3.100 has been released

Reply #65
v3.100 compiled with msvc2005
nothing special, GOGO-no-coda ~256kbps VBR + mp3packer

Re: Lame 3.100 has been released

Reply #66
v3.100 compiled with clang 5.0 with msvc2010 lib
nothing special, GOGO-no-coda ~256kbps VBR + mp3packer


 

Re: Lame 3.100 has been released

Reply #68
Corrected compiles uploaded. 32 bit and 64 bit versions tested on system without the Intel libraries present and load and work fine. 'More haste, less speed' called for, methinks! ;)

i may be the sole user of lamedrop (xpd), but was wondering if you'd be able to update that too at some point?


also, i guess this question is for anyone using the rarewares encodes, i got checksums from the a set of files (with the same setting from the same wav), one created with the 32 bit version and one created with the 64 bit version and got different results for the checksums...
i was wondering if this was normal, like i'm assuming it's just because they have a different footprint in the file somehow, i was just worried after the initial errors with the 64 bit version that something could be wrong. it seems fine, but i would have thought the checksums would be identical.

Re: Lame 3.100 has been released

Reply #69
Corrected compiles uploaded. 32 bit and 64 bit versions tested on system without the Intel libraries present and load and work fine. 'More haste, less speed' called for, methinks! ;)

i may be the sole user of lamedrop (xpd), but was wondering if you'd be able to update that too at some point?


also, i guess this question is for anyone using the rarewares encodes, i got checksums from the a set of files (with the same setting from the same wav), one created with the 32 bit version and one created with the 64 bit version and got different results for the checksums...
i was wondering if this was normal, like i'm assuming it's just because they have a different footprint in the file somehow, i was just worried after the initial errors with the 64 bit version that something could be wrong. it seems fine, but i would have thought the checksums would be identical.
Thanks for the 'nudge'! I was planning to get round to lamedropXpd, that'll give me the hurry up.

The only difference between the original compiles and the 'corrected' ones is that the first ones needed the Intel runtime libraries and the 'corrected' ones were compiled against the static libraries. I would not expect 32 bit and 64 bit encodes to be bit identical since, apart from anything else, the 32 bit compiles use 'nasm' code and the 64 bit compiles do not. I don't believe anyone has ever been able to hear any difference in the results, but you're welcome to try!! ;)

Re: Lame 3.100 has been released

Reply #70
But i would have thought the checksums would be identical.
They won't be bit identical because of the architectures. Same happens with FLAC, sometimes you get different files if you use a Linux binary encoder than a Windows compiled encoder.


Re: Lame 3.100 has been released

Reply #72
But i would have thought the checksums would be identical.
They won't be bit identical because of the architectures. Same happens with FLAC, sometimes you get different files if you use a Linux binary encoder than a Windows compiled encoder.

Seems like that would be a problem for a codec that claims to be lossless ;)  Lossy codecs, on the other hand, do all sorts of funky float arithmetic that gives different results on different architectures or hardware.


Re: Lame 3.100 has been released

Reply #74
It seems i found strange bug.
Take mp3 320 kbps (i tried files created with lame 3.99 and 3.100) encoded using foobar2000's converter with -S -cbr -b 320 -q 0 --noreplaygain - %d. Re-encode this file using lame 3.100 (i tried different builds - tmkk, foobar2000 free encoder pack and rarewares) and foobar2000's converter with -S -cbr --noreplaygain - %d, highest BPS supported 32. Resulted mp3 file is 2 times longer and sounds horribly distorted.
If i do the same re-encoding using lame 3.99 - no problem. 32 bit builds were used.