search for: base_2_part

...s), but > probably it will never be as fast as decoding of rice codes. Agreed, there's too much juggling going on to compete with rice codes, but maybe it can run at an acceptable speed with a bit of tuning... did you tell it to write the least significant bits separately (set the parameter base_2_part=true)? Also altering the algorithm so that low_bits is larger will produce a speedup (but impact the compression ratio). And there's a fair scope for optimization. Overall, the speed (after encoding the least significant bits and dividing them out) is going to be of the order of the sum of the...

...will never be as fast as decoding of rice codes. > > Agreed, there's too much juggling going on to compete with rice codes, but > maybe it can run at an acceptable speed with a bit of tuning... did you > tell it to write the least significant bits separately (set the parameter > base_2_part=true)? Also altering the algorithm so that low_bits is larger > will produce a speedup (but impact the compression ratio). And there's a > fair scope for optimization. Interesting is that for slightly larger low_bits is compression ratio sometimes better, at least in my case :). Maybe it...

Hello, I am the author of the Bonk audio compression program... i've just been looking at your comparrison table, and i noticed bonk gets marginally better compression than Flac on some files (actually i was rather surprised to see bonk on the list at all, it's not exactly high profile :-) ). Bonk in lossless mode is a pretty naive implementation of a predictive coder, so the main