First, please note that it has been a long time I didn't really looked
inside of the Lame code, so I'll perhaps tell a few wrong statements. (btw,
please could anyone explain me when to use the word "tell" and when "say"?)
> If I understand correctly, the "-mj" is evaluating if a frame
> qualifies for M/S coding beforehand, and if so, it will then be coded
> in M/S, independent of the outcome.
There is also another parameter: trying to minimise the toggling between s
and ms
> I've heard my fair share of examples where lame opts for M/S, but
> afterwards this is a bad choice, giving a M/S frame sounding much worse
> than S would have, or in vbr, more bytes are used on the M/S frame
> compared to the S frame.
Does this really happens in vbr? Could you please try using Mp3x and see if
the same frame could sometimes use more space in ms than in s? It seems so
strange...If it's true, I think that there is a mistake somewhere in the ms
bit allocation
> problem: once the criterium is met, and a frame tagged as
> "M/S"-material, it will always be a M/S, even if S would have been
> better.
Not always: I think that if we got something like s-s-s-ms-s-s it will be
converted before bitstream formatting to s-s-s-s-s-s in order to reduce the
togling artefact.
> Big advantage of this prediction method is the speed.
I don't know if it's still the case, but in the past both ms and s data were
computed as the mode of a frame could be changed according to the next one.
> Since you never have 100% accurate prediction this is one of the most
> prominent causes of poor quality in -mj mode. (read that post
> of me referring to 192JS of the Velvet track)
This Velvet track must have some (perhaps not yet known) other difficulties,
as the results are quite catastrophic for every encoder, including mp2 ones.
> What I'm suggesting: a "-mx" mode (or whatever letter)
>
> it would be a JS mode, but unlike the "-mj" mode it would not try to
predict
> anything, but just achieve optimal quality in an empirical way.
This is, to my mind, the goal of -mj, so any change should be made into -mj
> I'd be slow, but it'd be the best possible quality for cbr and best
quality/size
> for vbr. (as far as I can see)
not so slower, if both sets of data are already computed
just my 2 centimes about it...
Regards,
--
Gabriel Bouvigne - France
[EMAIL PROTECTED]
icq: 12138873
MP3' Tech: www.mp3-tech.org
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
