[Flac-dev] alternate compression

[Brian Willoughby]

On Aug 9, 2009, at 21:18, Didier Dambrin wrote:
>>> ..But sadly none of FLAC, WavPack or OptimFrog could compress the
>>> pre-processed song better, or hardly. And considering you'd also
>>> have to add
>>> the pool of frames, it would end up worse.
>>
>> This surprises me.  Have you tried aligning your frames to the
>> standard FLAC frame size?
>
> Not at all, because I have no idea how it works internally, I've  
> only be
> using the standalone binary for now. What's the standard frame size?
> (I work in Delphi, so playing with C++ API's require painfully
> translating/adapting them, so I wanted to stay away from that for now)
I was going to suggest that you could use the FLAC library via the C  
API, instead of the C++ API, but some quick research on Delphi  
doesn't seem to show support for C.  I use Objective C for object- 
oriented development, and it is very easy to incorporate C API.  I  
can't really use Delphi since it is Windows only, so I can't really  
help you there.


>> I would guess that most lossless audio compression methods are time
>> domain.  However, LJPG (lossless JPEG) uses a very efficient lossy
>> compression followed by lossless compression of the difference.  I
>> wouldn't be surprised if there is an audio codec which combines lossy
>> frequency domain compression with lossless compression of the
>> difference between the lossy version and the original.  If there
>> isn't then I'll just patent that...
>
> I've tried that already, and was very surprised by the results.  
> Wikipedia
> told me about those lossy+correction methods, and that there's  
> supposedly a
> version of AAC that can do this (& WavPack & others too, but in the  
> time
> domain I'd assume).
> ..so I started OGGing a song at various bitrates, subtracted it  
> from the
> original, and tried encoding the residual using the lossless packers I
> mentioned.
> To my surprise, the size of the OGG+the packed residual always roughly
> matched the size of the packed original. Tried with 32k, 128k &  
> 450k oggs..
> always the same! Not exactly the same of course, but I was  
> expecting much
> bigger results (not really smaller, assuming someone had tried the  
> same
> before me).
> (haven't tried with MP3, but it's probably worse)
One thing to keep in mind is that FLAC isn't necessarily very  
efficient at compressing silence.  While amplitude does correlate  
with size to some extent, it does not continue to improve below a  
certain amplitude.  Perhaps this is due to the overhead of the format  
itself.  One solution might be a custom format which embeds FLAC- 
compressed packets along with the lossy packets, thus sharing the  
overhead instead of having two completely independent files.

After noticing that quieter tracks are compressed smaller, I tried  
compressing silence, and I seem to recall that it didn't do quite as  
well as I expected.  Even if I am recalling this benchmark correctly,  
I suppose it isn't really important since very little music is that  
quiet.


> The residual from the OGG seemed to be very stable in gain, with a  
> bit depth
> decreasing along with the increasing OGG bitrate. I wasn't  
> expecting that,
> knowing it works in the freq domain.

In some respects, it should not really matter whether the compression  
is time domain or frequency domain, because the end result of lossy  
compression is added "noise."  Whether this noise comes about from  
time domain errors or frequency domain errors should be irrelevant.   
In either case, the amplitude of the error should be quite small, and  
an algorithm like FLAC can compress low-amplitude signals quite well.

Brian Willoughby
Sound Consulting