Mark Taylor schrieb am Sam, 30 Sep 2000:
> >
> > 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.
> >
>
> No need for lame_init_vbrtag(), since we have a flag the user
> can set already? If this flag is set, the tag is written
> directly into the mp3 bitstream. (so current code does no
> file i/o).
>
> One complication: a vbr tag and id3v2 tag! If there is also a id3v2
> tag, it will be written into the bitstream first, so
> lame_finish_vbrtag() will have to return a file offset
> where the vbr tag starts.
>
> Mark
How will the library know there is a id3v2 tag, and
why should the library know that?
I think the mp3 encoding library should do what it is
supposed to do, encode pcm samples into mp3 frames.
What the client software will add - ID3v2, WAV header, Xing header -
that should be of no interest for the *encoding library*.
Sure, we could build a tag library:
- routines to add ID3v2 tags
- routines to add WAV headers
- routines to add Xing VBR headers
This library could be of interest for some other clients too, but
in my opinion we should not mess it with LAME's encoding library.
Ciao Robert
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
