search for: freac

...t..." > > > Today's Topics: > > 1. Re: slow on apple silicon? (Robert Kausch) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 8 Jul 2022 14:16:33 +0200 > From: Robert Kausch <robert.kausch at freac.org> > To: flac-dev at xiph.org > Subject: Re: [flac-dev] slow on apple silicon? > Message-ID: <b97549ba-844d-cc21-752b-5889e35819bd at freac.org> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Am 08.07.2022 um 09:26 schrieb Martijn van Beurden: > > Op...

...equired for easy distribution on 12 year old OSes > (which, last I saw, make up almost 40% of Firefox's desktop > userbase, and likely will continue to for some time). > > > > ---------- Forwarded message ---------- > From: Robert Kausch <robert.kausch at freac.org > <mailto:robert.kausch at freac.org>> > To: flac-dev at xiph.org <mailto:flac-dev at xiph.org> > Cc: > Date: Mon, 06 May 2013 01:20:52 +0200 > Subject: Re: [flac-dev] Bug fix and compatibility patches for > 1.3.0pre4 > Timothy B....

...s Topics: >> >> 1. Re: slow on apple silicon? (Robert Kausch) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 8 Jul 2022 14:16:33 +0200 >> From: Robert Kausch <robert.kausch at freac.org> >> To: flac-dev at xiph.org >> Subject: Re: [flac-dev] slow on apple silicon? >> Message-ID: <b97549ba-844d-cc21-752b-5889e35819bd at freac.org> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> Am 08.07.2022 um 09:26 schrieb Martijn v...

...1. Re: slow on apple silicon? (Robert Kausch) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Fri, 8 Jul 2022 14:16:33 +0200 >>> From: Robert Kausch <robert.kausch at freac.org> >>> To: flac-dev at xiph.org >>> Subject: Re: [flac-dev] slow on apple silicon? >>> Message-ID: <b97549ba-844d-cc21-752b-5889e35819bd at freac.org> >>> Content-Type: text/plain; charset=UTF-8; format=flowed >>> >>> Am 08.07.2022 um...

...o, they're required for easy distribution on 12 year old OSes (which, > last I saw, make up almost 40% of Firefox's desktop userbase, and likely > will continue to for some time). > > > > ---------- Forwarded message ---------- > From: Robert Kausch <robert.kausch at freac.org> > To: flac-dev at xiph.org > Cc: > Date: Mon, 06 May 2013 01:20:52 +0200 > Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4 > Timothy B. Terriberry wrote: > >> _lseeki64 operates on the underlying file handle, and does not interact >> wel...

...ke it work again on most systems. Tested on Windows (MSYS) and Ubuntu 12.10. The main issues were inclusion of non-existing Makefile.deps, missing PACKAGE_VERSION define and wrong build order (i.e. trying to build flac before libFLAC and other dependencies). ---- Robert Kausch robert.kausch at freac.org -------------- next part -------------- A non-text attachment was scrubbed... Name: flac-1.3.2pre1-litefix.patch Type: text/x-patch Size: 3204 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20161210/a72de964/attachment.bin>

On 6/3/14, Robert Kausch <robert.kausch at freac.org> wrote: > Am 03.06.2014 16:45, schrieb lvqcl: >> 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 >> -mss...

...lite files into release tarballs. Yes, the missing Makefiles solve most of the issues. The patch can be reduced to the attached version. I'm not sure about the other files you listed. I guess they should either be added to the tarball or removed from git. ---- Robert Kausch robert.kausch at freac.org -------------- next part -------------- A non-text attachment was scrubbed... Name: flac-1.3.2pre1-litefix.patch Type: text/x-patch Size: 1183 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20161211/44fdfaf8/attachment.bin>

...tep is @EXEEXT@, so one possible solution would be to detect a Windows OS using something like '|if["$(expr substr $(uname -s) 1 10)"=="MINGW32_NT"];|' and set EXE=.exe in that case instead of generating the file from common.sh.in. ---- Robert Kausch robert.kausch at freac.org -------------- next part -------------- A non-text attachment was scrubbed... Name: flac-1.3.2pre2-litefix.patch Type: text/x-patch Size: 2153 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20161211/fd78b09f/attachment.bin>

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

...t that caused a crash in vorbis_comment_add_tag. Thanks and best regards, Robert PS @ list moderator: I sent message before I joined the list a few days ago, but it was ignored. The mail should still be in the moderation queue; please disregard that one. -- ---- Robert Kausch robert.kausch at freac.org

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

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

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

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

Hi all, New pre-release here is at: http://mega-nerd.com/tmp/flac-1.3.2pre3-win.zip http://mega-nerd.com/tmp/flac-1.3.2pre3.tar.xz Changes: * Fix tests with Makefile.lite build system. * Fixes for non-Intel CPUs. MD5 and SHA256 sums: > md5sum flac-1.3.2pre3* 61aa8597a220303daf4beb2b8756979d flac-1.3.2pre3.tar.xz 8b470ceac02340600db73bc6daea4fc7 flac-1.3.2pre3-win.zip

Timothy B. Terriberry wrote: > Instead I've attached a patch that uses fgetpos/fsetpos. This is > totally untested (I haven't even checked it compiles), but the idea > should work. MSDN says "The pos value is stored in an internal format and is intended for use only by *fgetpos* and *fsetpos*." (http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx), so

Janne Hyv?rinen wrote: > Oldest Visual Studio supported by FLAC 1.3 is Visual Studio 2005. FLAC > is also configured to be compiled with static linking, so no external > dependencies hinder its function. Ok. Thanks for pointing this out! I use a custom build setup and link dynamically against msvcrt.dll. That's why I came across that problem and didn't realize that it would not

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 42ce639..e5c7695 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -74,7 +74,7 @@ static inline unsigned int FLAC__clz_uint32(FLAC__uint32 v) { /* Never

Hi all, There's a typo in the conditional to check the exit condition in ascii_strcasecmp in share/utf8/charset.c. It checks for (!*s1 || !*s1) instead of (!*s1 || !*s2). Attached patch fixes this. Note that the typo did not affect the result of the function as the loop is exited before changing s1 or s2 anyway. The problem was found by cppcheck which is run automatically on the Debian