Mark wrote:
> I'm still not sure the gspi35_1.wav problem is caused by the ATH.
> I think it is actually caused by other flaws in the psy model.
> My reasons are:
>
> 1. using --athonly -V5 doesn't have the problem (in this case lame is
> choosing the bitrate so there is no audible distortion based only on the ATH)
>
> 2. any change which reduces the masking, such as using MAXNOISE
> for the noise calculations, or replacing the spreading function
> with something more reasonable, will also fix the problem.
>
: <snip>
>
> Mark
I agree Mark. I think the following program section(s) makes some of these
problems:
if (reduce_sidechannel) {
/* number of bits needed was found for MID channel above. Use formula
* (fixed bitrate code) to set the side channel bits */
for (gr = 0; gr < mode_gr; gr++) {
FLOAT8 fac = .33*(.5-ms_ener_ratio[gr])/.5;
save_bits[gr][1]=((1-fac)/(1+fac))*save_bits[gr][0];
save_bits[gr][1]=Max(125,save_bits[gr][1]);
used_bits += save_bits[gr][1];
}
}
After some testing I'm sure, it is an illegal assumption, that the Side
channel contains always less important data than the Mid channel.
I took the gspi35_2.wav and mixed it down to a mono file A.wav.
After inverting A.wav and saving as B.wav, I created a stereo file A+B.wav
out of them.
Lame is 100 percent sure that it should encode A+B.wav as MS stereo,
and that is OK. But the Mid channel is empty (exactly Zero Bits) and the
Side channel gets only a few (with VBR ~110) Bits. That is not OK!
So I disabled the above special for the side channel. After that, all went OK.
The Side channel got the Bits needed, and the Mid channel was still empty.
The Mid and Side channel can flip their role they play, and we have to think
about a criterion to decide which one they play actually. Cos, if we know
that the most important data is in the Side channel, we could determine the
needed Bits for the Mid channel like above for the Side channel.
As a quick fix, I would suggest turning the special treatment for the Side
channel off. Sadly, this slows down encoding speed :(
Robert
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
