Re: [Audacity-devel] new version of libmad out

Joshua Haberman wrote:
> > The things against it include the fact that the author hasn't
> > responded to a single email in the last nine months (according to
> > frequent discussions on the id3 devel list), its use of templates
> > (which makes it currently unportable to Mac and gcc 3.0)
>
> Why are templates unportable to Mac, and even more surprising to me,
> gcc 3.0?
Actually the issue is that gcc 3.0 is probably the first compiler
to actually implement templates correctly (i.e. according to spec).
CodeWarrior has bugs in its type inference, gcc 2.9x is a little
too forgiving in its typecasting, and Microsoft's compiler has
some outright bugs in the compiler.
Simple templated classes and STL generally work across all platforms
(assuming you avoid Microsoft's STL implementation). But when you
try to have a whole hierarchy of templated classes and templated
types, it's tricky to get code that compiles on all platforms.
That's one reason wxWindows doesn't use templates at all, even
where it would make sense (for the linked list or dynamic array,
for example).
> > I like libmad - right now the only concern I have about it is
> > that it requires that one assembly language function for good
> > performance.
>
> This seems like a small issue -- is it really that hard to convert
> between assembly syntaxes? I think there are even programs that do it
> automatically!
No, it's not that hard to convert. Sometimes an instruction on
one processor doesn't really have an analog on another processor,
though. I still think libmad is great, it just means that it's
one more thing to port if we want to support a new architecture.
> > P.S. libsndfile is now 2/3 done - I hope to check it in tonight!
>
> Wonderful! How is the lib-src thing working for you?
OK, I checked in the importing code for both in-place and copy.
The prefs dialog is done for exporting, but I still have to finish
writing the exporter.
It's already faster and handles way more file types. Possibly the
most important new filetype we support now, from a political
standpoint, is Windows Media Audio. Excellent!
As for lib-src, it's great except that I haven't figured out an
elegant way for users to be able to run configure; make and get
all of the libraries. Calling a configure script from our Makefile
doesn't seem like it's always the right thing to do.
What if we forced the user to manually make all of the sublibraries?
The configure script could check to see that they're built and give
them instructions on how to build them if they're not already...
Or we could have a script called "buildsublibraries.sh" which
does the configure for them...
- Dominic

Thread view

Posted to the mad-announce list:
---
MAD version 0.14.0b is now available.
Highlights of this release include:
- a new ID3 tag manipulation library implementation
- a new dithering algorithm for (hopefully) even better sound quality
- keyboard controls for `madplay' (see the man page for details)
- a fix for `madplay' segfaults on files that are a multiple of 4K
- improved code portability, and new MSVC++ project files
- other various small code improvements
The new ID3 tag manipulation library is the most significant addition.
The library has full support for reading ID3v1, ID3v1.1, ID3v2.2,
ID3v2.3, and ID3v2.4 tags, as well as support for writing ID3v1, ID3v1.1,
and ID3v2.4 tags.
---
Does this mean ditching libid3? It would be nice to depend on one less
library, and MAD's author has proven to write very solid and dependable
code.
Joshua
--
Joshua Haberman <joshua@...>

I'd be totally happy to ditch libid3.
The things libid3 has going for it are good testcases and a very
flexible API.
The things against it include the fact that the author hasn't
responded to a single email in the last nine months (according to
frequent discussions on the id3 devel list), its use of templates
(which makes it currently unportable to Mac and gcc 3.0), its
known bugs (has trouble with WinAmp-generated ID3 tags that
have both id3v1 and id3v2 tags), and overall bloat (way more
features than you really need).
Also, 80% of the code I wrote to handle ID3 tags is salvageable
if we switch to using libmad for the ID3 tags.
I like libmad - right now the only concern I have about it is
that it requires that one assembly language function for good
performance. I'll try to test it a while and see what the
performance difference really is. I want to make sure that
Audacity works acceptably on LinuxPPC, for example, even if
nobody writes the gcc-style PPC code for that routine.
(It looks like I'll have to write CodeWarrior-style PPC
assembly for the Mac port, since I didn't see it there...)
After the id3 additions, I like the "improved code portability"
bullet-point best. :)
- Dominic
P.S. libsndfile is now 2/3 done - I hope to check it in tonight!
Joshua Haberman wrote:
>
> Posted to the mad-announce list:
>
> ---
>
> MAD version 0.14.0b is now available.
>
> Highlights of this release include:
>
> - a new ID3 tag manipulation library implementation
> - a new dithering algorithm for (hopefully) even better sound quality
> - keyboard controls for `madplay' (see the man page for details)
> - a fix for `madplay' segfaults on files that are a multiple of 4K
> - improved code portability, and new MSVC++ project files
> - other various small code improvements
>
> The new ID3 tag manipulation library is the most significant addition.
> The library has full support for reading ID3v1, ID3v1.1, ID3v2.2,
> ID3v2.3, and ID3v2.4 tags, as well as support for writing ID3v1, ID3v1.1,
> and ID3v2.4 tags.
>
> ---
>
> Does this mean ditching libid3? It would be nice to depend on one less
> library, and MAD's author has proven to write very solid and dependable
> code.
>
> Joshua
>
> --
> Joshua Haberman <joshua@...>
>
> _______________________________________________
> Audacity-devel mailing list
> Audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

* Dominic Mazzoni (dominic@...) wrote:
> I'd be totally happy to ditch libid3.
>
> The things libid3 has going for it are good testcases and a very
> flexible API.
>
> The things against it include the fact that the author hasn't
> responded to a single email in the last nine months (according to
> frequent discussions on the id3 devel list), its use of templates
> (which makes it currently unportable to Mac and gcc 3.0)
Why are templates unportable to Mac, and even more surprising to me,
gcc 3.0?
> I like libmad - right now the only concern I have about it is
> that it requires that one assembly language function for good
> performance.
This seems like a small issue -- is it really that hard to convert
between assembly syntaxes? I think there are even programs that do it
automatically!
> P.S. libsndfile is now 2/3 done - I hope to check it in tonight!
Wonderful! How is the lib-src thing working for you?
Joshua
--
Joshua Haberman <joshua@...>

Joshua Haberman wrote:
> > The things against it include the fact that the author hasn't
> > responded to a single email in the last nine months (according to
> > frequent discussions on the id3 devel list), its use of templates
> > (which makes it currently unportable to Mac and gcc 3.0)
>
> Why are templates unportable to Mac, and even more surprising to me,
> gcc 3.0?
Actually the issue is that gcc 3.0 is probably the first compiler
to actually implement templates correctly (i.e. according to spec).
CodeWarrior has bugs in its type inference, gcc 2.9x is a little
too forgiving in its typecasting, and Microsoft's compiler has
some outright bugs in the compiler.
Simple templated classes and STL generally work across all platforms
(assuming you avoid Microsoft's STL implementation). But when you
try to have a whole hierarchy of templated classes and templated
types, it's tricky to get code that compiles on all platforms.
That's one reason wxWindows doesn't use templates at all, even
where it would make sense (for the linked list or dynamic array,
for example).
> > I like libmad - right now the only concern I have about it is
> > that it requires that one assembly language function for good
> > performance.
>
> This seems like a small issue -- is it really that hard to convert
> between assembly syntaxes? I think there are even programs that do it
> automatically!
No, it's not that hard to convert. Sometimes an instruction on
one processor doesn't really have an analog on another processor,
though. I still think libmad is great, it just means that it's
one more thing to port if we want to support a new architecture.
> > P.S. libsndfile is now 2/3 done - I hope to check it in tonight!
>
> Wonderful! How is the lib-src thing working for you?
OK, I checked in the importing code for both in-place and copy.
The prefs dialog is done for exporting, but I still have to finish
writing the exporter.
It's already faster and handles way more file types. Possibly the
most important new filetype we support now, from a political
standpoint, is Windows Media Audio. Excellent!
As for lib-src, it's great except that I haven't figured out an
elegant way for users to be able to run configure; make and get
all of the libraries. Calling a configure script from our Makefile
doesn't seem like it's always the right thing to do.
What if we forced the user to manually make all of the sublibraries?
The configure script could check to see that they're built and give
them instructions on how to build them if they're not already...
Or we could have a script called "buildsublibraries.sh" which
does the configure for them...
- Dominic