Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: alt preset extreme -m s ?? (Read 48120 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

alt preset extreme -m s ??

just wanted to make sure this command line was ok.  no conflict or anything?  I assume i could use -m s with preset standard as well?

thanks,
juglesh

alt preset extreme -m s ??

Reply #1
This was asked before many times, mostly by people who have been 'brainwashed' by some audio ripping community that joint stereo is a bad thing and simple stereo is always better.

While this may be true for a few popular encoders which have screwed up Joint Stereo implementation (FHg, Xing, etc), this is not true for LAME. Phase information is actually preserved in LAME (allowing for Dolby Surround information to be preserved). Used properly (i.e. all the --alt-presets), you should not encounter problems with Joint Stereo, and even if you do, the problems caused by Joint Stereo will not be as bad as the problems caused by the lack of bandwidth if you don't use Joint Stereo.

The second mistake people make is to assume that for VBR, it doesn't matter as long as they don't mind the bitrate increase. However they fail to forget that there are maximum frame sizes in MP3s. Sure, you can use simple stereo and increase a 128kbps frame to 256kbps frame without any problem. But you are talking about high quality VBR presets which average 192kbps and 256kbps. Especially for extreme, most of the frames used will be 224kbps, 256kbps and 320kbps frames.

Now you see the problem? You can use at most 320kbps frames, so in standard and even more so in extreme, using simple stereo, you will end up packing less data into a frame and this will cause problems to occur.

For a better understanding about Joint Stereo vs Stereo, let me refer to a discussion I had with Dibrom a couple of months back when he was tuning --alt-preset normal (an experiment which was eventually abandoned). At that time he was toying with the idea of forcing all short blocks to be 320kbps frames as a method to improve tracks with impulses and preechos (fatboy, castanets etc).

I then suggested to Dibrom to revert to normal joint stereo (the preset defaulted --nssafejoint) to increase the bandwidth for the 320kbps shortblocks (preecho can be reduced by allocating more bits to encode more coefficients of the transform). Dibrom discovered that this did not help. The problems caused by the joint stereo mode actually worsened the pre-echo and impulses.

Dibrom then tried something different, forcing stereo mode for the 320kbps shortblock. This also worsened the pre-echo and impulses. Not surprising because there's less bits available to encode the coefficients. I asked him to try experimenting with --ns-msfix values, but I don't think he actually went on to try that out.

So as you can see, joint stereo is a good thing because it increases bandwidth to encode the coefficients of the transforms. However there is also the chance of introducing artifacts and problems itself it not used properly. The --nssafejoint switch will cause the encoder to use as much JS frames as possible while making it safe against the artifacts. There is therefore no need to use simple stereo at all. JS with --nssafejoint will give you both the safety you need from JS artifacts and the additional bandwidth from using JS (but not as much bandwidth as without the --nssafejoint).

For lower bitrate encoding, of course, you would probably not want to use --nssafejoint because at that rate, the problems introduced by JS will be less than the problems of lower bandwidth. This is illustrated by looking at the --alt-preset ABR settings (Refer to abr_switch_map[] in parse.c in cvs). JS is used normally up to 160kbps. After that, --nssafejoint is introduced with a --nsmsfix modifier of 1.7 at 192kbps and 1.25 at 224kbps. At 256kbps, the full --nssafejoint is used.

For more details about the custom modifications Dibrom made to --nssafejoint and --nsmsfix check out this thread http://www.hydrogenaudio.org/forums/showth...?s=&postid=4727

alt preset extreme -m s ??

Reply #2
no, i havent been brainwashed, but i have washed my ears lately, have you?

juglesh

alt preset extreme -m s ??

Reply #3
juglesh sounds 31337 enough. He is probably right. Stereo r0xx0rs! And he washed his ears too.
[span style=\'color:maroon\']remember sammy jankis[/span]

 

alt preset extreme -m s ??

Reply #4
There's gonna be more ringing/dropout artifacts if you encode with pure stereo.

One good clip to check this out is serioustrouble.wav
Juha Laaksonheimo

alt preset extreme -m s ??

Reply #5
ok, i'll give js another chance, but where's this serioustrouble.wav?  I'm comparing mahavishnu orchestra right now.  This recording has serious stereo separation, guitar on one side, violin on the other, etc.

havent heard any funny stereo stuff yet, but havnt got ringing in th esimple stereo one either.

i'll make sure to give my ears a good scrub.

juglesh

alt preset extreme -m s ??

Reply #6
Hello juglesh,

Serioustrouble is at http://ff123.net/samples.html

You say you want to give the alt-preset Another Chance with js - what was the problem?
On which sample was forcing ms better sounding?


Wombat
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

alt preset extreme -m s ??

Reply #7
in general, lots of stuff ive d/l'ed has been screwy sounding with js.  maybe like ppl say, its been fixed with latest lame.

juglesh

alt preset extreme -m s ??

Reply #8
Hehe the d/loaded stuff may of been encoded with Xing or Blade or some poorly implemented MP3 encoding method.

*EDIT* Therefore leading to poorly implemented JS routines.

Use Lame 3.91 with --alt preset
-=MusePack... Living Audio Compression=-

Honda - The Power of Dreams

alt preset extreme -m s ??

Reply #9
Quote
Originally posted by juglesh
in general, lots of stuff ive d/l'ed has been screwy sounding with js.  maybe like ppl say, its been fixed with latest lame.

juglesh


Ah, stuff you downloaded. So you don't even know which settings were used to encode. I personally trust no single file I do not exactly know how it was encoded.
Please remember --alt-preset uses --nssafejoint, which slightly different to conventional -mj modes.

alt preset extreme -m s ??

Reply #10
There's no need for cleaning of ears or anything. Improperly used and improperly done, JS will cause problems. Properly used and properly done (i.e. using LAME with --alt-preset) JS will be superior.

alt preset extreme -m s ??

Reply #11
http://www.digital-inn.de/showthread.php3?threadid=8212

stereo vs. joint stereo - mid/side

Hi,

I would not damn unregistered so hard.

Please remember, everybody has different tastes.

alt presets have been tuned regarding different quality aspects of music.

One of those is pre echo.

ff123 proved, that ap standard is much better regarding pre echo.

That was to expect, as castanets is a hard example for pre echo and alt
presets have been tuned regarding pre echo.



But unreg. did not spoke of pre echo artifacts, he concerns about stereo
image.


And some of his arguments are quite well.
If you want to gain a lot quality and you are not worrying about some bytes
in resulting bitrate, then you don't need js in extreme setting.

My above sentence is of course not exact enough.
VBR mode choses a suitable bitrate regarding a certain level of quality.
If you force VBR to use only ms/stereo frames, then the bitrate will
increase (not much compared to actually alt extreme setting).
One exception:
What happens, if music is so complex that VBR would take a higher bitrate
than 320 ?
Then it would take a 320 mid/side frame. That is the best compromise regarding
all, frequency, tonality, stereo image etc.

RESULT:

From a theoretical point of view you need only joint stereo /  mid/side sometimes with
difficult music in 320 kbit frames. All other possibilities could be solved
with stereo frames, as long as you stay below 320.

Overall resulting bitrate would be a little increased over actual alt preset
extreme.


At the moment users like unreg. have a nearly perfect solution:

Overriding --alt-preset extreme

with:

--alt-preset extreme -ms


This solution has got one disadvantage:

If music is so difficult, complex, that Lame VBR mode would decide to take a
higher bitrate than 320, because then 320 mid/side would be taken and it would be
best compromise. But with overriding switch -ms this solution is not
possible.


Perhaps it is a new idea for Dibrom, to tune --alt-preset extreme regarding
stereo image.
I would suggest following:
Either : ap exterme with normal/old --nssafejoint switch. I remember with
this switch there was more use of stereo frames than with ap extrme now.
Or: a kind of "If.... then...." routine : in alt extreme: generally -ms
frames, only if "Lame" wants more than 320 , then lame takes 320 mid/side. This
would lead to only use of stereo frames in bitrates below 320, and in 320:  --nssafejoint is enabled, so
both, ms, mid/side is possible in 320 kbit frames.

I hope I described my ideas, suggestions in a way, you can understand them.



aahhh, for unreg there two ad hoc solutions:

1. as described above:
overriding --alt-extreme with -ms :

--alt-preset extreme -ms

(with disadvantage of no use of joint stereo in 320 kbit frames)


2. simply use:

--alt-preset insane

disadvantage: now you have 320 CBR.
But you told us: You would not worry about some extra kbits/s !!!

So this is the best solution for anybody who has concerns about quality.


But a further investigation of improving stereo image in apexterme could not
be bad.
Perhaps the samples of unreg. can prove or not artifacts in stereo image in
apextreme.
ABXing has to be done.

alt preset extreme -m s ??

Reply #12
Quote
ff123 proved, that ap standard is much better regarding pre echo.


I'm not completely sure, but I think the artifacting in 2nd_vent_clip.wav is caused by dropouts, not quite the same as pre-echo.

Samples which show problems with stereo image are needed before I'd start spending a lot of time on a problem which is so far not verified.

ff123

alt preset extreme -m s ??

Reply #13
I would be happy when it was possible to release a switch for the alt-presets to cancel the adaptive nssafejoint. Every setting with normal switches can´t compete with aps. But the downsides i hear sometimes are most likely caused by this. I have no chance to test around without having more control over the switches and dibrom has no time

Wombat
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

alt preset extreme -m s ??

Reply #14
Edit -- n/m, it seems my questions are answered on the R3mix forums.  Gotta 'RTFM' next time.

Cheers

alt preset extreme -m s ??

Reply #15
This is very misleading again, i wish this adaptive nssafejoint would be changeable due to testing if some kinds of distortion change in intensity. I never meant to remove joint stereo. With NO sample i provided or others think to provide joint stereo is inferior to ms from an stereo imaging point of view. Only used in conjunction with nssafe values for example it seems to be the reason for added noise in some situation, but it still has much less possibilities to fail than real ms.

Wombat
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

alt preset extreme -m s ??

Reply #16
Quote
Originally posted by Wombat
Only used in conjunction with nssafe values for example it seems to be the reason for added noise in some situation, but it still has much less possibilities to fail than real ms.
I guess you are referring to clips like sophia2.wav. In my opinion the actual problem with it using APS is not anything joint stereo threshold related. You can make it slightly better or worse by changing nsmsfix (m/s switching criterion) or mid/side masking threshold (internally), but it's not really the root or the answer of this problem. The problem is simply too low resolution because of one or various other reasons.

Essentially the same problem exists whether all the frames in problem sections are LR-coded or M/S-coded. Tweaking nsmsfix or internal m/s-masking threshold to be more or less sensitive is not the total cure in this case, though it's possible some tweaking might be part of the solution. But it really should do much better even with full LR-coding.
Just adding -Z makes it much better (and is still practically m/s-coded) than adding -ms alone.
Juha Laaksonheimo