similar to: about apodization functions

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.

Hi Guys, I know that FLAC format is currently limited to 8 channels but I was wondering if this hard limitation of the format or if it can be easily circumvented if the flac library is compiled with other settings and/or the software using it don't mind it Thanks ! -- Olivier Tristan Research & Development www.uvi.net

I see :( That what I would call a good struct size optimisation. Please tell me there was another reason behind this being only 3 instead of 8 or 16 bits, right ? 2017-01-25 18:30 GMT+01:00 Tor-Einar Jarnbjo <tor-einar at jarnbjo.name>: > Hello Olivier, > > the limitation is in the file format itself, as the number of channels is > encoded in a 3 bit field in the streaminfo

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)

Op 03-12-14 om 15:49 schreef Olivier Tristan: > [...] > If you want to check this on a single piano note, I would be > happy to know if this improves the monophonic use case as well. This sample is indeed a case where the retuning of FLAC 1.3.1 shows a severe regression. It seems the patch does work quite well in this case, but it does not fully fix the regression. FLAC 1.3.0 -5:

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 different windows

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 possible to re-add 'const char *apodization' member into

Don't overlook the FLAC in Ogg container solution. That's established as a standard for some time now, as far as I know, and would probably be better than a new, proprietary multi mono bundle. I haven't used it myself, but people have been talking about it for a while, and I believe that some "FLAC" users are actually working with FLAC in Ogg container files. Brian

Hi Guys, The current trunk do not build with GCC 4.2 on OSX when compiling cpu.c <cpuid.h> does not exists and __get_cpuid() is not defined This version of GCC is required if you want to support pre 10.7 systems which are still pretty common. It seems other project had the same issue https://bugzilla.mozilla.org/show_bug.cgi?id=836824 Don't know much what would be the right fix.

Hi Guys, In stream_decoder.c when assigning lpc restore function, only IA32 processor benefits from SS2 and SSE4.1 optimization. Shouldn't it be the case for x86_64 processor as well ? Thanks, -- Olivier TRISTAN uvi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20140311/1d49b5c2/attachment.htm

Hi Guys, I've just faced a wrong warning trying to encode a 24 bits WAV file if(wFormatTag == 1) { if(bps != 8 && bps != 16) { if(bps == 24 || bps == 32) { /* let these slide with a warning since they're unambiguous */ flac__utils_printf(stderr, 1, "%s: WARNING: legacy WAVE file has

Hi Guys, The following code in CPU.c (line 155) won't link if you don't have NASM code built even if FLAC__HAS_X86INTRIN is true as FLAC__cpu_info_asm_ia32 don't exists and the else is compiled if there is no dead code stripping if (FLAC__HAS_X86INTRIN) { FLAC__cpu_info_x86(0, &flags_eax, &flags_ebx, &flags_ecx, &flags_edx); info->ia32.intel =

Hi, This patch improves compression a very tiny bit on average, but up to 0.1 percentage point for classical music. I haven't found any tracks that show worsening compression with this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-LPC-order-guess.patch Type: text/x-patch Size: 0 bytes Desc: not available Url :

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,

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

More specifically, about this patch: http://git.xiph.org/?p=flac.git;a=commitdiff;h=70b078cfd5f9d4b0692c33f018cac3c652b14f90 I downloaded the latest code from git (flac-70b078c), disabled all SSE optimizations in the code and compiled it (GCC 4.8.2). This patch doesn't change FLAC output. Either gcc is too smart and optimizes this new code back to the old, or this fix is MSVS-specific. Or

This patch removes FLAC__lpc_restore_signal_16_intrin_sse2(). It's faster than C code, but not faster than MMX-accelerated ASM functions. It's also slower than the new SSE4.1 functions that were added by the previous patch. So this function wasn't very useful before, and now it's even less useful. I don't see a reason to keep it. -------------- next part -------------- A

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

Federico Miyara wrote: ... > The file format allows some unused fields for future use, such as the > padding block. It could include a flag to indicate a change in the > format adding one more streaminfo byte which would allow up to 256 > channels (actually, 256 + 8), or it could trigger a new byte when 11111111. > > There is also an invalid block identifier (127) which could be

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 >