HydrogenAudio

Hello,

I have great news for OptimFROG users: OptimFROG pr4.510,
and the Win32+Linux library pr1.200 are ready and can be
downloaded (on the Download page) from the OptimFROG site
(which is lately http://www.LosslessAudio.org (http://www.LosslessAudio.org)).

Please let me know if you find any problems so I can make
this a release version

What is new in this version:
  - encoding is now 6% faster with exactly the same
    compression
  - all the source code was reorganized and rewritten
    to use uniform standards and increase portability
  - OFR, OFS, OFF and the DLL/SO library were merged
    into a single, common code base
  - significantly reduced system dependent code areas
  - all programs are now Valgrind clean
  - fixed small problems (like not setting the file
    date for the correction file)

  - the OptimFROG library is now available for Linux
    as a SO library
  - the OptimFROG.dll version 1.200 is binary
    compatible with the previous versions
  - added new function OptimFROG_freeTags to release
    the memory allocated for the tags structure
  - new C++ wrapper interface for the OptimFROG
    library requiring less work for writing plug-ins
  - two C usage examples and two C++ usage examples
    of the library for Windows/Linux

  - complete source code for dBpowerAMP, Winamp 5,
    foobar2000, and XMMS plug-ins

  - site address has changed to (the other are still
    usable) http://www.LosslessAudio.org (http://www.LosslessAudio.org)

What to expect next:
  - development of OptimFROG will greatly accelerate
  - next major version will most probably include:
    improved compression, creation of self extracting
    archives, ID3v2 tags, Darwin/MacOS port, recovery
    information, gapless joining of multiple OptimFROG
    files, recovery of data from severely broken files

What is needed (what you can contribute):
  - it would be great to have extended support (more
    plug-ins for other players, sound editing tools)


If you have any questions, comments, suggestions or problems
regarding OptimFROG please don't hesitate to contact me at:

  FlorinGhido@yahoo.com

You can always find the newest version of OptimFROG at:

  http://www.LosslessAudio.org (http://www.LosslessAudio.org)

P.S. I would liked to put this in validated news, but I didn't
have enough rights

Thank you,
Florin Ghido

Excellent and good to hear from you again!

OFR, OFS, OFF

a lil text about what each exe is supposed to do would be very nice (i just wanna use the lossless option for example),

thanks for the new release.

 Wonderfull, thank you and keep up the great work Florin!

@smok3: OFR = lossless encoder, OFS = DualStream encoder, OFF = IEEE Float Audio encoder, they're described in the Doc folder of the archive.

Would be great if http://www.rockbox.org/ (http://www.rockbox.org/) supported this format

Would be great if http://www.rockbox.org/ (http://www.rockbox.org/) supported this format [a href="index.php?act=findpost&pid=314722"][{POST_SNAPBACK}][/a]

No chance without sources.

And even with sources chances would be smaller than 0. Or anyone here expects OptimFrog to decode at real time with 140mHz?

And even with sources chances would be smaller than 0. Or anyone here expects OptimFrog to decode at real time with 140mHz?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=314723")

According to [a href="http://web.inter.nl.net/users/hvdh/lossless/All.htm]Hans comparison[/url], in Fast mode with 900MHz it decodes at about 15x, so proportionally you need about 60MHz to decode at realtime. If you additionally take into account that with proper settings you can make decoding even faster, and that CPU in portable may be in decoding more efficient per MHz than AMD or Intel CPU, then the chances grow up to more than 0 [:

Hans comparison, in Fast mode with 900MHz it decodes at about 15x, so proportionally you need about 60MHz to decode at realtime. If you additionally take into account that with proper settings you can make decoding even faster, and that CPU in portable may be in decoding more efficient per MHz than AMD or Intel CPU, then the chances grow up to more than 0 [:[a href="index.php?act=findpost&pid=314734"][{POST_SNAPBACK}][/a]

Actually, in that case, AMD or Intel will be more efficient than the ColdFire. AFAIK, OptimFrog uses x86 ASM intensively to reach good speed on the x86 platform. The ColdFire CPU being used in the iRiver is not based on x86, but M68k instead.

Also, proportionality doesn't work that way when you compare different architectures.

For instance, look at FLAC in Heijden's comparison. It decodes 50x faster than real time. But it won't decode at 18mHz on the iRiver, no matter how much people would like it to happen.

Last but not least, this whole discussion is a moot point unless Ghido opens his sources. The RockBox is GPLd.

AFAIK, OptimFrog uses x86 ASM intensively to reach good speed on the x86 platform. The ColdFire CPU being used in the iRiver is not based on x86, but M68k instead.

M68k architecture is (or rather was) generally more efficient than x86 one. And to have it working on ColdFire you would need to port it anyway, so it would be a question of proper porting to have it more or at least as efficient.

this whole discussion is a moot point unless Ghido opens his sources.
[a href="index.php?act=findpost&pid=314739"][{POST_SNAPBACK}][/a]

True. Though from my personal POV (I'm not using portables) I prefer it to be closed-source than to watch zillions of potential forks (especially that Florin is doing a good job at maintaining and adding all the stuff).

True. Though from my personal POV (I'm not using portables) I prefer it to be closed-source than to watch zillions of potential forks.[a href="index.php?act=findpost&pid=314745"][{POST_SNAPBACK}][/a]

That is bullshit. FLAC, WavPack and Monkey's are open source, and you don't see forks.

Vorbis is open source, there are forks, and these forks are all for the best.

That argument reminds me of the old argument used by Musepack fanatics. "Since sources are not open, nobody can take them and f*** them up, creating bad quality files". What problem would be if people messed the sources, if we still have a trusted place to get good binaries?

M68k architecture is (or rather was) generally more efficient than x86 one.

As I pointed out already, you're basing your conclusions on a proportionality that doesn't necessarily exist. You can't safely extrapolate results in Heijden's test to other clock speeds, let alone other architectures!

Quote

True. Though from my personal POV (I'm not using portables) I prefer it to be closed-source than to watch zillions of potential forks.[a href="index.php?act=findpost&pid=314745"][{POST_SNAPBACK}][/a]

That is bullshit.

Oh come on, every sane person knows that open-source has both good & bad sides, for developers as well as for users. Foobar2000 isn't kept closed without a reason, even if Linux or MAC users would want to have it too.

As I pointed out already, you're basing your conclusions on a proportionality that doesn't necessarily exist. You can't safely extrapolate results in Heijden's test to other clock speeds, let alone other architectures!
[a href="index.php?act=findpost&pid=314747"][{POST_SNAPBACK}][/a]

You can't either. It was you who stated that it's impossible to decode OptimFROG at 140MHz in realtime. My statement that it could be decoded at even slower speeds is as right/wrong as yours.

Anyway, I find both things rather senseless to discuss here further.

I have great news for OptimFROG users: OptimFROG pr4.510,
and the Win32+Linux library pr1.200 are ready and can be
downloaded (on the Download page) from the OptimFROG site
(which is lately http://www.LosslessAudio.org (http://www.LosslessAudio.org)).[a href="index.php?act=findpost&pid=314574"][{POST_SNAPBACK}][/a]

It's great to see one of the top lossless compressors actively being developed. With the continuous work being done on the portable aimed FLAC, WavPack, etc., I was afraid La, Monkey's and OptimFROG would start lagging. Glad to see that doesn't go for the latter at least.

What is new in this version:
  - encoding is now 6% faster with exactly the same compression[a href="index.php?act=findpost&pid=314574"][{POST_SNAPBACK}][/a]

Great work, because you know even better than anyone else that speed was and is OF's major disadvantage.

What to expect next:
  - development of OptimFROG will greatly accelerate
  - next major version will most probably include: improved compression, ...[a href="index.php?act=findpost&pid=314574"][{POST_SNAPBACK}][/a]

Really looking forward to the day when OptimFROG actually outperforms La on both ratio and speed.

Congratulations on the new version and keep those updates coming

Oh come on, every sane person knows that open-source has both good & bad sides, for developers as well as for users. Foobar2000 isn't kept closed without a reason, even if Linux or MAC users would want to have it too.

The fact is, what would be the point of forking OptimFrog? Creating a version that compresses better? In that case, all the better! Let it come.

Anyway, I find both things rather senseless to discuss here further.[a href="index.php?act=findpost&pid=314752"][{POST_SNAPBACK}][/a]

Tough.

M68k architecture is (or rather was) generally more efficient than x86 one.
[a href="index.php?act=findpost&pid=314745"][{POST_SNAPBACK}][/a]

Except for floating point 

Really looking forward to the day when OptimFROG actually outperforms La on both ratio and speed.
[a href="index.php?act=findpost&pid=314754"][{POST_SNAPBACK}][/a]

Well, OptimFrog seriously outperforms LA on speed, and LA does not give that much better ratio. When you add the facts that LA are buggy, featureless and seemingly unmantained, OptimFrog won't be hard to choose for those situations when your looking for that maximum compression....

Tried the foobar and Winamp plugins. The foobar one seems to work well, but the Winamp one crashes both Winamp5 and 1by1. But as files that are compressed with the new encoder plays back well with the 1.07 Winamp2 plugin who works flawlessly with both players, it's not really a problem for me....

I'm on XPsp2. If you need specific info, please tell...

Tried the foobar and Winamp plugins. The foobar one seems to work well, but the Winamp one crashes both Winamp5 and 1by1. But as files that are compressed with the new encoder plays back well with the 1.07 Winamp2 plugin who works flawlessly with both players, it's not really a problem for me....
I'm on XPsp2. If you need specific info, please tell...

For Winamp 5, the OptimFROG.dll can be used from the following locations, in this order (the base paths can be different; I am running under Win2000):
(a) d:\Program Files\Winamp\
(b) d:\WINNT\system32\

The first is the directory where the winamp.exe is located, the other is a system-wide DLL search location. I tried playing .ofr and .ofs files after copying the DLL in (a) or (b) and it works ok.
I used the in_ofr.dll and OptimFROG.dll from OptimFROG_SDK_All_pr1200.zip.
When you try to use OptimFROG.dll version 1.100 (previous version), here on Win2000, the plug-in fails to run (it's not loaded at all) because the procedure entry point OptimFROG_freeTags is not present, but it does not crash though.

You can use OptimFROG_SDK\Test_SimpleC\OFROGDecSim.exe with the old OptimFROG.dll, version 1.100, from the OptimFROG_SDK_Win32_1100.zip, to see if it crashes; it should just display a startup error message.

You can also try deleting OptimFROG.dll from the (a) and (b) locations and copy again the new one, but this would not explain why it worked that way... Could you tell me a little more about how exactly Winamp crashes?

Thanks,
Florin Ghido

Well, OptimFrog seriously outperforms LA on speed, and LA does not give that much better ratio.[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=315045")

Wonder what gives you that idea. Take a look at the much quoted performance data by [a href="http://web.inter.nl.net/users/hvdh/lossless/lossless.htm]HansHeijden[/url], Speek (http://members.home.nl/w.speek/comparison.htm) and Guruboolez (http://www.foobar2000.net/lossless).
For a given compresion ratio, OptimFrog is twice as slow as La, both at encoding and at decoding (and even slower compared to Monkey's Audio, for that matter). La is only equalled in ratio by OptimFrog's very highest (and slowest) extranew/bestnew setting, and then still, only in Guruboolez' tests.

Quote

Well, OptimFrog seriously outperforms LA on speed, and LA does not give that much better ratio.[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=315045")

Wonder what gives you that idea. Take a look at the much quoted performance data by [a href="http://web.inter.nl.net/users/hvdh/lossless/lossless.htm]HansHeijden[/url], Speek (http://members.home.nl/w.speek/comparison.htm) and Guruboolez (http://www.foobar2000.net/lossless).
For a given compresion ratio, OptimFrog is twice as slow as La, both at encoding and at decoding (and even slower compared to Monkey's Audio, for that matter). La is only equalled in ratio by OptimFrog's very highest (and slowest) extranew/bestnew setting, and then still, only in Guruboolez' tests.
[a href="index.php?act=findpost&pid=315277"][{POST_SNAPBACK}][/a]

This is slightly misleading. All the above sites use for comparison Duron processors at 800/900 MHz, which don't have SSE. LA and Monkey's Audio use MMX for their computations, and without MMX they would be 3 times slower than now. On the other hand, OptimFROG uses SSE (which is present starting with Athlon XP and P3), when available, to speed up its computations. So, it is unfair to just say that OptimFROG it's twice slower than LA. None of the comparison sites assert the relations between OptimFROG's highnew, extranew, bestnew and LA's normal and high; they have only some combinations, which do not make clear the relation between compression ratios. Also, the test databases are somehow little, and not comprising all genres.

Another fact is that if you go to 24 bit, LA does not work at all, and MAC has low performance (its predictors are degenerated), due to them being tied to the MMX technology. OptimFROG fully supports it, at unchanged speeds (compared to 16 bit).

Here are, in my opinion, more accurate results, based on the corpus of 1047 files, having a total of 46992643860 bytes (46.993 GB), containing all genres, CD audio data, which I use for regressions and benchmarks.

52.70% OptimFROG bestnew 4.510

53.52% La high 0.4b
53.65% OptimFROG extranew 4.510

53.75% La normal 0.4b
53.78% OptimFROG highnew 4.510

As a conclusion: in my opinion, you can practically consider equivalent La high and OptimFROG extranew, and respectively, La normal and OptimFROG highnew. Also, OptimFROG bestnew is better here than La high by 0.82%.

About the time, here are some results on my Amd Athlon XP 1800+ for decoding speeds (the most important):

1.90x OptimFROG bestnew 4.510 [encoding 1.17x]

3.59x La high 0.4b [encoding 3.04x]
3.35x OptimFROG extranew 4.510 [encoding 2.09x]

5.06x La normal 0.4b [encoding 4.02x]
4.01x OptimFROG highnew 4.510 [encoding 2.67x]

My point is that OptimFROG will never fail badly. Every time, you can be sure that it is at least close the best value. I have samples recorded from the radio, on which LA (and Monkey's Audio, on which is based) are not able to track the complex stereo dependencies, and fail with 10-15% worse compression than OptimFROG.

OptimFROG is the result of many years of personal research, and is oriented towards the best compression possible. It has modes which work much slower than that of other compressors, but this do not imply it is a slow compressor. Its normal mode, is even a little faster at decoding than Monkey's Audio extra high mode, with comparable results (they are generally within 0.3%), only LA being significantly better.
So, it is not fair, in my opinion to say that OptimFROG is slow, only because it ALSO has modes which are slower.

As a note, I would like to mention that Monkey's Audio good performance (and implicitly LA) has at its roots the OptimFROG optimal stereo predictor concepts, somewhere in the beginning of 2002, when I explained them to Matthew. MAC uses a very simplified model of the optimal stereo predictor, but nevertheless, the compression increase was substantial (between versions 3.94 and 3.95).

Thank you,
Florin Ghido

That's most interesting to read, Florin. Thanks for that, and for OptimFROG.

In fact, as I mentioned before, it's a relief to finally see some movement at the upper end of the compression scale, now that La and Monkey's seem to be resting on their laurels.  Apple Lossless, FLAC or WavPack may be the codec of choice for playback and everyday use, but for long-time archival I prefer the sheer compression power of La or OptimFrog.

So keep it up and good luck!

hi,

i tested optimfrog and noticed something that i already saw with wavpack and which is different from flac for example.

i'm talking about the storage of the raw audio's checksum. after a quick test - corrupting an .ofr file - i realised that this checksum is not the main authority for error detection. i assume this is also the reason that it's not stored by default and has to be enabled by a command line switch? is there a reason to _not_ store it by default?

flac seems to treat the md5 checksum as an integral attribute of the encoded audio data, i.e. it's in the mandatory STREAMINFO tag and you cannot _not_ store it.

thanks

hi,

i tested optimfrog and noticed something that i already saw with wavpack and which is different from flac for example.

i'm talking about the storage of the raw audio's checksum. after a quick test - corrupting an .ofr file - i realised that this checksum is not the main authority for error detection. i assume this is also the reason that it's not stored by default and has to be enabled by a command line switch? is there a reason to _not_ store it by default?

flac seems to treat the md5 checksum as an integral attribute of the encoded audio data, i.e. it's in the mandatory STREAMINFO tag and you cannot _not_ store it.

thanks
[a href="index.php?act=findpost&pid=315543"][{POST_SNAPBACK}][/a]

I can't speak for Florin, but the reason that WavPack does not store the MD5 by default is simply to save the time of computing it (which gets to be significant, especially in the fast mode). WavPack (and OptimFROG) use a different error detection scheme internally on every block (which is required to silence errors during playback), so there's no need to do an MD5 sum by default to be robust.

In addition, with WavPack lossy (and maybe OptimFROG dualstream) the sum stored is computed on the original data, so it would not be useful for detecting errors at all in those modes.

I assume that FLAC has another error detection method for each block also, but since FLAC has no lossy mode it's not unreasonable for it to use a global MD5 for the whole file as an additional verification.

So, it is not fair, in my opinion to say that OptimFROG is slow, only because it ALSO has modes which are slower.

OptimFrog might not be slow per se (I'd concur it is), but when you compare with other formats like WavPack and FLAC, that encode several times faster, the comparision turns out to be obvious: OFR is a slow encoder. That's not a problem. It's like comparing ZIP and PAQar. ZIP is for acceptable compression and practicity. PAQar is for extreme compression at the cost of interoperability and, of course, time.

The slowness of OFR turns out to be more obvious when you compare it against Monkey's. Using Heijden's comparison (my favourite non-biased lossless comparison), you see that Monkey's in "normal" compress more and faster than OptimFrog's "fast". Same applies to APE's "extra high" versus OFR's "normal", "high" and maybe even "extra".

That's why my lossless comparison (http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison) places OFR as "slow" next to LA.

I can't speak for Florin, but the reason that WavPack does not store the MD5 by default is simply to save the time of computing it (which gets to be significant, especially in the fast mode).

i can't quite follow. md5 computation should be dirt cheap. openssl speed md5 on the duron 1600 in my server box claims to do just over 270MB/s. my p4 2600 with hyperthreading does over 500MB/s. the numbers are for block sizes of 8K.

am i missing something?

edit:

ofr --encode: 19.54s user 0.94s system 97% cpu 21.082 total
ofr --encode --md5: 20.02s user 0.96s system 97% cpu 21.574 total

edit2:

about the lossy modes, that's obviously correct. i implied lossless-only. and yes, flac doesn't need the md5 to detect errors mid-stream also.

i can't quite follow. md5 computation should be dirt cheap. openssl speed md5 on the duron 1600 in my server box claims to do just over 270MB/s. my p4 2600 with hyperthreading does over 500MB/s. the numbers are for block sizes of 8K.

am i missing something?
[a href="index.php?act=findpost&pid=315556"][{POST_SNAPBACK}][/a]

Well, I guess you're missing that WavPack fast mode is dirt cheap also. 

I just measured 8% slower doing the MD5 in that mode, which is enough of a hit that I don't think everyone should pay. I guess I could have an option to turn off an option that most people don't use, but that seems backwards to me.

First, there is a new release of the SDK, updating only the binary libraries (DLL/SO/lib, no need to recompile anything) which fixes the problem presented by Mr_Rabid_Teddybear. He was kind to send me a DrWatson dump, which was very helpful, and I want to thank him for his support.
The problem was with deallocation of tags in some situations, causing a crash on Windows when OptimFROG_freeTags is called.

bryant: I'm glad to hear from you...

TCM: As bryant said, I consider that not everyone uses the MD5 value. As you just tested, there is a slight increase in time, by the use of MD5 computation (in your test, 21.574/21.082 -> 2.33% increase, greater for faster modes, smaller for slower modes).
OptimFROG has CRC32 checksums for every block of several seconds, and they are used to check for *compressed block corruption* starting with the writing to disk (which can be faulty in very rare situations). The MD5 can be used to fingerprint the audio data without decompressing it, and for ensuring it decodes correctly.
For checking against compressed block corruption, you can use --verify which is light fast. For checking against correct decoding, you can use --check which decodes the file in memory, does the MD5 and then, if there is a MD5 stored, it compares with it.

rjamorim: I agree with you that compared with WavPack and FLAC, OptimFROG is slower, as they are targeted towards different goals.
Indeed, OptimFROG normal compresses slower than MAC extra high, but decodes a little faster. In my tests, and also in my opinion, I think of those modes as being somehow equivalent, being generally within 0.3% for mixed genres.
To compare them, OFR normal is better at noisier genres, and MAC extra high is better at tonal genres. The explanation (from inside) is that OFR normal uses a small predictor order with optimal adaptation, and MAC uses a very large predictor order with suboptimal adaptation (as it uses the well known Sign Sign LMS algorithm with some scaling in the regressor).
About your lossless comparison pages, they are indeed an awesome resource...  [BTW, I agree perfectly with "quite slow" put there for OFR ]

Thank you,
Florin Ghido

About your lossless comparison pages, they are indeed an awesome resource...   [BTW, I agree perfectly with "quite slow" put there for OFR ][a href="index.php?act=findpost&pid=315637"][{POST_SNAPBACK}][/a]

Thank you. I'm very glad it meets developers' approval

So, do you plan to add multichannel support to OFR soon? I think it's the most annoying limitation pointed out in the table (other than closed-sourceness, but let's not get into that debate...  )

To compare them, OFR normal is better at noisier genres, and MAC extra high is better at tonal genres. The explanation (from inside) is that OFR normal uses a small predictor order with optimal adaptation, and MAC uses a very large predictor order with suboptimal adaptation (as it uses the well known Sign Sign LMS algorithm with some scaling in the regressor).

I'd be interested to know what you meen by 'optimal adaptation' there, as I wasn't aware that there is any such thing as a generally 'optimal' form of adaptation. I take it you mean a standard LMS algorithm, rather than the less stable (but faster) sign-sign LMS?

Quote

Well, OptimFrog seriously outperforms LA on speed, and LA does not give that much better ratio.[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=315045")

Wonder what gives you that idea. Take a look at the much quoted performance data by [a href="http://web.inter.nl.net/users/hvdh/lossless/lossless.htm]HansHeijden[/url], Speek (http://members.home.nl/w.speek/comparison.htm) and Guruboolez (http://www.foobar2000.net/lossless).
For a given compresion ratio, OptimFrog is twice as slow as La, both at encoding and at decoding (and even slower compared to Monkey's Audio, for that matter). La is only equalled in ratio by OptimFrog's very highest (and slowest) extranew/bestnew setting, and then still, only in Guruboolez' tests.
[{POST_SNAPBACK}][/a]
(http://index.php?act=findpost&pid=315277")

And in my test:

[a href="http://studwww.ugent.be/~jdebock/lossless_audio_compression_test.htm]http://studwww.ugent.be/~jdebock/lossless_...ession_test.htm[/url]

I can't seem to access the download site. Are there any mirrors?

I can't seem to access the download site. Are there any mirrors?
[a href="index.php?act=findpost&pid=316722"][{POST_SNAPBACK}][/a]

I can host it, but I don't have the files to host because I can't access it either. If someone wants to email me the files I can host them.
(http://www.crapshack.com/email.png)

I can reach http://www.losslessaudio.org/ (http://www.losslessaudio.org/) without problem.

Yes it seems to be back today. I monitor many sites for version changes and OptimFROG site indeed seems to be quite often down for few-days periods.

Thankyou Ghido!

I am one of those users who wouldn't mind if the encoding took maybe 50% or whatever, longer, if the resulting file has advantages like:

Better Compression.

Error resilience (correction) - I wouldn't mind extra time at encode to generate extra checksums if it means my original data is safer.

Also, Playback/Decode speed is highly important to me, a lot more than time taken to encode. The way I see it, encode is once for a file, while playback is many times. Similarly data integrity is of high importance, while encode time is not really because I guess I could set it up in a batch and leave it unattended.

Anyway, it's great to hear you are developing this great project even further, thanks.

I am one of those users who wouldn't mind if the encoding took maybe 50% or whatever, longer, if the resulting file has advantages like:

Better Compression.
...
Also, Playback/Decode speed is highly important to me, a lot more than time taken to encode. The way I see it, encode is once for a file, while playback is many times.[a href="index.php?act=findpost&pid=318002"][{POST_SNAPBACK}][/a]

I may be wrong, but I'm afraid that with OptimFROG being the high-compression symmetrical codec it is, those two quoted needs of yours will be near to impossible to reconcile.

If you need fast decoding for reasonable compression ratios, you should consider either any of the asymmetrical codecs, being ALAC, FLAC and WavPack, or the efficiency (in terms of both encoding and decoding speed vs. ratio) of however symmetrical Monkey's Audio, which has nonetheless proven to be not that error robust.

or the efficiency (in terms of both encoding and decoding speed vs. ratio) of however symmetrical Monkey's Audio, which has nonetheless proven to be not that error robust.
[a href="index.php?act=findpost&pid=318006"][{POST_SNAPBACK}][/a]

I use Monkey's Audio at -c3000 because it offers better compression than Wavpack or Flac, while retaining decoding qualities that are similar, or at least good enough for transcoding (since encoding is usually slower than how fast MA can decode). It's the sweet spot as far as compromising goes. I'm very curious why you say it's "not that error robust" though.

PS: If I didn't care about speed, I would definitely use OptimFrog. If I ever run out of hard disk space it would be a toss up between using OptimFrog and WavPack in lossy mode. The latest versions of OF seem pretty decent now speed-wise.

I'm very curious why you say it's "not that error robust" though.[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=318086")

[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=33226&view=findpost&p=316496]http://www.hydrogenaudio.org/forums/index....ndpost&p=316496[/url]

I'm very curious why you say it's "not that error robust" though.

Read this post (http://www.hydrogenaudio.org/forums/index.php?showtopic=33226&st=175&p=316496&#entry316496) and downwards.

[span style='font-size:8pt;line-height:100%']Edit: Roberto beat me to it.[/span]

I'd previously mentioned having quite some negative experiences with file corruption of Monkey's Audio files as well.

Wow, thanks guys! I missed those posts somehow, and very glad to have read it. Been using APE for almost a year now, and I've never really had any trouble yet except once when a single file got corrupted somehow, but the error was discovered when foobar reported it while transcoding my entire collection to OGG Vorbis recently. Some food for thought, thanks (I think hehe).

PS: Sometimes foobar will report an error when there actually is none when tested (by trying to transcode a second time and/or listening to the suspect file). Strange.

Strange indeed, you may have a memory problem...

Strange indeed, you may have a memory problem...
[a href="index.php?act=findpost&pid=318115"][{POST_SNAPBACK}][/a]

I overclock so it's quite possible. Perhaps I'll do some memory and stability tests tonight. Regarding the APE format, I tried two quick (separate) tests; replacing bits and deleting them with a hex editor. Since I do all playback, decoding, and tagging in foobar, and it always reports a checksum error during decoding, I've decided it's safe to continue using Monkey's Audio fwiw. Good info to know though and something I never would have thought to test had someone not pointed it out. Peace of mind is a valuable thing.

Hey thanks for the information Polar. I don't understand about symmetrical & asymmetrical, but I have encoded to Flac several times & it seems about as good as OptimFrog. WavPack is also good. I have not settled on a long term archiving solution yet, I have just tried a few of these lossless encoders at times over the last couple of years
When I said fast "Playback/Decode speed"  I was also meaning efficiency of lower CPU utilisation - I don't know if those things are the same 
When encoding to OptimFrog it is like you can choose a higher compression for a tradeoff of a slower decode, are you saying that this situation can not be improved on much further than at present, at least not so it could ever beat a codec like Flac in this area?
Thanks 
   

I may be wrong, but I'm afraid that with OptimFROG being the high-compression symmetrical codec it is, those two quoted needs of yours will be near to impossible to reconcile.

If you need fast decoding for reasonable compression ratios, you should consider either any of the asymmetrical codecs, being ALAC, FLAC and WavPack, or the efficiency (in terms of both encoding and decoding speed vs. ratio) of however symmetrical Monkey's Audio, which has nonetheless proven to be not that error robust.