Ok, I'm quite busy, but I'd like to rise this question again..
In my opinion one of the biggest problems of nspsytune is its pre-echo handling still, and especially with long-blocks.
Since the block-switching is not nearly perfect, many times long blocks are used with attacks. Also sometimes transients are just not so sharp, that short blocks would be chosen.

I compared nspsytune lines:
-b320 -h --nspsytune --lowpass 20 --noshort --athtype 2 -Z -X0
-b320 -h --nspsytune --lowpass 20 --noshort --athtype 2
--alt-preset insane --noshort
against gpsycho line:
-b320 -h --lowpass 20 --noshort

The first nspsytune line sets the same properties as gpsycho line (same athtype, same noise shaping type, same noise quality measurement mode). Actually both nspsytune lines handled long-block pre-echo pretty much equally poorly, but first line could be considered "more fair".

some of the test clips I used to demonstrate this:
http://lame.sourceforge.net/download/samples/castanets.wav
http://sivut.koti.soon.fi/julaak/castanets_si02.flac
http://sivut.koti.soon.fi/julaak/blips.flac
http://sivut.koti.soon.fi/julaak/vangelis1.flac

Despite Dibrom's --alt-preset insane tweaks, nspsytune's long-block "problem" still is there.
--alt-preset insane does not solve nspsytune's long-block pre-echo problem...with blips.wav this long-block pre-echo problem is especially noticeable. Of course if block switching works correctly long-block pre-echo handling is not an issue. Of course normally Lame uses short blocks with sharp attacks. --alt-preset insane is still not very good with castanets_si02.wav - Gpsycho was clearly better. Same thing with castanets.wav, vangelis1.wav and quite a few other clips.

In my opinion Naoki should take a look what's going on or at least address this for nspsytune2. I've often thought, that nspsytune is not producing better pre-echo handling than gpsycho. This probably means for both long-blocks and short-blocks.

[edit]Edited out the incorrect pictures. EncSpot 1.1beta2's block-switcing view misses short-blocks. I verified this with mp3x-frame analyzer.

Hmm, I talked about this with Naoki, and although he agrees about the pre-echo part, he said that EncSpot 1.1beta2 displays the block-switching incorrectly.
I also checked this with mp3x, and yes, EncSpot misses short blocks, so the pictures were not valid.

Everything else is, though.

I suggest trying fastencc.exe -hq -br 320 on those samples to get an idea of just how good mp3 can get with pre-echo.

Maybe tuning for those samples messes up other samples (like fatboy).

ff123

fastencc.exe isn't freely available, is it?

Yes, it is. You can get it here: http://www.geocities.com/fastenc/files1/fastencc.zip

Hey thanks... how come Fraunhofer is giving this away free?

Suppose I wanted 192k CBR files (for my portable player)... is the general consensus that Lame --alt-preset cbr 192 will still sound better on the majority of music than fastenc v1.02 with -br 192 -hq?

Edit -- the reason I ask is in the title of this thread .

About nspsytune vs gpsycho:

I don't really have time to deal with this at the moment, but we have discussed this in the past, and I am aware that nspsytune is not always better on pre-echo than gpsycho. However, back in the dm-preset era, myself, ff123, and others had found that often nspsytune (at least on many clips, and furthermore with nssafejoint) did sound better than gpsycho in this regard. One of the clips we used to test this was florida_seq, another was castanets.

I believe part of the issue here may be nspsytune with cbr not performing quite as well as with vbr.

At any rate, the benefits of using nspsytune still far outweigh a possible few scenarios where it may not perform as well as gpsycho (forced to the same bitrate) in regards to pre-echo. The audible improvements (listed in the LAME changelog) --alt-preset standard provides over almost all other LAME command line, is a testament to this. Admittedly, I did add quite a few small psymodel tweaks on top of nspsytune with the --alt-presets, but even without these, many improvements are still there. Ironically, in regards to this thread, included within the list of improvements the --alt-presets provide, is much better pre-echo handling on difficult signals, and impulses especially Try encoding fatboy or something similar with --alt-preset insane, vs the gpsycho line, and api should come out sounding much better.

