This refactoring is in preparation for fixing the cast-align warning when
compiling on ARM (and possibly others). Testing on stereo 16 bit files
suggests that the difference between the performance of this code and the
old code is negligible (tested only on amd64/linux).
Restore a FLAC__ASSERT() to bitmath functions FLAC__bitmath_ilog2 and
FLAC__bitmath_ilog2_wide functions. This prevents the return of an
"undefined" value.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
Previously, the files lpc_intrin_sse2.c and lpc_intrin_sse41.c both defined
macros RESIDUAL_RESULT and DATA_RESULT. This situation made it impossible
to merge these files which we may do at some stage.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
According to docs, it's incorrect to just call CPUID with EAX=1.
One must to ensure that this value is supported.
CPUs that don't support CPUID level 1 are very old, but...
if FLAC tests CPUID presence it should also test CPUID level support.
Also the function FLAC__cpu_have_cpuid_asm_ia32 was simplified
according to the docs at Intel website and in Wikipedia.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
* The default channel mask for mono files was 0x0001 (front left) but it
makes more sense to use 0x0004 (front center) for such files.
* Also FLAC will accept not only mono WAV files with 0x0001 mask, but also
with 0x0002 (requested at https://sourceforge.net/p/flac/bugs/390/)
and 0x0004 (e.g. SoX creates mono files with this mask).
* The comment about channel support was updated.
* The error message
"Use --channel-map=none option to store channels in current order; FLAC files
must also be decoded with --channel-map=none to restore correct order."
is misleading: FLAC never changes the order of channels.
Decoding with this options also sets the channel mask of the resulting WAV
file to 0. Without this option the mask is equal to the value of
WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
Problem discussed here:
http://lists.xiph.org/pipermail/flac-dev/2014-June/004808.html
The values for the interval between two updates (e->stats_mask,
e->stats_frames_interval) were set ~10 years ago, and it is small
for current CPUs. It was now been increased too (0x3f -> 0xff, etc).
The update interval is still less than 1 second.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
FLAC was silently ignoring options for raw input for encoding mode (but
prints an error and aborts when _de_coding).
This can lead to bug reports such as https://sourceforge.net/p/flac/bugs/389/
FLAC now prints a message about options misuse for encoding mode.
Help messages were also updated.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
* Fix leaks in read_metadata_() that could occur because of read errors or
malformed streams.
http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/libFLAC/
stream_decoder.c?
r1=1.147&r2=1.147.2.1&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH
* Fix metadata block initialization bug in read_metadata_().
http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/libFLAC/
stream_decoder.c?
r1=1.147.2.1&r2=1.147.2.2&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH
Patch-from: lvqcl <lvqcl.mail@gmail.com>
* Replace _declspec with __declspec.
* Replace __wgetmainargs_ with __wgetmainargs_t and __wgetmainargs
with wgetmainargs because identifiers with leading underscores are
reserved for the compiler.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
The old code was creating an array of FLAC__int8, and then casting
that to a set of signed and unsigned 16 and 32 bit integers. This
was replaced with a single union containing all the requred array.
This solution means that there are fewer pointer casts and actually
gives the compiler more information with which to generate fast code.
Old code was for the Intel compiler, had no appreciable performance benefits
and doesn't actually work with current version of that compiler.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
When decoding, read the contents of the WAVEFORMATEXTENSIBLE_CHANNEL_MASK
tag and write write the channel mask to the WAV file.
Patch-from: lvqcl <lvqcl.mail@gmail.com>
