what's new:
*preset standard (former std3)
*presets medium and medium1

http://gabriel.mp3-tech.org/lame/

I can't find it (except alpha9)

I can't find here too.

Complete set of win32 binaries uploaded to my 'Other' page at Mirror 1 (link at foot of front page).

Here you go.

Edit: beaten like rodney king

Verve Remixed Track 09
Lame 3.94a10
Medium Tests


Preset Medium 8:37 176kbps
Preset Medium1 7:38 163kbps
Preset Dm-Medium 8:10 190kbps


Abx tests will follow tomorrow...

dm-medium can not be compared to medium presets. They are not targetting the same bitrate range.

What range are they targetting?

If you want to add a third medium candidate, the following is my entry in the "contest":

-V3 -b 128 --lowpass 17.5 --nspsytune --nsmsfix 1.8 --ns-sfb21 6.25 --athcurve 4 --shortthreshold 3.75,15 -X 1,3 -Z 1

This commandline targets the 165-180kbps range.

Few things in 3.94a10:

1.
--preset standard should have -b128
* test c44.wav: the pre-echo is clearly higher if min bitrate is not 128kbps, like it isn't now.

2.
The first frame should be "short", instead of "start". Dibrom's --alt-preset standard always uses short as the first frame, and although this may not be a problem often "in real life", at least some test samples like death2.wav should sound better in the beginning than now.

3.
I'd like to test which is better for standard-preset purpose, the current "-V4 -X 3,3" or "-V2 -X 1,3"

4.
I wonder if it would be possible to make switch(es) for adjusting masking for short-block and long-block separately.

The new alpha10 --preset standard uses -X 3 for both long and short blocks (unlike Dibrom's) and Gabriel said previously that there is probably no need for minimum bitrate constraints with -X 3,3. Now that you have found a case where not setting a minimum has caused a problem, we have unearthed a case of theory versus reality.

I'd go for -V2 -X 1,3 for standard...I think it's "safer". I've experimented with -X 3,3 at various VBR quality levels and while it can pull off some neat feats, using a lower VBR quality level can cause problems regardless of the noise measurement mode used. I think it's a matter of consistency...you are more likely to find a noticeable artifact with -V4 -X 3,3 than -V2 -X 1,3. IMO, --preset standard should give the illusion of transparency even it is not...and that means minimizing the impact and grossness of artifacts rather than minimizing their frequency.

On my crossfire.wav, medium1 is too noisy during the drum hits (pre-echo I guess)...adding -b 128 improves matters. Regular medium and my commandline are tolerable (though slightly noisy).

I'll have to post the FLAC sometime.

Yep, I'm suspecting that's the case..

While I am intrigued by how --preset medium works, I don't know if it truly fits the bill as a medium preset. It seems more of a 3.90.2 APS -Y competitor. It frequently produces files in the 180-190kbps range...sometimes going over 200kbps. At that rate, you have to question what you are going after since 3.90.2 APS was fairly consistent at averaging around 190-195kbps.

We have to ask ourselves: should the presets in 3.94 mimic those in 3.90.2, i.e. APS ~192kbps, APE ~256kbps? Are we targetting bitrate or are we targetting quality? We know 3.90.2 APS has its problems so should 3.94's standard preset aim for a higher level of transparency (and an according increase in bitrate) or should we try to eek out the best quality at 192kbps?

Maybe 3.94a10's medium preset aims for a "medium" level of quality. However, its bitrate is too high to fit into the 3.90.2 preset model...it gets too close to APS in size. My commandline was created thinking that 3.94 standard was going to target 192kbps like 3.90.2. In this light, it's a better choice than 3.94a10 medium (since its smaller) and it's slightly higher in quality (and bitrate) than medium1.

Here's the Crossfire track I mentioned before.

crossfire.flac

The first case where -b128 is helping with the current standard? That is interesting...


No, sorry. There is a VBR header in front of the files, and this header is long blocks. So the first audio granule can only be long or start, but not stop (it was stop or short before)
The first granule is only 13ms, and audio does not start immediately. Are you sure this is impacting quality? If needed we can check it.


In a9 std1 was using X1,3 and std3 was using X3,3.


Yes, that would be possible, but I am not sure if this would be usefull. Current start/short/stop blocks have nearly no masking computation now.

bitrates:

Yes, it would be fine is medium was reaching 165 as average (so there can be higher bitrate tracks, and some lower)
I think that right now, it's around 175.
If you have some tracks where the bitrate explodes with medium, that is interesting...

Will the -Y switch work with the new presets?

The first case.. That's interesting because that was the 2nd sample I tested with the new standard.. I'm pretty sure I can easily find more if needed for more evidence.. (I almost always do blind testing without saying, but in case somebody is wondering: --preset standard vs --preset standard -b128 ABA 6/6)


Yes, in case of the death2.flac -testsample, it seems to affect very much right in the beginning. Dibrom's APS sounds fine most probably because it uses short block there as the first frame at least according to mp3x. Of course, it is probably quite unlikely in real-life situation that the music starts so rapidly with a strong transient..

I need to read the a9 testing thread since I didn't do any testing with that version.. Have you or anybody tested the average bitrate of this new standard preset with large variety of different music compared to the old APS? I'm seeing quite a lot about 20kbps bitrate changes to both directions (sometimes old APS is bigger, sometimes new standard) depending on the track.
Do you have any specific quality results why you went for -V4 X3,3, instead of -V2 X1,3?

Well, I'm just wondering that there should be some way to manually adjust the amount of bits given to the start/short/stop blocks, of course I'm mainly thinking of giving a bit more bits than psymodel currently suggests hoping that it still improves transients.

In theory it should work just like with old APS: disabling noise shaping for over 16khz (scalefactor band 21) avoids bitrate bloating, which otherwise can happen due to missing scalefactor for sfb21 in MP3.

For the standard preset, yes. However, it's not needed for the medium and medium1 presets because they already incorporate -Y.

Ok. So if the new medium presets already have the -Y switch incorporated, the new APS in conjunction with the -Y switch would target the same bitrate (roughly)? Sounds a bit too simple to me...

Well I did not went with V4 or V2, I'm not using any -V value. (mainly because I'd like to alias -V to the presets in the future)

