lame-dev

[Lame-dev] 3.97 beta

[Gabriel B. <bou...@mp...>]

I am planning to update 3.97 to beta status, once I will have checked to 
python tests.

Any objection/suggestion?


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

[Lame-dev] 3.97 beta

[Gabriel B. <bou...@mp...>]

I think that we could release 3.97b around september 10th.

What need to be done:
*update version.h and versions in the docs
*regenerate configure stuff
*generate and commit testcase
*make dist, test
*tag
*sourceforge stuff

Once it is released, I'd like to create a 3.97 branch for potential 
fixes and 3.97 release, while we can enter in 3.98 alpha stage on the 
main branch.

Bye,

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

Re: [Lame-dev] 3.97 beta

[Alexander L. <Alexander@Leidinger.net>]

On Thu, 01 Sep 2005 20:00:51 +0200
Gabriel Bouvigne <bou...@mp...> wrote:

> *regenerate configure stuff

Can someone test the recent commits on non-FreeBSD platforms please?

Bye,
Alexander.

-- 
            Give a man a fish and you feed him for a day;
     teach him to use the Net and he won't bother you for weeks.

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

Re: [Lame-dev] 3.97 beta

[B. <rb...@im...>]

On Sep 04 2005, Alexander Leidinger wrote:
> On Thu, 01 Sep 2005 20:00:51 +0200
> Gabriel Bouvigne <bou...@mp...> wrote:
>=20
> > *regenerate configure stuff
>=20
> Can someone test the recent commits on non-FreeBSD platforms please?

On my Debian testing system, with GCC 4, it seems to work, but using
--enable-expopt=3Dfull generates this warning:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(...)
checking for nasm... /usr/bin/nasm
checking for assembler routines for this processor type... yes
checking for additional optimizations... configure: WARNING: LAME doesn't=
 know about your version of gcc
full
(...)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Well, at least it doesn't make the compile bomb as it did before. :-)

I will check how it works later, after the compilation is done.


Thanks, Rog=E9rio.

--=20
Rog=E9rio Brito : rb...@im... : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

Re: [Lame-dev] 3.97 beta

[B. <rb...@im...>]

On Jul 26 2005, Gabriel Bouvigne wrote:
> I am planning to update 3.97 to beta status, once I will have
> checked to python tests.

Ok. I will update the debian packaging then. I will possibly include
Christian Marillat's modifications to our packaging.

If anything else needs to be fixed, please let me know. I'm checking
out a copy of lame's CVS version right now (Hummm, I think that I've
been spoiled by svn now).


Thanks for any comments, Rog=E9rio.

--=20
Rog=E9rio Brito : rb...@im... : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

Re: [Lame-dev] 3.97 beta

[Alexander L. <Alexander@Leidinger.net>]

Gabriel Bouvigne <bou...@mp...> wrote:

> I am planning to update 3.97 to beta status, once I will have checked 
> to python tests.
>
> Any objection/suggestion?

For 3.96 some people noticed some configure problems. For this reason we
should make sure we use the latest autotools. I don't know how much time I
have at the weekend to look at it. I think Takehiro updated the files, but
I'm not sure about it.

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
BOFH excuse #213:

Change your language to Finnish

Re: [Lame-dev] 3.97 beta

[<rja...@ya...>]

--- Alexander Leidinger <Alexander@Leidinger.net> escreveu:

> Gabriel Bouvigne <bou...@mp...> wrote:
> 
> > I am planning to update 3.97 to beta status, once I will have checked
> > to python tests.
> > Any objection/suggestion?
> 
> For 3.96 some people noticed some configure problems. For this reason
> we should make sure we use the latest autotools. I don't know how much
> time I have at the weekend to look at it. I think Takehiro updated 
> the files, but I'm not sure about it.

