Updated: abr presets using >16kHz lowpass should be slightly improved on short blocks

Modified presets: portable/portable1 (2 candidates remaining, which one should be selected?)

New presets:
fast extreme
fast standard
fast medium
radio

edit: corrected a problem causing dropouts on may 8th. You should be able to get a fixed version on may 9th, depending on how quick compiles are updated. In the meantime, I'm providing a fixed version.

win32 binaries at RareWares, now.

You forgot to change the file link (it still links to the a13 one).

Does anyone have an approximate idea of when the a 3.94 stable build will be released? Or could that really depend on a billion different factors?

Ooops!! Sorry about that. Changed it now.

I'm playing around with portable presets.

On this sample
http://static.hydrogenaudio.org/extra/samp...ic_fields2.flac

it's extremely easy to hear ringing/watery artifacts
Quality : I'll have to abx them tonight / next days
Bitrate-wise (for a portable device like, let's say, muvo) I would prefer portable1.


lame --preset portable magnetic_fields2.wav
LAME version 3.94 MMX (alpha 14, May 4 2003 18:18:47) (http://www.mp3dev.org/)
warning: alpha versions should be used for testing only
CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding magnetic_fields2.wav to magnetic_fields2.wav.mp3
Encoding as 44.1 kHz VBR(q=4) j-stereo MPEG-1 Layer III (ca. 10x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
330/332 (99%)| 0:03/ 0:03| 0:03/ 0:03| 2.2799x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 1] *
80 [ 0]
96 [ 3] **
112 [ 21] %*******
128 [ 87] %%%*****************************
160 [185] %%%%%%%%**********************************************************
192 [ 29] %%*********
224 [ 6] ***
256 [ 0]
320 [ 0]
average: 151.3 kbps LR: 34 (10.21%) MS: 299 (89.79%)
Writing LAME Tag...done
ReplayGain: -7.3dB


lame --preset portable1 magnetic_fields2.wav
LAME version 3.94 MMX (alpha 14, May 4 2003 18:18:47) (http://www.mp3dev.org/)
warning: alpha versions should be used for testing only
CPU features: i387, MMX (ASM used), SIMD
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding magnetic_fields2.wav to magnetic_fields2.wav.mp3
Encoding as 44.1 kHz VBR(q=4) j-stereo MPEG-1 Layer III (ca. 10x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
330/332 (99%)| 0:03/ 0:03| 0:03/ 0:03| 2.3179x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 0]
80 [ 4] **
96 [ 7] ****
112 [ 44] %*********************
128 [122] %%%%%********************************************************
160 [133] %%%%%%%%%%%*******************************************************
192 [ 14] %******
224 [ 8] %***
256 [ 0]
320 [ 0]
average: 142.1 kbps LR: 34 (10.21%) MS: 299 (89.79%)
Writing LAME Tag...done
ReplayGain: -7.3dB

I think we've got a problem here. alpha14 is sounding horrible with the presets on one sample I found. I think it has something to do with short blocks and nspsytune.

I'll have to provide the sample when I get home but the opening section of "Exhausted" on the Foo Fighters self-titled album artifacts heavily with alpha14. The music is very distorted and gravelly-sounding guitar, lots of little impulses. Looking at Encspot, LAME is using a lot of short blocks on this sample. I tested it with alpha13 and it sounds OK but alpha14 is definitely problematic...lots of added noise. This happens with --preset [bitrate], --preset medium and --preset standard. It does NOT occur with plain CBR (which uses GPSYCHO), but it does occur with any commandline using --nspsytune. This says there is a problem with nspsytune.

Sorry to say but alpha14 is garbage. Now I am noticing watery cymbals even with --preset standard on several other tracks of the same album. Fortunately the root cause of this problem shouldn't be too hard to find since it affects everything (that I know of) that uses nspsytune.

I encoded something using this commandline (for a little avi-movie):
--preset cbr 56 -mm --resample 22050 -t
The result sounds much worse than the encode of 3.93.1. I analysed the files with Encsopt, and the result was: only short blocks in the alpha14-file (100%)! With 3.93.1 long blocks are 98,8%.

Here are some samples.

This is the distorted guitar sample:

3.94a14 --preset standard
FLAC

This file has watery guitar and cymbals:

3.94a14 --preset standard
FLAC

I listened your 2 samples, and I think tha I need more indications.
On "exhausted" I'm hearing a click around 1.5s, but it's also in the flac file.
According to your post, distortion on those 2 samples seems to be obvious to you.

Do I need to listen a specific portion, or to listen very loud? I am asking because at first glance, it seems ok to me.

I found cymbals, on bigme.mp3, a bit distorted, but not really chocking (in the mp3 line).

Note: I'd be interested by a sample where a14 standard is worst than a13, because theorically that should not happen.

IMO mithrandir's Exhausted sample sounds awful (for what I expect from aps). It has been the easiest to ABX (8/8 in 2 minutes) aps sample ever (except some pre-echo killer samples) for me.

The difference sounds comparable to a bottle of soda water that isn't closed properly.

According to you, does it sounds different than a13?

Yes. Just tested. No soda water with 3.94a13.

Edit: If you have a look at spectral view you see dropouts at 6000-8000 Hz and 12000+ Hz in a14 (not there in a13).

On gabriel.mp3-tech.org/lame I just uploaded 2 test versions. Could you do a quick test with those?

lame_test1 still has the problem.

lame_test2 sounds OK.

lame_test1 sounds like someone took a piece of sandpaper to the sample and rubbed. And yes, it does sound like there are dropouts in the lower treble range. Some of the signal p-p-p-peters in and out, like the sound your lips make when blowing into a brass instrument.

If you want to make the difference more pronounced, try --preset medium. lame_test2 is transparent on --preset medium, but test1 is simply awful.

Ok, I'm trying with medium...

With medium it's obvious on exhausted.flac

I commited the fix (well, I disabled some code). The result should now be the same as test2. (if you want to test a14 you can use it )

@Gaby

maybe you should take a look at how the short block values are stored in your array.
after a quick look it seems you guess they are layed out like
192 components (block 0)
192 components (block 1)
192 components (block 2).
iirc those blocks are interleaved, such that
component 0 (block 0, 1, 2)
component 1 (block 0, 1, 2)
...
component 191 (block 0, 1, 2)

but its been ages since i kept an eye on that, so it may have changed twice.

You are right about my guess...
Now, I think that I have to rewrite this loop

HEY, wazzup with Lame 3.94? Will there ever be a Final-Version? Alpha14 was created in MAY!

Big_Berny

Yes, but not with 3.94. 3.94 will only be released as a beta.

So why is that? Nevertheless, there definitely will be a new release that solves all confuses with the different releases? I mean people usually use the latest release, since this is supposed to be the best one…the same should be accomplished for LAME!

Because it is impossible to have a stable release without having released a beta first.

I heared about LAME 3.94 is going to be better in bitrates below 128? Will there once be a special speech compression?