search for: uvi

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

...-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 metadata block. > > Tor-Einar > > Am 25. Januar 2017 16:45:32 MEZ schrieb Olivier Tristan <o.tristan at uvi.net > >: >> >> 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 setting...

...w, 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 Willoughby On Jan 27, 2017, at 12:55 AM, Olivier Tristan <o.tristan at uvi.net> wrote: > Thanks everybody for their answer. > > This is quite unfortunate for me, but hey, that's life. > > I will probably end up doing some multi mono bundle similar to what Protools did back in the days with its .L .R files > > Le 26/01/2017 à 18:58, Martin Le...

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, 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

...flac__utils_printf(stderr, 1, "%s: WARNING: legacy WAVE file has format type %u but bits-per-sample=%u\n", e->inbasefilename, (unsigned)wFormatTag, bps); AFAIK only 32bits file require a format of 3 while it's fine for 8, 16 and 24bits Thanks ! -- Olivier TRISTAN uvi.net

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

...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, -- Olivier Tristan Research & Development www.uvi.net

...FLAC__cpu_info_x86(1, &flags_eax, &flags_ebx, &flags_ecx, &flags_edx); } else { FLAC__cpu_info_asm_ia32(&flags_edx, &flags_ecx); } Maybe it should be an ifdef instead of an if ? Thanks ! -- Olivier Tristan Research & Development www.uvi.net

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

.... 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 Willoughby > > > On Jan 27, 2017, at 12:55 AM, Olivier Tristan <o.tristan at uvi.net> wrote: > > Thanks everybody for their answer. > > > > This is quite unfortunate for me, but hey, that's life. > > > > I will probably end up doing some multi mono bundle similar to what > Protools did back in the days with its .L .R files > > >...

...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. Any idea ? Thanks, -- Olivier TRISTAN uvi.net

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

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

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:

...-Einar Jarnbjo wrote: > 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 metadata block. > > Tor-Einar > > Am 25. Januar 2017 16:45:32 MEZ schrieb Olivier Tristan > <o.tristan at uvi.net>: > > 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 softw...

...t; So the maximum of eight channels is really > embedded into the FLAC standard. To change > this would require a whole new standard (or > the use of multiple grouped FLAC streams in > an Ogg container). > > Regards, > Martin -- Olivier Tristan Research & Development www.uvi.net

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

...amp;flags_ebx, &flags_ecx, > &flags_edx); > } > else { > FLAC__cpu_info_asm_ia32(&flags_edx, &flags_ecx); > } > > > Maybe it should be an ifdef instead of an if ? > > Thanks ! > -- Olivier Tristan Research & Development www.uvi.net -------------- next part -------------- src/libFLAC/cpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/libFLAC/cpu.c b/src/libFLAC/cpu.c index 5f86809..4bad89c 100644 --- a/src/libFLAC/cpu.c +++ b/src/libFLAC/cpu.c @@ -118,7 +118,9 @@ ia32_cpu_info (FLAC__CPUInfo *info) FLAC__...

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: <http://lists.xiph.org/pipermail/flac-dev/attachments/20170227/631ac282/attachment.html> -------------- next part -------------- diff --git a/src/libFLAC/cpu.c b/src/libFLAC/cpu.c index 67a076d..bf0708c 100644...