similar to: 1.3.2pre2

Am 11.12.2016 um 11:35 schrieb Erik de Castro Lopo: > 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). Thank you for providing a second preview!

Am 08.12.2016 um 20:44 schrieb Brian Willoughby: > On Dec 8, 2016, at 12:59 AM, Dave Yeo <dave.r.yeo at gmail.com> wrote: >> 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

Janne Hyv?rinen wrote: > Zip with random patches: > > flac_mac: fixes some missing parameters from safe string handling > changes in flac_mac's main.c > flac_mac_project: adds flac's include dir for the project so new > functions can be found > progress_display: flac testing progress display used old functions that > didn't get utf-8 decoding >

Am 11.12.2016 um 00:05 schrieb lvqcl.mail: > Robert Kausch wrote: > >> The main issues were inclusion of non-existing Makefile.deps > > It does exist in git, but not in flac-1.3.2pre1.tar.xz. > > (Here's the list of all files that exist in git but not in > the pre-release tarball: > > .gitignore > Makefile.deps > ci\flac-autotool.sh > doc\isoflac.txt

Ralph, for Mac OS you should download either the Unarchiver which is free, or Entrophy which is what I use, but it costs like $15 I believe, both support decompressing .7z and Entrophy supports compressing TO .7z On Mon, May 6, 2013 at 3:00 PM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev at xiph.org > > To subscribe or

Thank you very much, Robert. Setting the CXXFLAGS and LDFLAGS did indeed solve my compilation issue. The resulting build now encodes this same fileset at level 8 in 1:46. so now we have: current code in git, intel build running through emulation for this fileset I was testing on (encode 23 24/96 files at level 8): 3:02 arm build from git, no Neon optimizations: 3:54 arm build from git, with

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 everyone, I'm back with the same issue as before: flac encoding on an M1 Max Macbook pro is much slower on an arm build of 1.4.0 than it is running through emulation on an x86_64 build. ./configure -enable-static -disable-shared CFLAGS=" -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.9"

Hello again, Quick question about 1.4.2 source. When I comopiled the latest source back in September, I got the " Neon optimizations : ...................... yes" output. When I compile the official 1.4.2 source, there's nothing about Neon. Has this just been removed from the output, or is the official 1.4.2 missing something? Thanks, Scott On Mon, Sep 19, 2022 at 4:15?PM Scott

Hi Erik, Thanks for looking over my patch. > > * Account for the updates to UTF-8 on Windows. > > One of these updates, added an "#ifdef _WIN32" to the file > src/share/win_utf8_io/win_utf8_io.c. Is this really necessary? Is > it not possible to just not include that file when not compiling > for windows? You're right. I changed my patch to only specify

1) to the author of test/test_replaygain.sh There are 2 identical lines in this file: line 137 and next. Is it intended or just a copy/paste error? 2) to ALL: I attached a small program. Compile and run it. * Does it work correctly when compiled with -O3 -msse2 options? * If yes, does it work correctly when compiled with -O3 -funroll-loops -msse2 options? ( and what is the version of your

Hello all! Please forgive me if this is the wrong mailing list for my question. First off, I am on Windows and using git bash for everything: $ uname MINGW32_NT-6.2 I am attempting to essentially do the kalidescope example. I have copied the code verbatim from the full code listing and am running the following command: $ clang-cl toy.cpp deps/llvm/build/Debug/lib/*.lib //MDd -o toy.exe -I

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: - The ICL patch fixes a typo in bitmath.h and adds FLAC__bitwriter_write_zeroes to the external declarations in bitwriter.c. - The Ogg patch replaces

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 Tanya, I have tried the 2.6 pre-release on the following host : Windows XP pro SP2 with mingw/msys : uname -a MINGW32_NT-5.1 OLIVE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown gcc -v Reading specs from d:/mingw/bin/../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads

Dear Vorbis devs, I'm Robert Kausch, author of fre:ac - free audio converter. Please consider using _ogg_malloc/_ogg_free in place of alloca in vorbis_comment_add_tag. alloca will cause undefined behaviour/crashing when it causes a stack overflow which can easily happen when adding cover art in a METADATA_BLOCK_PICTURE comment. I had a user trying to convert a FLAC file with a 2 MB

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

Erik de Castro Lopo wrote: > That's a really good question. Haven't was already dropped support for > MSVC6? If so, we should drop this #ifdef hackery. Can test this without > the hackery for versions of MSVC > 6? I don't have VC 2002/2003, but the oldest Visual Studio that FLAC supports is MSVS 2005 anyway. It can compile FLAC__uint64 -> FLAC__double conversion

On Thu, Sep 3, 2009 at 6:24 AM, Olivier Meurant<meurant.olivier at gmail.com> wrote: > Hi Tanya, > > I have tried the 2.6 pre-release on the following host : > > Windows XP pro SP2 with mingw/msys : > > uname -a > MINGW32_NT-5.1 OLIVE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown > > gcc -v > Reading specs from d:/mingw/bin/../lib/gcc/mingw32/3.4.5/specs

Hi all, Thanks in advance for your help, and sorry for the slow reply. I've created a small OS X example project <https://drive.google.com/file/d/0B8vFUUth7NpvRFI0MmI2bVJNNEU/view?usp=sharing> that reproduces the issue. (I've run into the size limit for emails on this list so I've put it on Google Drive.) The program just initializes a libFLAC++ stream decoder for a given file