I tried both X1,3 and X3,0 combinaisons, and tryed to reach the same average bitrate for both (average, so specific track can be far from the average).
This became std1 and std2 in a9. Based on comments, I changed to X3,3 in std3.
If you want alpha9 is available from gabriel.mp3-tech.org/lame.

I do not think that giving more bits to short blocks would help. They already have many bits as they only use the ath as masking. Probably changing bit allocation between subblocks would be a more efficient change. (There was some interesting posts about what still need to be done for short blocks on the dev list)

Well, how do you control resolution then? If standard is the "offset"-point, how do you go for lower and higher resolution, if not using -V? Some internal stuff, or just using ns-bass/alto/treble?

edit: ok I read from an earlier thread that you said: "Adjusting the masking and changing ath level are equivalent with nspsytune".
Gotta say that I don't quite understand how this would work.. My understanding was that when calculating the overall masking of some section (lets say for longblocks only now), it does the calculation for simultaneous masking (from tonality estimation,spreading function etc.) then this and ath are combined in order to get the total masking threshold. I mean I really can't understand how for example adjusting the masking with --ns-bass/alto/treble is equivalent to just changing ath level?? I mean ath could indicate that something is well within your hearing curve, but it's the non-perfect tonality estimation why the possible adjustment would be needed in order to have higher quantization resolution in a section which is otherwise perfectly covered by ATH.

No, your thinking is pretty much spot on. This is one of my reservations with the a10 medium preset: it can equal or exceed the bitrate of APS -Y, which should be the superior solution (since the medium presets also use -Y). I designed my commandline so that it is smaller than APS -Y about 95% of the time and yet it retains slightly more >16KHz information because it doesn't use -Y.

Here's an interesting example. I encoded Sgt. Pepper's in various forms; I provide the bitrate range across the 12 tracks and the final average.

3.94a10 standard: 207-242kbps range, 222kbps average
3.94a10 medium: 176-213kbps range, 195kbps average
3.94a10 medium1: 169-191kbps range, 179kbps average
3.94a10 "my medium": 173-195kbps range, 183kbps average
3.90.2 standard: 187-208kbps range, 194kbps average

