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

[Michael Niedermayer]

On Wed, May 02, 2012 at 12:53:17AM +0200, Jakub Stachowski 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.
> 
> >
> >[...]
> >
> >
> >
> >
> >_______________________________________________
> >ffmpeg-devel mailing list
> >ffmpeg-devel at ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

>  wmalosslessdec.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 2c39d2fc60d610ccc3d9597e4d0f1f3465a04610  001-reverse-decorrelation.patch
> From af0ed9db02450cb343da2fd781166f8d5a7f3808 Mon Sep 17 00:00:00 2001
> From: Jakub Stachowski <qbast at go2.pl>
> Date: Wed, 2 May 2012 00:33:17 +0200
> Subject: [PATCH] Don't restrict reverse decorrelation to both coded channels.
>  It is also used for mono data.

applied, thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120502/6f87b813/attachment.asc>