The Xing MP3 encoder is exceptionally fast. Do they cut corners to get such high
performance? Is their code written in assember?
What (if any) chance of getting similar speed out of LAME?
The Xing encoder is quite limited with regard to input sampling frequencies and
output bitrates. Has anyone
Roel> btw: what's the status on --nspsytune? I heard some fixes were made?
--nspsytune is a lot improved from 3.86.
I've asked some people to evaluate --nspsytune, and most of their
response were positive ones.
In VBR mode, --nspsytune usually improves sound quality with high
tonality li
There is only a problem with the Intel compiler if
you compile on Win 95/98. If you actually use Win NT/2000 as your OS, binaries
compiled with the Intel compiler run just fine on NT/2000 and ME/95/98. If you
want an example, I've posted binaries of both VC5 and IC on http://www.geocities.com
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 ENCOD
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
> From: "Mark Taylor" <[EMAIL PROTECTED]>
>
> 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: out_samplerate/(lcd(in_sampl
::
::
:: >
:: > 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 sha
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 cod
:: 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 unn
Note: has_SIMD is not tested.
int has_3DNow (void)
{
__asm__ (
"pushal \n"
"pushfl \n"
"popl %eax \n"
"movl %eax,%ecx \n"
"xorl $0x0020,%eax \n"
"pushl %eax \n"
"p
:: > 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 th
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 = \
> >
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: out_samplerate/(lcd(in_samplera
>
> 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 n
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/ )
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
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 ve
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.
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 "-
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
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 als
> "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!
--
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
[EMAIL PROTECTED]
mobile phone: [EMAIL PROTECTED]
icq: 12138873
MP3' Tech: www.mp3-tech.org
--
MP3 ENCODER mailing list ( http://geek.rcc.se
> 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 th
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 versi
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 G
> 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 command line switch
> for L
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 a
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
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.
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
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
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 abandone
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 p
Mathew Hendry schrieb am Don, 28 Sep 2000:
> > From: Mathew Hendry
> >
> > is pre-ANSI and non-standard - use 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 paramet
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. Wo
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 Pentiu
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
> From: Mathew Hendry
>
> is pre-ANSI and non-standard - use 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 parameter.
> va_arg(ap, type)
And not forgetting
va_end(ap)
althou
> -Original Message-
> From: David Balazic [mailto:[EMAIL PROTECTED]]
>
> Sigbjřrn Skjćret 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 mak
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 compile both routines in the same
> binar
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 co
> > 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 -
Sigbjřrn Skjćret 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.
/usr
On Wed, 27 Sep 2000, 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
> >
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 bett
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/ )
# 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 iden
If the mmx version of choose table is used for the compilation, what will
happen on a non-mmx cpu?
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/
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
> defi
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 recommendi
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 a
52 matches
Mail list logo