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

[lvqcl]

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 code there were 3 different #if  conditionals around the
code that uses CreateFile_utf8():
1)  #ifdef _WIN32 ... #endif
2)  #if defined _WIN32 && !defined __CYGWIN__ ... #endif
3)  #if defined _MSC_VER || defined __MINGW32__ ... #endif
It seems for me that the 2nd version makes more sense,so I replaced
them all with it.

Also this patch removes WINAPI_FAMILY_PARTITION ... CreateFile2 etc
stuff from the code.
The file src/share/grabbag/file.c contains non-UWP function
GetFileInformationByHandle,
and nobody complained, so it's OK to use non-UWP
CreateFileA/CreateFileW as well.


move_function_CreateFile_out_of_libFLAC.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 always available via
git history.

> I personnally use VS2013, and the reason I don't want to upgrade is the fact
> that VS2017 requires online registration to work. I'm pretty sure some users
> also have valid reasons to keep their old VS.

So you personally don't need 2005/2008 support.


(I don't care much about it myself though. If people prefer to let
them bitrot, fine by me.
Or maybe somebody really needs them, and will maintain them in working
condition).
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 there any developers that want to use libFLAC in their programs
and still use Visual Studio 2005 or 2008 ?

On the other hand, libvorbis 1.3.6 (released 2018-03-16) also needs
libogg and still has project files for MSVS 2005/2008 as well as 2010.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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

So, it makes sense to remove version check: better safe than sorry,
and performance
impact should be very small (probably negligible) anyway.


Better-workaround-for-MSVC-bugs.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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, 32)
>
> It's the same code for all bit depths, i provide a fixed-size signed int
> buffer to the lib (size=16384), with values with appropriate ranges for each
> bit depth (-128...+127 for 8 bit, etc.).
>
> The crash happens in stream_encoder.c line 2263 :
>
> encoder->private_->integer_signal[channel][i] = buffer[k++];
>
> It happens when I call FLAC__stream_encoder_process_interleaved(encoder,
> out, 16384/2) in my code. Its working perfectly for all bit depth except 32
> bit.
>
>
> Output message: Unhandled exception at 0x00F98441 in fmcomposer.exe:
> 0xC005: Access violation writing location 0x.
>
>
> I'm using the latest code from the github repository. Reading the docs
> didn't noticed any thing special to do for writing 32 bit FLACs, it seems it
> should be supported. Maybe I am missing something ?

AFAIK: while FLAC format itself supports 32-bit PCM, the official
encoder doesn't support it.

from include/FLAC/format.h:


/** The maximum sample resolution permitted by the format. */
#define FLAC__MAX_BITS_PER_SAMPLE (32u)

/** The maximum sample resolution permitted by libFLAC.
 *
 * \warning
 * FLAC__MAX_BITS_PER_SAMPLE is the limit of the FLAC format.  However,
 * the reference encoder/decoder is currently limited to 24 bits because
 * of prevalent 32-bit math, so make sure and use this value when
 * appropriate.
 */
#define FLAC__REFERENCE_CODEC_MAX_BITS_PER_SAMPLE (24u)

also, init_stream_internal_() function already checks bit depth:

if(encoder->protected_->bits_per_sample <
FLAC__MIN_BITS_PER_SAMPLE || encoder->protected_->bits_per_sample >
FLAC__REFERENCE_CODEC_MAX_BITS_PER_SAMPLE)
return FLAC__STREAM_ENCODER_INIT_STATUS_INVALID_BITS_PER_SAMPLE;


so, maybe you forgot to check return value for errors?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[flac-dev] GCC7: -Wimplicit-fallthrough

[lvqcl]

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];
^
lpc.c:490:5: note: here
   case 31: sum += qlp_coeff[30] * data[i-31];
   ^~~~
lpc.c:490:18: warning: this statement may fall through
[-Wimplicit-fallthrough=]
   case 31: sum += qlp_coeff[30] * data[i-31];
^
lpc.c:491:5: note: here
   case 30: sum += qlp_coeff[29] * data[i-30];
   ^~~~

...etc.

Relevant link:
https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 :


