Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: [USELESS] Why I Can't Use Lame 3.90.3 (Read 4955 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[USELESS] Why I Can't Use Lame 3.90.3

I had to start this topic because everybody just recommends 3.90.3

3.90.3 was tested ages ago, Hell it's 3 years old and you expect me to believe 3.91 and newer is not better.Yes i do know about the bugs in the newer versions, So what i don't use them I stick to the basics.

I have done lots of testing and newer versions sound better.

I have heard all that stuff about bitrate fluctuations and quality fluctuations
as well as tunings affecting the quality.

To me and alot of other people they perfer the newer vesions.

When comparing the newer versions they sound more sharp and clean not much smearing an less ringing.

I did this through abx'ing

ALSO look at all these changes to the code I can't just ignore these that's why i like the new versions.

Quote
LAME 3.97 alpha (CVS)
Robert Hegemann:
Fixed and out of array access
Fixed some small rounding problem in vbr-new quantization routines
Updated scalefactors allocation scheme in vbr-new
Fixed mingw32 configure problems
Resolved some compiler warnings
Gabriel Bouvigne:
Changed some FLOAT8 to FLOAT
Reworked -q1 and -q0
Updated presets
Fixed an error in ISO quantization on systems not using the IEEE754 hack
Faster quantization
SSE version of init_xrpow


LAME 3.96.1    July 25 2004
Robert Hegemann:
Fixed a rare bug in vbr-new (could lead to crashes or data corruption)
Gabriel Bouvigne:
some fixes in ACM codec
fixed padding when encoding to 320kbps
fixed block size selection for mid and side channels


LAME 3.96    April 11 2004
Gabriel Bouvigne:
new quantization selection mode (used in ABR/CBR)
set sfscale for ABR/CBR up to 160kbps


LAME 3.96 beta 2    March 28 2004
Takehiro Tominaga:
removed unnecessary integer convertion in resampling
Robert Hegemann:
reworked scalefactor allocation in vbr-new
fixed a freeformat decoding problem
Gabriel Bouvigne:
updated minimal bitrate for V1 and V2
Aleksander Korzynski:
added ability to disable ReplayGain analysis


LAME 3.96 beta    March 7 2004
Takehiro Tominaga:
fixed decoding issue
Aleksander Korzynski:
changed internal ReplayGain handling
fixed some issues when ReplayGain is used with resampling
Robert Hegemann:
added standard ISO quantization for vbr-new, used at lower quality settings
faster count_bits for vbr-new
faster find_scalefac_ave function for vbr-new
fixed an out of array access in psychoacoustic models; this bug could make some psy calculations worthless and sometimes let lame crash
fixed an error on silent scalefactor bands; this bug resulted in huffman data overrun problems while decoding, resulting in audible glitches
fixed a freeformat decoding bug
Gabriel Bouvigne:
adjusted short block thresholds
fixed some array addressing bugs
made ReplayGain analysis reentrant
David Chandler: fixed a crash in quantize_xrpow
Michal Bacik: fixed a crash when using 8kHz
Goran Markovic: fixed some decoding bugs
John Edwards: fixed a too small buffer in ReplayGain code


LAME 3.95.1    January 12 2004
Gabriel Bouvigne:
fixed a crash when using vbr-new
changed ReplayGain reference level to 89dB


LAME 3.95    January 11 2004
Gabriel Bouvigne:
fixed lowpass values when using vbr with mono files
faster quantization loops
faster count_bits
fixed a buffer requirement error in ACM codec
Takehiro TOMINAGA:
fixed mpglib and other decoding support code to prevent the crash when invalid mp3 input
removed Layer I decoding support
use FastLog and IEEE 754 hack on PowerPC too (approx. 10 percent faster)


LAME 3.94 beta December 15 2003
Takehiro Tominaga:
fixed block switching of nspsytune
best huffman divide in the inner loop. This should improve the quality, but PAINFULLY slow. So it is not enabled by default. Use -q0 to use it.
Changed -q option mapping. "-q2" until version 3.93 is now "-q3".
saving bits by better scalefactor storing
removed Vorbis support
substep quantization.This should help breaking the SFB21 bloating problem
made psychoacoustic model aware of ATH adjustements
use ATH value as short block masking lower limit
several fixes in psychoacoustic model
more robust decoding
Mark Taylor / Gabriel Bouvigne: fixed issues in VBR header
Mark Taylor: workaround against some hardware decoder defficiencies
Aleksander Korzynski: ability to compute the "Radio" ReplayGain and detect clipping on the fly. The ReplayGain value is stored in the Lame tag.
Gabriel Bouvigne:
work on presets
use presets by default for cbr/abr
use presets by default for vbr
analog silence detection in partitionned sfb21
do not compute noise in upper 0 part of the spectrum
only compute noise in modified scalefactor bands
Guillaume Lessard:
nogap related changes
Alexander Leidinger:
prevent closing the input fd prematurely if the input is a named pipe


LAME 3.93.1    December 1 2002
Gabriel Bouvigne:
preset medium added to the dll interface
fix for abr/cbr presets
fix -q0 switch
Alexander Leidinger: fix link problem on systems where socket() resides in libsocket


