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.
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 =
Mark Powell schrieb am Sam, 30 Sep 2000:
On Sat, 30 Sep 2000, Robert Hegemann wrote:
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
I'm not sure, but i think the test cases are to make sure that the
version you compiled on your box produces the same output as the
one's the developers were working with. it's a guard against different
compiler options making you a binary that produces different data than
what the developers
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.