Is there any size limitation for album art?

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.


Thanks,
Scott

___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 older versions of libFLAC didn't check picture filesize, but the  
current version doesn't allow to embed too big files.

___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Windows Universal Platform?

[lvqcl]

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 mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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

[lvqcl]

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.
Also, ffmpeg uses __asm__  for inline x86 assembly.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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. I don't see a reason to keep it.

05_remove_old_intrin_func.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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

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

[lvqcl]

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

[lvqcl]

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 with clang 3.6. If someone has an earlier version
of clang and can verify that it work, I'll drop the version number.



Maybe it's simpler to add

#ifndef __has_attribute
#define __has_attribute(x) 0
#endif
#ifndef __has_builtin
#define __has_builtin(x) 0
#endif

somewhere before their use? (see  
http://clang.llvm.org/docs/LanguageExtensions.html )

___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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__ || defined __clang__
  #if defined __clang__ && __has_attribute(__target__)
// definitions for newer clang
  #elif !defined __clang__ && (__GNUC__ > 4 || (__GNUC__ == 4 &&  
__GNUC_MINOR__ >= 9))

// definitions for newer GCC
  #else
// definitions for older GCC and clang
  #endif
#endif



Now, it's basically:



#if defined __INTEL_COMPILER
  // definitions for ICC
#elif defined _MSC_VER
  // definitions for MSVC
#elif defined __GNUC__ && defined __clang__
  // definitions for clang
#endif



By the way, what's the problem with GCC 4.6?
According to :
"... and logical operations (&& and ||). The latter two obey the usual  
short-circuiting rules of standard C."


So I thought that the directive

   #if defined __clang__ && __has_attribute(__target__)

is ok for GCC because "defined __clang__" is false and
preprocessor shouldn't try to parse "__has_attribute(...)" part.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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-4770)
using -8 encoding preset. The biggest difference between AVX2 enabled
and disabled was 35% (64-bit flac.exe, 24-bit WAV input file).
The smallest difference was 10% (32-bit flac.exe, 16-bit WAV input file).



Disassembly of the object files (before and after) is here:

http://mega-nerd.com/tmp/stream_encoder_intrin_avx2-before.txt
http://mega-nerd.com/tmp/stream_encoder_intrin_avx2-after.txt

This is with clang version 3.8.1 from Debian testing.


I forgot that all avx2 functions are inside "#ifdef FLAC__AVX2_SUPPORTED"
conditional, so they simply don't exist if FLAC__AVX2_SUPPORTED is not set.

Anyway, stream_encoder_intrin_avx2-after.txt shows that the code
contains AVX2 instructions such as vpabsd/vpaddd/vphaddd, so
this function was compiled properly.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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

[lvqcl]

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 FLAC__precompute_partition_info_sums_intrin_avx2()?

clang_cpu_support.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] metaflac crashes adding cuesheet

[lvqcl]

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


This command also imports tags from stdin, so the problem may be
in tag handling. At least, I tried to use this command without
--import-tags-from, and I cannot get crash.

Does version 1.3.1 crash as well?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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

[lvqcl]

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.


Patches that remove warnings of DJGPP compiler broke support
for Visual Studio 2005/2008.
I don't care about these versions really, but I find it very
amusing that 20-years old and almost forgotten platforms
are more important than 10-years old.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 see new file share/msvc2005_int.h in
the current git snapshot.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 include
(directly or indirectly) this file and also have their
own typedefs for these types.

(Also, currently FLAC/ordinals.h contains some nonsense
like "typedef uint32_t __int32 FLAC__uint32;", but that's
not a real problem)


So, what to do?

1) include share/compat.h where needed (but it's too big,
and even indirectly includes ).

2) create a new file compat_stdint.h or compat_inttypes.h
that has only necessary definitions and include it.

3) apply the attached patch and hope that it has the most
compatible definitions for these types.

4) drop MSVC 2005/2008 support.

5) revert some changes of integer types to [u]intNN_t.

ordinals_fix.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 all these [u]intNN_t types.

A possible solution is to move their definition from share/compat.h
into FLAC/ordinals.h. After all, this file already has this ifdef:

