[MP3 ENCODER] Macintosh LAME port (based on 3.61 and CocaCoder)
Hello, all. Now I introduce my new Macintosh LAME. It has GUI and users can encode from AIFF, WAVE, and CD audio with easy operation. You can download it at; http://www.ravi.ne.jp/fujibiz/lib/LAME_0127_1715.hqx Pls note, this is eary beta version, so please do not let the end users know this URL. That file is only binary compressed with StuffIt 5.x, not source. I also send a CD ripper code to the auther of Mac BladeEnc. Hope MP3 becomes more popular and easy to use. Thanks. -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MPEG 2 scalefactor table bug
Date: Wed, 26 Jan 2000 12:30:22 +0100
From: "Lionel Bonnet" [EMAIL PROTECTED]
I think there is a bug in scale_bitcount_lsf :
for ( over = 0, partition = 0; partition 4; partition++ )
{
if ( max_sfac[partition] max_sfac_tab[table_number][partition] )
over++;
}
max_sfac_tab gives the length in bits of the maximum scale factor
value(according to ISO13818-3, 2.4.3.2, p.17-18) :
wow, I think this bug was substantially limiting the possible
scalefactors for MPEG2!! I applied your fix and committed the
changes to CVS.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME: does the encoding code support distribut
On 27-Jan-2000 Mark Taylor wrote: Mike also claimed he was interested in parallel encoding, but I assume the real application is seamless splices of 30s mp3s created by the FhG demo encoder :-) Dammit you saw through my plan :). But the extension to parallel coding was a legitimate hack. I concluded this was impossible in general, because of the bitreservoir. (see below). But that was before VBR! The difficulty in getting reservoirs aligned etc just was a pain in the butt. I've switched to using mp2 (toolame) to do my editing/splicing. (working on a simple way of editing 8hour mp2 files at the moment) later mike -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] NOPOW define added in CVS...
I just committed a NOPOW define to CVS which when enabled will replace certain pow() combinations with optimized variants .. this gives an average of 20% speedincrease on my machines (68k PPC), might be more or less on yours, try it out... ;) It made no difference on my pentium II. Ok, it seems 68k (040/060) benefits the most from this, because it doesn't have exp/log functions in the FPU, and has to emulate them... - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] NOPOW define added in CVS...
S I just committed a NOPOW define to CVS which when enabled will S replace certain pow() combinations with optimized variants .. S this gives an average of 20% speedincrease on my machines (68k S PPC), might be more or less on yours, try it out... ;) Why don't you use table :) all pow(2.0, global_gain*0.25) and pow(2.0, -global_gain*0.1875) could be rewrite table lookup. Yes, that's probably alot more sensible... ;) - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] NOPOW define added in CVS...
on 00.1.28 4:00 AM, Sigbj?rn Skj?ret at [EMAIL PROTECTED] wrote: Ok, it seems 68k (040/060) benefits the most from this, because it doesn't have exp/log functions in the FPU, and has to emulate them... AltiVec has exp/log, but no pow. Using Vector Unit is much faster than looking up table. Just guess. No test. -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
