Re: [MP3 ENCODER] modularization
> client writes > client writes dummy > client asks the encoding engine <---+ > to encode a chunk to pcm samples| > and gets back some mp3 frames | > then client writes | -+ > client adds > client updates > The only thing the client has to do is keep track of the number > of encoded frames. I don't see a problem here. client needs to know mp3 header structure, CRC calculation method, and so on. That's not elegant, I think. --- Takehiro TOMINAGA // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] modularization
> > 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? Yes, that is the point. Rescaning the mp3 file and make vbr tag is a stupid idea. and, VBR tag is so popular and maybe a lot of frontend want to write it. Such a common needed function should be a part of library, I think. --- Takehiro TOMINAGA -- 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
On Sat, Sep 30, 2000 at 03:09:31PM +0200, Robert Hegemann wrote: > Mark Taylor schrieb am Sam, 30 Sep 2000: > > 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. > > strange, a simple make test resulted previously in perfect agreement, > but not anymore now: > > Encoding testcase.wav to testcase.new.mp3 > Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 LayerIII (11.0x) qval=2 > LAME version 3.88 (alpha 1)(http://www.mp3dev.org) > Using polyphase lowpass filter, transition band: 15115 Hz - 15648 Hz > Frame | CPU time/estim | REAL time/estim | play/CPU |ETA > 23/22(100%)|0:00/0:00|0:00/0:00| 0.6991x|0:00 > cmp -l testcase.new.mp3 testcase.mp3 | wc > 23 69 345 > > But the reason for this seems to be, that the old testcase > is for LAME version 3.87 alpha. So the difference is only > this text in the ancillary data section of the MP3s. > > A note to everyone who increases the version number, think > about the testcases too. > 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. $ ls -la -rw-r--r-- 1 pfk users 87488 Sep 30 17:49 origin-optimize.jpg -rw-r--r-- 1 pfk users 89582 Sep 30 17:50 origin-progressive-optimize.jpg -rw-r--r-- 1 pfk users 89582 Sep 30 17:50 origin-progressive.jpg -rw-r--r-- 1 pfk users 102270 Sep 30 17:49 origin.jpg May be the same is true for MP3 files. -- Frank Klemm -- 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 client writes dummy client asks the encoding engine <---+ to encode a chunk to pcm samples| and gets back some mp3 frames | then client writes | -+ client adds client updates 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
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 we 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. Mark Powell - UNIX System Administrator - The University of Salford Academic Information Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key -- 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
> > 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
> > > > 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". > > I don't see the point: why should the Xing-VBR stuff be part > of the encoding library? > > > Ciao Robert > The alternative is that all applications which use VBR or ABR code from the library have to write their own Xing-VBR code? Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] modularization
Mark Taylor schrieb am Sam, 30 Sep 2000: > 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. strange, a simple make test resulted previously in perfect agreement, but not anymore now: Encoding testcase.wav to testcase.new.mp3 Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 LayerIII (11.0x) qval=2 LAME version 3.88 (alpha 1)(http://www.mp3dev.org) Using polyphase lowpass filter, transition band: 15115 Hz - 15648 Hz Frame | CPU time/estim | REAL time/estim | play/CPU |ETA 23/22(100%)|0:00/0:00|0:00/0:00| 0.6991x|0:00 cmp -l testcase.new.mp3 testcase.mp3 | wc 23 69 345 But the reason for this seems to be, that the old testcase is for LAME version 3.87 alpha. So the difference is only this text in the ancillary data section of the MP3s. A note to everyone who increases the version number, think about the testcases too. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] modularization
Takehiro Tominaga schrieb am Sam, 30 Sep 2000: > > "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". I don't see the point: why should the Xing-VBR stuff be part of the encoding library? Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] modularization
> "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/ )
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/ )
