Help - Search - Members - Calendar
Full Version: A Lossless Comparison I Haven't Seen on HA...
Hydrogenaudio Forums > Lossless Audio Compression > Lossless / Other Codecs
dewey1973
Hey HA,

I was wondering what the lossless fans on HA thought of this comparison.

Ultimate Command Line Compressors

The experimental version of OptimFROG looks great. If compression is all that matters to you, OptimFROG seems like the best choice. Does anyone know when it is estimated to come out of experimental status?

I haven't heard much about MP4ALS but it seems pretty solid.

I can't believe how good OptimFROG looks. Significantly (in my mind) better than Monkey's and even beats La.

What do you all think?

rjamorim
I wish they included encode time. I'd guess that experimental mode takes ages to both encode and decode.
LANjackal
AFAIK, OptimFROG's almost always beaten almost everything else when it comes to compression. However, the price you pay in CPU time is huge.
Echizen
They didn't use the "-hh" switch vor wavpack.
*edit* wasn't present in version 4.31
dewey1973
QUOTE(rjamorim @ Feb 4 2007, 16:43) *

I wish they included encode time. I'd guess that experimental mode takes ages to both encode and decode.

I think this site's main concern is pure, unadulterated compression. Therefor, I'm not surprised they didn't list times. Since I'm only going to use the lossless files for archiving, encoding/decoding speed doesn't seem that important. I can just queue up the encoding tasks during the day and let them run at night.

Edit: Confirmed from the site:
QUOTE
This site reports the results of a wide variety of benchmarks to compare the latest state-of-the-art command line compressors with only one focus: ultimate size reduction.
Garf
QUOTE(dewey1973 @ Feb 7 2007, 20:38) *
QUOTE(rjamorim @ Feb 4 2007, 16:43) *

I wish they included encode time. I'd guess that experimental mode takes ages to both encode and decode.

I think this site's main concern is pure, unadulterated compression. Therefor, I'm not surprised they didn't list times. Since I'm only going to use the lossless files for archiving, encoding/decoding speed doesn't seem that important. I can just queue up the encoding tasks during the day and let them run at night.


But do you really want to wait as long for your files to decode again?
dewey1973
QUOTE(Garf @ Feb 7 2007, 11:41) *

But do you really want to wait as long for your files to decode again?


If I create lossy files for playback, I wouldn't anticipate having to decode the lossless files on a regular basis. I'd have to decode in order to replace a bad CD, transcode to the latest and greatest lossless codec, or switch lossy codecs. I don't see myself doing that very often. Am I missing something?
boombaard
QUOTE(dewey1973 @ Feb 7 2007, 21:55) *

QUOTE(Garf @ Feb 7 2007, 11:41) *

But do you really want to wait as long for your files to decode again?


If I create lossy files for playback, I wouldn't anticipate having to decode the lossless files on a regular basis. I'd have to decode in order to replace a bad CD, transcode to the latest and greatest lossless codec, or switch lossy codecs. I don't see myself doing that very often. Am I missing something?


not really, but if you were to suddenly lose your lossy collection and you'd have to encode everything again, i'm sure you'd get sick of a decoding speed of 2-3x realtime fairly quickly..
and backing up your lossy files as well would probably cost so much space it would be cheaper to just encode everything as MAC extra high (imo the best compromise between speed and compression ratios, but take it as an example in any case) in the first place..
still, whatever floats your boat wink.gif
LANjackal
QUOTE(boombaard @ Feb 7 2007, 16:45) *

QUOTE(dewey1973 @ Feb 7 2007, 21:55) *

If I create lossy files for playback, I wouldn't anticipate having to decode the lossless files on a regular basis. I'd have to decode in order to replace a bad CD, transcode to the latest and greatest lossless codec, or switch lossy codecs. I don't see myself doing that very often. Am I missing something?


not really, but if you were to suddenly lose your lossy collection and you'd have to encode everything again, i'm sure you'd get sick of a decoding speed of 2-3x realtime fairly quickly..
and backing up your lossy files as well would probably cost so much space it would be cheaper to just encode everything as MAC extra high (imo the best compromise between speed and compression ratios, but take it as an example in any case) in the first place..


My attitude is the same as dewey1973's but I use the same solution as boombard: MAC Extra High.
Josef Pohm
QUOTE(dewey1973 @ Feb 7 2007, 21:55) *

If I create lossy files for playback, I wouldn't anticipate having to decode the lossless files on a regular basis. I'd have to decode in order to replace a bad CD, transcode to the latest and greatest lossless codec, or switch lossy codecs. I don't see myself doing that very often. Am I missing something?


...hmmm... I don't really know. I am a great fan of OptimFrog myself, but:

- One day, I had to leave for a travel in four hours, so I decided to convert to MP3 a dozen of my favorite albums to have them with me in my DAP. The process couldn't finish in time. Twelve albums, four hours, 1.6ghz Tualatin CPU;
- Sometimes I like to run some other tasks while listening to some tunes on a Sempron 2600+. OFR BestNew eats so much of the CPU power (roughly 30%-50%, but please don't quote me on that) that there are times when I simply have to stop the music;
- One day I thought about scanning all of my music files to apply replaygain tags. A quick calculation made me realize that it would take more than two weeks. I decided I could not do that.
When this kind of issues is not a problem for you, OFR is a very good choice.

I also tried Monkey XH, which I agree would be the best compromise speed/ratio wise (encode/decode 25x on my Athlon64 3500+), but I personally experienced a few issues with it, so I, as one, decided to quit.

Finally, even if you're looking for higher compression ratios, Tak Extra could also be a good choice. Its compression ratio is in the range of OFR Normal and APE High and it offers decoding speed well over 120x on my Athlon64 3500+.
Lyx
Accepting something like 10x more cpuload just for 1% more compression is stupid. If you do that for dozens of albums then the increase in electricity-costs may be similiar to the price per mb which a bigger hdd would cost.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.