Hydrogenaudio Forums > Benchmark Site

JohanDeBock

Mar 23 2005, 13:04

Hello, I'm the author of a compression test site with only one goal: search for minimal size.
The lastest addition to the site is an audio compression test:

http://studwww.ugent.be/~jdebock/lossless_...ession_test.htm

My question is: are there any lossless audio compressors that are still missing on the list?

Thanks in advance!

rjamorim

Mar 23 2005, 13:09

QUOTE(JohanDeBock @ Mar 23 2005, 04:04 PM)

My question is: are there any lossless audio compressors that are still missing on the list?

http://www.rjamorim.com/rrw/

Also, I think it would be very welcome if you could provide links to places where people can obtain the codecs you are testing.

JohanDeBock

Mar 23 2005, 14:34

QUOTE(rjamorim @ Mar 23 2005, 09:09 PM)

QUOTE(JohanDeBock @ Mar 23 2005, 04:04 PM)

My question is: are there any lossless audio compressors that are still missing on the list?

http://www.rjamorim.com/rrw/

Also, I think it would be very welcome if you could provide links to places where people can obtain the codecs you are testing.

It's in my todo list

JohanDeBock

Jul 25 2005, 11:08

QUOTE(rjamorim @ Mar 23 2005, 09:09 PM)

QUOTE(JohanDeBock @ Mar 23 2005, 04:04 PM)

My question is: are there any lossless audio compressors that are still missing on the list?

http://www.rjamorim.com/rrw/

Also, I think it would be very welcome if you could provide links to places where people can obtain the codecs you are testing.

Done.
Added a list of all compressors used for my tests:
http://studwww.ugent.be/~jdebock/compressor_info.htm

Thanks for all the rare audio compressors!

Polar

Jul 25 2005, 16:08

QUOTE(JohanDeBock @ Mar 23 2005, 20:04 UTC)

Hello, I'm the author of a compression test site with only one goal: search for minimal size.
The lastest addition to the site is an audio compression test:

http://studwww.ugent.be/~jdebock/lossless_...ession_test.htm

Great overview, Johan.

Is there any particular reason why you haven't included FLAC's --super-secret-totally-impractical-compression-level in your test? In case you hadn't heard about FLAC's --super-secret-totally-impractical-compression-level before: no, I'm not kidding. Ssticl is actually mapped to --lax -P 4096 -b 4608 -m -l 32 -e -E -p -q 0 -r 0,16.

You can expect ssticl to compress at the very least about 20 times as slow as -8, for nominal compression gain. Hence its name. Quoting Omion:

QUOTE(Omion)

"ss" was by far the slowest in terms of both encoding and decoding. Encoding speed was not tested, but took around 5 hours per sample on my computer. Compression was marginally better than the presets. I must therefore agree that it is "totally impractical" and should remain "super secret" as its name suggests.

So even though --super-secret-totally-impractical-compression-level is just what it claims to be, I'd say it still deserves a spot in your comparative test, be it for "only one goal: search for minimal size".

JohanDeBock

Jul 26 2005, 03:10

QUOTE(Polar @ Jul 26 2005, 12:08 AM)

QUOTE(JohanDeBock @ Mar 23 2005, 20:04 UTC)

Hello, I'm the author of a compression test site with only one goal: search for minimal size.
The lastest addition to the site is an audio compression test:

http://studwww.ugent.be/~jdebock/lossless_...ession_test.htm

Great overview, Johan.

Is there any particular reason why you haven't included FLAC's --super-secret-totally-impractical-compression-level in your test? In case you hadn't heard about FLAC's --super-secret-totally-impractical-compression-level before: no, I'm not kidding. Ssticl is actually mapped to --lax -P 4096 -b 4608 -m -l 32 -e -E -p -q 0 -r 0,16.

You can expect ssticl to compress at the very least about 20 times as slow as -8, for nominal compression gain. Hence its name. Quoting Omion:

QUOTE(Omion)

"ss" was by far the slowest in terms of both encoding and decoding. Encoding speed was not tested, but took around 5 hours per sample on my computer. Compression was marginally better than the presets. I must therefore agree that it is "totally impractical" and should remain "super secret" as its name suggests.

So even though --super-secret-totally-impractical-compression-level is just what it claims to be, I'd say it still deserves a spot in your comparative test, be it for "only one goal: search for minimal size".

Didn't knew about this setting, will try it out, thanks for the info!

JohanDeBock

Jul 26 2005, 03:50

Just tested it is actually worse and slower

30.002.113 bytes -8--no-padding-b4096-l32-r16--lax
30.023.411 bytes --super-secret-totally-impractical-compression-level--no-padding
30.089.011 bytes --super-secret-totally-impractical-compression-level

Polar

Jul 26 2005, 05:09

QUOTE(JohanDeBock @ Jul 26 2005, 09:50 UTC)

Just tested it is actally worse and slower

30.002.113 bytes -8--no-padding-b4096-l32-r16--lax
30.023.411 bytes --super-secret-totally-impractical-compression-level--no-padding
30.089.011 bytes --super-secret-totally-impractical-compression-level

Which goes to show that the set of audio files you used is a bit too narrow-based for a benchmark test, I'm afraid.

Omion's comprehensive FLAC decoding speed test, which is the only publicly available test of ssticl I know of, showed a compression average of some 44.33% for ssticl, against about 44.37 % for level 8 encodings. That test was done on 14 and a half hours of CD audio, so no less than 8.5 GiB.

JohanDeBock

Jul 26 2005, 06:26

QUOTE(Polar @ Jul 26 2005, 01:09 PM)

Which goes to show that the set of audio files you used is a bit too narrow-based for a benchmark test, I'm afraid.

Omion's comprehensive FLAC decoding speed test, which is the only publicly available test of ssticl I know of, showed a compression average of some 44.33% for ssticl, against about 44.37 % for level 8 encodings. That test was done on 14 and a half hours of CD audio, so no less than 8.5 GiB.

Note that there is not much difference between:
-8 --no-padding -b4096 -l32 -r16 --lax
--super-secret-totally-impractical-compression-level --no-padding

Only the deprecated -E switch it seems, or is there also something the encoder doesn't display?

The reason the testset is rather small is because of the amount of programs I test and the extreme slowness of some of them.

JohanDeBock

Jul 26 2005, 06:33

Ah just noticed the blocksize is also different, will try with:
--super-secret-totally-impractical-compression-level --no-padding -b 4096

Still worse.

rutra80

Jul 26 2005, 07:56

Great site Johan