#if defined(_MSC_VER) && _MSC_VER < 1600

...and also to revert back src\share\getopt\getopt.c. After all,
its coding style is EXTREMELY old and imho it won't benefit
much from 'unsigned int' -> 'uint32_t' replacement.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 that comes from Unix will assume that is `uint64_t`. Better to
use `uint32_t` which is totally platform independant and unambiguous.


Ok, Visual Studio doesn't complain if idx is declared as uint32_t.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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.viva64.com/en/t/0012/


According to MSDN _BitScanReverse*() functions have signatures:
unsigned char _BitScanReverse(unsigned long *, unsigned long);
unsigned char _BitScanReverse64(unsigned long *, unsigned __int64);


The `unsigned long` type should be synonymous with `uint64_t` so using
`uint64_t` should be safe. Furthermore if they aren't synonymous we
*want* that to be a compile error!


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.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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]



Also MSVC fails because src/libFLAC/include/private/bitmath.h now
contains "uint32_t long idx" instead of "unsigned long idx".

According to MSDN _BitScanReverse*() functions have signatures:
unsigned char _BitScanReverse(unsigned long *, unsigned long);
unsigned char _BitScanReverse64(unsigned long *, unsigned __int64);

Other than that, it compiles everything without errors.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 for WinRT/UWP

 configure.ac| 10 ++
 examples/Makefile.am|  2 ++
 microbench/Makefile.am  |  4 
 src/Makefile.am | 10 +++---
 src/flac/Makefile.am| 13 +
 src/metaflac/Makefile.am|  8 ++--
 src/share/win_utf8_io/win_utf8_io.c |  9 +
 src/test_libFLAC++/Makefile.am  |  5 +
 8 files changed, 52 insertions(+), 9 deletions(-)



Ping :)


I think that FLAC sources should remain compatible with Visual
Studio 2010 (and probably earlier), people still need it.
For example: 

Is it possible to simply exclude win_utf8_io.c from compiling
if target OS is WinRT/non-desktop?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[flac-dev] [PATCH] for FLAC__cpu_info_asm_ia32

[lvqcl]

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: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 can see, decoder state isn't quite correct.

One of the ways to fix this is in the attached patch.
After the patch flac writes:

test.flac: ERROR while decoding data
 state = FLAC__STREAM_DECODER_ABORTED

which is more logical.

set_decoding_status.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 doesn't:

error C2010: '.' : unexpected in macro formal parameter list

It complains about the line

#define dfprintf(file, format, args...)

The correct syntax for variadic macro in MSVC is:

#define dfprintf(file, format, ...)


After this change, MSVC can compile flac without problems.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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: clear all flags (via memset(info, 0, ...) call)

step 2: test if cpuid is available. If not, return.

step 3: call cpuid, determine available CPU features
and set corresponding flags to 1.

