Re: [MP3 ENCODER] 3.84beta is out, default VBR mode = old VBR mode
Hello, everyone. I just upload my Macintosh port at: http://isize.egroups.co.jp/files/lame-dev/ Thanks. -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] new common macro
on 00.6.24 0:27 AM, Iwasa Kazmi at [EMAIL PROTECTED] wrote:
lame_errorf() was added in util.c.
I intend to replace fprintf(),printf(),assert() and exit()
with these macros.
That's really what I have been needed! Thanks a lot!
I can easily replace printf() to my GUI error handle function.
For Macintosh,
int StopAlertf(char* format, ...)
{
int status;
va_listlist;
char buf[256];
va_start(list, format);
status = vsprintf(buf, format, list);
va_end(list);
c2pstr(buf);
ParamText((StringPtr)buf, 0, 0, 0);
Alert(1000, 0);
return status;
}
Or for Windoze,
int StopAlertf(char* format, ...)
{
int status;
va_listlist;
char buf[256];
va_start(list, format);
status = vsprintf(buf, format, list);
MessageBox(NULL, buf, "LAME error", MB_OK);
return status;
}
--
Osamu Shigematsu
mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Normalize audio input
Hello, all. I would like to normalize (maxmize) and trim silent part from input audio data. I'm going to add both routine into get_audio.c (I don't use libsndfile). Does anybody know how to do that or such sound libraries? TIA -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] cast problem in takehiro.c
Hello, all. In file takehiro.c, I got following errors. I think unsinged should be changed to int, or all must be casted. Error : cannot convert 'unsigned int *' to 'int *' takehiro.c line 247 return count_bit_noESC(ix, end, 1, s); Error : cannot convert 'unsigned int *' to 'int *' takehiro.c line 251 return count_bit_noESC_from2(ix, end, huf_tbl_noESC[max - 1], s); Error : cannot convert 'unsigned int *' to 'int *' takehiro.c line 257 choice = count_bit_noESC_from3(ix, end, huf_tbl_noESC[max - 1], s); Error : cannot convert 'unsigned int *' to 'int *' takehiro.c line 281 return count_bit_ESC(ix, end, choice, choice2, s); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 369 gi-table_select[2] = choose_table(ix + a2, ix + i, bits); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 383 gi-table_select[0] = choose_table(ix, ix + a1, bits); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 384 gi-table_select[1] = choose_table(ix + a1, ix + a2, bits); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 454 r0t = choose_table(ix, ix + a1, r0bits); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 462 r1t = choose_table(ix + a1, ix + a2, bits); Error : cannot convert 'int *' to 'unsigned int *' takehiro.c line 490 r2t = choose_table(ix + a2, ix + bigv, bits); -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] type mismatch error in quantize-pvt.c line 1088
Hello, Robert. on 00.5.21 8:41 PM, Robert Hegemann at [EMAIL PROTECTED] wrote: Hi, the correct fix looks like this: if (scalefac-l[sfb]0) Oh, thank you. I will replace that code. -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[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] 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/ )
[MP3 ENCODER] calulation speed between float and double
Hi, all. Recently, I found that float (32bit folating point) is faster than double (64bit) when calculating devision. More, division is extreamly slower than multiplication. 750_um.pdf Table 6-7. Floating-Point Instructions (p.272-) fadd 1-1-1fadds 1-1-1 fdiv 31 fdivs 17 fmadd 2-1-1fmadds 1-1-1 fmul 2-1-1fmuls 1-1-1 fsub 1-1-1fsubs 1-1-1 MPC7400UM_prel.pdf fadd 1-1-1fadds 1-1-1 fdiv 31 fdivs 17 fmadd 1-1-1fmadds 1-1-1 fmul 1-1-1fmuls 1-1-1 fsub 1-1-1fsubs 1-1-1 With Metroworks Codewarrior, compiler does not convert division with constants to multiplication, so we had better optimize souce code level. I think, some other C compilers may not optimize in this topic, too. And if we don't add "f" on the end of constants, it will be considered as double, and this caused speed down. float x, y, z; x = y / z / 2.0; /* bad! */ x = y * 0.5f / z; /* good */ x = y / ( z * 2.0f ); But some math libraries may not support float, i.e, negligence. #define sinf(X) (float)sin((double)X) So, without using ANSI math.h in loop heavy, float - double has large overhead, I think using double is no merit. Data size is larger than float so I wonder it may cause cache miss-hit, lower loading/saving RAM - register. And PowerPC G4's vector unit does not support double. And pow(x,y) is much slower than exp(y*log(x)) on Macintosh (with MathLib on OS 9 + G4, and G3). How does everyone think about unifing float size to 32bit? It has merit to x86, or other CPU? -- Osamu Shigematsu mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] calulation speed between float and double
on 00.1.27 6:27 AM, Stefan Bellon at [EMAIL PROTECTED] wrote:
On StrongARM I tried REAL_IS_FLOAT, REAL_IS_LONG_DOUBLE and none of
both. It didn't make any difference in the resulting encoding time.
Greetings,
On my Mac, just retype typedef doublt FLOAT8 to typedef float FLOAT8, it
became little (about 5%) slower.
I guess, the reason may be type missmatch with constans.
There is very few use of math.h functions in LAME, so I think I'm able to
write own fucntions, or replace table reffering.
On my test, sin() in MathLib with float is about 1.5 times slower than
following funtion. (Not same quality. my function is low precise.)
I have not tested with libmoto by Motorola.
FLOAT sin_F(FLOAT x)
{
const static FLOAT p = 3.14159265358979f;
const static FLOAT q = 1.0f / p;
FLOAT x2, tx, s;
int t;
t = (x * q); /* floor() is very slow */
x = x - (t * p); /* make range to -pi/2 x pi/2 */
x2 = x * x;
/* calculate sin(x) */
s = x;
x *= x2; s += x * (FLOAT)-0.17584f; /* prevent overflow +- 1.0 */
x *= x2; s += x * (FLOAT) 0.008333217685101601546200f;
x *= x2; s += x * (FLOAT)-0.000198412698412698412526317115478490f;
x *= x2; s += x * (FLOAT) 0.027557319223985892510950593270458000f;
if ( t 1 ) s = -s;
return s;
}
--
Osamu Shigematsu
mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Creating code resource for Mac
Hi, all. I got a promblem when porting L.A.M.E for Macintosh as REALbasic plugin. The problem is almost of L.A.M.E codes are abruptly quit with calling exit() function. However, I have to return error code and I am not allowed call exit() in the code resource. I know, that GPL must be opened the source, thouth, the work to rewrite all functions to return error, don't call exit() is troublesome job and to give them comments of changings are more nuisance thing for me. So, I wonder, how can I make L.A.M.E does not quit abruptly with exit(). I think I could check errors with stderr file. Or is there any port for DLLs which return an error code, never quit in the L.A.M.E.? -- Osamu Shigematsu http://www.ravi.ne.jp/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] twinvq
Hello. TwinVQ is a technology by NTT, I thought, and VQ means vector quantazation. Threrefore, YAMAHA's SoundVQ may be same as TwinVQ. Please check out following URIs. http://www.wnn.or.jp/wnn-sound/twinvq/index.html http://www.yamaha.co.jp/xg/SoundVQ/ HTH. on 99.11.25 4:05 PM, Ampex at [EMAIL PROTECTED] wrote: this is a completely mp3 listserv, but in case any of you dont know about twinvq, its another natural audio codec with better frequency response than mp3 at the same bitrate. http://www.vqf.com, http://www.vqcentral.com, and channel #vqf on the DALnet IRC network (irc.dal.net), are good places to check it out. -- Osamu Shigematsu http://www.ravi.ne.jp/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re : [MP3 ENCODER] 32K limit (was Greetings)
Hello, Lionel.
on 99.11.9 6:18 PM, Lionel Bonnet at [EMAIL PROTECTED] wrote:
The 32K limit doesn't really exists on PowerPC : in each application memory
zone, you have the stack zone and the heap zone.There is a default stack
zone(32 K)but if you want to increase it, you must change the limit of the
heap, and so the limit of the stack.
So you must insert this code at the very beginning of the application :
stkNeeded=StackNeeded();
if (stkNeeded StackSpace())
{
SetApplLimit((Ptr) ((long) GetApplLimit() - stkNeeded + StackSpace()));
}
heapSize = (long) GetApplLimit() - (long) ApplicationZone();
I know, of course, stack meaning, though, this is not such a problem, I
think. We can easily increase stack size with project settings - target -
PPC target - stack size (default 64K) in CW.
I wrote following test code, but could not compile. The line,
char chunk[64*1024L];
is smaller than 128*1024L, and there may be enough remnant of stack,
however, CW tells me "local data is larger than 32K". I do think, locak data
is not equal to stack. Local data may mean local variables in specific
funcion.
How can I break though this limit? I ask this in general macintosh
programming mailing list, people says, "There is no way. Make it global or
static."
Do I misunderstand?
TIA.
#include string.h /* for memset */
#include Types.h
#include Memory.h
#include Quickdraw.h
#include Fonts.h
#include Events.h
#include Menus.h
#include Windows.h
#include TextEdit.h
#include Dialogs.h
#include OSUtils.h
#include ToolUtils.h
#include SegLoad.h
#include Sound.h
void Initialize(void);
int main(void)
{
long stkNeeded /*, heapSize */;
Initialize();
stkNeeded = 128*1024L; /* StackNeeded(); */
if (stkNeeded StackSpace())
{
SetApplLimit((Ptr) ((long) GetApplLimit() - stkNeeded +
StackSpace()));
}
/* heapSize = (long) GetApplLimit() - (long) ApplicationZone(); */
do {
} while (!Button());
return 0;
}
void Initialize(void)
{
InitGraf(qd.thePort);
InitFonts();
InitWindows();
InitMenus();
TEInit();
InitDialogs(nil);
InitCursor();
}
void foo(void)
{
char chunk[64*1024L];
memset(chunk, 0x00, 64*1024L);
}
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Greetings
Hello, Ben. on 99.11.8 5:01 PM, "Ben \"Jacobs\"" at [EMAIL PROTECTED] wrote: 1. In C/C++ Language settings panel, try disabling "ANSI Strict". I think that will allow you to compile the //-style comments. I also solve this way, though, this is not good solution. The best way is to fix source codes are not used // style comments by auther. Otherwise, every thime when updated the code, I have to edit // to /* */. 2. To solve the problem of local data 32k in file "lame.c", I moved the large arrays outside the local function. In other words, I made them global within the file. I insert the keyword "static". I wonder if this change makes encording speed to slow or not. The files which I changed from LAME to make MacLAME 3.37 are on my website now: Thanks. I will check it later. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 32K limit (was Greetings)
Hello, Mark.
on 99.11.9 10:29 AM, Mark Taylor at [EMAIL PROTECTED] wrote:
I've got so many patches which change all the c++ comments to c style,
I finally gave in and got rid of all the //'s :-)
Thank you very much for your job!
2. To solve the problem of local data 32k in file "lame.c", I moved the
large arrays outside the local function. In other words, I made them
global within the file.
What kind of compiler would have a 32k limit for data on the stack???
The Amiga seemed to have this problem, but you could set some option
to increase the limit.
I don't know why this limit exists on PowerPC machines, though, both
Metroworks CodeWarrior and MPW (Free C/C++ Development environment by Apple)
have this limit. Known by reports on other Japanese mailing list, MPW has
critial bug obtaining large stack more than 32K. (We can compile, but it
will not work.) I don't use MPW so I don't know this is truth or not.
To solve this problem, I put "static" before large array. This is not
important, serious for me. But the codes of LAME have so may globals,
statics, and this makes hard to understanding the flow of prosess to me.
Hope to be changed to use struct (pointers).
And one more suggestion. Macintosh programmers could not use f_open()
function because Macintosh has no full path consept. Windows, or UNIX has a
path, but Macintosh has not. Hard drive name is not specified and it can be
easy changed. Of course, file name may be contain spaces.
So don't use file name to specify the file. Hope to use FILE* to specify the
input/output file. With this change, I will be able to port LAME easiler.
ie.
typedef struct input_t
{
char* file; /* file name */
FILE* fp; /* file pointer */
/* and so on... */
} input_t;
typedef struct confing_t
{
input_t* input;
output_t* output;
VBR_t* VBR;
ID3_t* ID3;
/* and so on... */
} config_t;
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Greetings
Hello, LAME developers.
This is the first time for me to post the message to this community. So
please let me allow introduce myself. My name is Osamu Shigematsu, and now
porting LAME to Macintosh. My work had done and now optimizing the code for
Macintosh.
I'm newbie, though, I uploaded both binary and compleate source code with
codewarrior pro 5 (macintosh c/c++ popular IDE from metroworks) to hope
being someone's help. I know patent problem, so I wrote an e-mail to IIS and
Thomson multimedia that I upladed the stuffs.
BTW, I wonder if why the buffer for mp3 encorder is buffer[2][1152].
So we have to copy from insamp to buffer and the order is deffernt from
both, I can not use memcpy to copy the memory block. (of course, this is
terrible waste of the time, just pass buffer pointer to the read_samples
subroutine)
Does anyone know the reason? TIA.
/* this code from get_audio.c but modified to my style */
int
get_audio( short buffer[2][1152], int stereo, layer* info )
{
int j;
short insamp[1152][2];
int samples_read;
int framesize, samples_to_read;
static unsigned long num_samples_read;
unsigned long remaining;
if ( frameNum == 0 ) {
num_samples_read = 0;
num_samples = GetSndSamples();
}
remaining = num_samples - num_samples_read;
framesize = ( info-version == 0 ) ? 576 : 1152;
samples_to_read = ( remaining framesize ) ? framesize : remaining;
if ( samples_to_read 0 )
samples_to_read = 0;
if ( input_format == sf_mp3 ) {
DebugStr( "\psf_mp3 is not supported!" ); /* call debugger to draw
string (macintosh only!!) */
}
else
{
/* MPEG 1 */
if ( stereo == 2 )
{
samples_read = read_samples( (short*)insamp, 2*framesize,
2*samples_to_read );
samples_read /= 2;
for( j = 0; j framesize; j++ )
{
buffer[0][j] = insamp[j][0];
buffer[1][j] = insamp[j][1];
}
}
else
{
if ( autoconvert != FALSE ) /* autoconvert == TRUE */
{
/* downconvert from a stereo file into a mono buffer */
samples_read = read_samples( (short*)insamp, 2*framesize,
2*samples_to_read );
samples_read /=2;
for( j = 0; j framesize; j++ )
{
/* dont overflow the short int */
buffer[0][j] = ((long)insamp[j][0] +
(long)insamp[j][1])/2;
buffer[1][j] = 0;
}
}
else
{
samples_read = read_samples( (short*)insamp, framesize,
samples_to_read );
for( j = 0; j framesize; j++ )
{
buffer[0][j] = insamp[j][0];
buffer[1][j] = 0;
}
}
}
}
/* dont count things in this case to avoid overflows */
if ( num_samples != ULONG_MAX /* MAX_U_32_NUM */ ) /* limits.h */
num_samples_read += samples_read;
return( samples_read );
}
--
Osamu Shigematsu
http://www.ravi.ne.jp/
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
