LAME (Lame Aint an MP3 Encoder)

Jennifer Marsella wrote:
> hi..
> i was taking a look at your web site, because i need to downlowd a LAME, 
> of this tipe: lame_enc.dll, but i cant find it. do you have it somewhere?
> thank you
> Jennifer
> 

This is the second message of this type within on week... weird.
lame_enc.dll can be build from the source or downloaded as a 
pre-compiled binary from various places like:
http://www.jthz.com/~lame/ (compiled by Mitiok)
http://rarewares.hydrogenaudio.org/mp3.html (compiled by John33)
http://www.mp3-tech.org/encoders_win.html (compiled by Gabriel)

tobias

Ivan Farkas wrote:

> I made some modifications to the INSTALL and Makefile.MSVC files.
> This made it possible to compile using Microsoft Visual Studio 2003 (MSVC7)
> taking advantage of the Pentium 4 and AMD Athlon optimization.
> CPU=P4 switch works only for VS 2003.

Sorry, breaking compatibility with VC6 is not a good option.

> I also wrote a small Build_MSVC7.cmd file that contains this command below:
> 
> nmake -f Makefile.MSVC comp=msvc asm=no CPU=P4 /A

Do you know that you can directly ask VC to compile something in a dsw? 
It makes the makefile almost unnecessary.
Moreover, you are using P4 compiler optimisations, but not using asm 
optimisations from Lame. You will most likely end up with a slower 
binary than a simple compile using our current options but using 
assembly optimisations.


Perhaps your changes are usefull to you, but I think that this is not 
our case.

Regards,

-- 
Gabriel Bouvigne
 http://www.mp3-tech.org
personal page: http://gabriel.mp3-tech.org

On Sun, 21 Dec 2003 10:20:05 +0300
"Nic Tiger" <tiger7@...> wrote:

Please keep the lame-dev list in the CC, thanks.

> thanks for early reply!

I just came home from a christmas party and wasn't ready to go to bed...

> > What kind of changes are you talking about? We may be not interested in
> > special DOSX support, but if the changes improve the code quality in
> > general, it would be worth to include them and have DOSX support as a
> > byproduct.
> 
> It is simply MAK files and several header files to compile sources with DMC,
> along with some minor changes in code to provide successfull compilation in
> treat-warnings-as-errors mode.

Either you fixed a lot of code, or your compiler doesn't know a lot of
warnings...

