Re: [MP3 ENCODER] modularization
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 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] modularization
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/ )
Re: [MP3 ENCODER] modularization
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 starts. 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*. However, the information in the Xing frame is dependant on information in the total mp3 output. Now the encoding library could provide this info easily. Why should the client have to calculate this again? 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. This is true to some extent. I think the nature of mp3 files causes problems with this. The ideal is to seperate related procedures into modules. However, mp3 files combine all this info into one file. [ ID3v2 ] + [ Xing ] + mp3 + [ ID3v1 ] Although more elegant from a modularisation perspective to seperate functions. It makes the writing of a client more complicated. We're trying to make that easy right? The ideal is to modularise the LAME librar(y|ies) completely and to let the client write four files .id3v2, .vbr, .mp3, .id3v1. However, we have no choice. It's just .mp3 unfortunately. I think wwe have to accept the loss of elegance and combine these functions. Moving Xing out of encoding library causes complications for the client, due to recalculation of the seek table. Moving ID3v2 out of the encoding library causes complications for the client, due to file copying. Just my tuppence. ID3 will be handled by the client anyway and is not part of the encoding engine, as it is completely independent from MP3. You can also tag .ogg files or .wav files. The client has to do file handling and will do so So how will that work? client writes ID3v2 client writes dummy VBR header client asks the encoding engine ---+ to encode a chunk to pcm samples| and gets back some mp3 frames | then client writesMP3 frames | -+ client adds ID3v1 client updatesVBR header The only thing the client has to do is keep track of the number of encoded frames. I don't see a problem here. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] modularization
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 expected you would get. -answer On Sat, 30 Sep 2000, Frank Klemm wrote: To compare JPEGs I use jpegcmp. JPEG files with the same image contents can differ in nearly all bytes. You need no tags or things like that. Two different implementations of the huffman encoder are really enough, also a HQ/Low Speed Switch of the same implementation is enough. May be the same is true for MP3 files. -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] modularization
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/ )
