similar to: Do we need a pre-release?

lvqcl.mail wrote: > "make -f Makefile.lite" also doesn't work out of box. Didn't work for the 1.3.1 release either. Makes me wonder why we even keep it around. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Thomas Zander wrote: > I'd say let's have a release candidate. More often than not, some > issues turn up due to the exposure to a larger user base and, hence, > test cases. Ok, coming up. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Erik de Castro Lopo wrote: > Unfortunately I've lost/forgotten my Xiph SVN password. While I get > that sorted out for the real release, the pre-releases are here: > > http://mega-nerd.com/tmp/flac-1.3.2pre1-win.zip > http://mega-nerd.com/tmp/flac-1.3.2pre1.tar.xz Forgot to mention that I have tested this on x86_64/linux, armhf/linux and powerpc/linux. Erik --

On 12/08/16 12:24 AM, Thomas Zander wrote: > On 7 December 2016 at 21:08, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: >> lvqcl.mail wrote: >> >>> "make -f Makefile.lite" also doesn't work out of box. >> >> Didn't work for the 1.3.1 release either. Makes me wonder why we even >> keep it around. > > Because it works on

On 29 December 2015 at 08:08, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > I would suggest: > > #if SIZEOF_VOIDP == 8 I believe this is not portable. At least on my machine ("4.2.1 Compatible FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)") it's not defined. Probably this one comes closest: #define __SIZEOF_POINTER__ 8 Riggs

Dave Yeo wrote: > Doesn't SSE support imply SSE2+ support? Not for the CPU. Just because a CPU supports SSE, does not mean it is guaranteed to support SSE2+. For OS support, I'm not sure. Didn't later version of SSE add new registers? > I have a '96 install of an OS, it has been upgraded until end of life, > and it handles SSE4+ instructions fine even though the

Erik de Castro Lopo wrote: > Hopefull the final release candidate: > > http://mega-nerd.com/tmp/flac-1.3.3rc3.tar.xz > http://mega-nerd.com/tmp/flac-1.3.3rc3.tar.xz.asc I am assuming everyone was happy with that and that I can release a new version. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo

On 14 March 2016 at 09:02, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > commit a9f84425cfd5d1dbfb564730ca80d0b588cb4f24 > Author: Erik de Castro Lopo <erikd at mega-nerd.com> > Date: Mon Mar 14 18:14:31 2016 +1100 > > libFLAC/cpu.c: Use `sigemptyset` instead of `__sigemptyset` > > The former is POSIX while the later is a GNU

Patch is here: https://github.com/openwrt/packages/commit/1263599f96f13f11d719ce336dfb6a639b32de98 . Probably needs to be modified for inclusion into mainline.

HI all, I think its time for a new release. The current code base is stable and I've been building it for x86_64/linux, powerpc/linux, armhf/linux, x86_64/darwin in a Jenkins build bot. I'm pretty sure others have been building regularly on their platforms of interest. I made a first pass on an update to the changelog.html. I' also putting toether a release checklist that I will add

In stream_encoder.c there's the following code: #if defined FLAC__CPU_X86_64 /* and other 64-bit arch, too */ if(mean <= 0x80000000/512) { /* 512: more or less optimal for both 16- and 24-bit input */ #else if(mean <= 0x80000000/8) { /* 32-bit arch: use 32-bit math if possible */ #endif A) How to properly check for 64-bit architectures? I can check for "defined

Hi all, I just noticed this: https://sourceforge.net/p/flac/feature-requests/91/ a request for support of 32 bit audio data. The request has been around since 2008. Had two inial impressions: * Would adding this break brackwards compatibility too badly? Obviously decoding of 32 bit encoded data would not work with older versions of flac. * This is nuts. 24 bits has a dynamic range of

Thomas Zander wrote: > If you want to share the patch, I am happy to repeat some testing on > Sandy Bridge and Core2 with clang. The patch changes many files, libFLAC/bitwriter.c and test_libFLAC/bitwriter.c among them. So now I wait for the decision for patches #3 and #4 that I posted yesterday. > The slower decoding speed for 24 bit content on x86_64 seems > surprising, but

Seems time is going to be a constraint for me in the coming week, but I'll try and get more of these out to you as fast as I can get them written and tested. Keeping the patches in a separate branch for now seems like a good idea to me. Attached is a patch for 'test_streams.sh' On Tue, Mar 12, 2013 at 1:44 AM, Erik de Castro Lopo <mle+la at mega-nerd.com>wrote: > Jaren

Jaren Stangret wrote: > Attached is a patch for 'test_grabbag.sh'. Continuing in the same vein as > the other patches, this patch consists of minor reworks of > functions/commands as well as heavily commenting what's going on. > > More than halfway there! Jaren, Any sign of the patches for the rest of these tests? I have some other changes to the tests that I'd

lvqcl.mail wrote: > Microsoft Visual Studio 2015: > format.c(48): error C2065: 'PACKAGE_VERSION': undeclared identifier > > I edited MSVC project files (I changed 'VERSION' preprocessor variable > to 'PACKAGE_VERSION') and it resulted in successful build: > "Rebuild All: 26 succeeded, 0 failed, 0 skipped" Can I ask you to provide a patch

Jaren Stangret wrote: > Interestingly, I noticed compression level '0' is omitted, so I've added it > in. Thanks. > Also, I tested this on a 24bit/96kHz FLAC file and the test failed between > compression level 0 and compression level 1 -- the file size was greater > with a compression level of 1, rather than 0. The test works on > 'noisy-sine.wav'. It

Thomas Zander wrote: > In any case, the disable-SSE matter is still important. People are > still using flac on x86 machines without SSE, for instance AMD Geode > CPUs seem to live forever. libFLAC detects CPU SSE support in runtime, so --disable-sse is necessary for cuch CPUs only because it disables -msse2 switch. Maybe it makes sense to add new switch, --no-force-sse2 or

Dagobert Michelsen wrote: > Yes, C99 is on and according to B.2.18 from > http://docs.oracle.com/cd/E19205-01/819-5265/bjapp/index.html > also casual use. What does not work is the inclusion of a static function > from extern inline. It also does work if I declare bitwriter_grow_ also > as "inline". I actually think SUN/Oracle Studio is doing the wrong thing here as

Janne Hyv?rinen wrote: > I re-did the patch with these limitations. I also noticed I had left > stat() and fstat() functions unfixed previously. And encoder was limited > to 4G in many places when printing status info. Unfortunately, this patch did not apply cleanly. There were two problems; one in src/flac/main.c that was easy and obvious to fix, the other in include/share/compat.h.