Para asegurar una operación de alta velocidad, WavPack utiliza un predictor que se implementa completamente en matemáticas enteras. En su modo "rápido" la predicción es simplemente la extrapolación aritmética de las dos muestras anteriores. Por ejemplo, si las dos muestras anteriores eran -10 y 20, entonces la predicción sería 50. Para el modo por defecto se añade un factor adaptativo simple para sopesar la influencia de la muestra anterior en la predicción. En nuestro ejemplo, la predicción resultante podría variar entre 20 para ninguna influencia y 50 para la influencia total. Este factor de ponderación se actualiza constantemente en función de las características espectrales cambiantes de los datos de audio.
La predicción generada se resta entonces de la muestra real a ser codificada para generar el valor de error. En el modo mono este valor se envía directamente al codificador. Sin embargo, las señales estéreo tienden a tener alguna correlación entre los dos canales que puede ser explotada aún más. Por lo tanto, se calculan dos valores de error que representan la diferencia y el promedio de los valores de error izquierdo y derecho. En el modo de operación "rápido", estos dos nuevos valores se envían simplemente al codificador en lugar de los valores izquierdo y derecho. En el modo por defecto, el valor de diferencia siempre se envía al codificador junto con uno de los otros tres valores (promedio, izquierdo o derecho). Un algoritmo adaptativo determina continuamente el más eficiente de los tres para enviar basado en el balance cambiante de los canales.
En lugar de la codificación Rice, se utiliza un codificador de datos especial para WavPack. La codificación Rice es la codificación de bits óptima para este tipo de datos, y el codificador de WavPack es menos eficiente, pero solo en unos 0,15 bits por muestra (o menos del 1% para datos de 16 bits). Sin embargo, hay algunas ventajas a cambio; la primera es que el codificador de WavPack no requiere que los datos sean almacenados en un búfer antes de la codificación, sino que convierte cada muestra directamente a códigos de bits. Esto es más eficiente computacionalmente, y es mejor en algunas aplicaciones donde el retardo de codificación es crítico. La segunda ventaja es que es fácilmente adaptable a la codificación con pérdidas, ya que todos los bits significativos (excepto el "uno" MSB implícito) se transmiten directamente. De esta manera solo es posible transmitir, por ejemplo, los 3 bits más significativos (con signo) de cada muestra. De hecho, es posible transmitir solo el signo y el MSB implícito para cada muestra con un promedio de solo 3,65 bits/muestra.
Este esquema de codificación se utiliza para implementar el modo "con pérdidas" de WavPack. En el modo "rápido", la salida del decorrelator no adaptable se redondea simplemente al valor codificable más cercano para el número de bits especificado. En el modo por defecto se utiliza el decorrelador adaptativo (que reduce el ruido medio en torno a 1 dB) y tanto la muestra actual como la siguiente se tienen en cuenta a la hora de elegir el mejor de los dos códigos disponibles (que reduce el ruido otro 1 dB).
No se utiliza aritmética de coma flotante en la ruta de datos de WavPack porque, según el autor, las operaciones de números enteros son menos susceptibles a variaciones sutiles de chip a chip que podrían corromper la naturaleza sin pérdidas de la compresión (el error de coma flotante Pentium es un ejemplo). Es posible que un compresor sin pérdidas que usara matemática en coma flotante pudiera generar una salida diferente cuando se ejecuta en ese Pentium defectuoso. Incluso sin tener en cuenta los errores reales, las matemáticas en coma flotante son lo suficientemente complicadas como para que pueda haber diferencias sutiles entre las implementaciones "correctas" que podrían causar problemas para este tipo de aplicación. Se incluye un código de detección de errores de 32 bits en los flujos generados para mantener la confianza del usuario en la integridad de la compresión de WavPack.
El código fuente de WavPack es portable, y ha sido compilado en varios sistemas operativos Unix y similares a Unix (Linux, Mac OS X, Solaris, FreeBSD, OpenBSD, NetBSD, Compaq Tru64, HP-UX...) así como en Windows, DOS, Palm OS y OpenVMS. Funciona en muchas arquitecturas, incluyendo x86, ARM, PowerPC, AMD64, IA-64, SPARC, Alpha, PA-RISC, MIPS y Motorola 68k.
Se desarrolló una versión reducida de WavPack para el procesador de señal digital de la serie TMS320 de Texas Instruments. El objetivo principal era animar a los fabricantes a incorporar la compresión (y descompresión) WavPack en los grabadores de audio con memoria portátil. Esta versión soportaba características que solo eran aplicables a aplicaciones embebidas (compresión de flujo en tiempo real, tasa de compresión seleccionable) y descartaba características que solo se aplicaban a sistemas informáticos completos (autoextracción, modos de alta compresión, flotadores de 32 bits). Los DSPs de la serie TMS320 son dispositivos enteros nativos y son compatibles con WavPack. Se incluyeron algunas características "especiales" del software WavPack completo (capacidad de generar un "archivo" de corrección (stream), por ejemplo) y se excluyeron otras. Esta bifurcación se basaba en la versión 4.
Se agregó soporte para WavPack a WinZip a partir de la versión 11.0 beta, lanzada en octubre de 2006. Esta extensión al formato de archivo ZIP fue incluida por PKWARE, los mantenedores del formato, en el archivo de descripción oficial de APPNOTE.TXT a partir de la versión 6.3.2, publicada el 2 de febrero de 2009.