LAME 3.99 is out, 2012-02-28: version 3.99.5 has been released Options

[kwanbis]

Dropping LAME is a bad idea from branding standpoint. L is not a brand name, LAME is. This is way more important than any minor version.

Agree 100%.

[spoon]

Just testing the latest 3.99.1 from Rarewares, there seems to be changes to the Lame header written, previously it was written LAME3.98 now (very quick glance) it seems to be 'L3.99r1' that is why no programs are picking up the lame header now.

Old Lame (after an info chunk):



New Lame



This post has been edited by spoon: Nov 16 2011, 11:09

[john33]

Just by way of explanation, the problem relates to the desire to indicate that the release version is 3.99.1 as opposed to 3.99.

Under the old scheme it was not possible to indicate in the tag that it was 3.99 release, patch version 1, it was simply 'LAME3.99r', where 'r' indicated that it is a release version at a patch verion above '0', but the patch version number is not shown. If the release version was never at a patch version greater than '0', this was not an issue and the tag would read 'LAME3.99 ', but the change was to allow for the specification of what the patch version was above '0'.

CODE

const char *
get_lame_very_short_version(void)
{
    /* adding date and time to version string makes it harder for output
       validation */
#if   LAME_ALPHA_VERSION
#define P "a"
#elif LAME_BETA_VERSION
#define P "b"
#elif LAME_RELEASE_VERSION && (LAME_PATCH_VERSION > 0)
#define P "r"
#else
#define P " "
#endif
    static /*@observer@ */ const char *const str =
#if (LAME_PATCH_VERSION > 0)
      "L" STR(LAME_MAJOR_VERSION) "." STR(LAME_MINOR_VERSION) P STR(LAME_PATCH_VERSION)
#else
      "LAME" STR(LAME_MAJOR_VERSION) "." STR(LAME_MINOR_VERSION) P
#endif
     ;
    return str;
}

Above is the code that does the work.

So, as you can see, if the patch version is at '0', then the tag will read 'LAME3.99 ', as before, but if it is greater than '0' then it will read 'L3.99rn', where 'r' indicates that it is indeed a release version and 'n' = the patch version number.

Whether there may be a better way to do this is not for me to say, but knowing the patch version and, therefore, knowing if you are using the latest version must be of benefit.

[spoon]

Programs can update to this new standard, but who knows any program which reads a lame header (even iTunes?) might be broken, and updates might not be forthcoming for all programs.

[DARcode]

I second spoon's concerns, improved standards should always be introduced with some measure of backward compatibility at least for a transition phase.

[spoon]

Simple fix why not write:

LAME3.991

instead of L3.99r1

Keep to the LAME3.99a for point releases

Also I echo the concern about dropping the LAME branding, having encoded by: L3.99r1 is confusing.

This post has been edited by spoon: Nov 16 2011, 11:43

[Zenitram]

but knowing the patch version and, therefore, knowing if you are using the latest version must be of benefit.

Is this rule be "forever"? Is it good to remove "LAME" brand from the the "vendor" tag? Sorting is fun too (3.99r1, then 3.99a2, than 3.99b2, then 3.99r2, then 3.99a3... This is not trivial to sort, compared to L3.99.1r, L3.99.2a...). How someone who has never seen a LAME tag (this can happen!) can find that "L" or "L3.99" is the hint for "Lame" encoder? "Lame encoder" on Google redirects to http://lame.sourceforge.net, "L encoder" will never do it. I would have imagined something like "LAME3.99s" or "LAME4.00r"... (Why using .99 if you don't plan to rename it to .00 at some point? After 3.99.9, will the next one be 3.99.9.1?)

[john33]

The problem is that the LAME tag currently allows 9 bytes for the Version info. Without changing the size of this and causing more external software issues, no doubt, there has to be a compromise if the Patch Version Number is to be written. Previously, it wasn't written, so it wasn't an issue.

So, it really depends on whether people want the patch version number written into the LAME tag, or not.

[john33]

but knowing the patch version and, therefore, knowing if you are using the latest version must be of benefit.

