[MP3 ENCODER] 22/56/JS - Lame vs Fraunhofer

2000-06-13 Thread Shawn Riley
I forgot to add that Fraunhofer also sounded better at 48k than Lame did at 56k... Maybe this filtering is why. Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] 22/56/JS - Lame vs Fraunhofer

2000-06-13 Thread Shawn Riley
  Hi everyone. I've made an observation with the versions of the Fraunhofer ACM codec that I installed in about January some time & Lame 3.62. Yes, they're old versions, & maybe a lot has changed since then, but... this is what I did-   1- Encoded a sample with moderately low stereo separation w

Re[5]: [MP3 ENCODER] lame binaries

2000-06-13 Thread Dmitry
Hello Holger, Tuesday, June 13, 2000, 5:16:14 PM, you wrote: HD> Also, how many people know of UPX, how many know that you can unpack HD> it, and how many know that those files were packed? There should be at HD> least a comment about the fact that they're packed with UPX. open lame.exe in somet

Re: [MP3 ENCODER] Winamp bug update: they ARE aware

2000-06-13 Thread Zia Mazhar
Greg Maxwell wrote: > It's amazing the differences people hear, considering that when the bug is > not occuring the outputs as very nearly identical. > Very right! Same goes for evaluating encoders, too! - Zia -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re[4]: [MP3 ENCODER] lame binaries

2000-06-13 Thread Holger Dors
Hello Jaroslav, > If you download upx packer, you can simply to unpack packed files. yes, of course, but this is true vice versa as well: you can pack the files with UPX if you wish to. Also, how many people know of UPX, how many know that you can unpack it, and how many know that those files we

Re: Re[2]: [MP3 ENCODER] lame binaries

2000-06-13 Thread Jaroslav Lukesh
| Odesílatel: Holger Dors <[EMAIL PROTECTED]> | Hello Dmitry, | | > i'm using UPX executable packer http://upx.tsx.org | | exe packers are very tempting to reduce size, and I myself have done | that before, however, this method has it downsides as well, although | not many people are aware of it

Re: [MP3 ENCODER] Winamp bug update: they ARE aware

2000-06-13 Thread Greg Maxwell
It's amazing the differences people hear, considering that when the bug is not occuring the outputs as very nearly identical. On Tue, 13 Jun 2000, Jason Antony wrote: > > just did a massive search at the Winamp forum website and came up > with these: > > http://forums.winamp.com/ubb/Forum1/H

Re[2]: [MP3 ENCODER] lame binaries

2000-06-13 Thread Holger Dors
Hello Dmitry, > i'm using UPX executable packer http://upx.tsx.org exe packers are very tempting to reduce size, and I myself have done that before, however, this method has it downsides as well, although not many people are aware of it or telling you. For some arguments for _not_ using an exe p

Re: [MP3 ENCODER] lame binaries

2000-06-13 Thread Gabriel Bouvigne
> I took all of this into consideration, but the binary hosted on mp3-tech.org > is nearly twice the size of the one on chat.ru I use VC6, p pro target processor, customized optimisations, and inline any suitable function. -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech

Re: [MP3 ENCODER] lame binaries

2000-06-13 Thread Gabriel Bouvigne
Probably because of different compilers, and different optimizations   Regards,   --   Gabriel Bouvigne - France[EMAIL PROTECTED]icq: 12138873   MP3' Tech: www.mp3-tech.org - Original Message - From: Ampex To: [EMAIL PROTECTED] Sent: Saturday, June 10, 2000 11:42 PM

Re: [MP3 ENCODER] New WinAmp And the Old Bug...

2000-06-13 Thread David Balazic
Zia Mazhar wrote: > > > > > > WinAmp 2.63 has been released... I didn't notice the bug with the sweep test. > > > So, it seems that they have finally fixed it! Please check for yourselves and > > > confirm. Thanks. > > > > > > - Zia > > > > > > > > > > I just downloaded WinAmp 2.64, and decoded bo

Re: [MP3 ENCODER] What's Safe-VBR mode?

2000-06-13 Thread Pierre Hugonnet
Mark Taylor wrote: > > > To explain how this works, take a 128kbs CBR for example. > In that case, LAME allocated a base amount of > bits for each frame. This base amount is about 10% less than > a 128kbs stream, so that the bit reservoir is slowly built up. > LAME then allocates extra bits ba