Re: [MP3 ENCODER] Please Vote: Interface types

2000-09-28 Thread Whatever
On Wed, 27 Sep 2000, Frank Klemm wrote: +--X8X8---+ | [_] I do not vote| | [_] pointer to a public structure| | [_] private struct | | [X] pointer to a private struct | | [_] lame handle

Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Robert Hegemann
Mark Powell schrieb am Don, 28 Sep 2000: On Wed, 27 Sep 2000, Robert Hegemann wrote: At least your 3.87 MMX version seems to be compiled with the Makefile.MSVC I checked in, with RH_AMP and RH_VALIDATE_MS enabled. Dmitry, is that right? BTW Robert, are you recommending these

Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Robert Hegemann
Mark Powell schrieb am Don, 28 Sep 2000: On Wed, 27 Sep 2000, Robert Hegemann wrote: On my Linux Box with a Pentium 166 MMX the MMX and non-MMX version produce bit identical results. How did you get the Linux version to assemble the MMX code? I've had no luck with GNU as

Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Robert Hegemann
Gabriel Bouvigne schrieb am Don, 28 Sep 2000: At least your 3.87 MMX version seems to be compiled with the Makefile.MSVC I checked in, with RH_AMP and RH_VALIDATE_MS enabled. Dmitry, is that right? Should they be considered as default switches? In this case, why aren't they defined in

Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Gabriel Bouvigne
# of S frames/ total # of M/S frames]. Room enough on the lines :) 4) Why does the MMX mode and non-MMX mode give different output on my Cel450/Win95OSR2? Isn't MMX supposed to give same results? On my Linux Box with a Pentium 166 MMX the MMX and non-MMX version produce bit identical

Re: [MP3 ENCODER] MMX question

2000-09-28 Thread Robert Hegemann
Gabriel Bouvigne schrieb am Don, 28 Sep 2000: If the mmx version of choose table is used for the compilation, what will happen on a non-mmx cpu? it will crash, and it does so on my old P100. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some3.87 comments

2000-09-28 Thread Mark Powell
On Thu, 28 Sep 2000, Takehiro Tominaga wrote: "M" == Mark Powell [EMAIL PROTECTED] writes: M BTW The gcc 2.95.2 options are perfectly valid for FreeBSD as M well as Linux. Obviously :) Can they be copied into the FBSD M section too? silly thing. you had better detect

Re: [MP3 ENCODER] TagItem issues...

2000-09-28 Thread David Balazic
Sigbjrn Skjret wrote: /* in my man page va_start has only one argument (ap) ... */ Your man-page is wrong then I think, the second argument is so that va_arg() knows where to start (ie, it makes ap point to the next argument). HP-UX 10.20 man varargs say that it has only one arg.

Re: [MP3 ENCODER] MMX question

2000-09-28 Thread Gabriel Bouvigne
If the mmx version of choose table is used for the compilation, what will happen on a non-mmx cpu? it will crash, and it does so on my old P100. That's bad. Would it be possible to compile both routines in the same binaries, with an auto detection? Regards, -- Gabriel Bouvigne -

Re: [MP3 ENCODER] TagItem issues...

