>>>>> "M" == Mark Taylor <[EMAIL PROTECTED]> writes:
M> VbrTags: The library needs functions to create VBR tags, and
M> get_audio.c needs functions to read VBR tags. So we can either
M> add VBR tag code to the front end (duplicating code that is in
M> the library), or we can expose some kind of VBR tag code in the
M> library interface.
M> Creating VBR tags has the problem that it needs to rewind the
M> file and write at the beginning. This is the only place now
M> where libmp3lame does any file I/O. But at least it does not
M> open or close the file.
OK, I think and plan to do so, too. My plan is to add 2 functions to the API,
named "lame_init_vbrtag" and "lame_finish_vbrtag".
1 int lame_init_vbrtag(int guessed_framenumber)
- for the initialization(malloc buffers and make gfp->vbrtag = 1, and so on)
- returns VBR/ID3 tag size.
- caller program (frontend) fseek the output file to make a space for
writing these tags.
2 int lame_finish_vbrtag(char *TagSpace)
- called after finishing the encoding.
- it will make a VBR/ID3 tags and copy it to *TagSpace
- caller program (frontend) fseek to the beginning of output file, and
write it.
(I wonder which shoud we use, "vbrtag" or "mp3tags")
and for the lame_get_vbrtag is also needed, but I don't know much about
mp3 input ability, so I can't make the design of this function :)
M> Also, for installation, I think 'lame' should be statically
M> linked for now.
I agree too.
M> And should lame-analysis.h really be installed by default in
M> /usr/local/include directory?
BTW, default is changed /usr/include, by Florian.
I think we should use /usr/local.
M> I was thinking we should make a 'mp3x' directory, and put all
M> the mp3 frame analysis code in there (and remove the 'lame -g' option)
agree.
M> The frame analyzer is not of general interest - it is just a
M> tool for developers.
Ummm... but some of users will be interested in the encoded file
statics.
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
