Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
>In VBR mode, --nspsytune usually improves sound quality with high tonality like piano and tambourin but sometimes degrades sound with low tonality like snare drums. Would it be possible to use some other switch, like --cwlimit, to achieve good quality with --nspsytune on all tonalities? If so, what settings would have to be used for it? (i.e. how should I interpret --cwlimit?) -Youri -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
hi -- This is my first post to the list. I've been helping myself to the cvs source code for a few months now and this is a subject I have done some experimentation with. the only drawback I've found when using --nspsytune in vbr mode is that the average bitrate may increase somewhat dramatically. In one of my test cases (10 second clip) the avegare bitrate is 290 with --nspsytune vs 210 without it. lame version is 3.87 beta 1, options used were -b 128 -h -m j -q 1 -V 1 [--nspsytune] anyone interested in the clip can mail me. I have a small collection of 10 second clips that produce similar results. I also have samples which produce smaller average bitrates with --nspsytune. from now on I usually take some 30 seconds of source material and encode it both with and without --nspsytune to determine which will produce the smallest average bitrate before encoding the whole project. in cbr mode I prefer to use --nspsytune at all times. for the same reason naoki shibata and others have mentioned. On Fri, Sep 29, 2000 at 01:09:16PM +0900, Naoki Shibata wrote: > 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 like piano and tambourin but sometimes degrades sound with low > tonality like snare drums. > > In CBR mode, --nspsytune lowers artifacts in high frequency. -- Michael Horan III PGP signature
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
Ross Levis schrieb am Fre, 29 Sep 2000: > I think Roberts code should be included and implemented with a switch so > us "non-compilers" can test it. look at Dmitry's site, there it is for Windows users. http://www.chat.ru/~dkutsanov/~index.htm The latest alpha versions from CVS Repository. For testing purposes only!!! lame387nic with MMX support and Robert's alternate code lame-2928n with Robert's alternate code > > Ross. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
I think Roberts code should be included and implemented with a switch so us "non-compilers" can test it. Ross. Roel VdB wrote: > 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 alternate code' > RH> commented out. Sorry for the confusion. > > Robert, please consider defaulting the enhancements. It improves the > 'velvet' track quality considerable in JS mode. > > Is there a downside to this 'alternate code'? > > -- > Best regards, > Roel mailto:[EMAIL PROTECTED] > > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
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 like piano and tambourin but sometimes degrades sound with low tonality like snare drums. In CBR mode, --nspsytune lowers artifacts in high frequency. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
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 seems they are an abandoned project? /src/lame/i386$ cvs log fftsse.nas [...] description: revision 1.1 date: 2000/01/30 22:53:49; author: takehiro; state: Exp; initial check in of asm code from GOGO not working :) = Ingo -- _ ( ) ASCII Ribbon Campaign /~\ Against HTML Mail ' ` -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
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 project? >Cheers. First, I'm no assembler guru. In the past I did some assembler stuff for TMS9900 - you know TI994/a a Texas Instruments home computer with speech synthesizer and alike - and Motorola 68000 - Atari ST. My latest bit for bit optimization stuff was for a project group at university, where I had to program some field programmable gate arrays (FPGAs). The title of that project was (translated in english): "Design and implementation of a hardware system for the calculation of covered surfaces in the real time image processing". I never did any x86 assembler programming, even though I sometimes look at the assembler output from gcc to get an idea if an optimization was OK or not. The assembler routines in the i386 folder are Takehiro's backport from the GOGO assembler routines. Takehiro has those on the TODO list, so maybe in time Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
# 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 results. I compiled both releases (with and without mmx) with VC6, and the mp3 output is bit identical on my Cel460/win98. 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/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
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 the VC project? From my point of view yes, but not necessarily. I've no VC5, so I don't maintain these project files. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
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 options for improved quality? Would > that also be inconjunction with the --raise-smr 1 flag for VBR? > Cheers. I would recommend them, but they break Mark's testcases. They are independent from the --raise-smr stuff. I'm actually not sure about the benefit of --raise-smr 1 as this will increase noise modulation with another test case spahm.wav. It seems that vbrtest.wav and spahm.wav need diametrical tunings and the real solution would be a new spreading function. The safest is, don't use neither -q1 nor --raise-smr x. > 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 Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
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 v2.10.0 under FreeBSD. I'm obviously missing something? Yes, you need NASM, the Netwide Assembler NASM = nasm ASFLAGS=-f elf -i i386/ %.o: %.nas $(NASM) $(ASFLAGS) $< -o $@ %.o: %.s gcc -c $< -o $@ and you'll have to uncomment the following ## use MMX extension. you need nasm and MMX supported CPU. CC_SWITCHES += -DMMX_choose_table OBJ += i386/choose_table.o > 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? > > - > ## > # FreeBSD > ## > ifeq ($(UNAME),FreeBSD) > # some alternate code (work in progress [EMAIL PROTECTED]) > # CPP_OPTS += -DRH_AMP -DRH_VALIDATE_MS > # these options for gcc-2.95.2 to produce fast code > # CC_OPTS = \ > # -Wall -O9 -fomit-frame-pointer -march=pentium \ > # -finline-functions -fexpensive-optimizations \ > # -funroll-loops -funroll-all-loops -pipe -fschedule-insns2 \ > # -fstrength-reduce \ > # -malign-double -mfancy-math-387 -ffast-math > endif > - > > 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 Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
> 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 the VC project? 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/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
Roel VdB schrieb am Mit, 27 Sep 2000: > 3.86 (nommx) > > average: 235 kbs > > 3.87 nommx: > > average: 225.8 kbps > > 3.87 MMX > > average: 224.6 kbps > > remarks: > 1) 3.87 MMX is smaller, yet it sounds better (???) (velvet JS noise) does it sound better than 3.87 non-MMX or 3.86? > 1b)3.87 -V1 is 20% faster than 3.86 (thanks Robert!) > 1c)3.87 -V1 MMX is 35% faster than 3.86 (thanks Takehiro!) > 2) I miss the # of frames in each bitrate mode. The new real-time % >data looks really neat, but please re-instate the # frames. > 3) Would be really something if it would also say [total# frames/total ># 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 results. 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? Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
I had the same problem of MMX giving different results than the non-mmx. Maybe the algorithms are different? Is that correct? Isn't MMX (assembly in general) going to use a different algorithm, because if you are using the same algorithm for assembly as you do in C, shouldn't the C compiler give the same assembly as you just wrote? Am I way off? Also I was compiling both with MSVC and DJGPP. I thought I had basically the same options when compiling, I had none of the optional stuff like IEEE hack and Takehiro's modifications. But when the same commandline is used with LameVC (compiled with Visual C) and then again with LameDJ (Lame compiled with DJGPP), the outputs are different. I used constant bitrate encoding. Does anyone know how to build the DLL for Win32 using VC or DJGPP from the commandline ie make or nmake? thanks, Nathan D. Blomquist http://www.win32lame.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Roel VdB Sent: Wednesday, September 27, 2000 1:57 PM To: [EMAIL PROTECTED] Subject: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments Hello, first some data: (-V1 -mj -h -b128 -q1) 3.86 (nommx) > Encoding c.wav to c-386-nommx.mp3 > Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG1 LayerIII ( 6.0x estimated) qval=1 > Frame | CPU/estimated | time/estimated | play/CPU | ETA > 12498/ 12498(100%)| 0:04:07/ 0:04:07| 0:04:07/ 0:04:07|1.3215| 0:00:00 > - bitrate statistics - > [kbps] frames > 32 9 (0.1%) >128 109 (0.9%) >160 1270 (10.2%) >192 4365 (34.9%) >224 2074 (16.6%) >256 1305 (10.4%) >320 3367 (26.9%) > > average: 235 kbs 3.87 nommx: > LAME version 3.87 (beta 1, Sep 26 2000)(http://www.mp3dev.org) > Win32 binaries from www.chat.ru/~dkutsanov/ > polyphase lowpass filter disabled > Encoding c.wav to c-ic-nommx.mp3 > Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG-1 LayerIII ( 6.0x estimated) qval=1 > Frame | CPU time/estim | REAL time/estim | play/CPU |ETA > 12498/12498 (100%)|3:25/3:25|3:26/3:26| 1.5855x| 0:00 > 32 [%.1]* > 128 [ 2%]*** > 160 [19%]* > 192 [33%]** > 224 [13%] > 256 [10%]*** > 320 [24%]* > average: 225.8 kbps 3.87 MMX > LAME version 3.87 (beta 1, Sep 27 2000)(http://www.mp3dev.org) > Win32 binaries from www.chat.ru/~dkutsanov/ > polyphase lowpass filter disabled > Encoding c.wav to c-ic.mp3 > Encoding as 44.1 kHz VBR(q=1) j-stereo MPEG-1 LayerIII ( 6.0x estimated) qval=1 > Frame | CPU time/estim | REAL time/estim | play/CPU |ETA > 12498/12498 (100%)|3:03/3:03|3:03/3:03| 1.7822x| 0:00 > 32 [%.1]* > 128 [ 2%]*** > 160 [18%] > 192 [33%]** > 224 [13%] > 256 [11%]* > 320 [22%]** > average: 224.6 kbps remarks: 1) 3.87 MMX is smaller, yet it sounds better (???) (velvet JS noise) 1b)3.87 -V1 is 20% faster than 3.86 (thanks Robert!) 1c)3.87 -V1 MMX is 35% faster than 3.86 (thanks Takehiro!) 2) I miss the # of frames in each bitrate mode. The new real-time % data looks really neat, but please re-instate the # frames. 3) Would be really something if it would also say [total# frames/total # 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? thanks and Best regards, Roel mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