2000-09-28 Thread David Balazic
Frank Klemm wrote: :: /* Usage : :: lame_set_parameters(gfp, LAME_SAMP_FREQ__INT, 44100 , :: LAME_NR_CHANNELS__INT , 2 , :: LAME_LOW_PASS_VALUE__FLOAT , 16.050 , :: LAME_LOW_PASS_WIDTH__FLOAT , 0.75, :: LAME_COMMENT__STRING , "This is cool" ,

RE: [MP3 ENCODER] TagItem issues...

2000-09-28 Thread Mathew Hendry
-Original Message- From: David Balazic [mailto:[EMAIL PROTECTED]] Sigbjrn Skjret wrote: /* in my man page va_start has only one argument (ap) ... */ Your man-page is wrong then I think, the second argument is so that va_arg() knows where to start (ie, it makes ap point to

Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some3.87 comments

2000-09-28 Thread Mark Powell
On Thu, 28 Sep 2000, Robert Hegemann wrote: Mark Powell schrieb am Don, 28 Sep 2000: On Wed, 27 Sep 2000, Robert Hegemann wrote: On my Linux Box with a Pentium 166 MMX the MMX and non-MMX version produce bit identical results. How did you get the Linux version to assemble

Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some3.87 comments

2000-09-28 Thread Mark Powell
On Thu, 28 Sep 2000, Gabriel Bouvigne wrote: # of S frames/ total # of M/S frames]. Room enough on the lines :) 4) Why does the MMX mode and non-MMX mode give different output on my Cel450/Win95OSR2? Isn't MMX supposed to give same results? On my Linux Box with a Pentium 166 MMX

Re: [MP3 ENCODER] MMX question

2000-09-28 Thread Mark Powell
On Thu, 28 Sep 2000, Robert Hegemann wrote: Gabriel Bouvigne schrieb am Don, 28 Sep 2000: If the mmx version of choose table is used for the compilation, what will happen on a non-mmx cpu? it will crash, and it does so on my old P100. That's bad. Would it be possible to

RE: [MP3 ENCODER] TagItem issues...

2000-09-28 Thread Robert Hegemann
Mathew Hendry schrieb am Don, 28 Sep 2000: From: Mathew Hendry varargs.h is pre-ANSI and non-standard - use stdarg.h for the standard stuff. Should be va_start(ap) Oops! I mean va_start(ap, lastarg) where ap is your va_list and lastarg is the last non-variadic

Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Robert Hegemann
Mark Powell schrieb am Don, 28 Sep 2000: Wow the speed up is real sweet. What are the other .nas files in the i386 directory for? Specifically the fftsse.nas. Seems interesting if SSE can speed up some aspect of the encode. From the timestamps on these files it seems they are an abandoned

Re: [MP3 ENCODER] MMX question

2000-09-28 Thread Robert Hegemann
Mark Powell schrieb am Don, 28 Sep 2000: Hmm, you may dig in the Gogo sources. If I remember right they allowed to turn on optimizations with something like --use-mmx. This could be a way to do it in LAME too. Surely Gabriel was referring to the MMX code always being present

Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Ingo Saitz
MoiN On Thu, Sep 28, 2000 at 11:21:21AM +0100, Mark Powell wrote: Wow the speed up is real sweet. What are the other .nas files in the i386 directory for? Specifically the fftsse.nas. Seems interesting if SSE can speed up some aspect of the encode. From the timestamps on these files it

Re[2]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Roel VdB
Hello Mark, Thursday, September 28, 2000, 12:27:02 PM, you wrote: MP On Thu, 28 Sep 2000, Gabriel Bouvigne wrote: # of S frames/ total # of M/S frames]. Room enough on the lines :) 4) Why does the MMX mode and non-MMX mode give different output on my Cel450/Win95OSR2? Isn't MMX

Re[2]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Dmitry
Hello Gabriel, Thursday, September 28, 2000, 12:08:23 PM, you wrote: On my Linux Box with a Pentium 166 MMX the MMX and non-MMX version produce bit identical results. GB I compiled both releases (with and without mmx) with VC6, and the mp3 output GB is bit identical on my Cel460/win98.

Re: Re[2]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Robert Hegemann
Dmitry schrieb am Don, 28 Sep 2000: Hello Gabriel, Thursday, September 28, 2000, 12:08:23 PM, you wrote: On my Linux Box with a Pentium 166 MMX the MMX and non-MMX version produce bit identical results. GB I compiled both releases (with and without mmx) with VC6, and the mp3 output

Re[3]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Roel VdB
Hello Dmitry, Thursday, September 28, 2000, 1:34:50 PM, you wrote: D nommx version was compiled with ic 4.5 (with project files) D mmx version was compiled with makefile.msvc (ic4.5) D may be here is the problem since the nommx ic version seems to output abberant data, could you please try and

Re: [MP3 ENCODER] MMX question

2000-09-28 Thread Mark Powell
On Thu, 28 Sep 2000, Robert Hegemann wrote: Mark Powell schrieb am Don, 28 Sep 2000: Hmm, you may dig in the Gogo sources. If I remember right they allowed to turn on optimizations with something like --use-mmx. This could be a way to do it in LAME too. Surely Gabriel was

Re: Re[3]: [MP3 ENCODER] 3.87b MMX and no MMX give different results+ some 3.87 comments

2000-09-28 Thread Mark Powell
On Thu, 28 Sep 2000, Roel VdB wrote: Hello Dmitry, Thursday, September 28, 2000, 1:34:50 PM, you wrote: D nommx version was compiled with ic 4.5 (with project files) D mmx version was compiled with makefile.msvc (ic4.5) D may be here is the problem since the nommx ic version seems to

Re: [MP3 ENCODER] MMX question

2000-09-28 Thread david brown
Mark, I got that already, but I have no idea how to check for the presence of a MMX CPU. If someone knows how to do that, fine! Maybe there is some special x86 command that allows to decide whether it is a MMX CPU or not. As a quick fix we could implement that

Re: [MP3 ENCODER] MMX question

2000-09-28 Thread Robert Hegemann
Mark Powell schrieb am Don, 28 Sep 2000: Intel provide some code to do this at: ftp://download.intel.nl/support/processors/procid/cpuinfo.zip There's then the additional detection of Cyrix, AMD etc. which may cause complications. AMD have a similar 32 bit features value which also

Re: Re[3]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Robert Hegemann
Mark Powell schrieb am Don, 28 Sep 2000: I'm guessing that it's this that makes you happy with the velvet sound? RH_AMP stuff is what was previously known as RH_NOISE_CALC RH_VALIDATE_MS avoids to switch from LR to MS when the perceptual entropy indicates a need for

Re: Re[3]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Robert Hegemann
Mark Powell schrieb am Don, 28 Sep 2000: He also thinks -q1 could be unsafe. Is that unsafe just in v3.87 or has it always been so, Robert? Well, if we considered it always safe, we had made it default. Combined with some -V0 or -V1 it seems to be OK. If you compare

[MP3 ENCODER] modularization

2000-09-28 Thread Takehiro Tominaga
Ok, all... 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.

Re[4]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Dmitry
Hello Roel, RV since the nommx ic version seems to output abberant data, could you RV please try and compile an ic version with makefile.msvc (ic4.5)? done. i compiled 4 versions with makefile.msvc: ic, vc, nasm+ic, nasm+vc ic is bit identical to nasm+ic vc is bit identical to nasm+vc ic is

Re: Re[4]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Robert Hegemann
Dmitry schrieb am Don, 28 Sep 2000: but what version i have to upload??? from project file or from makefile??? with 'Robert's alternate code' enable or disable??? Well, officially the one with 'Robert's alternate code' commented out. Sorry for the confusion. Ciao

Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some3.87comments

2000-09-28 Thread Adam Ottley
Roel VdB wrote: 2) I miss the # of frames in each bitrate mode. The new real-time % data looks really neat, but please re-instate the # frames. Wouldn't the --nohist switch do this? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] resampling

