Skip to main content

Topic: Tiny encoder in lossy mode sounds differnent to wavpack (Read 3721 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • cram
  • [*]
Tiny encoder in lossy mode sounds differnent to wavpack
I have been running some tests on the performance of the wavpack algorithm for low bit rates and sample rates using the command line versions of the software.

e.g. wavpack -b24 file.wav file.wv

These have been performed at 16k sample rate and 11k sample rate as my application requires big reduction in the data file size. The command line algorithm states that 24 is the most compression available (although i have noticed that tiny encoder can go lower).

On the whole i have been pretty impressed with the lossy mode of the algorithm and found some suitable settings for my application.

My target hardware however requires fixed point maths so I have now implemented the tiny encoder 4.40 to perform the compression.

The issue that i have discovered is this version of the algorithm does not sound the same. There are additional distortion products when using the Tiny encoder which are not present on the command line version of wavpack.

I have tried using v4.40 of the command line version in case it was a version issue but this seems to perform as well as the latest wavpack version.

I have tried the command line version of Tiny encoder 4.40 and this does also have the distortion products which leads me to believe that they are specific to the implementation.

e.g. tinypack -b2.0 file.wav file.wv  (at 16kHz)

My concern is that the lack of resolution (or dynamic range) forced by a fixed point implementation has led to a compromise of the algorithm's performance.

1) has anyone else encountered this issue?
2) Is it just a known issue that the fixed point Tiny Encoder does not function as well as the floating point version?
3) Does anyone have any ideas in which areas the discrepancy in the algorithms performance could be occurring and if modification of the source code could improve the issues.

Any comments or suggestions would be much appreciated.

many thanks

  • shadowking
  • [*][*][*][*][*]
Tiny encoder in lossy mode sounds differnent to wavpack
Reply #1
For < 44.1 k you need to be more conservative. -b4 for 44.1k is much better than -b4 on 24k. You don't have the masking advantage of higher resolutions .
I have some artificial samples from the net with very low res: < 32k and i generally need -b 5 ~ 5.7 for full transparency. But you say the tiny version if different ... I am sure David can explain it much better than me or correct me on my theories.
  • Last Edit: 24 February, 2010, 05:32:54 AM by shadowking
wavpack 4.8 -b4x4s0.75c

  • cram
  • [*]
Tiny encoder in lossy mode sounds differnent to wavpack
Reply #2
Hi thanks for the reply

Unfortunately I can not be more conservative as my application requires a very low data rate.

The algorithm does work pretty well (not good enough for Hi-Fi but good enough for speech signals which is my application).

My issue is the degradation of the signal compared to the standard wavpack command line versions 4.40 or 4.60.1. If I can achieve the same audio files that these standard wavpack WIN32 command line can generates I will be happy and the algorithm will solve my requirements very well.


  • bryant
  • [*][*][*][*][*]
  • Developer (Donating)
Tiny encoder in lossy mode sounds differnent to wavpack
Reply #3
There is no difference between the tiny encoder and the regular encoder with respect to floating-point math; both use only integers except perhaps for very infrequent operations (like a few per block).

However, there are two differences that could affect quality. The first is the “extra” mode that can dramatically improve encoding quality in some circumstances. This is only available in the command-line version, but unless you had specifically enabled this with the “-x” option, you would not be getting it.

The other difference is in noise shaping. The tiny encoder has by default no noise shaping, so the quantization noise is always flat. In the command-line encoder the default is for dynamic noise shaping, which can improve encoding quality significantly. To disable noise shaping in the command-line version (to see if this is the difference) try adding the option “-s0”. Both versions can provide fixed noise shaping, so you might try “-s-0.5” in the tiny encoder and see if that improves things (the same option in the standard encoder should result in identical results between the two encoders). This fixed noise shaping moves the noise up or down in frequency, so you can tweak this value depending on whether the artifacts you are hearing are high or low in frequency.

If it turns out that dynamic noise shaping is the factor that is making a big difference for your application, we can discuss adding that to the tiny encoder. It does not require much extra CPU or code size, but it cannot work in the hybrid lossless mode (which I assume you are not using). Without actually looking into it, I think it would be fairly trivial to do (...famous last words).

Another thing to try is the “-h” switch (which also works identically in both encoders). This requires somewhat more CPU for both encoding and decoding, but will also improve quality.

Please let me know if there’s anything else I can do to help you with getting WavPack working for your application.


  • cram
  • [*]
Tiny encoder in lossy mode sounds differnent to wavpack
Reply #4
Hi David

Thank you for your quick reply.

I am keen to get the Tiny Encoder working for my application. Your email has eased my concerns about the fixed point implementation causing the difference.
From your suggestions it would appear that the first step is to isolate the cause of the sound difference.
I will start a piece of work to investigate the -x , -s and -h options and report back my findings hopefully in th next couple of weeks.