LAME 3.93    November 16 2002
Takehiro Tominaga:
bit allocation for pre-echo control improved for single channel encodings
substep noise shaping
optimizations by changing data structure
noise shaping model 2 fix
nspsytune FIR filter clean up
fix small psymodel bugs(DC current estimation, preecho detection of non-VBR mode, and nspsymode initialization)
portability fixes for Tru64 UNIX
Albert Faber: some fixes in the DLL
Simon Blandford: fixes for channel scaling in mono mode
Dominique Duvivier: some optimizations and a faster log10 function
Mark Taylor:
some tag related fixes in the direct show filter and in the ACM codec
fixed a mono encoding bug found by Justin Schoeman
calc_noise bug fix
other fixes
Alexander Leidinger:
update to autoconf 2.53, rewrite some configure tests
Akos Maroy: determine gcc version even with gcc 3.1
Andrew Bachmann: compile shared libs on BeOS (and perhaps other arches)
ultrasparc switches for gcc 3.1
fixes for SunOS 4.x
fixes for 64bit arches
CFLAGS fix for IRIX
don't override CFLAGS if exptopt isn't requested
Robert Hegeman:
some fixes
some fixes for VBR
Gabriel Bouvigne:
--noasm switch. Might help Cyrix/Via users
presets and alt-presets merged


LAME 3.92    April 14 2002
Alexander Leidinger:  add non linear psymodel (compile time option, disabled by default), workaround a bug in gcc 3.0.3 (compiler options, based upon suggestions from various people, see archives and changelog for more)
Steve Lhomme:  ACM wrapper (MS-Windows codec)
Steve Lhomme:  less memory copying on stereo (interleaved) input
Takehiro Tominaga: Inter-channel masking, enables with --interch x option
For buggy versions of gcc compiler (2.96*), back off on some of the advanced compiler options



LAME 3.91    December 29 2001
Darin Morrison:  Bugfix for --alt-preset (for content with low volume, clean vocals), only important for the "fast standard" preset
Alexander Leidinger:
add some missing files to the distribution
add --alt-preset to the man page


All the new alpha's are making good progress and to me is better quality then 3.90.3, My Friend Eaqual agree's with me too.

There hasn't been much testing on lame the last years.

There is just no time as we have AAC,Ogg and MPC

By the time lame get's really good most people won't care as they'll have their collection in more efficient formats

AFAIK

[USELESS] Why I Can't Use Lame 3.90.3

Reply #1
Meh. Don't we have enough threads about 3.90.3 versus 3.96.1 versus 3.97 alpha yet?

http://www.hydrogenaudio.org/forums/index....showtopic=32176
http://www.hydrogenaudio.org/forums/index....showtopic=32121
http://www.hydrogenaudio.org/forums/index....showtopic=32575

I think most people here expect 3.97 to become the recommended version once it's finalized.
Over thinking, over analyzing separates the body from the mind.

[USELESS] Why I Can't Use Lame 3.90.3

Reply #2
It'll Be a slow process as a lot of other people are interested in ogg,mpc and my future favourite AAC.

[USELESS] Why I Can't Use Lame 3.90.3

Reply #3
Quote
I think most people here expect 3.97 to become the recommended version once it's finalized.
[a href="index.php?act=findpost&pid=284422"][{POST_SNAPBACK}][/a]

Most people expect from HA.org to recommand 3.96.1, but it never happened. Why would 3.97 be recommanded?
There's one condition to make another lame relese the recommanded one: listening tests. And apparently, some people also request from the new one to be better than the previous one (which means, "even more transparent as transparent").
Few people are interested to test 3.97. And there are even less chance for 3.97 to sound better than 3.90.3 at high VBR settings.

Just my 2 cts.

[USELESS] Why I Can't Use Lame 3.90.3

Reply #4
As it seems to me, the current situation badly hurts Lame development, since it leads potential testers away from the latest versions.

Fortunately, most people seem to know better than whoever is in charge for the official recommendation:


[USELESS] Why I Can't Use Lame 3.90.3

Reply #5
Quote
When comparing the newer versions they sound more sharp and clean not much smearing an less ringing.
I did this through abx'ing
could you provide any links or logs for your tests?
if you are concerned about development then you might aswell post it along with some problem descriptions.
Quote
By the time lame get's really good most people won't care as they'll have their collection in more efficient formats
how good do you expect LAME to get?
I think it's pretty darn good already. for me, it's transparent even at bitrates of 160kbps.
Nothing but a Heartache - Since I found my Baby ;)

[USELESS] Why I Can't Use Lame 3.90.3

Reply #6
There have been some tests including 3.97 alpha's and they have done quite well in listening tests as well as quality measurement for example Eaqual.Eaqual has even had some results where 3.97 alpha's were much better than 3.96.1 and 3.90.3.

3.97 looks to be promising IMO

 

[USELESS] Why I Can't Use Lame 3.90.3

Reply #7
Quote
Quote
When comparing the newer versions they sound more sharp and clean not much smearing an less ringing.
I did this through abx'ing
could you provide any links or logs for your tests?
Quote
By the time lame get's really good most people won't care as they'll have their collection in more efficient formats
how good do you expect LAME to get?
I think it's pretty darn good already. for me, it's transparent even at bitrates of 160kbps.
[a href="index.php?act=findpost&pid=284435"][{POST_SNAPBACK}][/a]


I was more implying that it would get better transparancy at mid-high bitrates, but mostly less artifacts at lower bitrates 64-112.And be as fast as lame4.

I'll try and find those listning tests if not i'll redo them again easily.

[USELESS] Why I Can't Use Lame 3.90.3

Reply #8
Quote
I was more implying that it would get better transparancy at mid-high bitrates, but mostly less artifacts at lower bitrates 64-112.And be as fast as lame4.
as far as I followed the discussion, current LAME builds do not have a large headroom for speed increases.
this is planed to archive with v4 with a total code cleanup / improvement.

Quote
I'll try and find those listning tests if not i'll redo them again easily.
cool 

[span style='font-size:8pt;line-height:100%']edit: spelling[/span]
Nothing but a Heartache - Since I found my Baby ;)