> Also there is bugfix in decoder - in mpglib (I think very rare case since it
> wasn't fixed up to now).
> How can I submit it?

There are several ways. You could submit it into the bugtracker at
sf.net/projects/lame/, or you could put it on a webpage and post a link
to it to lame-dev@..., or if a diff of the changes is small you
could post it directly to the lame-dev list.

It would be best, if the diff is against the actual CVS version (the SF
project page tells you more about CVS in case you don't know how to use
it). As the CVS version doesn't differs much from the just released
3.94b, it would also be ok to use it as a base for the patches.

> > 1. Link to LAME as separate library (libmp3lame.a on unix or
> >    lame_enc.dll on windows)
> Under DOSX I could compile LAME as dll, but it would be rather inconvenient
> to use and usually slower than linking it as static library. So can I
> include it as static lib or not?

I let another developer of lame answer this question. Can we assume you
know about the patent issues
(http://lame.sourceforge.net/links.html#patents)?

Bye,
Alexander.

-- 
           I will be available to get hired in April 2004.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

On Sun, 21 Dec 2003 11:34:55 +0300
"Nic Tiger" <tiger7@...> wrote:

> > The encoding engine is already LGPLed. Only the decoding engine is
> > licensed withhin the GPL.
> 
> I've found out that mpglib is LGPLed since May 2001.
> I'll try compile it instead of mpglib bundled in LAME. Are you interested in
> updating mpglib in LAME with newest one under LGPL?

We already have the LGPLed mpglib with additional changes in a separate
CVS tree (it's called HIP). We now just need someone with enough time
willing to integrate this modified mpglib into the lame base source.

Bye,
Alexander.

-- 
           I will be available to get hired in April 2004.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

Alexander Leidinger wrote:


>>It is simply MAK files and several header files to compile sources with DMC,
>>along with some minor changes in code to provide successfull compilation in
>>treat-warnings-as-errors mode.
> 
> 
> Either you fixed a lot of code, or your compiler doesn't know a lot of
> warnings...

Well, there are not that many warnings in libmp3lame. (but much more in 
the lame.exe frontend)



>>Under DOSX I could compile LAME as dll, but it would be rather inconvenient
>>to use and usually slower than linking it as static library. So can I
>>include it as static lib or not?

Are you coming from the unix world?
Under win32, linking with a dynamic library as only a very minor 
overhead, as symbols are not resolved when loading the library, but in 
the compile time.


Regards,

-- 
Gabriel Bouvigne
 http://www.mp3-tech.org
personal page: http://gabriel.mp3-tech.org

On Sun, 21 Dec 2003 13:53:09 +0100
Gabriel Bouvigne <bouvigne@...> wrote:

> >>Under DOSX I could compile LAME as dll, but it would be rather inconvenient
> >>to use and usually slower than linking it as static library. So can I
> >>include it as static lib or not?
> 
> Are you coming from the unix world?
> Under win32, linking with a dynamic library as only a very minor 
> overhead, as symbols are not resolved when loading the library, but in 
> the compile time.

Statically linking should allow to use one more register and the address
of an access doesn't needs to get calculated as you don't have to
generate position independent code. Depending on the code this can be
measurable.

Bye,
Alexander.

-- 
           I will be available to get hired in April 2004.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

On Sun, 21 Dec 2003 18:14:05 +0300
"Nic Tiger" <tiger7@...> wrote:

> > We already have the LGPLed mpglib with additional changes in a separate
> > CVS tree (it's called HIP). We now just need someone with enough time
> > willing to integrate this modified mpglib into the lame base source.
> 
> And what is problem with integrating? I've done this in half of an hour

Time. We have to not only integrate HIP, we also have to test it.

> (well, my project uses mpglib directly, not through mpglib_interface). I
> have enough time and could help with mpglib integration. What should I do,
> and how?

Check out the CVS versions of lame and HIP, copy the necessary parts of
HIP into lame, make sure it compiles and works, make a patch available
or commit the changes yourself after getting write access to the lame
CVS. I'm willing to do the necessary automake/autoconf work if you don't
know how to do it.

Note: the GTK+ Frame Analyzer also uses mpglib, it needs to get
converted too.

Bye,
Alexander.

-- 
           I will be available to get hired in April 2004.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

Alexander Leidinger wrote:

>On Sun, 21 Dec 2003 18:14:05 +0300
>"Nic Tiger" <tiger7@...> wrote:
>
>  
>
>>>We already have the LGPLed mpglib with additional changes in a separate
>>>CVS tree (it's called HIP). We now just need someone with enough time
>>>willing to integrate this modified mpglib into the lame base source.
>>>      
>>>
>>And what is problem with integrating? I've done this in half of an hour
>>    
>>
>
>Time. We have to not only integrate HIP, we also have to test it.
>
>  
>
>Note: the GTK+ Frame Analyzer also uses mpglib, it needs to get
>converted too.
>  
>
Several changes were made to mpglib in order to make it possible for the 
library to return unclipped floating-point samples if the user of the 
library wants them instead of clipped integers. This was required for 
ReplayGain analysis and for finding the peak sample. You'd have to 
incorporate these changes too.

The changes of course can be LGPLed.

Regards,
AK

On Fri, 19 Dec 2003 14:48:36 +0100
Gabriel Bouvigne <bouvigne@...> wrote:

> >>Well, I did not thought about a 3.94 release after the beta, mainly 
> >>because we never released a release with the same version number.
> >>Do you think we should?
> > 
> > 
> > Hmmm... no.
> 
> 
> I am now thinking that it might be a good idea.
> There is a bug when using mono with low bitrate vbr modes. This should 
> be corrected, but I do not want to waste a version number just for some 
> simple issues like this one.

Why not? There are plenty of numbers out there, we don't have to be shy
using them. :-)

> On the other hand, if we wait for 3.95 to correct this one, it will 
> perhaps only be in 6 months.

Wen don't need to follow a strict 6 months schedule. We also can release
more often...

> So perhaps a 3.994 with correction for potential (and simple) issues 
> could be a good idea.

If you don't want to use 3.95, what kind of "number" do you want to use?
3.94c, 3.94b.1, ...?

Bye,
Alexander.

-- 
           I will be available to get hired in April 2004.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

Alexander Leidinger wrote:

>>There is a bug when using mono with low bitrate vbr modes. This should 
>>be corrected, but I do not want to waste a version number just for some 
>>simple issues like this one.
> 
> 
> Why not? There are plenty of numbers out there, we don't have to be shy
> using them. :-)

Because I am afraid to hit 4.0

>>On the other hand, if we wait for 3.95 to correct this one, it will 
>>perhaps only be in 6 months.
> 
> Wen don't need to follow a strict 6 months schedule. We also can release
> more often...

I'd like to, but considering the limited time that we have available...

>>So perhaps a 3.994 with correction for potential (and simple) issues 
>>could be a good idea.
> If you don't want to use 3.95, what kind of "number" do you want to use?
> 3.94c, 3.94b.1, ...?

I do not like 3.94c. I was thinking about just 3.94 release, but perhaps 
it will be even more messy to have 3.94b and 3.94.

Perhaps we could decide to use version numbers as needed, without beein 
shy, and if we hit 4.0 before Takehiro, reserve 5.x for the experimental 
version

After all, Microsoft is now in version 9


-- 
Gabriel Bouvigne
 http://www.mp3-tech.org
personal page: http://gabriel.mp3-tech.org

On Fri, 19 Dec 2003 18:55:53 +0100
Gabriel Bouvigne <bouvigne@...> wrote:

> > Why not? There are plenty of numbers out there, we don't have to be shy
> > using them. :-)
> 
> Because I am afraid to hit 4.0

It depends how you count... 3.99, 3.100, 3.101, ...

Bye,
Alexander.

-- 
           I will be available to get hired in April 2004.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

>>>Why not? There are plenty of numbers out there, we don't have to be shy
>>>using them. :-)
>>
>>Because I am afraid to hit 4.0
> 
> 
> It depends how you count... 3.99, 3.100, 3.101, ...

Are you serious?

-- 
Gabriel Bouvigne
 http://www.mp3-tech.org
personal page: http://gabriel.mp3-tech.org

On Fri, 19 Dec 2003 19:43:40 +0100
Gabriel Bouvigne <bouvigne@...> wrote:

> >>>Why not? There are plenty of numbers out there, we don't have to be shy
> >>>using them. :-)
> >>
> >>Because I am afraid to hit 4.0
> > 
> > 
> > It depends how you count... 3.99, 3.100, 3.101, ...
> 
> Are you serious?

