> From: Robert Hegemann <[EMAIL PROTECTED]>
> Date: Thu, 6 Jan 2000 19:56:30 +0100
>
...
>
> 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 :(
>
and also will use the same amount of bits for both mid and side channels!
Another quick fix: the '-m s' option :-)
How about this: To allocate bits between mid and side channel, go
back to using the ratio of mid_channel_energy / side_channel_energy?
This used to be used for both the ms stereo switching criterion and
deciding how many bits to allocate between L and R channels.
Using a switching criterion based on l & r maskings works much better,
however we could go back to using energies for the bit allocation.
Also, as a sanity check, if side_channel_energy > mid_channel_energy,
turn of ms stereo for that frame.
This would avoid the problem you describe.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
