[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

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

[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

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

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

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

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's expected

[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

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

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

[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

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

[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

[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

[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

[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

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

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

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

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

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

[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

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

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:

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

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

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

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

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

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

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 support

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

[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

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

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

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

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

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

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

[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

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

[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

[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

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

Thomas Zander <thomas.e.zan...@googlemail.com> писал(а) в своём письме 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. >> >>

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

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.

[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

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

[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

[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

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

[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

[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

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

[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

[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] 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 about writing my

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

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

[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

[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] [PATCH] fix the comment in lpc.c

The current text of the comment in the libFLAC/lpc.c states that the "negative shift is a NOP in the decoder", but I don't think this is accurate. The patch for a slightly reworded comment is attached. Also this patch is connected to:

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

lvqcl wrote: > Evan Ramos wrote: > >> Does my patch fix this issue on your end? > > > BTW, your patch also changes MSVC solution/projects. What's the > problem with them? I built flac/metaflac/libFLAC libraries > with Visual Studio many times, and haven't noticed an

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

Dave Yeo wrote: >> I cannot find information what version of binutils supports AVX/AVX2/FMA >> instructions, but IIRC OS/2 doesn't support AVX instructions anyway, >> so it doesn't matter much. > > Surprisingly, I've yet to have a report of an AVX related crash or trap > (used in FFmpeg and

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

Dave Yeo wrote: > Seems that the default binutils on OS/2 is too old to support AVX2, > attached patch works around this. Not the best solution as best would be > configure tests, but simple. Are you sure that these binutils support AVX and FMA? (Currently libFLAC doesn't contain AVX and FMA

[flac-dev] [PATCH] for grabbag/snprintf.c

Fixed a comment in the beginning of the file. grabbag_snprintf.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

[flac-dev] About the commit "Fix compiler warnings from new compiler flags."

https://git.xiph.org/?p=flac.git;a=commit;h=91790ef965553fd6d76e1f51b55dc4de3b54ad4b It (among other things) changes (void)chown(...) into FLAC_CHECK_RETURN(chown(...)). I don't know what warning "(void)chown(...);" raises, and I cannot test it because I don't have Linux, but FLAC_CHECK_RETURN

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

Dave Yeo wrote: > The nature of the error implies AVX2 support that is missing but I'm not > much up on assembly, > > Best to be safe so updated patch attached. > I've also opened a ticket, http://trac.netlabs.org/rpm/ticket/165#ticket > Dave I cannot find information what version of binutils

[flac-dev] MSVC, win_utf8_io, static and dynamic libs

Currently MSVS can build dynamic libraries (libFLAC_dynamic.dll, libFLAC++_dynamic.dll), static libraries (libFLAC_static.lib, libFLAC++_static.lib) and executables (flac.exe, metaflac.exe, etc). All executables are statically linked to libFLAC. It's possible to create a flac.exe that is linked

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

Evan Ramos wrote: >> So currently libFLAC on _WIN32 does depend on win_utf8_io. > > Does my patch fix this issue on your end? BTW, your patch also changes MSVC solution/projects. What's the problem with them? I built flac/metaflac/libFLAC libraries with Visual Studio many times, and haven't

[flac-dev] [PATCH] check iterator->is_writable

In libFLAC/metadata_iterators.c, functions FLAC__metadata_simple_iterator_set_block() FLAC__metadata_simple_iterator_insert_block_after() check the value of iterator->is_writable, but FLAC__metadata_simple_iterator_delete_block() doesn't do it. Is there any reason for it? Because I

Re: [flac-dev] About libFLAC -> win_utf8_io dependency

lvqcl wrote: > Sorry, it wasn't clear: I mean -- to enclose all declarations of such > functions in FLAC/*.h and FLAC++/*.h header files. And then modify > e.g. flac sources so that it compiles without warnings/errors about > undefined functions. I was able to compile flac/metaf

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

Janne Hyvärinen wrote: > Win_utf8 stuff should not be included in libflac since it's only to be > used by the flac.exe frontend. It is not needed by other programs nor > would they benefit from it without doing the extra work of converting > their ansi filenames and functions to utf-8. > >>

[flac-dev] [PATCH] for flacdiff

Fixes are similar to parts of the following commits: flacdiff.patch Description: Binary data

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

lvqcl wrote: >>> Win_utf8 stuff should not be included in libflac since it's only to be >>> used by the flac.exe frontend. It is not needed by other programs nor >>> would they benefit from it without doing the extra work of converting >>> their a

[flac-dev] libFLAC, win_utf8_io, etc.

Evan Ramos wrote: >> So currently libFLAC on _WIN32 does depend on win_utf8_io. > > Does my patch fix this issue on your end? I don't use libFLAC, so it's not an *issue* for me. So I didn't test your patch. Previously all win_utf8_io stuff was intended to be MSVC-only: the use of win_utf8_io

[flac-dev] About libFLAC -> win_utf8_io dependency

First, this dependency exists only on Windows. For obvious reasons such dependency cannot exist on Linux/FreeBSD/OSX/etc. Previous versions (up to 1.2.1) didn't support Unicode filenames on Windows. And then it was decided to add such support. Windows uses UTF-16, where characters have 16-bit

[flac-dev] flac, UTF-8 and Windows

That's how I understand how flac.exe works with unicode under Windows: There's a flag win_utf8_io_codepage that is equal either to CP_ACP or to CP_UTF8. Initially it's equal to CP_ACP. Then flac.exe/metaflac.exe call get_utf8_argv() that do some things and sets win_utf8_io_codepage to CP_UTF8

Re: [flac-dev] About libFLAC -> win_utf8_io dependency

So far I can see three ideal solutions of this issue: 1) Make Unicode support a part of the libFLAC API. In this case there will be no need in separate -lFLAC -lwin_utf8_io options, just -lFLAC will be needed. 2) Remove the dependency between libFLAC and win_utf8_io. In this case

Re: [flac-dev] About libFLAC -> win_utf8_io dependency

lvqcl wrote: >But it requires somebody to rewrite FLAC apps. At least I have a suggestion: to enclose all FLAC API functions that take char* filename argument into #ifndef FLAC__FILENAME_API_DISABLED ... #endif and maybe also all functions that take FILE* argument into #ifn

Re: [flac-dev] About libFLAC -> win_utf8_io dependency

lvqcl wrote: > At least I have a suggestion: to enclose all FLAC API functions that > take char* filename argument into > > #ifndef FLAC__FILENAME_API_DISABLED ... #endif Sorry, it wasn't clear: I mean -- to enclose all declarations of such functions in FLAC/*.h and FLAC++/*.h

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

Evan Ramos wrote: >> Sorry, I misunderstood your intention. The utf8_static library should >> stay as a separate component, but should be statically linked as needed >> (ie its only needed for Windows) > > My patch does not touch src/share/utf8, only src/share/win_utf8_io, > which the objects in

  1   2   3   4   5   >