2000-09-28 Thread Mark Taylor
As a value of 200 for BLACKSIZE showed an improvement in resampling, why does is still got a value as low as 25? Regards, -- Gabriel Bouvigne - France Hi Gabriel, Increasing BLACKSIZE only improves the sharpness of the lowpass cutoff. For resampling, I dont think we need an

Re: [MP3 ENCODER] resampling

2000-09-28 Thread Robert Hegemann
Mark Taylor schrieb am Don, 28 Sep 2000: I hope to add something soon which has it precompute the exact amount needed. Does anyone have code which computes the lcd (largest common denominator) of two ints? I think the number of windows needed is given by:

Re: [MP3 ENCODER] Re: 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Frank Baumgart
Dan Nelson wrote: In the last episode (Sep 28), Mark Powell said: BTW The gcc 2.95.2 options are perfectly valid for FreeBSD as well as Linux. Obviously :) Can they be copied into the FBSD section too? # these options for gcc-2.95.2 to produce fast code # CC_OPTS = \ #

Re: [MP3 ENCODER] MMX question

2000-09-28 Thread Frank Klemm
:: Mark, I got that already, but I have no idea how to check :: for the presence of a MMX CPU. If someone knows how to do :: that, fine! Maybe there is some special x86 command that :: allows to decide whether it is a MMX CPU or not. :: As a quick fix we could implement that

Re: [MP3 ENCODER] resampling

2000-09-28 Thread Frank Klemm
:: As a value of 200 for BLACKSIZE showed an improvement in resampling, why :: does is still got a value as low as 25? :: Low pass, high pass and resampling code should be replaced by artefact-less program code. All three are currently done by code not being a LTI system, which results in

[MP3 ENCODER] Second question: Compatiblity

2000-09-28 Thread Frank Klemm
Currently programs (must) access the lame_global_flags structure directly to setup lame. To get as much compatibility as necessary, it is important to know *when* programs (must) accessing this structure. [_] Frontends only accessing this structure for setup before any PCM sample to MP3

Re: [MP3 ENCODER] resampling

2000-09-28 Thread Frank Klemm
:: :: :: :: As a value of 200 for BLACKSIZE showed an improvement in resampling, why :: does is still got a value as low as 25? :: :: :: Regards, :: :: -- :: :: Gabriel Bouvigne - France :: :: Hi Gabriel, :: :: Increasing BLACKSIZE only improves the sharpness of

Re[6]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Roel VdB
Hello Robert, Thursday, September 28, 2000, 8:12:59 PM, you wrote: RH Dmitry schrieb am Don, 28 Sep 2000: but what version i have to upload??? from project file or from makefile??? with 'Robert's alternate code' enable or disable??? RH Well, officially the one with 'Robert's

Re: Re[6]: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

2000-09-28 Thread Joshua Bahnsen
As a side note to this question, is there a downside to using --nspsytune, besides being slower, it sounds better. Josh - Original Message - From: "Roel VdB" [EMAIL PROTECTED] To: "Robert Hegemann" [EMAIL PROTECTED] Sent: Thursday, September 28, 2000 7:14 PM Subject: Re[6]: [MP3 ENCODER]

Re: [MP3 ENCODER] MMX question

2000-09-28 Thread Takehiro Tominaga
"G" == Gabriel Bouvigne [EMAIL PROTECTED] writes: G This is usually done via the cpuid instruction. I just checked G the nasm manual, and this instruction is supported by nasm. and GOGO uses this to find out the CPU type. --- Takehiro TOMINAGA // may the source be with you! -- MP3