Major version number: 3, 4, 5, ...
Minor version number: 99, 100, 101, ...

Project version: Major.Minor

It's not decimal counting, but it is counting. I think a development
version of the linux kernel did the same, but I'm not sure (I'm more
familiar with FreeBSD).

It would be ok for me if the go this route, but if you (or someone else)
don't like it: no problem.

Bye,
Alexander.

-- 
           I will be available to get hired in April 2004.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

> Major version number: 3, 4, 5, ...
> Minor version number: 99, 100, 101, ...

Well, I do not like this (without real rational arguments)

If we consider the work done since 3.0, perhaps it would be acceptable 
to go toward 4 in a few versions.

But that would mean that the drastics changes in the experimental branch 
would be likely to be in 5.


-- 
Gabriel Bouvigne
 http://www.mp3-tech.org
personal page: http://gabriel.mp3-tech.org

Hi Chaps,

Normally I don't get involved because I haven't
written code in years.  However there are plenty of
precedents for following 3.99 with 3.100, in fact
that's the way versions work
major_version.minor_version.patch (or
Release.version.revision) and it is indeed decimal
it's a system of decimal integers separated by '.'

One thing that previous examples of this have
experienced is that end users often get confused by
going from 9 to 10 in this manner, or 99 to 100 as .10
is read as 0.10 (1/10) not 10 (1*10).

One example was that HP-UX 10.9 was followed by the
glorious 10.10 (a great release)

Strictly speaking of course the release numbers are
two digit normally and 10.09 is more correct than 10.9
however as no-one ever plans on 10 minor releases it
is common to write 10.9 for 10.09.

A weakness in my argument is that 3 digit release
numbers are unusual.

Anyway I will apologise for interupting and allow you
decision makers to continue your debate.  I hope you
didn't mind.

Do carry on, it is entertaining ;-)

(Personally I'd leave 4.xx for something major even if
that's a number of smaller features reaching maturity.
 3.94b looks very good, thanks!)

Regards,
Fairy


--- Gabriel Bouvigne <bouvigne@...> wrote: >
> Major version number: 3, 4, 5, ...
> > Minor version number: 99, 100, 101, ...
> 
> Well, I do not like this (without real rational
> arguments)
> 
> If we consider the work done since 3.0, perhaps it
> would be acceptable 
> to go toward 4 in a few versions.
> 
> But that would mean that the drastics changes in the
> experimental branch 
> would be likely to be in 5.
> 
> 
> -- 
> Gabriel Bouvigne
> http://www.mp3-tech.org
> personal page: http://gabriel.mp3-tech.org
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux
> Tutorials.
> Become an expert in LINUX or just sharpen your
> skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the
> bash shell to sys admin.
> Click now!
>
http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Lame-dev mailing list
> Lame-dev@...
>
https://lists.sourceforge.net/lists/listinfo/lame-dev 

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

On Fri, 19 Dec 2003 23:11:47 +0000 (GMT)
Fairy Liquidizer <fairyliquidizer@...> wrote:

> (Personally I'd leave 4.xx for something major even if
> that's a number of smaller features reaching maturity.
>  3.94b looks very good, thanks!)

That's my rationale for my suggestion too. Takehiros work in the branch
is as far as I can judge from the commit mails a major change. Whereas
just releasing 4.0 because it seems to follow 3.99 doesn't fit the
expectations of the users. Think about the change from linux 2.4 to 2.6,
or Windows 98SE to 2000 or FreeBSD 4.x to 5.x (do we have other FreeBSD
users on this list except me?). It's a major change in the Version
number and the users expect(ed) a major change in the way the Software
works/behaves.

Bye,
Alexander.

-- 
           I will be available to get hired in April 2004.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

Alexander Leidinger wrote:

> That's my rationale for my suggestion too. Takehiros work in the branch
> is as far as I can judge from the commit mails a major change. Whereas
> just releasing 4.0 because it seems to follow 3.99 doesn't fit the
> expectations of the users. Think about the change from linux 2.4 to 2.6,
> or Windows 98SE to 2000 or FreeBSD 4.x to 5.x (do we have other FreeBSD
> users on this list except me?). It's a major change in the Version
> number and the users expect(ed) a major change in the way the Software
> works/behaves.

But if the major change was done incrementally?
I have the feeling that it is fair to say that current Lame is a major 
change compared to 3.0 four years ago.

Anyway, we still have plenty of time to choose which version numbers to use.

In the meantime, I think that I will spend a version number by using 
3.95 for now.


-- 
Gabriel Bouvigne
 http://www.mp3-tech.org
personal page: http://gabriel.mp3-tech.org