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

[David Bryant]

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.

> 
> 
>> 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.

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.  :)

> 
> 
> [...]
>> @@ -344,6 +357,16 @@
>>          }
>>          pos = (pos + 1) & 7;
>>          crc = crc * 3 + S;
>> +
>> +        if(s->sh_zeros)
>> +            *dst++ = S << s->sh_zeros;
>> +        else if(s->sh_ones)
>> +            *dst++ = ((S + 1) << s->sh_ones) - 1;
>> +        else if(s->sh_dups)
>> +            *dst++ = ((S + (S & 1)) << s->sh_dups) - (S & 1);
>> +        else
>> +            *dst++ = S;
>> +
> 
> bit = S & and | or;
> *dst++= ((S+bit)<<shift)-bit;
> 
> with appropriate values for and,or,shift

Okay, done.


Thanks,

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wavpack_int32_2.patch
Type: text/x-patch
Size: 2814 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070804/6a556d20/attachment.bin>