[Flac-dev] alternate compression

[Didier Dambrin]

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


> As for the pool, it seems like the first occurrence of a repetition
> would compress like usual, and the subsequent ones would compress
> more than usual.
>
>> The problem is the discontinuities I think. Say you work with little,
>> non-tempo-synced frames, and you find a matching frame, which you
>> subtract
>> from the song at the places it matches. You'll have a discontinuity
>> around
>> it. If the frames around this one also match, it doesn't matter as
>> they will
>> be subtracted as well. But if they don't (enough), the
>> discontinuity will
>> stay.
>
> You may be right about the discontinuities.  Have you tried making
> your transitions only at zero-crossings?
>

no but that could be worth a try


>> I also tried windowing the frame before subtracting it, no more
>> discontinuity but with small frames it's not very useful anymore.
>
> Windowing may seem like a good idea, but remember that your decoder
> will have to recreate every step that your encoder uses so that it
> can be undone.  Thus, windowing may make it difficult to be lossless.
>

It would be undoable, as long as it's the original frame that you store, you 
can compute the adapted frame from it, and do anything you want.
For the normalization, you'd store the frame gain along with the time where 
it repeats.


>> But if I run the pre-processing on something perfectly repeated
>> several
>> times, it really finds the frames, and it doesn't require knowing
>> the tempo.
>> If you don't know the tempo, the only problem will be misalignment,
>> which
>> will leave little bits of audio that were too short to find
>> matching frames,
>> but most of the processed waveform will still be silence.
>
> Seems like knowing the tempo would allow the encoding phase to take
> far less time.  It makes sense that you don't absolutely "need" it,
> but you did say it takes a really long time to find matches.
>
>
>> Btw, are all lossless compression methods working in the time domain?
>
> 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)

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.