[FFmpeg-devel] Handling of mono data in WMA lossless

[Reimar Döffinger]

On 2 May 2012, at 00:53, Jakub Stachowski <qbast at go2.pl> wrote:

> W dniu 2012-05-01 22:44, Michael Niedermayer pisze:
>> On Sun, Apr 29, 2012 at 11:36:15PM +0200, Jakub Stachowski wrote:
>>> Hello
>>> 
>>> While testing WMA lossless decoder on various files I found another
>>> case when it outputs different data from Microsoft's implementation.
>>> I have not been able to fully fix this, so I am sharing what I found
>>> so far in hope that someone else will be able to provide additional
>>> information.
>>> 
>>> WMAL apparently has special way of dealing with mono (where all
>>> samples in both channels are identical) data: only first channel is
>>> coded and decoder is expected to copy samples to second channel.
>>> 
>>> Attached testsamples.c creates two files designed to cause encoder
>>> to use this mode: samples-equal.pcm have first frame with mono data,
>>> in second frame it is different. Decoder should copy data from first
>>> channel to second.
>>> sample-zero.pcm has data in first channel and zeros in second. In
>>> this case decoder should not copy data. I have no found any specific
>>> flag which decides that, but it is possible that do_interch_decorr
>>> is used.
>>> Attached patch makes ffmpeg decode both files ok. It also fixes
>>> Mashiat's sample.
>>> 
>>> However it does not work with real world sample (
>>> http://stream1.criteriamx.com:8080/part.wma ) . Unfortunately I
>>> cannot share whole file.
>>> 
>>> Differences are following:
>>> - in my previous samples, copying of data from first to second
>>> channel has to be done before all filtering. Otherwise second frame
>>> will be broken
>>> - however in this sample it is the other way around - samples has to
>>> be copied as last step or decoder starts generating wrong data
>>> - there are frames which have both channel coded and yet encoder
>>> should overwrite data. Which really makes no sense to me.
>>> - I decoded the sample into wav and compressed it again with
>>> Expression encoder. This time ffmpeg could decode it ok. Maybe
>>> behaviour was different in older version of SDK (10.00.00.3700) ?
>> 
>> in general stereo codecs that do decorreleation treat a non coded
>> second channel like a coded seconded channel with all 0 values.
>> the decorrleation will then do the "copy".
>> its also possible in some codecs (WMA comes to mind if iam not
>> mistaken) that the first channel is not coded but the second is, this
>> is rare but that cant be handled by a simply copy.
>> 
>> not sure if any of this helps ...
> 
> This is exactly what I have been missing. I guess it really pays to actually have some idea how audio coding works. All my weird attempts to copy data were unnecessary, for some reason reverse decorrelation was restricted to case when both channels are coded. Removing that check fixes my synthetic test files, real world test case and does not break 3 other random WMA files I tested. Patch is attached.

Not important, but the "else" is kind of pointless when the if contains a return...