similar to: 1.3.2pre3 (Hopefully final)

Hi, I tested my own Win32 compile of pre1 and pre2 one or two weeks ago (flac.exe through foobar2000 for transcoding), and the results were as expected: no errors, roughly same speed on my Intel Core i...something mobile, very slightly improved compression performance in comparison with 1.3.1). I didn't test all -1..-8 modes, but I diffed the source code of libFLAC between 1.3.1 and 1.3.2,

For what it's worth, I tested both the 32- and 64-bit flac.exe's on my Windows 10, with about 45 WAV files I have. Got some warnings about unexpected metadata, but the audio was encoded fine. Using the --keep-foreign-metadata flag cleared those warnings. I even had a weird WAV that caused "WARNING: legacy WAVE file has format type 1 but bits-per-sample=24", but flac dealt

On Thu, Dec 22, 2016 at 12:19:21AM +0000, oresteszoupanos at hotmail.com wrote: > > For what it's worth, I tested both the 32- and 64-bit flac.exe's on my > Windows 10, with about 45 WAV files I have. > > Got some warnings about unexpected metadata, but the audio was encoded > fine. Using the --keep-foreign-metadata flag cleared those warnings. Excellent! Do you

Hi all, New pre-release here is at: http://mega-nerd.com/tmp/flac-1.3.2pre2-win.zip http://mega-nerd.com/tmp/flac-1.3.2pre2.tar.xz Changes: * Fix PACKAGE_VERSION in MSVS project files. * Fix Makefile.lite in tarball (make test is still failiing). MD5 and SHA256 sums: > md5sum flac-1.3.2pre2* e276e3a9e99ae07f4bd25278f533b9e5 flac-1.3.2pre2.tar.xz

Hi all, I have tagged 1.3.0pre4 in git and provided a tarball here: http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz I have built and tested the git tree on: linux-x86_64 openbsd5-i386 freebsd5-i386 as well as successfully cross compiling from Linux to 32 and 64 bit MinGW. As far as I am concerned, the only thing left to do for this release is to update the

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

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

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

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/

On 28-04-13 13:23, LRN wrote: > On 28.04.2013 13:38, Erik de Castro Lopo wrote: >> I have tagged 1.3.0pre4 in git and provided a tarball here: >> >> http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz >> >> I have built and tested the git tree on: >> >> linux-x86_64 openbsd5-i386 freebsd5-i386 > i686-w64-mingw32 - builds correctly,

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

Hi all, As people may have seen there's a pre-release here: http://downloads.xiph.org/releases/flac/beta/ Specifically: flac-1.3.1pre1.tar.xz : The source code flac-1.3.1pre1-win.zip : Windows 32 and 64 bit binaries Please test. I'm particularly interested in hearing about the windows binaries which were cross compiled from Linux to Windows. Unfortunately there is a bug

Avuton Olrich wrote: > On 7/11/05, Erik de Castro Lopo <erikd-flac@mega-nerd.com> wrote: > >>and I'm thinking of adding support for FLAC in a CAF container >>as well. Is anyone else working on this? If so please let me >>know so we can agree on how FLAC should be contained with CAF. > > > I'm sorry, but what are the advantages to the different

Hi all, It hasn't really been publicized much yet, but Apple has a new container file format called CAF: http://developer.apple.com/documentation/MusicAudio/Reference/CAFSpec/ CAF files current support integer and float PCM formats, A-law, u-law and a number of others including AAC and Apple's own Apple Lossless Audio Codec (alac). I have already implemented support for what I can

Ulrich Klauer wrote: > Erik de Castro Lopo wrote: > > > In my latest commit I have updated all version strings and copyright > > dates. > > Here are some fixes to this. (Patch 2 compressed due to mailing list > size constraints.) Instead of the first patch, it would also be fine > to leave the encoding at ISO-8859-1, but store the name "Hyv?rinen" in

On 25.5.2013 10:54, Erik de Castro Lopo wrote: > Robert Kausch wrote: > >> Hi all, >> >> I tried 1.3.0pre4 with ICL on Windows and found some issues. Not sure if >> this is the right place to submit patches, but someone suggested this on >> the apparently dead SourceForge patch tracker. >> >> The first two are quite straight forward: >>

Compiling current git on MacOSX 10.5.8 Darwin mac.stare.cz 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 $ ./autogen.sh Updating build configuration files for FLAC, please wait.... configure.ac:26: require Automake 1.11, but have 1.10 autoreconf: automake failed with exit status: 1 Why

I managed to get around it. I used the stream functions and provided my own callbacks for reading and writing. What's strange is that what I've done is just copied the contents of read/write/seek/tell/eof callbacks from the sources to my application and it works just fine, no glitches. When I use the build-in implementation, it just crashes without any reason. It's not a problem to

Hi all, In the LLVM backend for the DDC compiler, since version 2.7 I have been doing the following: declare external ccc i32 @some_fn(%struct.Obj* ) align 8 ; bunch more declarations and code. define external ccc i32 @some_fn(%struct.Obj* %_p_vn) { entry: but now I'm getting an error at the function definition saying: error: invalid redefinition of function

Currently cpu.h lacks FLAC__SSE_TARGET and FLAC__SSEnn_SUPPORTED macros for clang. I added them, but I cannot properly test them as I can't get compiled flac.exe under Windows (don't know how to setup clang under MSYS2). If somebody has working clang, please test this patch. Does it affect en/decoding speed? Or at least, dows it affect disassembly of functions such as