I'm sure this has been asked before, but I can't find it, and it's not in the FAQ (it should be - please!)

On which samples is --alt-preset extreme audibly better than --alt-preset standard.On which samples is --alt-preset insane audibly better than --alt-preset extreme.On which samples is --alt-preset insane not transparent?

Of these, awe32_20sec, birds, erhu and liebestod make me think that, on music I'm likely to encode, there's a very small (but greater than zero) chance of an artefact being encoded. Whether I ever notice it is a different matter!

The problem is audible in headphones in a silent environment.The reverberation after each noise is cut.The "KRRRRRRsssssss", where "KRRRRRRR" is the noise, and "sssssss" it's decaying echo become"KRRRRRRss---s-s--s", where - are silences.

Extreme is better, but not really hard to ABX. --insane is often near-transparency.

Interesting to note : I find Fhg codec bundled with CoolEdit (VBR qual 100 HQ lowpass 20Khz) MUCH better than --alt-preset standard (3.90.2) for the same bitrate. And on a quick audio comparison, I find --ape a bit worse than the same Fhg encoding (but I need to ABX in order to confirm my impression with this sample).

glass_shortABX 7/8 - there's a "blip" about half way through. It's the same kind of problem as birds and erhu.

also... I know the song, but I've forgotten it, so can you tell me where "Jump" is from please? Artist and Album? Thanks!

btw, why do you .zip some ape files?

Cheers,David.

P.S. can these samples from other places be added to the HA samples folder please? Specifically, awe32_20sec, and the above two, if it's OK with guruboolez. With sensible all lower case and no spaces filenames in .flac format?

· Jump is a song from Van Halen (1984 album, but not sure).· Funny, but I never notice any artifact with --alt-preset standard on the glass_short sample. I uploaded this sample in order to show the funny behaviour of mppenc at --standard preset (something like 260 kbps for a tonal sample)· I can't put a direct link with a zip or rar file. There's an anti-leech system on Lycos pages.

EDIT : Yes, you're right, a 3.90.2 encoding has the same artifact than with erhu. No problem (or really low) with 3.94.a12. I never noticed it on a larger sample.

4. It doesn't help awe32_20sec at all. For me the artefacts (the bass drum sound changes) aren't even subtle - I don't need to ABX - I can just get "X" correct without comparison. I've created an even more difficult sample (or obvious problem) by delaying one channel of awe32_20 by 40 samples.

aps -Z bitrate is significantly lower than ape on these samples, and yet the blip in erhu is still obvious with ape. This suggests that, for this sample/problem, ape doesn't deliver the "safety margin" it promisses, and is actually wasting bits without solving the problem. --alt-preset extreme -Z solves the problem, and I think it fixes Fugue too (compared to aps -Z). It doesn't fix awe32_20sec, but it improves it (compared to aps -Z).

Since glass_short wasn't even posted as a problem sample for aps, yet revealed this "blip" problem, which is present in two other (relatively normal) clips, isn't it sensible to suggest --alt-preset standard -Z as the "standard"? Or am I just being too picky?

According to some tests I performed some time ago, CEP 2.0 Fhg codec, VBR max quality, was noticeabily worse than LAME aps on usual pre-echo test samples, but was better in trumpets1.wav. Still, LAME api was the best on this sample.

There will be no further improvements by me if that's what you mean. 3.94 looks like a step in the right direction, but it sounds like there is a lot of tuning left to do, which is always the hardest part. I don't know how things will turn out in the end, but my involvement with LAME has been over for awhile.

aps -Z bitrate is significantly lower than ape on these samples, and yet the blip in erhu is still obvious with ape. This suggests that, for this sample/problem, ape doesn't deliver the "safety margin" it promisses, and is actually wasting bits without solving the problem. --alt-preset extreme -Z solves the problem, and I think it fixes Fugue too (compared to aps -Z). It doesn't fix awe32_20sec, but it improves it (compared to aps -Z).

Originally, I had planned to modify --alt-preset extreme to use noise shaping 1 but stopped working on LAME before I got around to it. At the time 3.90.2 was released, most of these samples weren't known about and so I believed that I'd finally fixed the artifacts related to noise shaping 2. Most of the problems were solved, but a few remained which were discovered later in the samples you've pointed out.

So, yes, in place of --alt-preset extreme, one should probably use --alt-preset standard -Z instead. FWIW, --alt-preset extreme never really did provide much of an improvement over --alt-preset standard, if any improvement at all. I've never recommended that people use this over --alt-preset standard, and have instead recommened --alt-preset insane if they find --alt-preset standard to be insufficient for some reason. I guess the main reason that I even included an --alt-preset extreme option is because I knew that people would tweak beyond --alt-preset standard even if they couldn't hear the difference anyway, so I figured it'd be best to give them a theoretical improvement rather then have them use some external switches which would negatively impact the --alt-preset behavior.

