IPB

Welcome Guest ( Log In | Register )

16 Pages V  « < 6 7 8 9 10 > »   
Reply to this topicStart new topic
LAME 3.99 is out, 2012-02-28: version 3.99.5 has been released
kwanbis
post Nov 16 2011, 07:24
Post #176





Group: Developer (Donating)
Posts: 2362
Joined: 28-June 02
From: Argentina
Member No.: 2425



QUOTE (apodtele @ Nov 16 2011, 03:38) *
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%.


--------------------
MAREO: http://www.webearce.com.ar
Go to the top of the page
+Quote Post
spoon
post Nov 16 2011, 10:39
Post #177


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2749
Joined: 24-March 02
Member No.: 1615



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


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
john33
post Nov 16 2011, 11:17
Post #178


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



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. smile.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
spoon
post Nov 16 2011, 11:25
Post #179


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2749
Joined: 24-March 02
Member No.: 1615



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.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
DARcode
post Nov 16 2011, 11:36
Post #180





Group: Members (Donating)
Posts: 682
Joined: 10-January 05
From: Italy
Member No.: 18968



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


--------------------
WavPack 4.70.0 -b384hx6cmv/qaac 2.43 -V 100
Go to the top of the page
+Quote Post
spoon
post Nov 16 2011, 11:40
Post #181


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2749
Joined: 24-March 02
Member No.: 1615



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


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Zenitram
post Nov 16 2011, 11:42
Post #182





Group: Members
Posts: 7
Joined: 30-August 05
Member No.: 24206



QUOTE (john33 @ Nov 16 2011, 12:17) *
but knowing the patch version and, therefore, knowing if you are using the latest version must be of benefit. smile.gif

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?)


--------------------
MediaInfo: http://mediaarea.net/MediaInfo
Go to the top of the page
+Quote Post
john33
post Nov 16 2011, 12:16
Post #183


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



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.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
john33
post Nov 16 2011, 12:18
Post #184


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (Zenitram @ Nov 16 2011, 11:42) *
QUOTE (john33 @ Nov 16 2011, 12:17) *
but knowing the patch version and, therefore, knowing if you are using the latest version must be of benefit. smile.gif

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


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
RobertoDomenico
post Nov 16 2011, 13:32
Post #185





Group: Members
Posts: 87
Joined: 16-November 11
Member No.: 95208



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.
Go to the top of the page
+Quote Post
lameboy
post Nov 16 2011, 15:35
Post #186





Group: Members
Posts: 44
Joined: 3-September 08
Member No.: 57866



QUOTE (john33 @ Nov 16 2011, 13:18) *
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.





--------------------
XLD // FLAC // LAME
Go to the top of the page
+Quote Post
apodtele
post Nov 16 2011, 16:33
Post #187





Group: Members
Posts: 39
Joined: 16-November 11
Member No.: 95199



QUOTE (lameboy @ Nov 16 2011, 09:35) *
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

Go to the top of the page
+Quote Post
bilbo
post Nov 16 2011, 16:38
Post #188





Group: Members
Posts: 190
Joined: 16-April 07
Member No.: 42593



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!


--------------------
Glass half full!
Go to the top of the page
+Quote Post
john33
post Nov 16 2011, 19:05
Post #189


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (bilbo @ Nov 16 2011, 16:38) *
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. wink.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
GeSomeone
post Nov 16 2011, 20:49
Post #190





Group: Members
Posts: 922
Joined: 22-October 01
From: the Netherlands
Member No.: 335



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.


--------------------
In theory, there is no difference between theory and practice.
Go to the top of the page
+Quote Post
Alex B
post Nov 16 2011, 23:22
Post #191





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



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


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
halb27
post Nov 16 2011, 23:59
Post #192





Group: Members
Posts: 2439
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



I second Alex B's proposal.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Alex B
post Nov 17 2011, 00:05
Post #193





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



... 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.


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
lock67ca
post Nov 17 2011, 00:16
Post #194





Group: Members
Posts: 26
Joined: 24-June 05
Member No.: 22928



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

3.98.4 plays perfectly.
Go to the top of the page
+Quote Post
Alex B
post Nov 17 2011, 00:42
Post #195





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



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.


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
timcupery
post Nov 17 2011, 05:54
Post #196





Group: Members
Posts: 780
Joined: 19-December 01
From: Tar Heel country
Member No.: 683



QUOTE (spoon @ Nov 16 2011, 05:40) *
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.


--------------------
God kills a kitten every time you encode with CBR 320
Go to the top of the page
+Quote Post
RobertoDomenico
post Nov 17 2011, 07:26
Post #197





Group: Members
Posts: 87
Joined: 16-November 11
Member No.: 95208



QUOTE (lock67ca @ Nov 17 2011, 00:16) *
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
Go to the top of the page
+Quote Post
Aleron Ives
post Nov 17 2011, 08:28
Post #198





Group: Members
Posts: 190
Joined: 22-March 10
From: California
Member No.: 79208



QUOTE (timcupery @ Nov 16 2011, 20:54) *
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. laugh.gif (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
Go to the top of the page
+Quote Post
db1989
post Nov 17 2011, 11:24
Post #199





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



QUOTE (john33 @ Nov 16 2011, 11:16) *
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…

QUOTE (spoon @ Nov 16 2011, 10:40) *
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
Go to the top of the page
+Quote Post
Alex B
post Nov 17 2011, 11:29
Post #200





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



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.


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post

16 Pages V  « < 6 7 8 9 10 > » 
Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd October 2014 - 14:12