rockbox/apps/codecs/libwavpack
Nils Wallménius c8535f27d1 Switch coldfire builds over to new toolchain using gcc 4.5.2 and binutils 2.20.1
Retune codec compiler optimizations with new compiler. Overall speedup with aac and flac getting big speedups.


git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29042 a1c6a512-1295-4272-9138-f99709370657
2011-01-12 22:28:43 +00:00
..
arm.S FS#11335 by me: make ARM assembly functions thumb-friendly 2010-06-11 04:41:36 +00:00
arml.S FS#11335 by me: make ARM assembly functions thumb-friendly 2010-06-11 04:41:36 +00:00
bits.c
coldfire.S
float.c
libwavpack.make Switch coldfire builds over to new toolchain using gcc 4.5.2 and binutils 2.20.1 2011-01-12 22:28:43 +00:00
LICENSE
make.bat
metadata.c make WavPack library check the extent of the block that it is parsing so that it cannot run into the next block; also enhance the metadata code to handle the case of files with non-audio blocks at the beginning (which can happen if the source WAV file has lots of RIFF data) 2010-12-05 19:25:32 +00:00
pack.c Remove all tabs within codec path. 2010-02-22 19:44:05 +00:00
README
README.rockbox
SOURCES
unpack.c
wavpack.h make WavPack library check the extent of the block that it is parsing so that it cannot run into the next block; also enhance the metadata code to handle the case of files with non-audio blocks at the beginning (which can happen if the source WAV file has lots of RIFF data) 2010-12-05 19:25:32 +00:00
words.c libwavpack: put some lookup tables in iram, speedup of 8-10% on coldfire (h300). 2010-12-21 14:08:41 +00:00
wputils.c make WavPack library check the extent of the block that it is parsing so that it cannot run into the next block; also enhance the metadata code to handle the case of files with non-audio blocks at the beginning (which can happen if the source WAV file has lots of RIFF data) 2010-12-05 19:25:32 +00:00

////////////////////////////////////////////////////////////////////////////
//                           **** WAVPACK ****                            //
//                  Hybrid Lossless Wavefile Compressor                   //
//              Copyright (c) 1998 - 2004 Conifer Software.               //
//                          All Rights Reserved.                          //
//      Distributed under the BSD Software License (see license.txt)      //
////////////////////////////////////////////////////////////////////////////

This package contains a tiny version of the WavPack 4.0 decoder that might
be used in a "resource limited" CPU environment or form the basis for a
hardware decoding implementation. It is packaged with a demo command-line
program that accepts a WavPack audio file on stdin and outputs a RIFF wav
file to stdout. The program is standard C, and a win32 executable is
included which was compiled under MS Visual C++ 6.0 using this command:

cl /O1 /DWIN32 wvfilter.c wputils.c unpack.c float.c metadata.c words.c bits.c

WavPack data is read with a stream reading callback. No direct seeking is
provided for, but it is possible to start decoding anywhere in a WavPack
stream. In this case, WavPack will be able to provide the sample-accurate
position when it synchs with the data and begins decoding.

For demonstration purposes this uses a single static copy of the
WavpackContext structure, so obviously it cannot be used for more than one
file at a time. Also, this decoder will not handle "correction" files, plays
only the first two channels of multi-channel files, and is limited in
resolution in some large integer or floating point files (but always
provides at least 24 bits of resolution). It also will not accept WavPack
files from before version 4.0.

To make this code viable on the greatest number of hardware platforms, the
following are true:

   speed is about 4x realtime on an AMD K6 300 MHz
      ("high" mode 16/44 stereo; normal mode is about twice that fast)

   no floating-point math required; just 32b * 32b = 32b int multiply

   large data areas are static and less than 4K total
   executable code and tables are less than 32K
   no malloc / free usage

To maintain compatibility on various platforms, the following conventions
are used:

   a "short" must be 16-bits
   a "long" must be 32-bits
   an "int" must be at least 16-bits, but may be larger
   a "char" must default to signed


Questions or comments should be directed to david@wavpack.com