[flac-dev] [PATCH] move CreateFile() function from libFLAC

This patch renames flac_internal_CreateFile_utf8() function to grabbag__CreateFile_utf8() and moves it from /src/libFLAC/windows_unicode_filenames.c into src/share/grabbag/file.c This function is not used by libFLAC anyway. After this, it should be possible to compile libFLAC as UWP. In the old c

Re: [flac-dev] Question: MSVS 2005/2008 support?

On Wed, May 2, 2018 at 5:25 PM, Stéphane Damo wrote: > I don't like the decision to remove the old VS project files, in my opinion > it's better to keep them, marked "not updated anymore". But it means that they eventually will become unusable. Besides, files that are "not updated anymore" are al

[flac-dev] Question: MSVS 2005/2008 support?

By default, FLAC requires ogg library. Support of old versions of Visual Studio was removed from libogg code about 2 years ago: https://git.xiph.org/?p=ogg.git;a=commit;h=18c401c6bc8814d06f3ae53ebf5d4399f90871cc libogg 1.3.3 (released 2017-11-07) cannot be built with MSVS 2005/2008 anymore. Are t

[flac-dev] [PATCH] Fix more GCC warnings about case fall-through

THere was a patch that silences GCC -Wimplicit-fallthrough warnings, see https://git.xiph.org/?p=flac.git;a=commit;h=1b5c09e4c692e243239945be3cba3ec72ea1699f There are a few more places that need this treatment. The patch is attached. Fix-more-GCC-implicit-fallthrough-warnings.patch Description:

[flac-dev] [PATCH] More generic version of MSVC bug workaround

There was a fix for a bug in MSVC 2015 update2: https://github.com/xiph/flac/commit/94a61241b02064c7d9fe508f72a742f2a90b8492 It seems that it's not the only version affected, see comment from 40th in this commit. Also, JRMC is affected: https://yabb.jriver.com/interact/index.php/topic,115742.0.htm

Re: [flac-dev] Crash when writing 32bit flac files, am I doing something wrong ?

On Thu, Mar 22, 2018 at 3:41 AM, Stéphane Damo wrote: > Hello, > > I manage to successfully write 8, 16 and 24 bit, all stereo, FLAC files. But > when I try to write 32 bit FLACs my program crashes. > > FLAC__stream_encoder_set_bits_per_sample is called to match the desired bit > depth (8, 16, 24,

[flac-dev] GCC7: -Wimplicit-fallthrough

If I compile libFLAC with GCC 7.1 I see many warnings like lpc.c: In function 'FLAC__lpc_compute_residual_from_qlp_coefficients': lpc.c:489:18: warning: this statement may fall through [-Wimplicit-fallthrough=] case 32: sum += qlp_coeff[31] * data[i-32]; ^~~

Re: [flac-dev] max size for album art?

Pierre-Yves Thoulon wrote: None, apart from the standard metadata block size limitation (2^24 bytes, e.g. 4GB). Pretty big for any kind of album art... 2^24 = 16777216, i.e. only 16 Megabytes. Kind regards. Pyt. Le 10 mai 2017 à 17:11, Scott Brown - scottcbr...@gmail.com a écrit : I

Re: [flac-dev] max size for album art?

Scott Brown wrote: Is there any size limitation for album art? Slightly less than 16 megabytes. I have a user who says adding large artwork (from a scanner) is corrupting the file metadata. I don't >know if this is a flac limitation, a tag lib issue, or something I'm doing. AFAIK olde

Re: [flac-dev] Windows Universal Platform?

Erik de Castro Lopo wrote: Hi all, Anyone know anything about Windows Universal Platform? Someone raised an issue on github: IIRC the issue with UWP was raised also in this ML: http://lists.xiph.org/pipermail/flac-dev/2017-January/006101.html ___

[flac-dev] [PATCH] some typos in header files.

The attached patch fixes a few typos. fix_typos.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] [PATCH] fix LLVM compile

Olivier Tristan wrote: Hi guys, Please find attached a patch that fixes the OSX build with llvm only __asm__ is supported but GCC support both so it's not an issue using this one AFAIK. lvqcl can probably confirm this. I can obly confirm that it works in GCC/MinGW, but that'