step 4: test OS SSE support. If the OS doesn't support SSE
(or if such test isn't possible) then set all sseN flags to 0.

step 5: test OS AVX support. If the OS doesn't support AVX
then set all avxN flags to 0.

(currently there's some discrepancy: if FLAC__SSE_OS==1 then
step 4 is skipped on Linux, and only on Linux)


If the target OS is Android then step 4 can be skipped because
all versions of Android for x86 support SSE. But the current code
skips everything after the 1st step! All flags in the info struct
are unset, and all accelerated functions are disabled.

After my patch only the step 4 is skipped for Android, as it should be.


And for x86-64 arch, there's no need in steps 2 and 4, for all CPUs and OSes.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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 disable all intrinsics for GCC 4.8
and older (and afaik for clang): only if a file was
compiled with -msse option then sse intrinsics are allowed.
-msse2 enables sse and sse2 intrinsics, and so on.


The common way is to compile different files with different
options. For libFLAC it means that all *_sse.c files should be
compiled with -msse switch, all *_sse2.c files should be compiled
with -msse2, and so on. But unfortunately it's not supported in
the current build system.

OTOH, GCC 4.9 (and newer) doesn't require those switches:
now it's possible to set supported instruction set on a per-function
basis. That's what libFLAC does with FLAC__SSE_TARGET(x) macro.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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

and then build as normal.

Cheers,
Erik


Found a bug in Android OS SSE test.

Fix for the master branch is in master_fix1.patch file,
fix for wip/cpu branch is in wip_fix1.patch file.

master_fix1.patch
Description: Binary data


wip_fix1.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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 disables -msse2 switch.

Maybe it makes sense to add new switch, --no-force-sse2 or
--disable-force-sse2 or similar? And replace

if test "x$asm_optimisation$sse_os" = "xyesyes" ; then
XIPH_ADD_CFLAGS([-msse2])
fi

with

if test "x$force_sse2" = "xyes" ; then
XIPH_ADD_CFLAGS([-msse2])
fi

?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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 win32: OK
MSVC 2010 x64: failed
MSVC 2015 x64: failed

error C4235: nonstandard extension used: '__asm' keyword not supported on this 
architecture

MSVC doesn't support inline asm for x86_64 code. That's why it
cannot compile ia32_cpu_info() for x86_64 arch.

This can be fixed with the attached patch.

cpufix.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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 __cpuidex() and doesn't use __cpuid(),
although VC2015 has both __cpuid() and __cpuidex().

If you're only concerned about the following code

if (FLAC__AVX_SUPPORTED)
__cpuidex(cpuinfo, level, 0); /* for AVX2 detection */
else
__cpuid(cpuinfo, level); /* some old compilers don't support __cpuidex 
*/

then MSVC 2015 can create debug builds because it has both __cpuid() and 
__cpuidex()

But I thought that you're more concerned about DCE issue in general.
So I changed existing __cpuid() into non-existing __cpuid22().
For VC2015, FLAC__AVX_SUPPORTED is defined as 1, so the code always
calls __cpuidex() and never calls (non-existing) __cpuid22().
Yet MSVC 2015 cannot create debug build.

So this proves that MSVC 2015 cannot discard unused references in debug builds.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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__cpu_info_x86
fatal error LNK1120: 1 unresolved externals

So, all currently available MSVC compilers cannot create debug builds
for such code.
But I have no idea are they really necessary or not.





If so, I'd be inclined to jsut
drop support for it. Its over 10 years old and aren't there free versions
of more recent MSVCs available?


IIRC nobody complained about dropping support for MSVC 6/.NET/2003
during the development of FLAC 1.3.0.
But e.g. Audacity switched from MSVC 2008 to MSVC 2013 only at the end
of 2014 year: .
FLAC 1.3.1 was released at about the same time.
Maybe now it makes sense to remove MSVC 2005/2008 support... but anyway,
it won't help with DCE and MSVC debug builds.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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 hoping to do
depended on the fact that any sane compiler drops code which can be
proved to be un-needed at compiler.

Can LTCG be disabled?


Sure.

The question is, what to do with the debug configuration.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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); /* for AVX2 detection */
 else
 __cpuid(cpuinfo, level); /* some old compilers don't support __cpuidex 
*/

adds reference to __cpuidex() even though MSVC2005 doesn't have it
(according to MSDN, it was added to MSVC 2008 SP1).


That suggests that FLAC__AVX_SUPPORTED is true. Can you set it to false
for MSVC2005?


No, FLAC__AVX_SUPPORTED is 0 (initially it's undefined, then inside cpu.h
it's defined as 0).

MSVC cannot discard unused references in debug builds and when LTCG is on,
for example: 
<http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193437.html>

And currently LTCG is enabled for release builds.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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 needs to be fixed. I think the way it works on Linux makes
the most sense.



Doesn't SSE support imply SSE2+ support?


There's no point to test OS SSE support if a compiler already
inserted SSE/SSE2 instructions everywhere (because of -msse2 switch).


The problem is that the OS has
to preserve the XMMS registers when doing a context switch. Once the
kernel is preserving the XMMS registers, I'd assume that all SSEx
instructions should work.


If the OS doesn't support SSE instructions but -msse2 option was used
then libFLAC will crash: it cannot disable the use of SSE/SSE2
instructions that were generated by the compiler.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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.c   153

It doesn't know about uint32_t type, so the definition of cpu_xgetbv_x86() 
fails.
It can be fixed by adding "#include share/compat.h" to cpu.c (or by using
FLAC__uint32 from FLAC/ordinals.h).

When I fix this, the following problem occurs:

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); /* for AVX2 detection */
else
__cpuid(cpuinfo, level); /* some old compilers don't support __cpuidex 
*/