I do think that Naoki should attempt to look into this matter, but I don't feel the situation is quite as it's made out to be, with the implication that nspsytune is always inferior in regards to gpsycho with pre-echo. This is not the case as some examples show, and I'm sure Noaki would agree with this as well since he and Takehiro significantly modified and tuned the pre-echo routines in gpsycho to what they are now in nspsytune, specifically to improve handling in many cases.

It's a dubious thing, this fastencc.exe. I don't know what to think of it

But be careful when using it, it is affected by evil the stereo collapse bug - http://ff123.net/fastenc.html (ff123, is your site down at the moment? :confused: )

CU

Dominic

Edit: Yes, of course, only the normal setting is affected, I forgot that

The site is up. The stereo collapse bug only affects the fast (default) mode. -hq is fine.

ff123

So do you think it's worth (with -hq) for 192k and below CBR? Or some other recommended range of bitrates where it could have less pre-echo than Lame and better sound?

Just looking for an opinion here, I understand that opinions vary quite a bit. TIA.

This codec is the same as MMJB "very high," which as I recall you said you don't use any longer because it is too slow. While it is good with pre-echo, it has some other flaws in it at 192, including occasional low-freq dropouts.

ff123

Dibrom, I'm not talking about -alt-preset vbr modes, I'm talking pure gpsycho-nspsytune head-to-head fair preset comparison. In my opinion gpsycho wins in pre-echo handling. And we can still hear problems even with alt-presets pre-echo tweaks, direcetly related to nspsytune, which are not present with gpsycho.

Well, anyway. Naoki has acknowledged this. I believe, he said that also Robert has said the same this as I. nspsytune needs better pre-echo and it's possible to implement and pre-echo handling is not clearly better than gpsyco, it's often clearly worse.
Naoki is working on it for nspsytune2.
I can do some test, and show some samples to prove my point early next week.

I do acknowledge that gpsycho is sometimes better than nspsytune on some pre-echo, I'm just not convinced that this is always the case. If that were so, it would seem to contradict some test results from quite awhile back.



Hrmm.. I'd be interested in Robert's statements in this regards. When I was originally talking to him quite awhile back, he really didn't seem to have much experience listening with nspsytune or really knowing exactly how well it performed in many situations (originally, before the --dm-presets, it seemed that mostly the only one really having tested nspsytune much was Naoki, and even then he hadn't worked on it for some months). For that matter, it would appear that the --alt-presets often go against what some of the developers would "think" would work... yet somehow they do work really well. I know the --alt-presets aren't the issue here, but what I'm emphasizing is that (and no offense to the LAME team), often times it appears the LAME developers don't have the best understanding of real world performance of certain aspects of the code, due to a lack of rigorous testing.

At any rate, I have talked to both of them in the past as well (before dm-presets), and have also stated my concerns that pre-echo control is not that great in either gpsycho or nspsytune. Both agreed with me as well, but so far, aside from the tweaks I've made with the --alt-presets, nothing has really been done to remedy this.



Of course I agree with the first part, I'm just not so sure that nspsytune is as bad as implied all around. Furthermore, at least from the perspective I speak from, when I say that nspsytune is "better for pre-echo", I also take into account the many tweaks and modifications I made which built upon this already. Surely you'd consider the much improved impulse handling as "better pre-echo control".



I believe what you say, I just don't know if I feel it's to the same degree. Admittedly, I stopped comparing nspsytune and gpsycho for pre-echo handling quite awhile ago since nspsytune offers so many other improvements, so it could be possible. However, that would also seem to contradict some very early testing like I said before.

In short though, I do very much agree with you that the pre-echo handling in LAME (in both gpsycho and nspsytune) could use some serious work still.