Is this rule be "forever"? Is it good to remove "LAME" brand from the the "vendor" tag? Sorting is fun too (3.99r1, then 3.99a2, than 3.99b2, then 3.99r2, then 3.99a3... This is not trivial to sort, compared to L3.99.1r, L3.99.2a...). How someone who has never seen a LAME tag (this can happen!) can find that "L" or "L3.99" is the hint for "Lame" encoder? "Lame encoder" on Google redirects to http://lame.sourceforge.net, "L encoder" will never do it. I would have imagined something like "LAME3.99s" or "LAME4.00r"... (Why using .99 if you don't plan to rename it to .00 at some point? After 3.99.9, will the next one be 3.99.9.1?)

The next version is already designated as '3.100' which will cause a further problem!!

This post has been edited by john33: Nov 16 2011, 12:19

[RobertoDomenico]

Don't know if this is any help. When converting some FLAC to MP3 Lame 3.99.1 with XLD on OS X Lion and then playing them back with iTunes under get info iTunes reports "Encoded with LAME 32bits version 3.99.1 (http://lame.sf.net)"

The files play back gapless perfectly.

[lameboy]

The next version is already designated as '3.100' which will cause a further problem!!

Indeed. Since the maximum number of characters is 9 (9 bytes), for the next major version with a patch (LAME 3.100.1) one has the following options:

LAME31001
or
L3.100r1

Or something else in 9 characters.

[apodtele]

Indeed. Since the maximum number of characters is 9 (9 bytes), for the next major version with a patch (LAME 3.100.1) one has the following options:

LAME31001
or
L3.100r1

Or something else in 9 characters.

Obviously, this is about priorities. Many people here including myself think that 'LAME' brand is way way way more important than squeezing in '.1'.

In addition there won't be 3.100 until it is released. It is not late to stop this silliness and reset the counter. Why not 4.0 already? Why not 5.0 if 4.0
is taken? Indeed dropping periods is much more harmless

LAME5000
LAME5001
LAME5101

[bilbo]

Why not just use a letter designation for now such as:

3.99a
3.99b
...
...
3.99z

This will give us 25 more revisions to fight about it!

[john33]

Why not just use a letter designation for now such as:

3.99a
3.99b
...
...
3.99z

This will give us 25 more revisions to fight about it!

The 'a' and 'b' are already in use for 'alpha' and 'beta' versions.

[GeSomeone]

r,s,t,u,v,w,x,y,z seems vaguely familiar somehow, gives just 9 "revisions", the new scheme leaves one char extra.
At least foobar2000 has no problems displaying the new version tag.

[Alex B]

Please change the LAME header back to the old more compatible format. Many SW & HW players can now read the LAME tag and play files gaplessly, but apparently the changed header does not work with every player.

For example, here is how JRiver Media Center sees the 3.98.4 and 3.99.1 headers:

LAME 3.98.4

CODE

MPEG-1 Layer 3
236 Kbit VBR
44.1 Khz Joint stereo

Copyrighted: No
Original: Yes
Protected by CRC: No
Encoder: LAME
Gapless: Yes (576 start, 828 end)

LAME 3.99.1

CODE

MPEG-1 Layer 3
273 Kbit VBR
44.1 Khz Joint stereo

Copyrighted: No
Original: Yes
Protected by CRC: No
Encoder: L3.9
Gapless: No

I'd request to label the current version as 3.99r and then do the 5.0 release. (4.0 must be skipped because of known reasons.)

Then the LAME developes can create up to 5 x 99 versions before the encountering the next problem - 10.0.
i.e. 5.00, 5.01, 5.02 ... 5.99, 6.00, 6.01 ... and so on.

IMHO, this a very important thing and even if the 5.00 release does not contain any other significant changes, fixing this header problem justifies the new version number.

This post has been edited by Alex B: Nov 16 2011, 23:35

[halb27]

I second Alex B's proposal.

[Alex B]

... And as already reported EncSpot Pro is one of the programs that do not recognize the new header. Encspot Pro is a sacred relic from the past, but I still use it almost every day.

[lock67ca]

So that would also explain the trouble I'm having with gapless playback in iTunes and my Ipod?

3.98.4 plays perfectly.

[Alex B]

I just tried the current Winamp build. It can be added to the list of victims. It does not recognize the encoder delay and padding values from the LAME v.3.99.1 header.