adds reference to __cpuidex() even though MSVC2005 doesn't have it
(according to MSDN, it was added to MSVC 2008 SP1).
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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 armhf linux as well as
cross-compiling from linux to x86 and x86_64 Windows.



So if I understand things correctly, the current meaning of --(en|dis)able-sse 
is:

on Linux:
--enable-sse:
add -msse2 to the compiler switches
do not test SSE OS support (assume that SSE is supported)
--disable-sse:
do NOT add -msse2
test SSE OS support

on other OSes:
--enable-sse:
add -msse2 to the compiler switches
test SSE OS support  (why?)
--disable-sse:
do NOT add -msse2
test SSE OS support

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?


Also: are there any compilers / target OSes such that libFLAC currently
has no way to test OS support of SSE? The current code will always
disable SSE for such builds:
--enable-sse:
add -msse2 to the compiler switches
disable the use of SSE code
--disable-sse:
do NOT add -msse2
disable the use of SSE code

previously --enable-sse made it possible to override this.



Please test compiling on Windows and anything else you can get your
hands on.


Will do.
MSVC 2015: builds OK.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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 such OSes. For example,
XMPlay still works on Win95 and NT (at least that's written in
its readme file).
On the other hand foobar2000 requires at least XP SP2, and
I suspect that fb2k is more popular than XMPlay.

(AIMP and MusicBee now officially require Vista+).
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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) if FLAC__SSE_OS==1 then MSVC cannot compile current cpu.c:
"#include " line is inactive and MSVC complains:
cpu.c(278): error C2065: 'EXCEPTION_EXECUTE_HANDLER': undeclared identifier
cpu.c(279): error C2065: 'STATUS_ILLEGAL_INSTRUCTION': undeclared identifier

2) the current code (simplified):

if(info->ia32.sse) {
#if !FLAC__SSE_OS
/* assume user knows better than us; turn it off */
disable_sse(info);
#elif ...
#elif defined(__linux__) && !FLAC__SSE_OS
#elif ...
#else
#endif
}

means that the __linux__ part is never compiled: if FLAC__SSE_OS==0 then
this code becomes just "disable_sse(info);" and if FLAC__SSE_OS==1
then "defined(__linux__) && !FLAC__SSE_OS" is always false.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__SSE_OS change

[lvqcl]

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 defined anywhere, so I think that
the following changes should be made:

  defined FLAC__NO_SSE_OS ->  0
 !defined FLAC__NO_SSE_OS ->  1
  defined FLAC__SSE_OS->  FLAC__SSE_OS
 !defined FLAC__SSE_OS->  !FLAC__SSE_OS

So the code

 #if defined FLAC__NO_SSE_OS
/* assume user knows better than us; turn it off */
disable_sse(info);
 #elif defined FLAC__SSE_OS
/* assume user knows better than us; leave as detected above */
 #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ...

becomes

 #if 0
/* assume user knows better than us; turn it off */
disable_sse(info);
 #elif FLAC__SSE_OS
/* assume user knows better than us; leave as detected above */
 #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ...

which is equivalent to

 #if FLAC__SSE_OS
/* assume user knows better than us; leave as detected above */
 #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ...

(and there should be no "&& !FLAC__SSE_OS" after "#elif defined(__linux__)")


But yes, all those #ifs and #elses are horrible for readability and
maintainability.


OTOH dead code elimination (as in ffmpeg) makes it impossible to build
debug version...
Probably it's better to have one main simple cpu.h and several additional
files (one per architecture) but I'm not going to volunteer for the
refactoring.


CHeers,
Erik


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. Don't know about users of ancient versions of Linux/BSD/etc though.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[flac-dev] FLAC__SSE_OS change

[lvqcl]

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__) || defined(__FreeBSD_kernel__) ..