[flac-dev] [PATCH 6/5] comments in stream_decoder.c

There are 2 comments in stream_decoder.c that mention FLAC__lpc_restore_signal_asm_ia32_mmx() requirement for the output array. The text is updated to include intrinsic functions too. 06_decoder_comment.patch Description: Binary data ___ flac-dev mailin

Re: [flac-dev] [PATCH 5/5] SIMD: remove outdated SSE2 code

Erik de Castro Lopo wrote: lvqcl wrote: Ok, will do it, but currently xiph git still contains old code. Sorry, should be updated now. The patch is attached. 05_v2_remove_old_intrin_func.patch Description: Binary data ___ flac-dev mailing list

Re: [flac-dev] [PATCH 5/5] SIMD: remove outdated SSE2 code

Erik de Castro Lopo wrote: Sorry, this patch fails to apply on top of the others. Would you be able to rebase against what's currently in the tree? Ok, will do it, but currently xiph git still contains old code. ___ flac-dev mailing list flac-dev@xip

Re: [flac-dev] [PATCH 5/5] SIMD: remove outdated SSE2 code

Olivier Tristan wrote: Is the SSE 4.1 support detected at runtime ? i.e you compile with 4.1 support in order to get the intrinsincs by the compiler but the actual code >is only called at runtime when 4.1 is supported by the computer Correct (if the compiler isn't too outdated). ___

[flac-dev] [PATCH 5/5] SIMD: remove outdated SSE2 code

This patch removes FLAC__lpc_restore_signal_16_intrin_sse2(). It's faster than C code, but not faster than MMX-accelerated ASM functions. It's also slower than the new SSE4.1 functions that were added by the previous patch. So this function wasn't very useful before, and now it's even less useful

[flac-dev] [PATCH 4/5] SIMD: accelerate decoding of 16-bit FLAC

This patch adds 2 new functions, FLAC__lpc_restore_signal_intrin_sse41() and FLAC__lpc_restore_signal_16_intrin_sse41(). The decoding speed of Subset-compatible 16-bit FLAC files is slightly increased on SSE4.1-compatible CPUs. 04_add_new_intrin_func.patch Description: Binary data __

[flac-dev] [PATCH 3/5] SIMD: accelerate decoding of some 24-bit FLAC

This patch accelerates decoding of non-Subset 24-bit FLAC files (where lpc_order > 12). (The improved function is FLAC__lpc_restore_signal_wide_intrin_sse41(). It requires SSE4.1 and it's used only by 32-bit libFLAC) 03_wide_decode.patch Description: Binary data _

[flac-dev] [PATCH 2/5] SIMD: remove extra space

Most libFLAC code don't have a space between if and a parenthesis, so the patch removes them from lpc_intrin_sseNN.c files. 02_spaces.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-

[flac-dev] [PATCH 1/5] SIMD: add const qualifier

This patch adds const to some variables, to make code slightly easier to read. 01_const.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] about "cpu.h: Fix compiler detection" patch

Erik de Castro Lopo wrote: the bug *before* the logic is evaluated. My current solution in the above PR is to avoid `__has_attribute` and use this: #elif defined __clang__ && (__clang_major__ > 3 || \ (__clang_major__ == 3 && __clang_minor__ >= 6)) /* clang */ which I have tested

[flac-dev] about "cpu.h: Fix compiler detection" patch

After this patch, all FLAC__SSEN_SUPPORTED variables are undefined for GCC, so intrinsic versions of functions are not compiled into libFLAC. Previously, the code was: #if defined __INTEL_COMPILER // definitions for ICC #elif defined _MSC_VER // definitions for MSVC #elif defined __GNUC__ ||

Re: [flac-dev] [PATCH] cpu.h: add defines for clang

Erik de Castro Lopo wrote: How reliable a test is that? I do 99.9% of my dev work on a laptop and whenever I need to benchmark something I need to do so on a desketop machine because the laptop doesn't give consistent results. About 1.5 years ago I tested AVX2 speed increase on Haswell (i7-477

[flac-dev] [PATCH 1/2] for lpc_intrin_sseNN.c

This patch fixes bracket placement, extra space, etc in lpc_intrin_sse2.c and lpc_intrin_sse41.c ident_fix.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

[flac-dev] [PATCH] cpu.h: add defines for clang

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

Re: [flac-dev] metaflac crashes adding cuesheet

James wrote: The command used by abcde is metaflac --no-utf8-convert --import-cuesheet-from=/home/me/Audio/abcde.50107806/cue-50107806.txt --import-tags-from=- /home/me/Audio/abcde.50107806/track1.flac but I get the same result re-trying without the --no-utf8-convert and -no-utf8-co

[flac-dev] [PATCH] for compat.h

Description: redefine inline as __inline only for C, not for C++. compat_inline.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] os/2 support using Watcom

