On Mon, 2002-07-01 at 23:12, Chris Holt wrote:
> Hello, Raider,
Hello Chris,
> 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.
lame should be the correct decoder. Or is it only the best encoder?
About being objective... I'm not the only one, and one of my friends
wasn't even told what's the difference (he assumed that all are mp3s and
told me "look, only the first version is like the original" - well, that
IS the original).
About DSP... same devices were used as for playing the ripped original
or other CDs. And the burner can be taken out of the list, as the
burner is dumb enough not to know what data is written on the CD.
I even had on the list a cbr320 which is the max of what mp3 can offer.
> 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.
IMHO the lowpass filter has nothing to do with dynamics. Just cutts
off the data people can't hear. Same goes for a highpass filter. Only
this time it will cut off anything beyond a certain level. It makes
sense to employ both type of filters to automaticaly reduce the quantity
of data the encoder has to compress.
But you are right Chris. I will try it one more time with the -k
switch, and maybe with the -k switch and the other options combined. As
the documentation says it should disable all filters.
> 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. :)
What other decoder? Bladeenc?
signature.asc
Description: This is a digitally signed message part
