search for: apodization

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

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

Currently apodization function is hardcoded, see commit <http://git.xiph.org/?p=flac.git;a=commitdiff;h=4e8fe85bceb245dfce07d1956b144e1cb6587c9f> FLAC is locale-dependent so "tukey(0.5)" doesn't work for locales with decimal comma. But "tukey(5e-1)" should be locale-independent so it is p...

Hi, I was doing some speed and compression comparisons with various apodization/windowing functions, and found out that the definitions for the bartlett and bartlett_hann window in the FLAC codebase have been wrong since their introduction. The attached patch fixes that. Furthermore, I found some peculiar behaviour of the gauss apodization that seems to expose bug. Using...

Hi Guys, Does having multiple apodization functions change something to the decoding process or does it only apply to the encoding process ? I have been able to gain almost 10% by using several apodization functions (it takes way more time to encode but this is quite a non issue in my use case) but I don't want to sacrifice any dec...

Martijn van Beurden wrote: > Hi, > > I was doing some speed and compression comparisons with various > apodization/windowing functions, and found out that the > definitions for the bartlett and bartlett_hann window in the > FLAC codebase have been wrong since their introduction. The > attached patch fixes that. How it affects compression ratio? > Furthermore, I found some peculiar behaviour of th...

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

Martijn van Beurden wrote: > 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, b...

Op 22-09-14 om 21:56 schreef Erik de Castro Lopo: > Wouldn't "tukey(1/2)" be better? > > Erik 5e-1 is directly parsed by strtod, while 1/2 isn't AFAIK.

On 22.9.2014 23:22, lvqcl wrote: > Martijn van Beurden wrote: > >>> Wouldn't "tukey(1/2)" be better? >>> >>> Erik >> 5e-1 is directly parsed by strtod, while 1/2 isn't AFAIK. > Another idea is to write flac_strtod() (and probably local_strtod() too) > function that is able to parse both "0.5" and "0,5" strings

Martijn van Beurden wrote: > This patch changes the settings associated with compression > levels 6, 7 and 8. With this patch, -e is no longer used, but > instead apodization functions are added. This should improve > compression with at least 95% of all material. Independent tests > show that this is probably the case. But your patch changes only two last presets (-7 and -8) so -6 stays unchanged. ( IIRC it should have "tukey(5e-1);partial_tukey(2)" as...

Martijn van Beurden wrote: >> And I also suggested to consider a different setting for -7 preset: >> -7 == -l 12 -b 4096 -m -r 6 -A tukey(0.5);partial_tukey(2) >> see <http://www.hydrogenaud.io/forums/index.php?s=&showtopic=106545&view=findpost&p=871797> >> >> But it will decrease decoding speed for this preset. > > Yes, that is another thing

Op 20-10-14 om 16:36 schreef Martijn van Beurden: > Op 20-10-14 om 16:31 schreef lvqcl: >> But your patch changes only two last presets (-7 and -8) so >> -6 stays unchanged. ( IIRC it should have >> "tukey(5e-1);partial_tukey(2)" as its apodization string >> instead of current "tukey(5e-1)" ). > > .... okay, I really don't know how it is possible I missed > that. Sorry. Here's the patch again. Sadly, it turns out this patch requires another patch to fix the test_compression.sh test. The LP coefficient appr...

...decoding. (https://git.xiph.org/?p=flac.git;a=commit;h=ea0d5ddadc6902e873983c89f473130b3bb6625f) * Faster encoding using SSE and AVX. (many separate patches by lvqcl) * Fixed bartlett, bartlett_hann and triangle functions. (http://lists.xiph.org/pipermail/flac-dev/2014-August/004983.html) * New apodization functions partial_tukey and punchout_tukey for improved compression. (http://lists.xiph.org/pipermail/flac-dev/2014-August/005000.html) * Retuned compression presets to incorporate new apodization functions. (http://lists.xiph.org/pipermail/flac-dev/2014-August/005001.html) Obviously a lot more...

...see anything I've missed? > > Cheers, > Erik > -- > Looking good, clearly a couple of things I?d forgotten all about! Two things: 1) Shouldn?t we give Martijn van Beurden a mention for his great work on the "bartlett, bartlett_hann and triangle functions? and "New apodization functions partial_tukey and punchout_tukey? code? 2) There is a typo under ?Build system?: "buiuld systems? Maurits

Dear experts, I try not to trouble the list again after this question. I want to print this vector into a file > myvec [1] --Control --Control --Control --Control --Control HBA2 HBA1 [8] HBA1 --Control HBB --Control HBB HBA1 MBP [15] --Control HBA1 HBA2 HBB PTGDS GAPDH UBC [22] --Control GAPDH TPT1 HUWE1 PRM1 CKM

Flake is a completely independent codebase. When I used it years ago, I remember it being not only better compression but significantly faster as well. I believe some of the techniques used in libflake were added to libFLAC in 1.1.4. However, some of the improved compression in flake was due to options that are outside the FLAC 'subset', such as larger blocksize, greater number of

Op 03-12-14 om 16:48 schreef Olivier Tristan: > Looks like I've missed the talk about this regression introduced in 1.3.1.

...ool FLAC__stream_encoder_set_sample_rate(FLAC__StreamEncoder *en * The actual values set for each level are: * <table> * <tr> - * <td><b>level</b><td> - * <td>do mid-side stereo<td> - * <td>loose mid-side stereo<td> - * <td>apodization<td> - * <td>max lpc order<td> - * <td>qlp coeff precision<td> - * <td>qlp coeff prec search<td> - * <td>escape coding<td> - * <td>exhaustive model search<td> - * <td>min residual partition order<td> - * <td>m...

..., samples = 0}}, verify = 0, use_ogg = 0, serial_number = 1139381067, lax = 0, do_mid_side = 0, loose_mid_side = 0, do_exhaustive_model_search = 0, do_escape_coding = 0, do_qlp_coeff_prec_search = 0, min_residual_partition_order = 2, max_residual_partition_order = 2, rice_parameter_search_dist = 0, apodizations = 0x8311d6c "", max_lpc_order = 0, blocksize = 1152, qlp_coeff_precision = 0, padding = 4096, requested_seek_points = 0x8312194 "", num_requested_seek_points = -1, cuesheet_filename = 0x0, cued_seekpoints = 1, is_first_file = 1, is_last_file = 1, align_reservoir = 0x8072a90, al...