similar to: building issue on OSX GCC 4.2 / Xcode

Olivier Tristan wrote: > 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 >

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

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, 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, 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 decoding speed as this is the bottleneck for me. Thanks,

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 =

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.

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

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

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 guys, Please find attached a patch that fixes the OSX build with llvm only __asm__ is supported but GCC support both so it's not an issue using this one AFAIK. lvqcl can probably confirm this. Thanks ! -- Olivier Tristan Research & Development www.uvi.net -------------- next part -------------- An HTML attachment was scrubbed... URL:

libFLAC for Windows compiled with GCC/MinGW can't detect SSE OS support: it can't use GCC+Linux detection code and can't use MSVC+Win32 code that uses SEH (__try/__except). So it doesn't use any SSE/SSE2/etc routines. One way to fix it is to call configure script with --enable-sse (flac will probably crash on Win95/WinNT4 but who cares). Another way is to add a new code just for

This could make sense indeed. I suppose this is not a libFlac feature and that I should end up using libogg and or adding myself basic ogg support in order to support that ? Thanks ! 2017-01-28 7:37 GMT+01:00 Brian Willoughby <brianw at audiobanshee.com>: > Don't overlook the FLAC in Ogg container solution. That's established as a > standard for some time now, as far as I

This patch adds 2 new functions, FLAC__lpc_restore_signal_intrin_sse41() and FLAC__lpc_restore_signal_16_intrin_sse41(). The decoding speed of Subset-compatible 16-bit FLAC files is slightly increased on SSE4.1-compatible CPUs. -------------- next part -------------- A non-text attachment was scrubbed... Name: 04_add_new_intrin_func.patch Type: application/octet-stream Size: 9851 bytes Desc: not

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 :

Olivier Tristan <o.tristan at uvi.net> ?????(?) ? ????? ?????? Fri, 21 Mar 2014 22:41:00 +0400: > Check with -mfpmath=387 to be sure that x87 FPU code is used and not some > SSE optim made by GCC I added "XIPH_ADD_CFLAGS([-mfpmath=387])" into configure.ac Still the result is different from SSE version. --------------- MSVS adds two instructions to the generated code after

-------- Forwarded Message -------- Subject: Re: [flac-dev] Flac multi channel Date: Wed, 25 Jan 2017 15:55:14 -0300 From: Federico Miyara <fmiyara at fceia.unr.edu.ar> To: Tor-Einar Jarnbjo <tor-einar at jarnbjo.name> Besides the fact that many multichannel signals largely exceed 8 channels, there are examples of signal packaging with many channels which are actually