Ozkan Sezer wrote: The attached set of patches adds support for OS/2 using Watcom compiler (tested with Open Watcom 1.9). My only interest was building a working dll (the last patch in the set adds a makefile for it), therefore I did not touch other places: If there is interest, I can do so.

Re: [flac-dev] [PATCH] fix MSVC 2005/2008 build

Erik de Castro Lopo wrote: The definitions of these types are inside #if block with _MSC_VER < 1600 condition, so these changes affect only MS Visual Studio compilers with _MSC_VER < 1600 (i.e. MSVS 2005 and 2008). Thats a really great solution to this problem. Applied! Thanks. But I can't s

[flac-dev] MSVC 2005/2008 can't compile libFLAC

These versions of Visual Studio don't have stdint.h and all [u]intNN_t types. But now these types are everywhere in FLAC codebase. An easy fix would be to move definitions of these types from share/compat.h into FLAC/ordinals.h (see attached patch). But it may break some 3rd party programs that i

[flac-dev] [PATCH] fix getopt.c

This patch fixes 2 problems in getopt.c: 1) MSVC 2005 (and probably 2008) can't compile it because it doesn't have stdint.h 2) nameend and nextchar are pointers and the difference between them should be casted to 'size_t' type, not 'unsigned int' or 'uint32_t'. getopt_fix.patch Description: Bin

Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably

Erik de Castro Lopo wrote: Not all of them *needed( converting, but afaiac this makes the code base better. I never liked the way the original C standard allowed the use of `unsigned` alone as type. These recent updates broke MSVC 2005 (and probably 2008) builds because they don't have and al

Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably

Erik de Castro Lopo wrote: It's synonymous to uint32_t, but if the 1st parameter for _BitScanReverse*() functions has 'pointer to unsigned long' type then IMHO it's better to simply use unsigned long variable there. Sorry, I disagree on the idea of using `unsigned long` exactly because anyone

Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably

Erik de Castro Lopo wrote: Also MSVC fails because src/libFLAC/include/private/bitmath.h now contains "uint32_t long idx" instead of "unsigned long idx". Ah, missed that because it was MSVC code. They should be `uint64_t`. No, sizeof(unsigned long) is always 4 on Windows. See http://www.viva

Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably

Ozkan Sezer wrote: Well, the commit seems like overkill :) not all the unsigned needed converting. And build fails : format.c:53: error: conflicting types for 'FLAC__STREAM_SYNC' ../../include/FLAC/format.h:176: error: previous declaration of 'FLAC__STREAM_SYNC' was here [many others follow]

Re: [flac-dev] [PATCH 0/5] Allow multiple targets to be disabled

Hugo Beauzée-Luyssen wrote: configure.ac: Allow the programs to be disabled configure.ac: Allow bench to be disabled configure.ac: Don't build any tests when they are explicitely disabled configure.ac: Allow examples to be disabled win_utf8_io: Avoid forbidden functions when building f

[flac-dev] [PATCH] for FLAC__cpu_info_asm_ia32

Stumbled upon https://bugzilla.mozilla.org/show_bug.cgi?id=1096651#c9 bug Some old CPU (Cyrix) sets EDX but not ECX when executing CPUID. One of the solutions it to clear ECX before calling cpuid, and it can be applied to libFLAC code as well, see the patch. cpuid_cyrix_fix.patch Description: Bi

