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

[David Bryant]

Hi.

Michael Niedermayer wrote:
> Hi
> 
> On Sat, Aug 04, 2007 at 10:06:53PM -0700, David Bryant wrote:
> [...]
>>>> 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).
> 
> well if your goal is to losslessly compress "lossy"/"misfiltered" audio
> then such special cases would make sense though trying to losslessly
> compress these seems to not make that much sense to begin with ...
> 
> that is just setting these LBSs to zero might very well be closer to
> the original untrashed audio ...

You're probably right, but I suspect some users would not tolerate this 
behavior from a "lossless" compressor.  :)

I have attempted to strike a balance between being a pure audio codec 
(like FLAC) and a WAV fle compressor/archiver (which is how people often 
use WavPack). This is why it stores extra RIFF chunks verbatim and does 
a few tricks to get significantly better compression on some real files 
that I've found.

Of course, handling 32-bit integer audio in the first place is a little 
silly because as far as I can tell has no useful purpose...

Thanks,

David