(the ratings are relative - none of the files deserves lower than a 4.5 on the true MOS scale)

With awe32_20sec_2 the artefacts are more obvious, so I haven't ABXed today, but the differences are similar to above:

aps = aps -Z : not at all transparent (noise on first two bass drum hits)ape = ape -Z : much better, but still thereapi : even better still - but still very slight problem on first bass drum hit

On Fugue, the size of the difference in quality approximately corresponds to the size of the difference in bitrate.On awe32_20sec_2, api is much larger than ape, but only a little better. ape is much better than aps, but only a little larger. (exagerated, but you get the point).

It seems there are (at least) two categories of artefact remaining:

one which occurs because of noise shaping 2 and can be removed by -Z

another due to "spiky" waveforms which mp3 just doesn't like, but can be minimised or removed by using the highest possible bitrate --alt-preset insane

maybe yet another due to pre-echo on some (soft?) transients with nspsytune, which can't be solved without another new psymodel.

It was interesting to hear your reason for creating --alt-preset extreme Dibrom. It seems that there is a practical use for the preset though: reducing the audibility of artefacts on the most difficult files, without hitting 320kbps. However, to quote your usual advice, if you really want to encode impossible files "as well as possible", use api or (better still) move to mpc.

The quality goes upwards from aps > aps -Z > ape -Z > api.

ape without -Z doesn't fit into this progression, since it's worse than aps -Z for some samples, but better for others.

It seems to indicate that there are samples where using -Z to force use of that particular scalefactor can produce problems too, so the specific problem samples you tried, where -Z was no worse, might not be representative of the whole spectrum of music.

Of course, in the present thread, Dibrom has noted that certain samples (like those you tested) weren't known about then, so perhaps his opinion is now revised.

--alt-preset standard is well tested and lacks transparency only on rare cases. I don't think --alt-preset standard -Z has been tested anywhere near as much and shown to be OK, so I won't be using it, but I might try it if I notice a specific problem with APS (which won't be too often, now I mostly encode in Musepack mppenc --quality 5 --xlevel).

JohnV did say exactly that, but Dibrom said "and by specifying -Z you may end up degrading quality in cases as well."

I can't figure out if he had any specific for saying this, because it came in one of the (at the time) very frequent replies which essentially said "Look, don't worry about the switches which are in --alt-preset standard, because there are things which can't be accessed from the command line; and don't try to improve it by adding other switches, because it's already as good as it can get, and more importantly, you'll almost certainly make it worse by trying to 'tweak' it".

So maybe he had a very specific problem in mind, or maybe he was just trying to stop people messing with the --alt-presets.

With the many tests samples I've been trying, I am slowing coming to an even more contraversial conclusion... r3mix is often better than --aps!!!

Sorry - only joking! I should have tried this one on April 1.

Seriously though - I have found something which no-one here has ever said, probably because no one uses 128kbps CBR mp3: --alt-preset cbr 128 is often worse than -b 128 -h (i.e. the lame default). ap cbr 128 is probably better in the majority of cases (though I wouldn't bet my life on it), but there are many many samples where -b 128 -h is actually better than --alt-preset cbr 128.

This isn't a late April fool - try the samples listed in this thread for starters. Much of the time neither command line is transparent, so to some extent it depends on which artefacts you find most annoying; but there are some cases where lame default beats the "tuned" line hands down.

Just thought it was worth mentioning. I've already PMed ff123, who helped develop the command line behind --alt-preset cbr 128. Maybe the fact that it's worth trying other things (even other encoders) at 128kbps should be in the HA FAQ - and/or a subject for further lame tuning?

It has been said many times that Gpsycho has often for example better pre-echo control than plain vanilla nspsytune preset, so I don't know if that's anything new. Many times it has been said that the non-codelevel tweaked presets aren't necessarely always performing better than some other switches with a bunch of samples. The --alt-preset cbr 128 also suffers (although prolly not quite similarly) from the use of noise shaping type 2. Try the samples listed in this thread using --alt-preset cbr 128 -Z although this may not be ideal overall... And since GPsycho uses noise shaping type 1 by default, it performs very well with those samples which fail with ns-type2...

gpsycho plain vanilla -b128 -h is indeed not bad for 128kbps. But if you use abr, I think the advantage will turn more clearly to nspsytune considering overall quality aspects.

And no, in vbr coding I don't believe that using noise shaping 1 (-Z with APS/APE) will lead to worse quality, but it definitely leads to better quality in some cases. Lower quality with noise shaping 1 is definitely possible with lower bitrate cbr though.