[flac-dev] [PATCH] set decoding status if write callback failed.

Open src/flac/decode.c, find write_callback() function and add return FLAC__STREAM_DECODER_WRITE_STATUS_ABORT; to the beginning of the function. Decoding will fail with the following message: test.flac: ERROR while decoding data state = FLAC__STREAM_DECODER_READ_FRAME As you c

Re: [flac-dev] Please test more libFLAC/cpu.c changes

Erik de Castro Lopo wrote: This code is in flux and in the current state the logic probably has inconsistencies that will be fixed in due course. What I am very much more interested in is if the code in the wip/cpu branch currently compiles and passes the test on Windows with MSVS. No, it doe

Re: [flac-dev] Please test more libFLAC/cpu.c changes

Erik de Castro Lopo wrote: Found a bug in Android OS SSE test. Sorry, what is the bug and how does this fix it? FLAC__cpu_info(FLAC__CPUInfo *info): detects CPU features that can be used and sets corresponding flags in the info struct. Feature detection algorithm for x86 arch: step 1: clea

Re: [flac-dev] FLAC__SSE_OS change

Erik de Castro Lopo wrote: No, what is needed is a way to disable SSE at run time even if it has been compiled in at build time. It's not possible if ALL flac/libFLAC files are built with -msse2 option. So the only solution is to remove -msse2 option from configure.ac. Unfortunately it will d

Re: [flac-dev] Please test more libFLAC/cpu.c changes

Erik de Castro Lopo wrote: Hi all, Julian Calaby has weighed in and provided a bunch of fixes for the dreaded cpu.c file. I've pushed them to the wip/cpu branch and I'd appreciate it if people could test them. Assuming you already have a clone of the repo: git pull git checkout wip/cpu

Re: [flac-dev] FLAC__SSE_OS change

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 disabl

Re: [flac-dev] FLAC__SSE_OS change

Erik de Castro Lopo wrote: Ok, I think I've fixed it in: commit a08e90c425343630d820b8775d5a2a63a02689ee Author: Erik de Castro Lopo Date: Sun Jun 26 21:09:08 2016 +1000 libFLAC/cpu.c: Fixes for MSVC Please test. MSVC 2005 win32: OK MSVC 2010 win32: OK MSVC 2015 win3

Re: [flac-dev] FLAC__SSE_OS change

Erik de Castro Lopo wrote: lvqcl wrote: No, MSVC 2015 is also affected. I renamed __cpuid() to __cpuid22(), I thought the original problem was with `___cpuidex`, not `__cpuid`! VC2005 generates code that uses __cpuid() because VC2005 has no __cpuidex(). VC2015 generates code that uses

Re: [flac-dev] FLAC__SSE_OS change

Erik de Castro Lopo wrote: The question is, what to do with the debug configuration. Is this only a problem with MSVS2005? No, MSVC 2015 is also affected. I renamed __cpuid() to __cpuid22(), and it wrote: error LNK2019: unresolved external symbol ___cpuid22 referenced in function _FLAC__

Re: [flac-dev] FLAC__SSE_OS change

Erik de Castro Lopo wrote: MSVC cannot discard unused references in debug builds and when LTCG is on, for example: And currently LTCG is enabled for release builds. Ok, thats a problem. A large chunk of the cleanup I was

Re: [flac-dev] FLAC__SSE_OS change

