Thread: Listening tests
View Single Post
Old 09 August 2005, 06:00 am   #7
Join Date: Aug 2005
Posts: 5

xmixahlx, Thanks for your interestin the thread. Maybe you should read the beginning of the thread so you would get an idea of what we are talking about. I'm going to try to summarize it for you:

I was asking: 3How come in all the listening tests MPC is around 140-146kbps and MP3 at 128kbps. How is that a fair comparison?
Lefungus answered: bitrates on tiny samples are irrelevant, only average bitrate (on full albums for ex) is relevant.
I countered: Then why doing tests only on the tiny samples that are 140+kbps? How is it fair vs. MP3@128?
Lefungus answered once more: The tests are supposed to test difficult parts, hence the tendency of MPC to allocate more bits there, where it would average 128kbps on a large sample.
Then, I said: Well, but if the average is 128kbps and the hard parts are 146, then other parts "easy parts" must be around 110kbps. How come there is no test on these parts, where MPC could very well sound worse than MP3 since it is using a lower bitrate?

So, basically, you answered there:
dude, you're smoking crack. musepack is quality-based NOT bitrate-based.
1. My smoking habit is relevant only to me
2. Thanks for the info. You will notice that I know that and I was not the one that suggested that MPC would average at 128kbps on a large sample (with the encoding test parameters), so please don't get mad at me!

again... crack
Tell me then, how can MPC average 128kbps on an album, then allocate higher bitrates on hard parts without allocating bitrates lower than 128 on some parts of the music? I am apparently not the only one smoking crack over here.

how do you have such strong opinions based on bull shit?
You will notice that my sentence was starting with "I guess", hence not referring to a 'strong opinion' as you put it, but to a guess. It is my guess that quality based means allocating high bitrates to complex parts and low bitrates to the less complex parts. Hence, with parameters that will give an average of 128kbps (for example) some parts will be over 128kbps and some parts under. But these parts were 'simple parts' so they did not require 128kbps to sound as good as the more complex parts.

So far, I don't think anyone will disagree.

Now, comparing such a codec to a CBR 128kbps MP3 is highly unfair if you compare only the complex parts. Of course MP3 will sound worse: It is allocating less bits per second (I do understand there are other factors coming into play here). A fair comparison would compare complex parts and simple parts, just to prove that the quality based algorithm doesn't degrade the simple parts (encoded < 128kbps) too much.

do you know what you are talking about?
Yes, I do. Comparing a Codec at 146kbps and a codec at 128kbps is just nuts. It has little point, let me try to explain:

I could write a codec (assuming I had the time and skill to do it ;-)) that would detect the complex parts of the music. It would encode these parts of the music at 320kbps. Then, on the other parts, it would just produce a 32kbps crappy piece of music that would sound horrible. By comparing 'problematic samples' as all the 4 tests listed in the front page does, my codec would be on top of every single one of them. The fact that the non complex parts are just horrible wouldn't be covered by the tests.

My codec's strong points would be to allocate maximum number of bits to complex parts. Since these tests all focus on this point, they would miss the crappy part of my codec and they would be highly unfair to the other codecs.
pieroxy is offline   Reply With Quote