I exchanged my settings from my previous post (http://www.hydrogenaudio.org/forums/showth...s=&threadid=614) with '--alt-preset fast standard' and when I look at the histograms it looks, as if this mode uses more than double the number of strict stereo frames than my old settings. This way the files are much larger. Any explanations for this ?

--alt-preset fast standard uses a higher msfix value, this is the thresholed that LAME uses for choosing between ss and js frames. Add --nssafejoint to your command line to get the same results.

You mean: '--alt-preset fast standard' has the --nssafejoint switch activated ?
Is the --nssafejoint switch an improvement concerning sound quality and/or space usage ?

I don't know if exaclty the --nssafejoint switch, but for sure some switch/tweak that changes ms_fix value (btw, it's the same that nssafejoint does hehe). Yes, it's an improvement because prevents dropouts and other artifacts. In the other hands, a ss frame demands more bits in VBR than a js frame, so you get a bigger bitrate.

--alt-preset fast standard uses --nssafejoint with --nsmsfix 2.13 in addition to some other custom modifications to the way masking is handled for joint stereo. In my experience this does not lead to a significant jump in bitrate unless it is necessary. These modifications fall under the "improvements to joint stereo" mentioned in the 3.90 history and they definitely allow an improvement in sound quality. Perhaps the most notable clip where this is present in is "serioustrouble".

Still, I'd like to know, why 'fast standard' produces
average: 220.0 kbps LR: 4333 (53.30%) MS: 3796 (46.70%)
or similar results on my music (in this case: I want it all from Eurythmics).
All other settings I tried produce a maxmimum of 12% strict stereo frames. Doesn't anybody else get these results ?
And what is more important: if the fast standard setting requires so many frames to be encoded in strict stereo, maybe the other settings generate 'bad' stereo sound....

erm, it would be interesting, if fast standard produces nearly the same stereo frames like extreme. Can you test it with your test song ? (how many stereo frames with extreme ?)


Every new compile I test with song "Leaving Las Vegas" by Sheryl Crow & Friends Live from Central Park, it is over 7 minutes long. I use this test song since a longer time, because it has had nearly a quite high pitrate and in past a lot stereo frames, so that in past it was an extreme test, as I remember, it was the song with most stereo frames in joint stereo mode/with nssafejoint) I ever had.

test setting always:

--alt-preset extreme -b224 -F
(to feel safe of using really high bitrates and not to have to write here a lot percentages of different bitrates)

This override to 224 works always.


Eg. with Lame compile of 2001 12 15 I have following:
99,7 % stereo frames (0,3 % mid/side)
224 21%
256 34%
320 45%
Average bitrate: 278
long blocks 97,8 %

With latest compile of 2001 12 29:
44,2 % stereo only !!
224 55%
256 23%
320 23%
Average bitrate: 253
long blocks 97,8 % the same as in past

This test song has been one of my songs with highest bitrate and most used stereo frames.

Now I am a little bit concerned that exrteme uses too much mid/side frames to save bitrate.
With normal music there have been less stereo frames in past, too, and resulting lower bitrates than 280.
So in past there has been an average bitrate around 250 to 260 if you have encoded a lot different albums.
But I remember that with complicated music it reached 280 and that was allright, because that music was interesting, no saving at the wrong place.

It may be that now the extrme preset results in more stable averageing bitrates around 256 kbit, but as I see, even that 278 song results only in 253.

As conclusion I want to test to add --nssafejoint to my preset, but it did not work, it resulted the same.


--alt-preset extreme -b224 -F
the same result like:

--alt-preset extreme -b224 -F --nssafejoint or:
--alt-preset extreme -b224 -F -m j --nssafejoint




Forcing extrme to use only stereo frames, worked with newest Lame 3.91/3.90.02, some overrides like -b224 -F and -m s work.

example:
--alt-preset extreme -b224 -F -m s vs. --alt-preset extreme -b224 -F