Erik de Castro Lopo wrote: lvqcl wrote: error LNK2019: unresolved external symbol ___cpuidex referenced in function _FLAC__cpu_info_x86 libflac_static.lib fatal error LNK1120: 1 unresolved externals flac.exe The code if (FLAC__AVX_SUPPORTED) __cpuidex(cpuinfo, level, 0

Re: [flac-dev] FLAC__SSE_OS change

Dave Yeo wrote: >on other OSes: > --enable-sse: > add -msse2 to the compiler switches > test SSE OS support (why?) >It's a bit contradictory: why test whether *BSD etc support SSE or not >but at the same time allow compiler to use SSE/SSE2 unconditionally? Yes, that n

Re: [flac-dev] FLAC__SSE_OS change

Erik de Castro Lopo wrote: MSVC 2015: builds OK. Great. Thanks. The current code builds OK on MSVC 2015 and 2010 but not on MSVC 2005: error C2059: syntax error : ';' cpu.c 153 error C2059: syntax error : 'type' cpu.c 153 error C2061: syntax error : identifier 'cpu_xgetbv_x86' cpu.

Re: [flac-dev] FLAC__SSE_OS change

yErik de Castro Lopo wrote: I think I've fixed both those in: commit 23778a3a6018f5dcb5fc1ad6ac97ad8391afc69d Author: Erik de Castro Lopo Date: Sat Jun 25 17:02:06 2016 +1000 libFLAC/cpu.c: More pre-processor cleanups I've tested on this in x86, x86_64, powerpc and arm

Re: [flac-dev] FLAC__SSE_OS change

Martin Leese wrote: lvqcl wrote: ... P.S. I wonder what's the point to test OS SSE support in 2016? I believe that users of Windows 95 and Windows NT4 don't expect new software to work on their OSes. I do (although I am often disappointed). There are developers that still su

Re: [flac-dev] FLAC__SSE_OS change

lvqcl wrote: Erik de Castro Lopo wrote: I actually think my change is correct. It should be easier to see if you look at the github version of the change: https://github.com/xiph/flac/commit/e120037f3c67b23fd9eef7ccd04d2df57fa1a9a6#diff-9f048b83ff55071de36263cf0f403b2eL209 P.P.S. 1

Re: [flac-dev] FLAC__SSE_OS change

Erik de Castro Lopo wrote: I actually think my change is correct. It should be easier to see if you look at the github version of the change: https://github.com/xiph/flac/commit/e120037f3c67b23fd9eef7ccd04d2df57fa1a9a6#diff-9f048b83ff55071de36263cf0f403b2eL209 FLAC__NO_SSE_OS was never

[flac-dev] FLAC__SSE_OS change

About the commit I admit I don't understand the following lines: #if !FLAC__SSE_OS /* assume user knows better than us; turn it off */ disable_sse(info); #elif defined(__FreeBSD__) || def

[flac-dev] [PATCH] for Darwin asm compile

This patch should fix https://sourceforge.net/p/flac/bugs/438/ I cannot test it myself because I don't have Mac OS X. But the fact that such patch was included in Audacity means that it should be OK. Or maybe it's better to ask Audacity/Macports/Fink devs for comments? macho_asm.patch Descripti

Re: [flac-dev] FLAC Visual Studio file tidy-up?

Orestes Zoupanos wrote: VS2015, considering it's quite recent and the Community Edition has a free-to-use-for-open-source license going on. Yup, into win32\VS2010 and VS2015. VS2015 or VS2005? Currently FLAC has 2 Visual Studio solutions: one for VS2005 (and 2008) and another for VS2010 an

Re: [flac-dev] FLAC Visual Studio file tidy-up?

Orestes Zoupanos wrotw: Yup, into win32\VS2010 and VS2015. VS2015 or VS2005? Currently FLAC has 2 Visual Studio solutions: one for VS2005 (and 2008) and another for VS2010 and all newer (2012, 2013, 2015...) ___ flac-dev mailing list flac-dev@xiph.or

[flac-dev] [PATCH] fix for metadata_iterators.c

My patch for metadata_iterators didn't completely fix the problem. The behavior of chain_prepare_for_write_() must always be the same as the behavior of FLAC__metadata_chain_check_if_tempfile_needed(). Currently it's not the case: one check was missed in FLAC__metadata_chain_check_if_tempfile_ne

Re: [flac-dev] FLAC Visual Studio file tidy-up?

Erik de Castro Lopo wrote: I'm looking to maybe move all the .sln and related Visual Studio project files (not the source .c and .h files!) into new directories under "win32\*" within the flac reppo. Any objections/tips or reasons to leave them as is? Lvqcl and other Window

Re: [flac-dev] [PATCH] MSVC2015U2 workaround, version 2

Ozkan Sezer wrote: Why not use a 64bit suffix to that 0x, e.g. 0xi64 to make the intention clear? (since you are specifically targeting msvc, the non-portability of i64 suffix shouldn't be a problem.) Maybe it's better to use ui64 suffix then? Also, ULL suffix works too. But

[flac-dev] [PATCH] MSVC2015U2 workaround, version 2

Here's a new version of a patch that fixes a problem with MSVC2105 update2, but it doesn't disable any optimization, so the resulting encoding performance should be almost unaffected by this workaround. MSVC compiles abs_residual_partition_sums[partition] = (FLAC__uint32)_mm_cvtsi128_si32(

Re: [flac-dev] [PATCH] workaround for a bug in MSVC 2015 U2

lvqcl wrote: It seems that MSVC miscompiles abs_residual_partition_sums[partition] = (FLAC__uint32)_mm_cvtsi128_si32(mm_sum); into movqQWORD PTR [rsi], xmm2 I just thought that it's also possible to use the following workaround: abs_residual_partition_sums[part

Re: [flac-dev] [PATCH] workaround for a bug in MSVC 2015 U2

Erik de Castro Lopo wrote: Ok, I'll take the original patch as it is. DO you have a link to a bug report on this problem? It would be nice to put it in a comment above the workaround. :sigh: I hoped that somebody else will find what's wrong and will create a bugreport... Well, here is the li

Re: [flac-dev] [PATCH] workaround for a bug in MSVC 2015 U2

Erik de Castro Lopo wrote: As I wrote earlier, MSVC 2015 U2 incorrectly compiles stream_encoder_intrin_*.c files for x86-64 platform. As a result, flac works, but compression ratio is close to 1. This patch disables some compiler optimizations, and compression ratio reverts back to normal values

[flac-dev] [PATCH] workaround for a bug in MSVC 2015 U2

As I wrote earlier, MSVC 2015 U2 incorrectly compiles stream_encoder_intrin_*.c files for x86-64 platform. As a result, flac works, but compression ratio is close to 1. This patch disables some compiler optimizations, and compression ratio reverts back to normal values. msvc_bug.patch Description

Re: [flac-dev] [PATCH] "iff" instead of "if" in comments

Timothy B. Terriberry писал(а) в своём письме Sun, 01 May 2016 19:29:42 +0300: "Iff" is commonly-used shorthand for the mathematical "if and only if", e.g., "returns true iff stat() succeeds for both files and they have the same device and inode" means it *won't* return true unless all of thos

[flac-dev] [PATCH] "iff" instead of "if" in comments

I noticed that there are several comments with "iff" word instead of "if", and it looks like typos to me. The patch is attached. iff_if.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/fla

[flac-dev] [PATCH 2] too big padding can result in flac file corruption

Here's the fix for another problem in metadata_iterators.c: it is possible for libLFAC to create too big padding metadata block -- a) when it merges existing padding blocks b) when it expands padding block during metadata changes. THe result is corrupted FLAC file. The patch should fix the proble

[flac-dev] [PATCH] MSVC: add ENABLE_64_BIT_WORDS macro

This patch adds ENABLE_64_BIT_WORDS preprocessor variable to libFLAC_dynamic, libFLAC_static and test_libFLAC projects, x64 platform. vcxproj.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listin

[flac-dev] [PATCH] bitwriter.c

1) removes unused FLAC__WORD_ALL_ONES definition 2) adds a couble of comment that unused bits of accumulator can contain garbage 3) turns assert inside FLAC__bitwriter_write_utf8_uint32 into realtime check (similar to FLAC__bitwriter_write_utf8_uint64() function) bitwriter.patch Description: Bina

[flac-dev] [PATCH] image embedding can result in flac file corruption

Currently it's possible to corrupt FLAC file with flac and metaflac tools. If image filesize is just slightly less than 2^24 bytes then the size of PICTURE metadata block will be more that this limit. The first patch (fix1.patch) adds additional check in /share/grabbag/picture.c/read_file() and

[flac-dev] MSVC 2015: problem after update2

Anybody still has MSVC 2015 update 1? It seems that MSVC 2015U2 miscompiles stream_encoder_intrin_sse2.c, stream_encoder_intrin_ssse3.c (and probably stream_encoder_intrin_avx2.c, but currently I cannot test it 'cause I don't have avx2 CPU). I wonder what happened and what changed in the asm cod

Re: [flac-dev] Broken build on musl libc

Dave Yeo писал(а) в своём письме Tue, 15 Mar 2016 02:09:13 +0300: >> With --disable-sse, FLAC__SSE_OS is undefined and FLAC__cpu_info() uses >> sigemptyset/sigaction to determine OS SSE support. > > That's not quite right as I have to build binaries with --disable-sse (I > build and distribute b

Re: [flac-dev] Broken build on musl libc

Thomas Zander писал(а) в своём письме Mon, 14 Mar 2016 15:29:13 +0300: >> @lvqcl, I tried to test this, but couldn't figure out what CPU architecture >> and configure options were required to build the code that changed. >> >> Any clues? > > AFAIK this p

[flac-dev] [PATCH] Compilation failure...

John Warburton wrote: Thank you for the feedback. This is cross-compiling for mingw-w64-x86_64 using gcc-5.3.0 and mingw-w64-4.0.4 on GNU/Linux. Upon attempting to compile now, a large number of errors occur in flac/decode.c which I have placed at the end of this email. They are eased by addin

Re: [flac-dev] [PATCH] remove libFLAC dependency of win_utf8_io

Erik de Castro Lopo wrote: When I tried apply that patch, all but one hunk succeeded. I inspected the rejected part, but that seemed to have already been applied. '1_sources.patch' creates windows_unicode_filenames.h and windows_unicode_filenames.c files that don't exist in the current git.

Re: [flac-dev] [PATCH] remove libFLAC dependency of win_utf8_io

Erik de Castro Lopo wrote: > lvqcl wrote: > >> The set of four patches that remove dependency of libFLAC on win_utf8_io. >> >> Tested only on Windows, with MSVC and MSYS/MinGW (both autotools and >> makefile.lite) >> >> Please review, especially makefil

[flac-dev] [PATCH] use more windows API in src/share/utf8/utf8.c

src/share/utf8/utf8.c mentions that "On NT-based windows systems, we could use WideCharToMultiByte()/MultiByteToWideChar(CP_UTF8), but MS doesn't actually have a consistent API across win32". flac/metaflac don't support Win98 since ver. 1.3.0, so it's possible to use system routines to convert t

[flac-dev] [PATCH] do not include windows.h if not necessary

As was written earlier -- share/compat.h indirectly includes windows.h (and other files because of it). It is necessary for declaration of CreateFile_utf8(), but only two files need it: src/flac/decode.c and src/share/grabbag/fil

[flac-dev] [PATCH] remove src/share/utf8/Makefile.am

The patch removed Makefile.am files from subdirs of src/share, but for some reasom didn't remove src/share/utf8/Makefile.am. This file is not included into release tarballs, so I think it's indeed unnecess

Re: [flac-dev] Performance tests

Martijn van Beurden писал(а) в своём письме Tue, 02 Feb 2016 08:14:42 +0300: > Once again, I did some performance testing. Results are here: > > http://www.audiograaf.nl/misc_stuff/Comparison on 32-bit ARM > (Raspberry Pi B).pdf > http://www.audiograaf.nl/misc_stuff/Comparison on 64-bit Linux >

Re: [flac-dev] Problems building on MinGW

Martijn van Beurden wrote: Hi all, I tried building the latest flac.git on Windows with MinGW just today, and got the following build error: (I had to copy-paste this 'by hand', so there might be a few small mistakes) CCLD utf8/libutf8.la CC win_utf8_io/win_utf8_io.lo win_

[flac-dev] [PATCH] fix MSVC 2005 debug build

MSVC2005 cannot build libFLAC in debug configuration, and this patch fixes it. vc2005_debug_build.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] test_streams dependencies

Brian Willoughby писал(а) в своём письме Sun, 31 Jan 2016 22:26:40 +0300: > My assumption is that the code was written to call flac_fopen() so that it is > portable to every operating system, even those without fopen(). If you > replace flac_fopen() with fopen(), then the tests won't compile o

[flac-dev] question about src/test_seeking.c - seek_barrage()

seek_barrage() has variable n of type long int (which is 32bit usually). Then we see something like n = (long int)total_samples; So, why n has type long int, and not FLAC__int64 or some other 64-bit type? ___ flac-dev mailing list flac-dev@xiph.org

[flac-dev] test_streams dependencies

test_streams currently depends on grabbag and (on Windows) on win_utf8_io libs. It depends on win_utf8_io only because it uses flac_fopen() function. It will become to depend on libFLAC when all file functions will be moved from win_utf8_io to libFLAC. Not a big problem, but it is possible to avo

[flac-dev] [PATCH] utf8.c: add missing check

The patch adds check of the result of make_utf8_string(), similar to the existing check of make_unicode_string(). utf8_addcheck.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] questions about utf8 library

Erik de Castro Lopo wrote: Also fixed. Thanks. There's also src/share/utf8/Makefile.am file that has the same issues. (I don't know why utf8 source files are included in two makefiles, one is src/share/Makefile.am and another is src/share/utf8/Makefile.am) utf8_Makefile.patch Description: B

Re: [flac-dev] questions about utf8 library

Erik de Castro Lopo писал(а) в своём письме Sun, 31 Jan 2016 01:47:01 +0300: >> 1) Both src/share/Makefile.am and src/share/utf8/Makefile.am >> have iconvert.h inside EXTRA_DIST, although iconvert.c includes it. >> Why? > > EXTRA_DIST is for files that are not listed elsewhere in the Makefile.am

[flac-dev] [PATCH] modifications of win_utf8_io

This patch changes win_utf8_io.c: simplifies *print functions, improves file related functions and prepates to move all file related functions into libFLAC. win_utf8_io.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://li

[flac-dev] [PATCH] comment in locale_hack.h

This file belongs to plugin_xmms, so the comment in it was fixed. comment_locale_hack.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

[flac-dev] [PATCH] remove plugin_common library from MSVC

Previously src/plugin_common library was used by flac own Winamp plugin (MSVC/Windows) and by XMMS plugin (*nix). The Winamp plugin is long gone from flac tree, so plugin_common is unused on Windows. This patch removes it from MSVC project files. remove_plugin_common_from_msvc.patch Description:

[flac-dev] questions about utf8 library

1) Both src/share/Makefile.am and src/share/utf8/Makefile.am have iconvert.h inside EXTRA_DIST, although iconvert.c includes it. Why? 2) What's the purpose of charsetmap.h? It seems that it's not used anywhere. ___ flac-dev mailing list flac-dev@xiph.org

[flac-dev] [PATCH] fix dependencies for MSVC

Currently MSVC fails when it rebuilds flac solution, because of some missing dependencies. this patch fixes MSVC projecy files. fix_msvc_lbflac_dependency.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/m

Re: [flac-dev] Lets do a 1.3.2 release

lvqcl wrote: > Erik de Castro Lopo wrote: >> Ok, lets do it. > > I just thought that it's more complicated. All *file* functions should > really be moved to libFLAC. But other functions should not, because > libFLAC doesn't use them. > I'm thinking ab

Re: [flac-dev] Lets do a 1.3.2 release

Erik de Castro Lopo wrote: >> Currently functions in win_utf8_io.c are a compatibility layer for >> libFLAC. I can't see reasons not to move win_utf8_io.c into libFLAC. > > Ok, lets do it. I just thought that it's more complicated. All *file* functions should really be moved to libFLAC. But other

[flac-dev] [PATCH] utf8 lib fixes (not win_utf8_io!)

Files share/utf8/charset.c and share/utf8/iconvert.c aren't needed under Windows. The patch removes them from MSVC build system. utf8.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-

Re: [flac-dev] Lets do a 1.3.2 release

lvqcl wrote: > all I can suggest > is to apply this patch, then fix issues if they'll happen after > this. But seriously, as a matter of fact win_utf8_io is a part of libFLAC. Functions from libFLAC call functions from win_utf8_io... For example: FLAC__stream_decoder_ini

  1   2   3   4   5   6   >