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: [TROLLING] firestarter trolling split (Read 8137 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[TROLLING] firestarter trolling split

Reply #25 –
Quote
Ok, seems that I've found what can kill you !!! 
1. Monkey Audio uses only M/S coding (sic! only M/S, w/o L/R, mpeg is more advanced in this area) when compress (losslessly(!!) or you doubt it ?) the data.
See: http://www.monkeysaudio.com/theory.html
2. Lossless Predictive Audio Compression (LPAC) uses the same methods.
[a href="index.php?act=findpost&pid=227461"][{POST_SNAPBACK}][/a]


He-he, no.
1. Yes
2. Yes
3. It is lame we are discussing.
4. You have not answered my question.

[TROLLING] firestarter trolling split

Reply #26 –
Quote
A question to you SirGrey. "What are happening" with those two channels, when you compress it.

It is not very interesting what happen when you compress, interesting what you get when decompress.
You get errors (difference).
When you have L/R coded signals, error in both L and R are large.
When you have (L+R)/2 and L-R, error in second ch is much smaller.
(if channels are correlated, so means difference is not large)
That the idea of Joint stereo basis...
EDIT: That's the basis, of course, things are not that simple 

[TROLLING] firestarter trolling split

Reply #27 –
Look sunshine,

If you force "discrete" stereo, the codec can put different coding noise in the left and right channels. That's the only choice it has.

If you allow "joint" stereo, then the codec can switch between M/S and L/R representation as it sees fit. It can hide the coding noise in either pair of channels, and weight the noise between the pair.


The coding noise sits under the wanted signal - that's the whole point of a psychoacoustic based codec. If it didn't, you'd hear it!

Now, please tell me, for a nearly mono signal, how a "discrete" stereo encoder can hide the coding noise under the signal, when the signal appears to come from the middle of the stereo sound stage, while the coding noise is being added at extreme left and right?

The "unmasking" from moving something away from the signal that was masking it, is up to 25dB!!! Which means that, if you insist on forcing the coding noise to be spatially separate from the signal, then it has to be (up to) 25dB lower in order to remain inaudible.

Given a finite (and relatively low) limit of 320kbps total, how is this a benefit?


btw, that's a theoretical argument. In practice of course, the codec can make mistakes. But if you don't trust the codec to choose what stereo mode to use, or what lowpass to use, then I don't know how you can even think about letting it choose which spectral band to add most coding noise in!

Maybe we need a special switch to force the codec not to add any coding noise. Oh, hang on - we already have that function - it's called a lossless codec!


It's just silly to use a psychoacoustic based codec which aims to code audible areas with greater accuracy than inaudible areas, and then to prevent it from doing its job properly!


As FireStarter ignored phong's excellent post, I suppose he's the kind of FireStarter who likes to come back and fan the flames!

If you were really interested FireStarter, then you'd have read the FAQ more carefully, and you wouldn't be making arguments which have already been answered plenty of times.

Cheers,
David.

[TROLLING] firestarter trolling split

Reply #28 –
Ahh. Hence my statement about "What goes inn, must come out"
and diffrences coused by compression.
A. preserve stereo separation, you got a two channel source, with compression
the two channels are ex: joint, when decompress theres quite a bit information
that get lost. So atm. i see true stereo as a better sulution.
There are other lossy formats that don`t have this behaviour,
so it would be quite safe to say, that it is not the method itself that are unwanted,
but rather the code and implementation in lame.
(if joint was perfect, i stil would prefer stereo.)

/Edit/
I am not your Sunshine 2b.
regarding the mention of FAQ, i repeat, where do it state
that HA. is conclusive and absolute.
As preferance,
Quote
-m s is bad, -q 0 is stupid