100% stereo instead of 44,2%
224 46% - 55
256 23% - 23
320 32% - 23
long blocks 98,8% - 97,8 (short blocks slightly reduced compared to extreme as it is)
average slightly increased to 262 instead of 253


But why can I override with -m s and not with --nssafejoint or --nsmsfix 1.0 ?



Hi I have tried some variants:

--alt-preset extreme --nssafejoint --nsmsfix 0
--alt-preset extreme --nssafejoint --nsmsfix 1.0

Both resulted to the same like normal
--alt-preset extreme

Only
--alt-preset extreme -m s
resulted to something different than exrteme, of course with 100% stereo frames, but I want to activate joint stereo with nssafejoint....

I Want It All - Results on my web page:
http://divx4.org/user.gif

This of any help for you ?

Thank you very much.
It shows that with these two test songs (mine Sheryl Crow and your Eurythmics) there is a similar use of stereo and mid/side frames in both settings, fast standard and extreme.

The Eurythmics forces lame to use a bitrate of 270 with extreme, so there are still songs which demand very high bitrates.

I am going to test more with the new alt switches and some more test songs/albums.

But it is still interesting why for test purposes overriding with nsspytune not works.

Fast standard uses this many stereo frames because on the files I've tested on, it needed this many stereo frames to sound good. And yes, you can read "improved joint stereo" in 3.90 in the alt-presets to mean that the "normal" LAME behavior uses far too little stereo frames in some situations.

Remember that not only is --nssafejoint and --nsmsfix 2.13 used, but there are also other changes made internally which there are not switches for, so you may not be able to exactly match the behavior via the commandline unless you specify --alt-preset fast standard first.

Edit: Oops.. Dibrom again. Sorry for the confusion.. heh.

This is by design. In the past extreme used more stereo frames than were necessary.



This is not the case. It's called more efficient handling of joint stereo. --nssafejoint --nsmsfix 1.0 uses too many stereo frames and does not directly address the area where joint stereo in LAME has failed in the past. Instead it is more of a "sweeping" approach that inadvertently fixes the problems but results in too high of a bitrate because of wasteful use of stereo frames.



It's not an issue with "complex" music, it's an issue with LAME using too many stereo frames in a wasteful manner with --nssafejoint (nsmsfix 1.0). This is because the tuning which is related to how much masking should be used is not calibrated properly unless --alt-preset is used.



Because of the way --alt-preset handles joint stereo. As I've said before, you cannot always use experimental switches with --alt-preset and expect them to behave the same way, because internally things work much differently with this mode than with the standard LAME presets.

In conclusion, --alt-preset extreme is tuned to sound good, not to behave how you "think" it should behave and unless you can actually abx a difference where you believe more stereo frames should be used, I will consider it a non-issue.

Just a small note that might be interesting to you... --alt-preset extreme should be more sensitive in the areas where LAME failed in the past with joint stereo than simply using --nssafejoint. It addresses the situation more directly and adjusts masking in the manner safejoint did, but to an even greater degree, and only exactly where it is necessary. This is a much more efficient and proper approach.

Thank you for explanation, Dibrom. The changes and improvements are amazing in such a short time.

In various threads (including this one), it seems like LAME is almost at the point where there's a de facto code fork between the "standard" LAME behavior and the --alt-preset LAME behavior. It started out just being some presets as shorthand for long complex sets of switches, but if now it's actually different code internally, isn't that somewhat of a code fork? There's "normal LAME" and there's "DiBrom modified LAME," they just happen to both be distributed in the same executable...

Hi,

I don't think it's a fork.

In Dibroms compiles you can use normal, old switches, too !!!!

But there are additional the alt presets.
They work on their own way, of course.

And in mitioks compiles you have same behaviour, there are alt switches, too.

The alt-presets in Dibrom's and Mitiok's Compiles are different ?

Not now. There the same. Dibrom's latest changes were folded in as 3.91 stable.