So here, a10 medium uses more bits than 3.90.2 standard (which doesn't even use -Y). Of course, since this is a 1968 pop recording there probably isn't many HF information but it's an interesting case nonetheless. Also look at the bitrate ranges across tracks. 3.90.2 standard has a tight 21kbps range, while a10 standard and a10 medium have ranges of 35kbps and 37kbps, respectively.

Mind you, I haven't really discussed the quality angle but I think we should make sure a preset is a valid candidate from a bitrate perspective before giving it tough aural scrutiny. I'm not trying to put anybody down but rather call to mind that we are building off of 3.90.2 and the users have a certain level of expectations from previous experience. If standard goes from ~192kbps to ~210kbps - even though quality improves - I'm not so sure that's an ideal situation. Again, I think we need to define what "standard" and "medium" really mean. If "standard" means targetting a certain quality level a la MPC standard then increasing the bitrate is expected. But if we are saying "standard" is the very best quality you can get without producing large files, then the 192kbps mark should be the target.

Look mithrandir, I hate to say this, but your messages really have started to sound like this is a contest of who can pimp his "own designed" preset the most. IMO presets shouldn't be build like that, and I don't like this "my preset designed to do blaa blaa" attitude, especially when some basic switches are slightly tweaked, and there's no extensive listening test results available.

Instead of hyping "your own desinged preset", why not provide listening test results/comparisons... Building Lame presets is a community effort, and nobody should proclaim some simple preset combination as "his design". It only incites people like randar to get somekind of glory no matter what.

Anyway, enough about this, but I just don't like to see HA turn into preset pimping place where people compete whose slightly tweaked preset will be put into Lame, so that they will get "glory".

I'd like to know how did you decide to use --nsmsfix 1.8 with medium preset? Why not 3 or no nsmsfix at all, since Lame's mid/side coding is rather good anyway. Also, how did you end up choosing ns-sfb21 6.25 for medium preset? Give me some concrete examples...

I don't know how he came up with it, but I've noticed on one sample that default --nsmsfix with --alt-preset abr/cbr at lower bitrates (under 160kbps I think it was with 3.90.2 & 3.94a9) there is an extremely noisy artifact with guruboolez's creaking.wav sample which is reduced to almost nothing by dropping down to around --nsmsfix 2.5. It's a real bad artifact, so it's something maybe people should be checking out a bit more carefully and might be worth lowering the default preset --nsmsfix down if the negative side of it wouldn't be too bad or noticeable.

Here's a zip with creaking encoded with lame 3.94a10 "--preset 140" & "--preset 140 --nsmsfix 2.5", should be very easy to hear the difference.

Edit: fixed link, dunno what happened there (Thx jesseq)

Yeah.. --nsmsfix is a funny switch, because it doesn't only control how much stereo-frames and how much mid/side-frames are used. --nsmsfix actually also affects to how much bits are given to the mid/side-frames, in other words masking threshold of the mid/side frames.
A nice example of this is the seriousTrouble.flac -clip. With a10 --preset standard --nsmsfix 3.5 it is full of holes and separate "blips" in the spectra. With --nsmsfix 0.5, the same areas still use only mid/side-frames, but have clearly higher bitrate, leading to very solid spectra. With full stereo coding, it's full of holes and blips again, although the bitrate is high.

I'd infact like to hear from Lame developers what and how nsmsfix really does its job.

Interesting clip (although the zip didn't work). Looking at the mid/side and stereo-frame distribution, it seems that in this case, the problem section gets stereo frames when using --nsmsfix 2.5 which perform better although not perfect. Seems to be transient induced noise...

I'm sorry you think that way.

I'm not trying to cool anybody's jets but I wanted to incite a frank discussion on what the presets mean in 3.94. I have a certain idea of what they should be but I think that they are beginning to become something else. I'm not trying to say that's wrong, but I know users are going to wonder what's going on.

Think about it this way. HA still promotes 3.90.2 as the preferred LAME version. This version is also 14 months old. 3.94 is supposed to be the real successor to 3.90.2 and should become the new recommended version. So 3.94 gets released and people discover that the presets they used in the past have gotten bigger. Sure, the quality has improved, but so what when (a) a year of development has passed by and (b ) bitrate has increased. I think people are expecting 3.94 standard to be just like 3.90.2 in size but better in quality.

The standard and medium candidates within alpha10 may be great from a quality perspective but quality is not the only consideration when it comes to the presets...it's about getting the most bang for the buck. I think that users want standard to stay at 192kbps...just as it was with 3.90.2. But it's not going that way with 3.94. I don't want people think that the work people have put into the current presets was improper but I think we need a "check-in" to determine what the presets SHOULD be. Should they mimic Dibrom's presets in 3.90.2 or should we shed that "baggage" and begin anew?

If the community in general thinks it's acceptable for 3.94 medium to be similar in size to 3.90.2 standard -Y, then that's democracy in action. Since I am a user and not a developer I am trying to guess what a typical user may want. I'm not trying to impede the process but to add diversity of thought.


You won't be satisfied with my decision process.

Say you took a WAV with reasonable stereo channel use. OK, VBR encode that WAV at various --nsmsfix values (from 0 to 3.5) and write down the bitrate at each point. Now plot that on a graph. You'll see that the bitrate doesn't go up much as you move from 3.5 to 3.25 to 3 to 2.75 to 2.5. As you get closer to 2 the curve starts increasing faster. By 1.5 it's getting rather steep...and so on. I did this using a variety of WAV files, plotting many graphs, until I found a nsmsfix value that was as low as possible before the bitrate really started taking off...finding the point where the curve kinks. I have a background in economics so I was thinking along the lines of diminishing returns. Where is the best spot for getting the most mileage?

I also thought this way: LAME defaults to 3.5 and standard uses 1.38. Just from there you could say 1.8 was a good choice for a medium preset. It could have been 1.6, it could have been 2.0. 1.8 is just a number I ended up with...but I am confident that it is very much in the ball park of where it "should" be.

Sure I'll catch hell for not using deep listening tests but since nsmsfix is a sliding value, I can't really screw it up. Actually, I DID perform some listening tests, but not of the preferred double-blind variety.


Smile.

3.90.2 standard uses 3.75dB. There's the benchmark. A medium preset isn't going to use anything lower so I choose 6.25dB strictly from a bitrate tuning perspective. I collected a few tracks with a lot of HF information and VBR encoded at different ns-sfb21 values and did the graph plotting thing. Oh, I can hear the groans now. But really, you can "get away" with this because medium is not going to be transparent anyhow and we know that --ns-sfb21 6.25 is going to be better than -Y.

So while my chosen values are educated guesses, they do produce files at my desired bitrate. And nothing is stopping anyone from trying these settings and telling me they are horrible.

Well, bitrate statistics is certainly one way to look at it (now I understand the "design"-part better ), and it may be a good base. But imo listening tests are always needed, and always the most important factor.
I agree that people are expecting the presets to give about the same average bitrates, or even a bit lower than 3.90.2. And yes, medium should be clearly lower bitrate than standard.

A few points:

I think that overall the current std is reaching the same bitrate as 3.90.2. But this is overall, we are not doing abr here. So if you have an album where it's 20kbps more, we do not really care. If on a lot of albums, the global overall bitrate is 20kbps higher, that's a problem.
Perhaps it's overall too high, I can not be sure about it. Only large set of encodings can tell this, and this means much more people encoding than just me.

About the nsmsfix, be carefull with your values. The same values as before (3.93.1 and lower) do not have the same effect. I myself determined the current numbers by trying to reach the same proportion of MS/SS as with previous versions. So now "nsmsfix 3" is probably a wrong value.

Ath and masking: adjusting ath and masking does not make that much differences in the standard area. But you are right, it's unsuitable for other target ranges as medium or extreme. The key is --maskingadjust. The second key is --athshape for the shape of ath4 curve (a -V1 is doing --athshape 1, as an example).
For this --verbose is your friend.

I perfectly agree that current medium are not totally good. They could be considered more as drafts than candidates. But we still need first impressions in order to know in wich direction to go.

I is also possible that on some tracks we could encounter this scheme:
3.90.2 std: 192kbps
3.94 std: 230kbps
3.94 med: 197kbps
This would seems normal, as long that it's only for some tracks, and that 3.94std would improve over 3.90.2std. (once again, we are in vbr, not abr)

Also for the newcomers, the 3.94a8 thread was the basis for the choice of the current std.

You ask for bitrate comparison - here you go. I'll rip + encode some CDs I randomly picked from my collection - and edit the results in this post. If you want more information, please tell me.
1: lame 3.90.2 --alt-preset standard [overall bitrate] - [min song bitrate] - [max song bitrate]
2: lame 3.94a10 --preset standard [overall bitrate] - [min song bitrate] - [max song bitrate]

So far (it'll grow slowly, I encode @ 750 Mhz, so be patient):

Salsa Cubana - The Gold Collection CD2 (total time: 1:13:14)
1: 202kbps - 157kbps - 218kbps
2: 223kbps - 193kbps - 256kbps BTW: The number of frames in 40-112kbps range is < 0,1 % for all tracks

Living Colour - Back in Town (tt: 0:45:23)
1: 215kbps - 194kbps - 233kbps
2: 211kbps - 206kbps - 215kbps

Santana - Supernatural (tt: 1:14:59)
1: 209kbps - 163kbps - 231kbps
2: 201kbps - 163kbps - 215kbps (1 Song with > 10% frames </= 112kbps, 3 Songs 1-3%)

Mike Watts - Ballhog or Tugboat [Track 1-14 due to scratches] (tt: 48:06)
1: 204kbps - 180kbps - 223kbps
2: 193kbps - 163kbps - 218kbps (Some tracks up to 10% </= 112kbps frames again)

Hans Söllner - Hey Staat! (tt: 44:22 - for those who don't know Hans Söllner: It's commedy - voice + guitar)
1: 166kbps - 154kbps - 181kbps
2: 165kbps - 153kbps - 175kbps

Dub War - Pain (tt: 50:49)
1: 209kbps - 173kbps - 223kbps
2: 217kbps - 182kbps - 232kbps

Lisandro Adrover - Tango - Esencia y después (tt: 41:18 - recorded 2000, no freq. cutoff as old tango recordings)
1: 184kbps - 179kbps - 196kbps
2: 201kbps - 196kbps - 206kbps

Tricky - Maxinquaye (tt: 57:13)
1: 175kbps - 129kbps - 210kbps
2: 180kbps - 135kbps - 241kbps
No! Actually it loves salsa - it gives extra bits to salsa for perfect transparency.

BTW: JohnV's post about a problem without -b 128 made me curious. Trying to find something similar I took the 1st track with 10% frames @ 112/96/...kbps(Santana - Maria Maria) and started to search for audible differences in low bitrate passages. Found 1 difference so far (ABXed 7/7) but haven't compared with --preset standard -b 128 so far. If -b 128 causes a difference, I'll post seperately.

Well, I got the explanation from Takehiro:
Currently, MS/LR switching is based on the amount of sum of Energy/Masking. Because --nsmsfix adjusts Mid/Side masking-threshold, the sum of Energy/Masking is changed by it too, and it thus changes some MS/LR switching.

Takehiro thinks it is too hackish to make another switch, which only adjusts the sum of Energy/Masking value (without adjusting MS-masking) so that Mid/Side-switching could be controlled separately from the Mid/Side-masking. Instead he says Lame developers should find ways to improve masking calculations in the psy-model.

Obviously there have been some changes in psymodel masking calculations in alpha builds, so --nsmsfix value have to be somewhat different than in 3.93.1 and earlier in order to get about the same sum of E/M -> MS/LR switching distribution.

edit: Heh, also this was the first time I heard about --maskingadjust. Like the -V switch, it adjusts the VBR masking. As far as I know --maskingadjust does just that, where as the -V adjusts few other things as well (although now Gabriel is going to change totally the way -V works, by pointing certain presets to different -V values afaik). So with --maskingadjust you set the VBR masking "offset" point, and with --ns-bass/alto/treble you can adjust more precicely the certain frequency areas from the offset. --maskingadjust and --ns-bass/alto/treble adjust both Mid/Side and LR -masking.

Yes, --maskingadjust only changes the masking. (I just introduced it)

You can simulate -V behaviour by:
*selecting vbr mode (--vbr-old,....)
*using ath4
*using --athshape
*using --maskingadjust
*using --lowpass

When you specify an --athlower value, it appears LAME divides that by 10 (look at the "level adjustement:" value when encoding with verbose). So --athlower 3 is really lowering the ATH by 0.3dB, not 3dB. Is this the intended behavior?

Sorry, maybe it's a little bit off-topic, but here are are some quick results concerning encoding speed for the new std preset with lame 3.94a10. I have found 4 different compiles giving the same output:

--preset standard with nbozovic's (aka nebob on the board) compile (05/02/2003):
1.091x
--preset standard with mitiok's compile (05/02/2003):
1.085x
--preset standard with west's compile (03/02/2003):
1.049x
--preset standard with john33's compile (02/02/2003):
1.005x

Comment : the fastest one offers 8% more speed than the slowest one.

Tested on a single 6'23'' song. My computer is a PII 333 with 128Mo RAM and WinXP SP1.

CU,
Manu

@tigre:

I conclude, that 3.94 Std doesn't like salsa.

no. I conclude that the new standard is close to the old one. in terms of quality AND size.

According to results, 3.94std is 2kbps higher than 3.90.2 on average.

So perhaps we need to lower it, but the difference is not that huge.

IMHO, the focus should be on on transparency in APS and not on notions of keeping the bitrate inline with previous versions. As a heavy consumer of APS mp3s, it would not bother me in the least to have average album size go from 100mb go 120 if it meant that a great deal more safety could be attained when it comes to quality, and I'm reasonably certain that can also be said for the vast majority of APS users. The bitrate standards set by APS in 3.90.2 are imperfect if not arbitrary and though they worked out pretty well, they do not necessarily represent what the bitrate that mp3 as a format requires to achieve transparency in all situations.

How much testing needs to be performed on 3.94 for it to be accepted at HA as the new, recommended version of LAME?

My understanding is that extensive testing was done on 3.90.2, but I don' t have a sense of what "extensive" means. What is the criteria for 3.94 to be considered "finished?"