Hi all, This patch adds two new apodization functions that I developed. From my own test results (on quite a diverse dataset) they outperform the current best apodizations by 0.05% - 0.1% (depending on the specifics) on compression. Here's a selection of the test results *Apodization functions* ,Compres, Speed partial_tukey(2) tukey(0.5) , 56.50 , 37.2x partial_tukey(3) , 56.51 , 37.0x tukey(0.75) gauss(0.2) tukey(0.25), 56.54 , 35.8x partial_tukey(2) , 56.55 , 50.5x tukey(0.25) gauss(0.2) , 56.57 , 49.6x tukey(0.5) , 56.69 , 79.3x Speed is in times realtime. Here "tukey(0.75) gauss(0.2) tukey(0.25)" was the best combination of three existing apodization functions I could find, and it is outperformed by "partial_tukey(2) tukey(0.5)" by 0.04 percentage points, which is 0.07%. It improves 0.19 percentage points or 0.33% on the default at the cost of halving in speed. By design, there is no decoding speed penalty nor are there any compatibility issues. The only trade-off is slower encoding. This might not look much, but this is actually a better deal than using -8 over -5, which improves 0.23 percentage points at the cost of cutting the encoding speed to 1/3th and slightly slower decoding. The use and internals of these windows are explained in the documentation that is in the patch itself. Note, this patch includes the patch I mailed a little more than a week ago, which fixes the triangle, bartlett and bartlett_hann windows. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-partial_tukey-and-punchout_tukey-apodization-fun.patch.gz Type: application/gzip Size: 4324 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20140810/1eaa7d40/attachment.bin
Martijn van Beurden wrote: Hi Marijn, Sorry for the lack of response on this. I didn't understand it when it came in and I needed time to properly review it. Sunday morning after a really good night's sleep seems like a good time for that :-). I've currently got this patch in an un-published branch.> This patch adds two new apodization functions that I developed. > From my own test results (on quite a diverse dataset) they > outperform the current best apodizations by 0.05% - 0.1% > (depending on the specifics) on compression. > > Here's a selection of the test results > > *Apodization functions* ,Compres, Speed > partial_tukey(2) tukey(0.5) , 56.50 , 37.2x > partial_tukey(3) , 56.51 , 37.0x > tukey(0.75) gauss(0.2) tukey(0.25), 56.54 , 35.8x > partial_tukey(2) , 56.55 , 50.5x > tukey(0.25) gauss(0.2) , 56.57 , 49.6x > tukey(0.5) , 56.69 , 79.3x > > Speed is in times realtime. Here "tukey(0.75) gauss(0.2) > tukey(0.25)" was the best combination of three existing > apodization functions I could find, and it is outperformed by > "partial_tukey(2) tukey(0.5)" by 0.04 percentage points, which > is 0.07%. It improves 0.19 percentage points or 0.33% on the > default at the cost of halving in speed. By design, there is no > decoding speed penalty nor are there any compatibility issues. > The only trade-off is slower encoding. > > This might not look much, but this is actually a better deal > than using -8 over -5, which improves 0.23 percentage points at > the cost of cutting the encoding speed to 1/3th and slightly > slower decoding. The use and internals of these windows are > explained in the documentation that is in the patch itself.If I understand this correctly, these new apodization functions only affect compression and that files compressed with these new functions will still decode correctly with older versions of the FLAC decoder. Is that right? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Hi,> If I understand this correctly, these new apodization functions only > affect compression and that files compressed with these new functions > will still decode correctly with older versions of the FLAC decoder. > > Is that right?Yes, that is correct. These functions are used to window the audiodata, but only for the predictor stage. What these new function enable, practically speaking, is using only part of the signal to generate a predictor. My theory is that this helps because short transients introduce noise into the predictor. The predictor becomes very good at prediciting one part of the signal, instead of mediocre for the whole block. For more information on the whole window-thing, it might be a good idea to see this hydrogenaudio-post by Josh himself: http://www.hydrogenaud.io/forums/index.php?showtopic=44229 One thing to note is that this patch only affects the encoder stage that evaluates various possible predictors, not the actual coding stage. This patch only add the new windows to the codebase. My follow-up e-mail (Retuning compression levels) suggests one possible retuning of the compression levels 6, 7 and 8 that make use of these new functions.