Re: [MP3 ENCODER] modularization

2000-09-30 Thread Mark Taylor
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.

Re: [MP3 ENCODER] modularization

2000-09-30 Thread Robert Hegemann
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 =

Re: [MP3 ENCODER] modularization

2000-09-30 Thread Robert Hegemann
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

Re: [MP3 ENCODER] modularization

2000-09-30 Thread Whatever
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

Re: [MP3 ENCODER] modularization

2000-09-29 Thread Mark Taylor
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.