Hello Mark,
Tuesday, August 22, 2000, 9:18:22 PM, you wrote:
MT> Problem is, this is a lot of work and it is not clear that it would
MT> really improve things.
does it mean anthing if I say it will? :)
MT> The hard part is how do you tell if M/S gives
MT> better results than S? The only way is by some measure of distortion
MT> - allowed_distortion. But as we know, all measures of distortion are
MT> just very rough guidelines - if they were really good, VBR would be pefect!
As you might know, I've been doing extensive tests on noise graphs the last
two months. My conclusion is that the VBR of lame is _very_ good.
Check out the graphs of different encoders at this page:
as you can see, the current noise-calculations of VBR seem to do what
they're intended to: minimize noise. The -V1 mp3 is actually closer
to the original wav than the 256S is.
Does the VBR sound better? Well, no, but I'm convinced the reason for
this is the shortcomming of the -mj mode.
I know you've always been very sceptical about VBR, but on the other
hand the fundamental shortcoming in JS is less of a concern?
I don't understand: How can one expect a simple MS-qualification
formula to predict how a frame will come out sounding? Like you say,
and I agree, the guess is ok for let's say 95% of the time, but 5% is
a very high failure rate in this field. I don't want my tracks to
sound ok,95% of the time. I want it 100%. (within the constraints of
what is physically possible with mp3)
The only way to have some sort of quality guarantee, is to check the
frame after encoding.
I agree with Robert that the current -mj should be tweaked in the
conventional way.
MT> Thus my fear is that if we use some function of the distortion, we
MT> will not be able to tell in a reliable way if mid/side sounds better
MT> than stereo.
I'm sure even the current "rough" formula would be enough to safeguard
from current exploits.
The reason I'm convinced of this lies herein:
At current, the (extremely likely) reason the JS vbr file runs up in
bitrate is that the current distortion-meter used to determine
acceptable distortion actually works!
Let's put some things together:
I've got a 192S file sounding ok
I've got a 192JS file sounding bad
I've got a -V1 S sounding ok
I've got a -V1 _sounding ok_, but with remarkably larger number of 320
frames.
This suggests that:
current noise calculations on the VBR picks up on the JS distortion,
and compensate for it! (otherwise the -V1 -mj would have sounded bad)
now instead of compensating by making the bitrate higher, you could
try the S-frame alternative.
Lame VBR is the best in the world. Thanks to your and others' work.
MT> Here is what I would suggest:
MT> (I've done this many times: it is tedious and a lot of work!)
my point exactly :))
MT> Can you isolate the problems in velvet.wav to a few frames, and then
<cut very long and detailed explanation, which explains a lot>
MT> skew the average downward.
Thank you for the great explanation.
I will look into this asap. I'm doing some exams this week,
so time's very limited at current...
..
I think this issue should be looked upon _long-term_.
We both recognize that the current -mj implementation does not give
one guarantee of good quality.
Instead of spending countless hours (what you also recognize) trying
to fight symptoms, why not build up an approach like -mx that measures
instead of predicts?
* Who is to say that a tweak to the M/S conditions to fit "velvet"-needs
will not have negative implications on other clips?
* What's the impact of these current -mj files where, once a minimal
requirement is met, M/S is defaulted? I get files with >90% M/S
frames. Does this "feel" natural? Wouldn't it be more credible if you'd
get a file with a more mixed distribution of S-M/S?
* tightening the M/S-allowed condition, will undoubtedly decrease the
potential gain in available that can be harvested with -mj mode. (say
you tweak -mj to get that number of 35% M/S frames in Velvet even
lower, to the point where the artifacts are gone)
(* are you sure about the quality implications of rapidly switching
S-M/S?)
* how about <112kbit/s frames? Shouldn't the predictive model be
(more?) adaptive to different bitrates?
* What if you'd optimize your psycho-accoustics? How would this
impact on your prediction model?
You get the point? All these uncertaincies can be resolved quite
simply: introduce a measuring-based model rather than a (increasingly
complex) model based on "assumptions".
I can only speak for myself, but don't you feel a curiosity how such
an -mx mode would act? _What if_ it returns 50% S frames where the
current model returns only 5% of them? Would you reshape your opinion
then?
Maybe it would make -V8 sound acceptible? Maybe it would drastically
improve 128kbit/s encodings.
I think most of us would actually be very surprised of what results
might actually come out of the "computer".
I'm not asking to cast out certaincies, but I'm asking relief for all
the uncertaincies.
--
and now the opinion of the man with a $3 socioligy book:
It stings to see me here claiming "-mj is inept".
It's unfortunate to see that some cultivate disbelief and
scepticism and go through great lengths defending the establishment
rather than face the obvious.
If I were borg, I would have made clear by now that this emotional
reasoning is highly inefficient. :)
All of this is just to benefit lame quality.
--
Best regards,
Roel mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
