Hello, Raider,
At 2002-07-01, 17:19:00 you wrote:
> I don't see anything on the r3mix site related with this problem. Even
>if it's extremely helpful and well organised... still, no hint.
What I was getting at with that site was that tests, very similar to what you are
doing, were run with both analytical software and a large number of "professional"
listeners in blind tests. (using 25 grand worth of amp and headphones, no less)
I'll quote from the site here (please don't shoot the messanger!) :)
-------------
Conclusions:
90% of the 128 Kbit material was picked out
MP3@256 was rated to have the same music quality as cd!
If you find MP3@256 to be of inferior quality compared to the original cd, you're very
likely to be doing something wrong with the test (correct decoder, no objective double
blind testing, DSP filters distorting the process, ...) Maybe this is something for
you.
The treshold of mp3 transparency lies somewhere between 128kbit/s and 256kbit/s,
depending on the kind of music and your hearing and equipment.
-------------
> Given the above list - which included the switches involved in encoding
>the original wav (the decoding was like this 'lame -decode tune.mp3')
>are there any other filters that are triggered by default?
The reason I point this out is that there are, in fact lowpass filters being applied
by default, however the --r3mix option specifically sets the lowpass at 19.5.
(assumed to be near the threshold of human hearing) But these filters don't have
anything to do with dynamic range, they affect frequency response. I guess you could
try adding -k which eliminates any attempt at filtering, but I don't think it will
make any difference, and it's not recommended according to the help file.
I don't know of any attempts by lame to compress or expand dynamic range (that is your
complaint, right?) I can't think of anything in the encoding process that would limit
the dynamic range (perhaps it would be affected at lower bitrates, but only for those
frequencies that are limited by this).
Perhaps you might want to try another decoder? Just to ensure that there is nothing
funny going on there. I'm trying very hard to think of things that could account for
the differences in the en/de coded files, but I'm not coming up with much. I've not
seen much to refute the tests and logical conclusions from the r3mix site, and I don't
personally have the equipment or "golden ears" required to dispute it myself. So the
best I can do is approach this from a logical "troubleshooters" standpoint and place
my faith in your hearing and equipment. :)
Chris
_______________________________________________
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder
