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/ )

Reply via email to