[FFmpeg-devel] [PATCH] handle INT32INFO in WavPack decoder

[Kostya]

On Sat, Aug 04, 2007 at 10:06:53PM -0700, David Bryant wrote:
> Hi.
> 
> Michael Niedermayer wrote:
> >Hi
> >
> >On Sat, Aug 04, 2007 at 03:39:13PM -0700, David Bryant wrote:
> >>Hi.
> >>
> >>This patch adds the handling of the INT32INFO block to the WavPack 
> >>decoder. This block is used to properly decode integer samples over 24 
> >>bits, 
> >
> >the dst array into which the values get stored is 16bit, how is this 
> >supposed
> >to work?
> 
> The WavPack decoder in FFmpeg currently handles only 16-bit audio. I 
> suspect that the original author assumed that the INT32INFO block was 
> only used for large integers and that's why he did not implement it.
> 
> However, since that block is also used for 16-bit audio when the LSB 
> redundancies are detected, I thought it would be good to add it. Without 
> it, some vanilla 16-bit stereo files will fail to decode.

Well, the name is a bit misleading. 
 
> >
> >
> >>but is 
> >>also used with smaller integers to efficiently encode audio blocks that 
> >>have redundancies in their LSBs (e.g. all zeros, all ones, etc.)
> >
> >etc == duplicate some bit into all LSBs
> >
> >the upscaling by adding 0 bits i can still understand but the other cases?
> >this seems like a senseless misdesign
> >is this used by any real files in the wild? if no then iam against 
> >supporting
> >it
> >if it is we dont have a choice but its ugly, the format could as well 
> >contain
> >a special case to store 0xDEADBEAF in the lsbs more efficiently
> 
> The 0 bit case is the most common, but I have certainly encountered the 
> other two cases. One specific case I remember was Adobe Audition 
> generating 32-bit integer files from 24-bit sources that had the LSB 
> filled in with sometimes 0s and sometimes 1s, obviously from dithering 
> when it should not have.

I thought the sandard practice is to fill LSBs with some noise instead of
replicating LSB (or they could use MSBs which is common too).
But according to the Murphy's law if there is a possibility of misdesign,
somebody will misdesign and implement it that way. 
 
> As an aside, I have certainly been surprised by some of the weird audio 
> data I've seen on CDs. Some audio production software obviously does 
> undithered normalization and ends up creating CDs with missing sample 
> values in regular patterns. I even saw a track where every sample was a 
> multiple of 3!
> 
> Regular lossless audio compression algorithms do not detect these cases 
> because the decorrelation destroys the patterns, but early on I 
> considered adding detection and handling of [some of] these cases to 
> WavPack but decided in the end that it was too ugly (even though it 
> could sometimes make a significant improvement in compression).
> 
> I never, however, considered checking for 0xDEADBEEF.  :)

[...]
> 
> Okay, done.

Applied, thanks for the patch 
 
> Thanks,
> 
> David