[timcupery]

Simple fix why not write LAME3.991 instead of L3.99r1
...
Also I echo the concern about dropping the LAME branding, having encoded by: L3.99r1 is confusing.

I proposed this awhile back, on a thread wishing that Lame 3.98.4 could be distinguished from 3.98.2 in the header info (as it was, both versions are denoted in the header as LAME3.98r).
Similarly, Lame 3.90.3 just shows up as LAME3.90. with nothing after the decimal.
I think for now, dropping the decimal and making it LAME3.991 is the best solution, to keep the header consistent with previous versions.

[RobertoDomenico]

So that would also explain the trouble I'm having with gapless playback in iTunes and my Ipod?

3.98.4 plays perfectly.

I can't say for the iPod but with iTunes 10.5.1 on OS X MP3's created with XLD using LAME 3.99.1 play back perfectly gapless and play back perfectly gapless on the Apple TV 2

[Aleron Ives]

I think for now, dropping the decimal and making it LAME3.991 is the best solution, to keep the header consistent with previous versions.

It's also worth noting that this is only an option as long as the plans for the next version number are changed. Since 1999, the sub-version numbers have always been limited to a maximum of two digits (LAME 3.01, 3.22, 3.96.1, etc.), and since that is the case, removing the period before the final number works, as it's understood that the sub-version can only be two digits. If 3.100 is released, it will forever eliminate the possibility of removing the final decimal point, as it won't be clear whether the sub-version is two or three digits in any given future release without looking at the ChangeLog.

If the developers are still opposed to moving beyond LAME 3.x releases, they could always switch to numbering the releases in hexadecimal. They could then release LAME 3.9A - 3.FF (while still using lowercase letters "a" and "b" for alpha/beta) before having to deprecate the 3.x series. (Yes, this is said in jest, but the sad thing is it would probably be less disruptive to software compatibility than removing the "LAME" string from the version identifier field.) I agree with those who have said that it's preferable to remove a decimal point to fit in full version numbers than to shorten the "LAME" name to "L", so I hope the developers can find a solution which satisfies their desire for version specificity while preserving software compatibility.

This post has been edited by Aleron Ives: Nov 17 2011, 08:30

[db1989]

The problem is that the LAME tag currently allows 9 bytes for the Version info. Without changing the size of this and causing more external software issues, no doubt, there has to be a compromise if the Patch Version Number is to be written. Previously, it wasn't written, so it wasn't an issue.

So, it really depends on whether people want the patch version number written into the LAME tag, or not.

And yet, two posts earlier…

Simple fix why not write:

LAME3.991

instead of L3.99r1

Keep to the LAME3.99a for point releases

Also I echo the concern about dropping the LAME branding, having encoded by: L3.99r1 is confusing.

Then use LAME3100x for 3.100 (assuming version 3 lasts forever!). Something tells me that the one-, three-, and one-digit limits for major version, minor version, and revision numbers aren’t going to be exhausted any time soon.

Really, with how simple this seems, I don’t understand the amount of discussion that has come out of it!

This post has been edited by db1989: Nov 17 2011, 11:25

[Alex B]

Everyone must keep in mind that we are speaking about a well hidden code that resides inside the LAME header. It has very little importance to the users. It does not necessarily need to be exactly identical to the actual LAME revision number. The most important thing is to keep the LAME header compatible with the existing player implementations. Thanks to LAME, gapless MP3 playback is now possible with many SW and HW players. There is no reason to make that anyhow more difficult.

However, it would not harm to use a string that indicates the actual version number if the code is 100% compatible.

In my opinion the idea to use 3.991, 3.992, etc or include additional letters like 3.99C would cause confusion and the road would dead end at 3.1000 or 3.100C. As already said, a sensible thing to do would be to proudly start a new numbering scheme from 5.0. Then the LAME developers could decide later if they want to simply use the numbers chronologically like 5.00...5.99, 6.00...6.99 and so on -- or continue releasing minor "point" versions like 5.0.1, 5.1.3, 6.2.5, etc

For comparison, the Firefox version number has quickly advanced from 3.6.xx to 8.0 in less than one year after the developers changed the numbering logic.