>
> I just separated frontend from library. but many things does not work
> correctly yet (VBR histgram, etc), or even checked(many configure
> option, etc).
>
> Mark suggested that "library" code should be in the libmp3lame, but
> before moving to it, I want to everyone to check my modifications.
>
> We are at the start point of the modularized work. This is not the
> final release. Probably there are too many bugs. Probably you can't
> agree with my modularization policy.
>
> So, tell me your opinion and bug reports.
>
It passes all my test cases, so no unexpected changes to the
algorithms :-). I had some comments yesterday, but I see
a lot of them have already been fixed today.
some thoughts:
VbrTags: The library needs functions to create VBR tags, and
get_audio.c needs functions to read VBR tags. So we can either add
VBR tag code to the front end (duplicating code that is in the
library), or we can expose some kind of VBR tag code in the library
interface.
Creating VBR tags has the problem that it needs to rewind the file and
write at the beginning. This is the only place now where libmp3lame
does any file I/O. But at least it does not open or close the file.
id3tags: looks like you've fixed this already? Although
now there is a lame-id3tag.h header file in addition to
lame.h. I would be tempted to merge this into just lame.h.
Also, for installation, I think 'lame' should be statically linked for
now. And should lame-analysis.h really be installed by default in
/usr/local/include directory? I was thinking we should make a 'mp3x'
directory, and put all the mp3 frame analysis code in there (and
remove the 'lame -g' option) The frame analyzer is not of general
interest - it is just a tool for developers.
I will some time tomorrow to look around some more.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
