similar to: FLAC 1.3.2 has been released

First off, this code is horrible to read and work on. The recent commits are the first of what I hope is a massive clean up of this code. lvqcl wrote: > So if I understand things correctly, the current meaning of --(en|dis)able-sse is: > > on Linux: > --enable-sse: > add -msse2 to the compiler switches > do not test SSE OS support (assume that SSE is

Attached is a patch to fix the incorrect CPU feature detection: On 2.1.2017 16.39, Janne Hyvärinen wrote: > Something seems to be wrong with cpu.c CPU detection code. When I > compile things with MSVC all instructions except FMA is detected as > missing, even though they are present in my CPU. That of course > results in awful performance. > > >

lvqcl wrote: > It doesn't know about uint32_t type, so the definition of cpu_xgetbv_x86() fails. > It can be fixed by adding "#include share/compat.h" to cpu.c (or by using > FLAC__uint32 from FLAC/ordinals.h). Ok, added share/compat.h. > When I fix this, the following problem occurs: > > error LNK2019: unresolved external symbol ___cpuidex referenced in

Op 04-12-14 om 20:05 schreef Erik de Castro Lopo: > Martjin, are you able to make your test material available? DO > you have any test scripts your use to run your tests? Sorry, most of the testmaterial isn't copylefted, and I don't think it is possible to get a nice copylefted test library. That's because most copylefted material is indie, and sadly the mastering techniques

Security is quite important, but I believe that audio quality and lossless performance trump security for nearly all users of flac. In other words, unless the bugs affect the lossless quality of flac, then those old downloads should remain available. Of course, place a notice about the potential for security issues, but let the users make their own decisions. Personally, I find it important to

Hi all, Google Security Team member, Michele Spagnuolo, recently found two potential problems in the FLAC code base. They are : CVE-2014-9028 : Heap buffer write overflow CVE-2014-8962 : Heap buffer read overflow For Linux distributions, the specific fixes for these two CVEs are available from Git here:

Hi all, With the patch I mailed earlier today, I found out a few adjustments could be made to the compression level settings.This retuning speeds up the encoding and improves compression, while not changing anything decoding-wise. Currently, compression settings are as follows -5, -l 8 -b 4096 -m -r 5 -A tukey(0.5) -6, -l 8 -b 4096 -m -r 6-A tukey(0.5) -7, -l 8 -b 4096 -m -e -r 6-A

Erik de Castro Lopo wrote: > I also notice that on sourceforge: > > https://sourceforge.net/projects/flac/files/flac-win/ > > there are still 1000+ downloads per week 1.2.1 windows binaries > with know security holes. What do people think of the idea of > disabling downloads of old, known buggy Windows binary downlaods? FLAC 1.2.1 is the last version that works on

unsigned int and FLAC__uint32 are used interchangeably, leading to warnings with platforms (e.g. djgpp) where int32_t is long: bitreader.c: In function `FLAC__bitreader_read_rice_signed': bitreader.c:721: warning: passing arg 2 of `FLAC__bitreader_read_unary_unsigned' from incompatible pointer type bitreader.c: In function `FLAC__bitreader_read_rice_signed_block': bitreader.c:850:

I have been running a lot of large compression tests to see how well Martijn van Beurden's new presets do and was once again reminded how real the fragmentation problem still is. To have decent speed it's necessary to run multiple encoders in parallel. In my setup FLAC was compressing four files at the same time and each instance writes tiny bits of data to disk at once. A

On 1/14/17, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Ozkan Sezer wrote: > >> unsigned int and FLAC__uint32 are used interchangeably, leading to >> warnings with platforms (e.g. djgpp) where int32_t is long: > > Is `sizeof int == 4` though? Yes, obviously it is > I couldn't image FLAC working correctly > if it wasn't. > > Erik

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Patch applied, tested, commited and pushed. Great. But, what about my other patches? I admit that many of them aren't necessary, but (imho) a couple of them are important. I can explain in detail why I think this.

On 11/09/11 02:58 pm, Erik de Castro Lopo wrote: > If anyone else has Flac patches that they would like to > see commited to the Xiph Git repo, now would be a good time > to speak up. A couple of build system fixes for OS/2. Not very experienced with git so just attaching. Dave -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hi all, I have a new pre-reelase (with a GPG signature) up here: http://mega-nerd.com/tmp/flac-1.3.3rc1.tar.xz http://mega-nerd.com/tmp/flac-1.3.3rc1.tar.xz.asc This code is built from commit 10a28d482a8e48b806f61ab766992b2add98ec43 plus another commmit to change the version numbers which I will not be pushing to the public repo before the final release. Note that audio files encoded

Johnny Rosenberg wrote: > Maybe a stupid question, but I was born stupid and I have walked that > path ever since, so: Is there a changelog? The only changelog is the git changelog. I will be writing a real changelog to go in the actual release tarball before the official release. The git changelog is available here: https://git.xiph.org/?p=flac.git;a=summary or in any git clone of

Hi i have seen that the dbPowerAmp ripping and encoding software supports a new so-called "FLAC uncompressed" format, e.g. http://www.audiostream.com/content/dbpoweramps-flac-lossless-uncompressed-wish-come-true i know only the normal flac compression levels from 0 to 8. have i missed an option on the flac comamnd line tool or how could i achieve that on the linux command line flac

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

lvqcl wrote: > No, MSVC 2015 is also affected. I renamed __cpuid() to __cpuid22(), I thought the original problem was with `___cpuidex`, not `__cpuid`! Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Janne Hyvärinen wrote: > Something seems to be wrong with cpu.c CPU detection code. When I > compile things with MSVC all instructions except FMA is detected as > missing, even though they are present in my CPU. That of course results > in awful performance. What Windows version and CPU was this? Erik -- ---------------------------------------------------------------------- Erik

>> Oh I don't doubt the basics, red book is red book and bits are >> identically replicable and re rippable bits. > > I don't see any problem with taking innovation as far as is practical > and saying "it's finished, no more updates". Sure, basics :) Again, I'm meaning in regard to about bugs, docs, porting and nits. > If I want to do freedb