1. 17 Sep, 2014 1 commit
    • Erik de Castro Lopo's avatar
      Remove old/broken PPC/Altivec code. · b60f16bb
      Erik de Castro Lopo authored
      * Removes FLAC__lpc_restore_signal_asm_ppc_altivec_16*
        from lpc.h and stream_decoder.c
      * Removes PPC-specific code from cpu.c and cpu.h
      * Removes PPC stuff from libFLAC/Makefile.lite and build/*.mk
      * Removes as/gas/PPC-specific stuff from configure.ac and
      * Removes libFLAC/ppc folder and remove "src/libFLAC/ppc*/Makefile"
        lines from configure.ac
      Patch-from: lvqcl <lvqcl.mail@gmail.com>
  2. 09 Aug, 2014 5 commits
  3. 28 Jul, 2014 3 commits
    • Martijn van Beurden's avatar
      Fix bug when using -p switch during compression · 27846708
      Martijn van Beurden authored
      When using the -p switch during encoding, the encoder should try
      different qlp predictor precision steps. However, some faulty code
      was too severely restricting the possible steps. This patch lifts
      the restriction to match a restriction coded a little further in
      the process. This doesn't make using -p worth your while, but at
      least it doesn't create larger files now
      Signed-off-by: Erik de Castro Lopo's avatarErik de Castro Lopo <erikd@mega-nerd.com>
    • Erik de Castro Lopo's avatar
      libFLAC/cpu.c : Simplify OS SSE support detection. · 6a28facd
      Erik de Castro Lopo authored
      Simplify the code that tries to detect whether OS supports SSE instructions.
      a) Linux: "old" vs "new" sigaction
      OBSOLETE_SIGCONTEXT_FLAVOR was disabled in Mar 2007 in commit 1ca3a445.
      According to <http://unixhelp.ed.ac.uk/CGI/man-cgi?sigaction>: "Support for
      SA_SIGINFO was added in Linux 2.2" (released in Jan 1999). If noone wants to
      use FLAC with Linux kernel 2.0 then it's safe to delete this code.
      b) MSVC: try/catch vs. sigill_handler
      TRY_CATCH_FLAVOR was enabled in Jan 2009 in commit a832ef32. According to the
      comment in cpu.c, "sigill_handler flavor resulted in several crash reports on
      win32". Also this sigill_handler flavor is not thread-safe.
      c) MinGW: fxsave/fxrestore vs. sigill_handler
      The code was added Mar 2014 in commit 99d5154f. It's better to use FXSR flavor
      instead of sigill_handler flavor. The reasons are the same as for MSVC.
      Patch-from: lvqcl <lvqcl.mail@gmail.com>
    • Erik de Castro Lopo's avatar
      libFLAC : SSE optimisations. · 02591f6b
      Erik de Castro Lopo authored
      Add new function:
      and rewrite function:
      Testing shows noticeable speed increase on Intel Core i3/5/7 (up to 30%
      for -8 mode), AMD Athlon64, Phenom, Bulldozer/Piledriver, but no increase
      or even very small speed decrease (~2% for -8 mode) on Intel Core2.
      Patch-from: lvqcl <lvqcl.mail@gmail.com>
  4. 27 Jul, 2014 2 commits
  5. 19 Jul, 2014 2 commits
  6. 13 Jul, 2014 1 commit
  7. 09 Jul, 2014 1 commit
  8. 08 Jul, 2014 1 commit
  9. 06 Jul, 2014 3 commits
  10. 04 Jul, 2014 1 commit
    • Miroslav Lichvar's avatar
      stream_encoder : Improve selection of residual accumulator width · f081524c
      Miroslav Lichvar authored
      In the precompute_partition_info_sums_ function, instead of selecting
      64-bit accumulator when the signal bps is larger than 16, revert to the
      original approach based on partition size, but make room for few extra
      bits to not overflow with unusual signals where the average residual
      magnitude may be larger than bps.
      It slightly improves the performance with standard encoding levels and
      16-bit files as the 17-bit side channel can still be processed with the
      32-bit accumulator and correctly selects the 64-bit accumulator with
      very large 16-bit partitions.
      This is related to commits 6f7ec60c and 187e596e
      Signed-off-by: Erik de Castro Lopo's avatarErik de Castro Lopo <erikd@mega-nerd.com>
  11. 03 Jul, 2014 4 commits
  12. 02 Jul, 2014 3 commits
  13. 01 Jul, 2014 2 commits
    • Erik de Castro Lopo's avatar
      test_libFLAC/md5.c : Fix the tests. · 74d81333
      Erik de Castro Lopo authored
      The previous version of this test worked on amd64 and powerpc64 but
      failed on armhf. Investigation show that the previous version of the
      test data was generated for a case where the ARRAY_LEN macro was
      exploiting undefined behaviour.
      Fix was ditching the ARRAY_LEN macro and then recalculating the
      target data.
    • Erik de Castro Lopo's avatar
      test_libFLAC/endswap.c : Improvements. · c69a2094
      Erik de Castro Lopo authored
      * Print endian-ness of test host.
      * Replace ugly macro with C code.
      * Add tests for H2LE_16 and H2LE_32 macros.
  14. 30 Jun, 2014 2 commits
  15. 29 Jun, 2014 3 commits
  16. 28 Jun, 2014 6 commits
    • Erik de Castro Lopo's avatar
      libFLAC/bitmath : Restore an ASSERT that was removed some time after 1.2.1. · a8567d4b
      Erik de Castro Lopo authored
      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>
    • Erik de Castro Lopo's avatar
      libFLAC/lpc_intrin_sseN.c : Disambiguate macro names. · 9aa15464
      Erik de Castro Lopo authored
      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>
    • Erik de Castro Lopo's avatar
      libFLAC: CPUID detecion improvements. · 2c150525
      Erik de Castro Lopo authored
      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>
    • Erik de Castro Lopo's avatar
      flac: Fix channel order for mono files. · 99257e17
      Erik de Castro Lopo authored
      * 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
      Patch-from: lvqcl <lvqcl.mail@gmail.com>
    • Erik de Castro Lopo's avatar
      flac: Fix encoder and decode progress messages with --ogg. · 1d12d98e
      Erik de Castro Lopo authored
      Problem discussed here:
      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>
    • Erik de Castro Lopo's avatar
      flac : Fix handling of raw input option. · a5c3a37c
      Erik de Castro Lopo authored
      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>