Probably it should be

 #if FLAC__SSE_OS
/* assume user knows better than us; leave as detected above */
 #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ..

?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 and all newer (2012, 2013, 2015...)




Then I don't quite understand. Do you plan to drop support for VS2005/2008?
Besides, VS2015 and VS2010 solution/project files will be almost identical,
so what's the benefit from separate VS2015 and VS2010 solutions?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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_needed(), and also 
chain_prepare_for_write_()
checks sizes of metadata blocks *after* making the changes of the chain, while
FLAC__metadata_chain_check_if_tempfile_needed() does it *before* the changes.

This patch changes FLAC__metadata_chain_check_if_tempfile_needed() so that it
keeps some info (lbs_state, lbs_size) about estimated changes and then
uses it to check the block sizes.

It also simplifies FLAC__metadata_chain_check_if_tempfile_needed() a little.

metadata_iterators_fix.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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

I'm ok with this if you are.


I don't care much actually... THough I'd like to know exactly what files
will be moved and where. Into 2 new directories "win32\VS2005" and
"win32\VS2010", or somewhere else?


Maybe it's better to ask those who use libFLAC in their Windows programs.
Audacity devs? Winamp devs? Somebody else?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 I don't know is it better to use it or not...
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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(mm_sum);

into this:

movqQWORD PTR [rsi], xmm2

while it should be

movdeax, xmm2
mov QWORD PTR [rsi], rax

With this patch, MSVC emits

movqQWORD PTR [rsi], xmm2
mov DWORD PTR [rsi+4], r9d

so the price of this workaround is 1 extra write instruction per partition.

msvc_bug_v2.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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[partition] = 
(FLAC__uint32)_mm_cvtsi128_si32(mm_sum);
+#if (defined _MSC_VER) && (_MSC_FULL_VER == 190023918) && (defined 
FLAC__CPU_X86_64)
+abs_residual_partition_sums[partition] &= 0x;
+#endif

probably this will be faster than to disable optimization.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 link:   
https://connect.microsoft.com/VisualStudio/feedback/details/2659191/incorrect-code-generation-for-x86-64


It seems that MSVC miscompiles
abs_residual_partition_sums[partition] = 
(FLAC__uint32)_mm_cvtsi128_si32(mm_sum);
into
movqQWORD PTR [rsi], xmm2

So it incorrectly copies 8 bytes from mm_sum to 
abs_residual_partition_sums[partition]
(it should copy 4 lower bytes and zero out 4 upper bytes).

It should be something like
movdeax, xmm2
movqQWORD PTR [rsi], rax
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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.


Rather than having the same chunk of code in three different
files, wouldn't it be nicer to put it in "share/compat.h" and
include it as needed?


But it will disable optimization on all other files that directly or
indirectly include compat.h (that is, almost all files).

IMHO it's too broad. It seems that this problem with MSVC is local
and only stream_encoder_intrin_*.c are affected.



Or do you mean something like that --

share/compat.h:

#if defined FLAC_ENABLE_MSVC2015U2_WORKAROUND1
#if (defined _MSC_VER) && (_MSC_FULL_VER == 190023918) && (defined 
FLAC__CPU_X86_64)
#pragma optimize("g", off) /* workaround for a bug in MSVC 2015 U2 */
#endif
#endif

src/libFLAC/stream_encoder_intrin_*.c:

#define FLAC_ENABLE_MSVC2015U2_WORKAROUND1
#include "share/compat.h"

-- ?

...Not sure that share/compat.h is a right place for this workarounds.
This bug is quite local and doesn't manifest itself in other source
files, and share/compat.h is quite global and affects many files.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 those
conditions are satisfied.


Wow. Didn't knew this.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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/flac-dev

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

[lvqcl]

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

fix3.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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/listinfo/flac-dev

[flac-dev] [PATCH] bitwriter.c

[lvqcl]

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: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 removes rather useless check from FLAC__metadata_object_picture_set_data().

It's enough to fix the command-line tools, but I think that it also makes
sense to add additional checks into libFLAC library; so fix2.patch adds
two checks of metadata block length.

