Re: [MP3 ENCODER] post-encoding mp3 amplification
Pierre Hugonnet wrote: It seems to be for DOS/WIN only... Is there something equivalent for Unix ? I don't think so though someone may be working on it. The utility mentioned, however, works fine with a little WINE. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] realtime encoding specs ?
Mark Powell wrote: FYI My PIII 583MHz (not Coppermine) provides ~1.5x normal speed. On Win98 the new VBR encodes at ~1.1x on my AMD K62-428. CBR is a bit faster. K62 is known for slow FPU so I would expect much better from the P3. I think the LAME website says P2-266 will encode CBR realtime! Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Visual Basic source code
Hi, I'd like to know if anyone knows of any implementation of the lame_enc.dll library written in Visual Basic, or if there's any Visual Basic example available. Thanks in advance, Carl ___ Are you a Techie? Get Your Free Tech Email Address Now! Many to choose from! Visit http://www.TechEmail.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Free format
Mark Taylor schrieb am Die, 26 Sep 2000: Hi all, I now have free format working in my decoder, MAD. If anyone would like to try it -- get version 0.11.4b or later: ftp://ftp.mars.org/pub/mpeg/ Thanks Rob, great! So far it seems to work with any free format bitrate I've created with LAME, all the way up to 640 kbps. Cool The real reason I'm writing, though, is I think I've discovered some problems with LAME's free format encoder. :-) First: Using --freeformat -b X --mp3input, the output bitrate is not X, but the bitrate of the input file. LAME will even generate free format VBR, which is forbidden, if the input file is VBR. Thanks! this should be fixed now. another thing that does not work: lame -b640 --freeformat -g fatboy.wav fatboy.mp3 fatal error. MAXFRAMESIZE not large enough. in mpg123.h MAXFRAMESIZE is defined as 1792, but a 32 kHz 640 kps MP3 consists of 2880 bytes per frame (2090 at 44.1 kHz, 1920 at 48 kHz). Changing this seems to trigger another BUG somewhere: LAME stops with: Only 8 and 16 bit input files supported 1792*8 = 14336 bits, 1920*8 = 15360 bits, 2090*8 = 16720 bits, more than 32767/2, reason for BUG? 2880*8 = 23040 bits, more than 32767/2, reason for BUG? I haven't looked deeper at this, I had no time yet :-(. Second: With some (usually high) bitrates, LAME seems to mangle the bitstream. The effect is usually to hear short bursts of garbage in the left channel, but it seems to depend on the input file as well as the bitrate. Not all frames are affected. Rob, can you provide us with a short example track? I'm not surprised, considering you are probably only the 3rd person to ever use freeformat :-) first is Mark, who is the second person? Mark Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] AVI Encoder
Windows 2000 allows for avi files over 2GB. I was experiencing the same problem until I switched. It doesn't support original format AVIs over 2 Gb. The problem is with the original AVI format specification which allowed a maximum size of 2 Gb. The problem is that some programmes write files larger than this size which then become non-standard and you'll have trouble playing them on ANY OS. There is a newer AVI specification called OpenDML which does allow files to be written over 2 Gb, but they must be in this format to work. The 2 Gb file size limit on AVI files is not platform-dependent. What you may be confusing this with is the 4 Gb file size limit on ANY file under FAT 32. Windows 2000 does not use FAT 32 and can store files over 4 Gb happily. But, original format AVIs over 2 Gb will not work properly on any standard player. David -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] TagItem issues...
On 25 Sep, Sigbjørn Skjæret wrote: simply making a new TagItems interface which allows you to specify the type of data the TagItem contains. This will be much better in the long run, and will allow the TagItems to contain any type of data. This sounds more complex than my proposed "void*" change. Keep in mind: More complex, but not that hard. "KISS". I'm not even gonna ask. ;) ---snip--- KISS Principle /kis' prin'si-pl/ n. "Keep It Simple, Stupid". A maxim often invoked when discussing design to fend off creeping featurism and control development complexity. Possibly related to the marketroid maxim on sales presentations, "Keep It Short and Simple". ---snip--- Bye, Alexander. -- I believe the technical term is "Oops!" http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Linux Magazine Editor's Choice Awards
Mark Taylor wrote: LAME won a "Tuxie"! I've heard that for the multimedia catagory, the awards were: 1. xmms 2. grip 3. lame 4. icecast Mark Congratulations to all lame developers (and testers) ! Pierre -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] TagItem issues...
This sounds more complex than my proposed "void*" change. Keep in mind: More complex, but not that hard. "KISS". I'm not even gonna ask. ;) "Keep It Simple, Stupid". [...] Right, well, I believe that's exactly what it is now. ;) - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] TagItem issues...
This way there is no need to parse any strings, we don't pass any pointers, the setup routine would just be a big switch/case. This is basically the way TagItems work when passed on stack, in fact, that combined with another identical function that does float we're pretty much set. Why do we need float at this point ?? Because several of the parsed arguments are floats? Well, anyway, I just finished up the following: /* Set a parameter with string-pointer */ void lame_set_string(lame_global_flags *gfp, lame_param_tag tag1, ...); /* Set a parameter with float or double value (varargs promotes floats to double) */ void lame_set_float(lame_global_flags *gfp, lame_param_tag tag1, ...); /* Set a parameter with char, short or int value (varargs promotes integrals to int) */ void lame_set_int(lame_global_flags *gfp, lame_param_tag tag1, ...); This can cater for any kind of parameter, and the functions themselves are very simple, yet can take several parameters in a row... Should I start implementing this now, or wait after 3.87 release? Mark? What needs to be changed to make a real shared library: o Exchange all direct access to lame_global_flags in parse.c with calls to lame_set_xxx(). o main.c can't hold lame_global_flags, change lame_init() to allocate and return a pointer to lame_global_flags. o Move lame_global_flags out of lame.h, it should never be accessed externally. o ..and any other changes still needed for re-entrance ofcos. - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] realtime encoding specs ?
On Tue, 26 Sep 2000, Ross Levis wrote: Mark Powell wrote: FYI My PIII 583MHz (not Coppermine) provides ~1.5x normal speed. On Win98 the new VBR encodes at ~1.1x on my AMD K62-428. CBR is a bit faster. K62 is known for slow FPU so I would expect much better from the P3. That was with the options: -V1 -b128 -mj -h under FreeBSD. It wasn't a competition I was just giving him some empirical evidence to work with :) I think the LAME website says P2-266 will encode CBR realtime! CBR is a very large topic. There a umpteen option combinations. Cheers. 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] realtime encoding specs ?
Mark Powell schrieb am Die, 26 Sep 2000: On Tue, 26 Sep 2000, Ross Levis wrote: Mark Powell wrote: FYI My PIII 583MHz (not Coppermine) provides ~1.5x normal speed. On Win98 the new VBR encodes at ~1.1x on my AMD K62-428. CBR is a bit faster. K62 is known for slow FPU so I would expect much better from the P3. That was with the options: -V1 -b128 -mj -h under FreeBSD. It wasn't a competition I was just giving him some empirical evidence to work with :) I think the LAME website says P2-266 will encode CBR realtime! CBR is a very large topic. There a umpteen option combinations. Cheers. The info on the website is about an older version of LAME. lame -h -b320 x.wav x.mp3 will result in ~1.4x often on my Pentium166 MMX (at 200 MHz) VBR is 2 to 4 times slower than CBR -V1 -b128 -mj -q1 ~0.38x -V1 -b128 -mj -h~0.46x -V1 -b128 -mj -f~0.62x or with RH_AMP defined and doing some carefully noise shaping -V1 -mj -q1 -X6 -Y -Z ~0.13x But these factors are only rough estimations, they vary a lot on different music pieces. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] TagItem issues...
Sigbjørn Skjæret schrieb am Die, 26 Sep 2000: Why do we need float at this point ?? Because several of the parsed arguments are floats? ie. frequencies could be passed in Hertz as ints, was just something to think about now while we change the API anyway Should I start implementing this now, or wait after 3.87 release? I think 3.87 is already out, CVS is tagged 3.88 alpha 1 You may get in contact with Takehiro to see what will be done next. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] on configure.in
hi I was reading the configure.in from the CVS tree to check for the presence of GTK, you may use AM_PATH_GTK(version-at-least, shell command if found , shell command if not found) as in AM_PATH_GTK(1.2.0, , echo Cannot find GTK: Is gtk-config in path? ) bye a. -- Andrea C. Mennucci, Scuola Normale Superiore, Pisa, Italy -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] problem with configure
I don't have gtk-config on my system so when configure searches for it it returns no like it should, but then it tries to run the program "no", I assume to get the version # of gtk or something. So then in the makefile HAVEGTK is defined even though I don't have it... Josh -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] TagItem issues...
Why do we need float at this point ?? Because several of the parsed arguments are floats? ie. frequencies could be passed in Hertz as ints, was just something to think about now while we change the API anyway Yes, but no reason not to have the possibility there. ;) Should I start implementing this now, or wait after 3.87 release? I think 3.87 is already out, CVS is tagged 3.88 alpha 1 Ah, yes, so I see... You may get in contact with Takehiro to see what will be done next. Takehiro, wanna drop me a line when you are finished moving stuff about? ;) - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Re: problem with configure
In the last episode (Sep 26), Joshua Bahnsen said: I don't have gtk-config on my system so when configure searches for it it returns no like it should, but then it tries to run the program "no", I assume to get the version # of gtk or something. So then in the makefile HAVEGTK is defined even though I don't have it... The correct solution would be to rip out the configure.in test and use the autoconf module provided in the gtk-1.2 package (gtk.m4). -- Dan Nelson [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] off topic: AVI Encoder
I can do that already with CDEx but that integrates the LAME compression as well so I can go straight from a PCM Wav file to an MP3 Wav file. The only slight problem comes with larger AVIs where the file size of the AVI with uncompressed data goes over 2 Gb rendering the file non-standard and, therefore, useless. Well, if you want to stay under win95/98, you can use FlaskMpeg to backup your data, as it includes a built-in mpeg-2 decoder and got an avi output plugin. It helped me a lot, as I now don't have to decompress first in a big wav before re-encoding. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Miscellaneous MP3 questions
Howdy All, I just finished adding a very basic intensity stereo implementation to our encoder, using what little the ISO spec had to say on the subject as a guide. It doesn't really improve the sound much, but I suspect that this has to do with the questions I encountered (and worked around) while coding it up. The questions: 1) M/S stereo require both channels to switch block types simultaneously - why/how doesn't intensity? (I run intensity using long only for now.) The ISO decoder takes the block type for decoding the intensity position info from the left channel, which essentially requires both channels to have the same block type, as there is no simple way to reconcile long and short scalefactor bands. So why aren't the channels required to have the same block type? 2) In layer-II coding, the first band to code using intensity is specified by the mode extension - in layer-III it can by dynamically varied and is understood implicitly from the bitstream by the decoder. But the spec gives no suggestions for algorithms on where to begin using intensity. (I used a fixed #define.) Does anyone have a reference on this? (Exhaustive search is not really an option?) 3) Right now I feed the raw (L/R) signal into the psych model, which produces SMR. The distortion thresholds are calculated using: dist_thresh(sfb) = SMR(sfb) * energy(sfb) * (1/bandwidth(sfb)) The bandwidths are constant. The energies I can take either a) from the raw L/R data, or b) from the joint processed L+R (sum) and zeroed (difference) data. Obviously, the latter makes little sense, as it will lead to distortion thresholds of zero in the right channel, causing massive overallocation of bits to that channel, which is precisely the opposite of what is intended in joint stereo. Using the former, however, causes me to either have to rewrite the entire bit/noise allocation loop to process channels in pairs (probably the right answer?) or to compare sum/difference quantization noise to L/R thresholds (my current compromise). Any thoughts? (I'm still looking for that Johnston Ferreira paper, so if it has a detailed description of the answer, I apologize now for bothering everyone again.) I've also been wondering: 4) The decoder has a reorder() function which gets called on short/mixed grains right before alias reduction/synthesis. Why is there no analogous function in the encoder? Is there some ealier step of decoding or encoding that implicitly (or explicitly, and I just haven't noticed it) 'disorders' them? 5) Where does the delay value of 768 samples come from in the Layer-III ATT psychoacoustic model (ISO dist10)? Inquiring minds wanna know, Alex PS - BTW, when I reenabled SCFSI in my encoder after retooling the bit/noise allocation loop to use best scalefactors rather than last scalefactors it suddenly began working fine; when I try to use it with the standard ISO bit/noise it causes horrible quality problems... -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] off topic: AVI Encoder
Well, if you want to stay under win95/98, you can use FlaskMpeg to backup your data, as it includes a built-in mpeg-2 decoder and got an avi output plugin. It helped me a lot, as I now don't have to decompress first in a big wav before re-encoding. The only slight problem is that the Windows bundled MP3 encoder doesn't produce audio and video sync. LAME does, but it's not available as an AVI encoder. David -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] TagItem issues...
Should I start implementing this now, or wait after 3.87 release? Hi CISC, 3.87 was released last night. It's mostly just to have a last release before the code re-orginization that Takehiro is going to do this week. That will involve splitting the C code into a frontend and library directory. So it would be good if we could hold off on all commits until this is done. What needs to be changed to make a real shared library: o Exchange all direct access to lame_global_flags in parse.c with calls to lame_set_xxx(). o main.c can't hold lame_global_flags, change lame_init() to allocate and return a pointer to lame_global_flags. o Move lame_global_flags out of lame.h, it should never be accessed externally. o ..and any other changes still needed for re-entrance ofcos. I think we have to keep the old interface, since several applications use it. So lame_global_flags will still have to be instantiated by the calling program and exposed to the calling program. I dont think this is incompatiable with a shared library? Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Miscellaneous MP3 questions
Hi Alex! 1) M/S stereo require both channels to switch block types simultaneously - why/how doesn't intensity? (I run intensity using long only for now.) The ISO decoder takes the block type for decoding the intensity position info from the left channel, which essentially requires both channels to have the same block type, as there is no simple way to reconcile long and short scalefactor bands. So why aren't the channels required to have the same block type? I think there is an implicit requirement to be of the same block type. 2) In layer-II coding, the first band to code using intensity is specified by the mode extension - in layer-III it can by dynamically varied and is understood implicitly from the bitstream by the decoder. But the spec gives no suggestions for algorithms on where to begin using intensity. (I used a fixed #define.) Does anyone have a reference on this? (Exhaustive search is not really an option?) If I understand the DOCs right, then in IS mode, starting at lower frequency bands, the last right channel scalefactor band not completely zero marks the last MS or LR coded band. All bands above are intensity stereo coded, magnitudes in left channel, position in right channel. Bands with illegal intensity position have to be MS or LR decoded. note: the zero part of the spectrum goes from bigvalues*2+count1*4 So you will have to calculate the corresponding scalefactor band. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