I managed to compile 3.96.1 on all esoteric platforms I have
access to (http://www.rarewares.org/mp3.html) with the exception of 
Tru64 unix. If there's any interest, I can report the compile errors
I get with Tru64 once I return home, next monday.

I also plan to test current 3.97 code in these platforms next week.

Regards;

Roberto.

__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger 
http://br.download.yahoo.com/messenger/ 

Re: [Lame-dev] 3.97 beta

[<rja...@ya...>]

--- Roberto José de Amorim <rja...@ya...> escreveu:
> I managed to compile 3.96.1 on all esoteric platforms I have
> access to (http://www.rarewares.org/mp3.html) with the exception of 
> Tru64 unix. If there's any interest, I can report the compile errors
> I get with Tru64 once I return home, next monday.
> 
> I also plan to test current 3.97 code in these platforms next week.

As it turns out, I came home earlier than I expected, and tested 
the current CVS on several platforms already:

Solaris v9 SPARC and x86: no problems
FreeBSD 4.8 and 5.4, OpenBSD 3.4, NetBSD 1.6.1 and 2.0: no problems


MacOS X 10.3: error

brhist.c:65: header file 'term.h' not found


HP Tru64 Unix 5.1: error

source='brhist.c' object='brhist.o' libtool=no  depfile='.deps/brhist.Po'
tmpdepfile='.deps/brhist.TPo'  depmode=tru64 /bin/ksh ../depcomp  cc
-DHAVE_CONFIG_H  -I. -I. -I.. -I../libmp3lame -I../include -I..      -c
`test -f 'brhist.c' || echo './'`brhist.c
cc: Error: brhist.c, line 425: Missing ";". (nosemi)
    int     i, lines = 0;
---------------^
cc: Error: brhist.c, line 452: In this statement, "cur_nums" has a signed
int type, but occurs in a context that requires a pointer. (needpointer)
            ++lines;
--------------^
cc: Error: brhist.c, line 458: In this statement, "cur_nums" has a signed
int type, but occurs in a context that requires a pointer. (needpointer)
        show = show && (lines > 1);


HP-UX 11 v2: errors:

        source='brhist.c' object='brhist.o' libtool=no \
        depfile='.deps/brhist.Po' tmpdepfile='.deps/brhist.TPo' \
        depmode=hp /bin/sh ../depcomp \
        cc -DHAVE_CONFIG_H  -I. -I. -I.. -I../libmp3lame -I../include
-I..     -I/opt/gnome/include/gtk-1.2 -I/opt/gnome/include/glib-1.2
-I/opt/gnome/lib/glib/include  -c `test -f 'brhist.c' || echo
'./'`brhist.c
cc: "brhist.c", line 176: warning 611: Type conversion loses "const"
qualifier.
cc: "brhist.c", line 176: warning 563: Argument #2 is not the correct
type.
cc: "brhist.c", line 425: error 1000: Unexpected symbol: "->".
cc: "brhist.c", line 446: error 1588: "i" undefined.
cc: "brhist.c", line 446: error 1566: Test expression in for must be
scalar.
cc: "brhist.c", line 446: error 1560: Modifiable lvalue required with
operator "++".
cc: "brhist.c", line 447: error 1603: Incompatible operands: assign
operator.
cc: "brhist.c", line 448: error 1603: Incompatible operands: assign
operator.
cc: "brhist.c", line 449: error 1563: Expression in if must be scalar.
cc: "brhist.c", line 451: error 1563: Expression in if must be scalar.
cc: "brhist.c", line 455: error 1566: Test expression in for must be
scalar.
cc: "brhist.c", line 455: error 1560: Modifiable lvalue required with
operator "++".
cc: "brhist.c", line 460: error 1563: Expression in if must be scalar.
cc: "brhist.c", line 461: warning 563: Argument #2 is not the correct
type.
cc: "brhist.c", line 461: warning 563: Argument #3 is not the correct
type.
cc: "brhist.c", line 461: warning 563: Argument #4 is not the correct
type.
cc: "brhist.c", line 464: error 1566: Test expression in for must be
scalar.
cc: "brhist.c", line 464: error 1560: Modifiable lvalue required with
operator "++".
cc: "brhist.c", line 465: error 1603: Incompatible operands: assign
operator.


It's worth mentioning the Tru64 compiler is Compaq C V6.5, and not GCC.
Likewise, HP-UX is using HP C compiler.


Hope that helps. It seems to me brhist.c is the culprit.

Best regards;

Roberto.

__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger 
http://br.download.yahoo.com/messenger/ 

Re: [Lame-dev] 3.97 beta

[Alexander L. <Alexander@Leidinger.net>]

Roberto Jos=E9 de Amorim <rja...@ya...> wrote:

> MacOS X 10.3: error
>
> brhist.c:65: header file 'term.h' not found

Ia ssume "gcc" and "configure" here: I try to get time at the weekend for
this problem. Is there a term*.h somewhere?

> HP Tru64 Unix 5.1: error
[...]
> HP-UX 11 v2: errors:
[...]
> It's worth mentioning the Tru64 compiler is Compaq C V6.5, and not GCC.
> Likewise, HP-UX is using HP C compiler.

Either those C compiler are more strict than our source is able to comply t=
o,
or they don't support newer C standards... I don't know if we're able to co=
me
up with a solution for those cases. And I don't know if such a solution is
needed, how fast is lame on those boxes?

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID =3D 72077137
If God had meant for us to be in the Army, we would have been born with
green, baggy skin.

Re: [Lame-dev] 3.97 beta

[<rja...@ya...>]

--- Alexander Leidinger <Alexander@Leidinger.net> escreveu:

> Roberto José de Amorim <rja...@ya...> wrote:
> 
> > MacOS X 10.3: error
> >
> > brhist.c:65: header file 'term.h' not found
> 
> Ia ssume "gcc" and "configure" here: I try to get time at the weekend
> for this problem. Is there a term*.h somewhere?

Ops. Sorry about that. I was using a MacOS host that only had 2.x series
gcc. I tried to compile on a host with gcc 3.3, and lame came out
without problems.

> > HP Tru64 Unix 5.1: error
> [...]
> > HP-UX 11 v2: errors:
> [...]
> > It's worth mentioning the Tru64 compiler is Compaq C V6.5, and not
> GCC.
> > Likewise, HP-UX is using HP C compiler.
> 
> Either those C compiler are more strict than our source is able to
> comply to,
> or they don't support newer C standards... I don't know if we're able
> to come
> up with a solution for those cases. And I don't know if such a solution
> is needed, how fast is lame on those boxes?

Painfully slow, like in any non-x86 platform.

I don't know if their C compilers are non-compliant or too strict.
But it's worth mentioning they compile libmp3lame and mpglib without
any problem. That's why I was inclined to believe the error was in 
brhist.c

Regards;

Roberto.

__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger 
http://br.download.yahoo.com/messenger/ 

Re: [Lame-dev] 3.97 beta

[<rja...@ya...>]

> > > HP Tru64 Unix 5.1: error
> > [...]
> > > HP-UX 11 v2: errors:
> > [...]
> > > It's worth mentioning the Tru64 compiler is Compaq C V6.5, and not
> > GCC.
> > > Likewise, HP-UX is using HP C compiler.
> > 
> > Either those C compiler are more strict than our source is able to
> > comply to,
> > or they don't support newer C standards... I don't know if we're able
> > to come
> > up with a solution for those cases. And I don't know if such a
> solution
> > is needed, how fast is lame on those boxes?
> 
> Painfully slow, like in any non-x86 platform.
> 
> I don't know if their C compilers are non-compliant or too strict.
> But it's worth mentioning they compile libmp3lame and mpglib without
> any problem. That's why I was inclined to believe the error was in 
> brhist.c

BTW, another comment:

On Tru64 unix, GCC 3.3 also breaks. The error is:

Making all in frontend
if gcc -DHAVE_CONFIG_H  -I. -I. -I.. -I../libmp3lame -I../include -I..   
 -O3  -ffast-math                     -funroll-loops -Wall    -MT
brhist.o -MD -MP -MF ".deps/brhist.Tpo"  -c -o brhist.o `test -f
'brhist.c' || echo './'`brhist.c;  then mv -f ".deps/brhist.Tpo"
".deps/brhist.Po";  else rm -f ".deps/brhist.Tpo"; exit 1;  fi
brhist.c: In function `brhist_disp':
brhist.c:425: error: parse error before '->' token
brhist.c:452: error: invalid type argument of `->'
brhist.c:458: error: invalid type argument of `->'
*** Exit 1

As usual, brhist.c is the culprit :(

On HP-UX, gcc 3.4.2 compiles LAME fine.

Hope that helps...

Regards;

Roberto.


	
	
		
_______________________________________________________ 
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/

Re: [Lame-dev] 3.97 beta

[Robert H. <Rob...@gm...>]

Am Samstag, 30. Juli 2005 17:19 schrieb Roberto Jos=E9 de Amorim:
> > I don't know if their C compilers are non-compliant or too strict.
> > But it's worth mentioning they compile libmp3lame and mpglib without
> > any problem. That's why I was inclined to believe the error was in
> > brhist.c
>
> BTW, another comment:
>
> On Tru64 unix, GCC 3.3 also breaks. The error is:
>
> Making all in frontend
> if gcc -DHAVE_CONFIG_H  -I. -I. -I.. -I../libmp3lame -I../include -I..
>  -O3  -ffast-math                     -funroll-loops -Wall    -MT
> brhist.o -MD -MP -MF ".deps/brhist.Tpo"  -c -o brhist.o `test -f
> 'brhist.c' || echo './'`brhist.c;  then mv -f ".deps/brhist.Tpo"
> ".deps/brhist.Po";  else rm -f ".deps/brhist.Tpo"; exit 1;  fi
> brhist.c: In function `brhist_disp':
> brhist.c:425: error: parse error before '->' token
> brhist.c:452: error: invalid type argument of `->'
> brhist.c:458: error: invalid type argument of `->'
> *** Exit 1
>
> As usual, brhist.c is the culprit :(
>
> On HP-UX, gcc 3.4.2 compiles LAME fine.

hmm, seems to make no sense:=20
there is no "->" pointer dereferencing in line 425
422 #void
423 #brhist_disp(const lame_global_flags * gf)
424 #{
425 #    int     i, lines =3D 0;

it seems there is some preprocessor definition for lines declared in
some header file we include.

"#undef lines" after the includes section could help here.


Ciao Robert

Re: [Lame-dev] 3.97 beta

[Robert H. <Rob...@gm...>]

Am Samstag, 30. Juli 2005 17:04 schrieb Roberto Jos=E9 de Amorim:
> --- Alexander Leidinger <Alexander@Leidinger.net> escreveu:
> > Roberto Jos=E9 de Amorim <rja...@ya...> wrote:
> > > MacOS X 10.3: error
> > >
> > > brhist.c:65: header file 'term.h' not found

to sum it up:
=2D the system has no "ncurses" library installed, or configure did not fin=
d it
=2D the system has no "termcap" library installed, or configure did not fin=
d it
=2D the system has no "term.h", "HAVE_TERMCAP" is defined even though
it seems to be not case here


Ciao Robert

Re: [Lame-dev] 3.97 beta

[Alexander L. <Alexander@Leidinger.net>]

On Sat, 30 Jul 2005 18:12:00 +0200
Robert Hegemann <Rob...@gm...> wrote:

> Am Samstag, 30. Juli 2005 17:04 schrieb Roberto Jos=C3=A9 de Amorim:
> > --- Alexander Leidinger <Alexander@Leidinger.net> escreveu:
> > > Roberto Jos=C3=A9 de Amorim <rja...@ya...> wrote:
> > > > MacOS X 10.3: error
> > > >
> > > > brhist.c:65: header file 'term.h' not found
>=20
> to sum it up:
> - the system has no "ncurses" library installed, or configure did not f=
ind it
> - the system has no "termcap" library installed, or configure did not f=
ind it
> - the system has no "term.h", "HAVE_TERMCAP" is defined even though
> it seems to be not case here

Here are the checks which decide if HAVE_TERMCAP is set or not:
---snip---
AC_CHECK_LIB(termcap, initscr, HAVE_TERMCAP=3D"termcap")
AC_CHECK_LIB(curses, initscr, HAVE_TERMCAP=3D"curses")
AC_CHECK_LIB(ncurses, initscr, HAVE_TERMCAP=3D"ncurses")
---snip---

So one of those libs must be present. Now the question is: what's the
right header to include here?

Bye,
Alexander.

--=20
            The dark ages were caused by the Y1K problem.

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

Re: [Lame-dev] 3.97 beta

[B. <rb...@im...>]

On Jul 27 2005, Alexander Leidinger wrote:
> Gabriel Bouvigne <bou...@mp...> wrote:
> >I am planning to update 3.97 to beta status, once I will have checked=20
> >to python tests.
> >
> >Any objection/suggestion?
>=20
> For 3.96 some people noticed some configure problems. For this reason w=
e
> should make sure we use the latest autotools.

I didn't have any problems with configure on my system (Debian,
testing), but trying to use GCC 4.0.1 and the optimization options
passed to configure makes the compile bomb, at least due to the
following two options:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
cc1: error: unrecognized command line option "-fmove-all-movables"
cc1: error: unrecognized command line option "-freduce-all-givs"
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I guess that another case could be included in the auto* things?


Hope this helps, Rog=E9rio.

--=20
Rog=E9rio Brito : rb...@im... : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

Re: [Lame-dev] 3.97 beta

[B. <rb...@im...>]

On Jul 27 2005, Rog=E9rio Brito wrote:
> I didn't have any problems with configure on my system (Debian,
> testing), but trying to use GCC 4.0.1 and the optimization options
> passed to configure makes the compile bomb, at least due to the
> following two options:
>=20
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> cc1: error: unrecognized command line option "-fmove-all-movables"
> cc1: error: unrecognized command line option "-freduce-all-givs"
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

These were a problem if I used --enable-expopt=3Dfull, but not with
norm.

Anyway, compiling with GCC 4, I get a fair amount of warnings (mostly
talking about signed vs unsigned comparisons, but also some others).

Are patches for such janitorial things wanted?

In the mean time, I will try to slowly improve the debian packaging.


Thanks for any feedback, Rog=E9rio.

--=20
Rog=E9rio Brito : rb...@im... : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

Re: [Lame-dev] 3.97 beta

[B. <rb...@im...>]

On Jul 27 2005, Rog=E9rio Brito wrote:
> Are patches for such janitorial things wanted?

Talking about janitorial things, I see that the documentation could
use a little facelift here and there.

What is the preferred documentation format? Should we adopt something
neutral from which to generate the HTML pages, manpages etc?

I see that there is some duplicate parts there (and the manpage didn't
even talk about the "medium" preset) and having it just automatically
generated would be a plus, I think.

I still have this weekend for spare projects before I get back from
vacations. I would sincerely love to improve things as much as I can
in this little time that remains.


Thanks for any feedback, Rog=E9rio.

--=20
Rog=E9rio Brito : rb...@im... : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

Re: [Lame-dev] 3.97 beta

[Gabriel B. <bou...@mp...>]

Rog=E9rio Brito a =E9crit :
> Talking about janitorial things, I see that the documentation could
> use a little facelift here and there.
>=20
> What is the preferred documentation format? Should we adopt something
> neutral from which to generate the HTML pages, manpages etc?
>=20
> I see that there is some duplicate parts there (and the manpage didn't
> even talk about the "medium" preset) and having it just automatically
> generated would be a plus, I think.

I agree that a generated documentation (at least for the basic and full=20
options list) from a single source would be a great thing, as man pages=20
and html are constantly out of synchronisation. Maybe such a generator=20
already exists?

Regarding docs, the current one needs to be updated.

For the configuration/build scripts, there is no need to hurry. We can=20
choose to wait a little before releasing 3.97 beta1. I'd prefer waiting=20
a little more than rushing to release and discover 1 week later that=20
some scripts need to be updated.

Regards,

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

Re: [Lame-dev] 3.97 beta

[Takehiro T. <tak...@in...>]

From: Gabriel Bouvigne <bou...@mp...>
Subject: Re: [Lame-dev] 3.97 beta
Date: Thu, 28 Jul 2005 10:35:56 +0200

> Regarding docs, the current one needs to be updated.

Agree. The bug tracker in sf.net says we have following documentation bugs.

1158305 --unsigned option is not described in the manpage
1158303 --signed option is not described in the manpage
1158301 --big-endian option is not described in the manpage
1158300 --little-endian option is not described in the manpage
1158253 Data format is not described in the manpage
1158196 Man page ambiguous about bit width
1158193 Man page doesn't tell about stereo format in raw
1158189 Man page doesn' tell about endianity
1143595 extralibs-dev-VERSION.zip not found in gtk site

They are small, but really bugs. I think we should at least remove the
outdated and wrong documents before the 3.97release.
-- 
Takehiro TOMINAGA // may the source be with you!

Re: [Lame-dev] 3.97 beta

[Gabriel B. <bou...@mp...>]

Takehiro Tominaga a =E9crit :

> Agree. The bug tracker in sf.net says we have following documentation b=
ugs.
...

It is perhaps time to do a review pass over the bug tracker...

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

Re: [Lame-dev] 3.97 beta

[Takehiro T. <tak...@in...>]

Hi,

From: Gabriel Bouvigne <bou...@mp...>
Subject: Re: [Lame-dev] 3.97 beta
Date: Wed, 03 Aug 2005 22:14:01 +0200

> > Agree. The bug tracker in sf.net says we have following documentation bugs.
> ...
> 
> It is perhaps time to do a review pass over the bug tracker...

Agree.

I think #1177076 is one of show stoppers, but I wonder this one is
still valid.

http://sourceforge.net/tracker/index.php?func=detail&aid=1177076&group_id=290&atid=100290

Is there any MS-windows user to test this bug report ?

And, there're many, many many reports about ACM.
What should we do with ACM ? Is there someone willing to check the report
and able to fix the bug ? If not, should we remove the ACM support ?
-- 
Takehiro TOMINAGA // may the source be with you!

Re: [Lame-dev] 3.97 beta

[Gabriel B. <bou...@mp...>]

Takehiro Tominaga a =E9crit :

> I think #1177076 is one of show stoppers, but I wonder this one is
> still valid.
>=20
> http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1177076&gr=
oup_id=3D290&atid=3D100290

I do not have internet access now, but I am guessing you are talking=20
about the one regarding msvc7/net and nasm.
Since msvc7, the project/workspace format changed. It is supposed to=20
import old ones, but practically it fails with the nasm configuration.

I should create new correct vc7 files to solve this (but I do not have=20
vc7 at home).
Anyhow, I do not think this should be a stopper for a beta.
We can still eventually have a 3.97beta, with a 3.97 release 1 month=20
latter that would include those additionnal project files.


> And, there're many, many many reports about ACM.
> What should we do with ACM ? Is there someone willing to check the repo=
rt
> and able to fix the bug ? If not, should we remove the ACM support ?

We effectively have a support problem with the ACM. It works in many=20
cases, so I think that we should not remove it. However, there are also=20
many reported cases of failure that would need to be solved.
Honestly, I am not really experienced in ACM, and this is not really my=20
cup of tea.
Perhaps we should make a call on the mailing lists for someone willing=20
to help on this part?

Regards,

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

Re: [Lame-dev] 3.97 beta

[Robert H. <Rob...@we...>]

Hi Gaby,

here a quote from the original bug report:

[quote]

The following error occurs compiling source
running "nmake -f makefile.msvc cpu=p3 comp=ms"

libmp3lame\encoder.c<405> : error
c2065: 'PSY_NSPSYTUNE' : CONSTANT NOT SET

libmp3lame\encoder.c<470> : error
c2065: 'PSY_GPSYCHO' : CONSTANT NOT SET


note:
my compiler is Microsoft Visual C++ .NET and the
version of NASMW is 0.98.39

THANKS for your help

[/quote]

There is no problem with project files, he does not use them.
Looking at the line number where the problem occurs, it
seems to be some older snapshot from maybe January.
But, as someone else already reported, LAME does compile
with VC.NET and with Visual Studio 8 beta 2 too (tried it
myself).

Talking about ACM. Could it be a problem that we only have
encoding and no decoding abilities in our ACM?? Does
replaygain calculation work without decoding support?


Ciao Robert



----- Original Message -----
From: "Gabriel Bouvigne" <bou...@mp...>
To: "Takehiro Tominaga" <tak...@in...>
Cc: <lam...@li...>
Sent: Saturday, August 13, 2005 3:59 PM
Subject: Re: [Lame-dev] 3.97 beta


Takehiro Tominaga a écrit :

> I think #1177076 is one of show stoppers, but I wonder this one is
> still valid.
>
>
http://sourceforge.net/tracker/index.php?func=detail&aid=1177076&group_id=29
0&atid=100290

I do not have internet access now, but I am guessing you are talking
about the one regarding msvc7/net and nasm.
Since msvc7, the project/workspace format changed. It is supposed to
import old ones, but practically it fails with the nasm configuration.

I should create new correct vc7 files to solve this (but I do not have
vc7 at home).
Anyhow, I do not think this should be a stopper for a beta.
We can still eventually have a 3.97beta, with a 3.97 release 1 month
latter that would include those additionnal project files.


> And, there're many, many many reports about ACM.
> What should we do with ACM ? Is there someone willing to check the report
> and able to fix the bug ? If not, should we remove the ACM support ?

We effectively have a support problem with the ACM. It works in many
cases, so I think that we should not remove it. However, there are also
many reported cases of failure that would need to be solved.
Honestly, I am not really experienced in ACM, and this is not really my
cup of tea.
Perhaps we should make a call on the mailing lists for someone willing
to help on this part?

Regards,

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



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Lame-dev mailing list
Lam...@li...
https://lists.sourceforge.net/lists/listinfo/lame-dev

Re: [Lame-dev] 3.97 beta

[<rja...@ya...>]

--- Gabriel Bouvigne <bou...@mp...> escreveu:
> Perhaps we should make a call on the mailing lists for someone willing 
> to help on this part?

Maybe we can ask Steve Lhomme (robUx4) to take a look at it? He 
created the ACM codec in the first place, IIRC.


	
	
		
_______________________________________________________ 
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/

Re: [Lame-dev] 3.97 beta

[B. <rb...@im...>]

On Aug 13 2005, Gabriel Bouvigne wrote:
> We can still eventually have a 3.97beta, with a 3.97 release 1 month
> latter that would include those additionnal project files.

Well, I am not exactly sure what are the usual practices of releasing lam=
e,
but what exactly are the currently "blocker" problems?

I'm also asking this because I would like to encode some files and if any
pending fixes would affect the=20

Anyway, back to the MS environment, while I have no experience/possibilit=
y
of using Microsoft's compiler, I can try to build lame (with Dev-C++) und=
er
wine to see potential problems.

BTW, GCC 4 is now the current compiler on Debian/testing and I could try
compiling it with -Werror so that some warnings could be eliminated.

BTW #2, with GCC 4, one cannot specify --expopt=3Dfull (while it could be
used with GCC 3.x).


Regards,

--=20
Rog=E9rio Brito : rb...@im... : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/