fix1.patch
Description: Binary data


fix2.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[flac-dev] MSVC 2015: problem after update2

[lvqcl]

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 code that MSVC generates.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 both with and without) so that some users on PII's
> don't get a sigill, even though the OS supports SSE. So it seems to
> unconditionally disable SSE support or test the CPU support with
> sigemptyset/sigaction.

Currently --disable-sse does the following:
1) enables code that detects OS SSE support;
2) disables -msse2 option.

Without --disable-sse flac assumes that target OS supports SSE
and target CPU supports SSE2.

If you want to create a program that works on non-sse2 x86 CPUs,
you can also do this: open configure.ac, find the following code

if test "x$asm_optimisation$sse_os" = "xyesyes" ; then
XIPH_ADD_CFLAGS([-msse2])
fi

and remove it.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 part should always be built on Linux (except on Android) on
> x86 CPUs. If at all, --disable-sse could prevent it.
>
> Riggs

IIRC --disable-sse *en*ables this code.


The current default option is --enable-sse which defines FLAC__SSE_OS macro,
so libFLAC doesn't test OS SSE support.

With --disable-sse, FLAC__SSE_OS is undefined and FLAC__cpu_info() uses
sigemptyset/sigaction to determine OS SSE support.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 adding this to decode.c:

#if _WIN32
#include 
#include 
#endif

...among the headers.

Then, this error results when attempting to link flac.exe:

decode.o:decode.c:(.text+0x4fe1): undefined reference to `CreateFile_utf8'
decode.o:decode.c:(.text+0x50fb): undefined reference to `CreateFile_utf8'
../../src/share/grabbag/.libs/libgrabbag.a(file.o):file.c:(.text+0x156):
undefined reference to `CreateFile_utf8'
../../src/share/grabbag/.libs/libgrabbag.a(file.o):file.c:(.text+0x188):
undefined reference to `CreateFile_utf8'
collect2: error: ld returned 1 exit status
Makefile:487: recipe for target 'flac.exe' failed

I believe the developers have been attending to code relevant to this error
in the recent past.



It seems that some patch was partially applied. Two possible fixes for
the problem are attached.

The first adds missing defines to src/flac/decode.c and src/share/grabbag/file.c

The second removes #ifdef...#endif directives from 
windows_unicode_filenames.(c|h)

(they're mutually exclusive - there's no point in applying both of them)

fix_variant1.patch
Description: Binary data


fix_variant2.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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.


Lets just get a patch that fixes what we have now.


Here it is: the missing parts of d40a6bc commit are in the
attached fix_d40a6bc_commit.patch




Also an (optional) use_winapi_macro.patch from

was re-made and attached.

fix_d40a6bc_commit.patch
Description: Binary data


use_winapi_macro.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 makefile patches, I'm not very familiar with them.
>
> Applied. All good. Thanks.

But the 1st patch ('1_sources.patch' file) was not applied... I suspect
that Windows build is broken now.

Before this set of 4 patches, I posted a patch that tries to prevent unnecessary
inclusion of windows.h -- 'use_winapi_macro.patch' file from
<http://lists.xiph.org/pipermail/flac-dev/2016-February/005856.html> message.

'1_sources.patch' was made after it, and as a result 'use_winapi_macro.patch'
must be applied before it. If you object to that patch, I can make version of
'1_sources.patch' that is based on the current code.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 to/from UTF-8.


I removed all fprintf(stderr...) code from the win32 code because
non-windows code in utf8.c doesn't print anything in such cases and
simply returns an error.

utf8_new.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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/file.c

In 
was proposed to add a preprocessor macro to solve the issue.

The patch is attached.

use_winapi_macro.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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 unnecessary. It's better to remove it than let it bit-rot.

remove_unused_makefile.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Performance tests

[lvqcl]

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
> (2008 Intel).pdf
>
> I'll add some results for 64-bit Windows (2014 Intel with AVX2)
> in a few days. Results look nice, a 20% speedup on my x86_64
> platform for the slowest mode. Not much difference for ARM.
> Sorry for the confusing colors (swapped between the two PDFs)

BTW, 64-bit flac can benefit from 64-bit words in bitreader/bitwriter
routines. Currently it requires --enable-64-bit-words switch in
./configure parameters. It would be interesting to test its effect,
especially on ARM.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Problems building on MinGW

[lvqcl]

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_utf8__io/win_utf8_io.c:266:13: error: static declaration
of 'set_filename_utf8' follows non-static declaration
 static void set_filename_utf8(int b)
 ^
win_utf8__io/win_utf8_io.c:106:6: note: previous declaration
of 'set_filename_utf8' was here
 void set_filename_utf8(int b);
  ^

win_utf8__io/win_utf8_io.c:266:13: warning:
'set_filename_utf8' defined but not used [-Wunused-function]
 static void set_filename_utf8(int b)
 ^

make[3]: *** [win_utf8_io/win_utf8_io.lo] Error 1


This probably has something to do with the recently merged utf8
patches? FLAC 1.3.1 didn't have this problem.


Here's a simple patch that should fix it (attached).

BTW, this version of win_utf8_io.c is intermediate because a part of it
will be moved to libFLAC, and I'll test the final version more thoroughly...

build_fix.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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

[lvqcl]

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 on systems 
> that don't have fopen().

I REALLY doubt it. Even if such systems exist, there's little reason
to support test_streams on them.

fopen() was changed to flac_fopen() here:
https://git.xiph.org/?p=flac.git;a=commitdiff;h=5705b4d7b2c3c5311138e9f4b66658c51f3cc22b#patch64
as a part of "Huge Windows utf8 I/O patch from Janne Hyvärinen".

> You could simply have the following:
>
> #if defined _MSC_VER || defined __MINGW32__
> #define flac_fopen fopen
> #endif
>
> In a header, or simply at the top of test_streams/main.c where there's 
> already some conditional compilation.

Currently flac_fopen is already defined as fopen on non-MS systems.
So it's simpler to change flac_fopen back to fopen in this file.
___
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()

[lvqcl]

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
http://lists.xiph.org/mailman/listinfo/flac-dev

[flac-dev] test_streams dependencies

[lvqcl]

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 avoid
this dependency by replacing flac_fopen() with fopen().

test_streams doesn't open/create files with unicode filenames, so it won't
affect its functionality.

So, what's better:
a) replace all flac_fopen() calls inside test_streams/main.c with fopen()
b) leave it as is, so that on Windows build of test_streams will depend on 
libFLAC
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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

[lvqcl]

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

[lvqcl]

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
> but which need to end up in the distribution tarball.


So should it be moved from EXTRA_DIST into 
utf8_libutf8_la_SOURCES/libutf8_la_SOURCES
where iconvert.c is mentioned?



>> 2) What's the purpose of charsetmap.h? It seems that it's not used
>> anywhere.
>
> It was added in 2002, but like you said is not used anywhere.
>
> I'll remove it.

BTW, it's still referenced in EXTRA_DIST list in the above-mentioned two files.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[flac-dev] [PATCH] modifications of win_utf8_io

[lvqcl]

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://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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

[lvqcl]

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: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[flac-dev] questions about utf8 library

[lvqcl]

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
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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/mailman/listinfo/flac-dev

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

[lvqcl]

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 own patch to fix libFLAC -- win_utf8_io
dependency. It'll keep win_utf8_io library and move only necessary
functions into libFLAC. It's more elegant and simple (I hope).
___
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]

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 functions should not, because
libFLAC doesn't use them.

Two of them - win_get_console_width() and strlen_utf8() - are used only
in src/flac/utils.c. So it makes sense to move these functions into
that file.

But what to do with print functions (printf_utf8, fprintf_utf8, and
vfprintf_utf8) ?

1) keep separate share/win_utf8_io library, with only these three functions in 
it
2) move them to share/grabbag/snprintf.c
3) create new share/grabbag/win_utf8_printf.c file and move them there
4) move them to share/utf8 library
5) something else?
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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

[lvqcl]

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

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

[lvqcl]

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_init_file() calls init_file_internal_()
that calls flac_fopen() that is defined as fopen_utf8().

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.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev