News:
The final release of OptimFROG 4.505 is here, and an entire release series 1.05 of input plug-ins with APEv2 read tagging support. There is also a new plug-in for dBpowerAMP. The new foobar2000 plug-in has streaming support (playing HTTP streams), which you can try with the http://ghido.shelter.ro/Audio/piano.ofr example (49 kbps) ;-)


Features:

• asymptotically the best compression ratios available
  
• Win32 and Linux command line versions
  
• fast operation, default mode encodes at 12.4x real-time and decodes at 17.4x real-time on Athlon XP 1800+
  
• extensible, streamable compressed format, tagging compatible
  
• enhanced compression and speed compared to version 4.5alpha
  
• optimize mode, further improving compression at no decoding cost
  
• extranew and bestnew compression modes for even better compression
  
• backward compatible with version 4.2x (decode only)
  
• 64 bits large file support under Win32
  
• optimal support for all integer PCM wave formats up to 32 bits
  
• full pipe support for encoding and decoding
  
• multiple file processing on the same command line
  
• full raw file support
  
• quick verify compressed file integrity function
  
• compatible with Exact Audio Copy, with ID3v1.1 tagging
  
• extensible command line format
  
• full raw file support
  
• simple to use, but powerful Windows GUI encoder, Kermit (made by Speek) available at
  http://home.wanadoo.nl/~w.speek/kermit.htm
  
• foobar2000, dBpowerAMP, Winamp2, Winamp3, XMPlay and XMMS plug-ins
  
• bitstream error resilience and transparent real-time recovery
  
• fast seek with intelligent caching for plug-ins
  
• ID3v1.1 and APEv2 read tagging support for plug-ins
  
• streaming support (playing HTTP streams) for foobar2000 plug-in
  
• Replay Gain compatible plug-ins for foobar2000 and Winamp3

This is not true. "LA" 0.4 is better (about compression ratio) and faster (decode).

Don't put a fly in the ointment

Excellent news Ghido.

Yep, good job, but the first statement ("asymptotically the best compression ratios available") is undoubtedly false, period!

undoubtedly ?
I've just tested on one track (my winner, in compression challenge : piano track - 2'20 min)




I'm not sure that -high is the best setting for LA.
LA encoding is playable on my Duron 800 ; Monkey -c5000 is always buggy (foobar & winamp : error) ; ofr encoding need too much power, and playback is awfully slow (not only playback : encoding is interminable)

YES! (except rare events with "classic" tracks).



One track only?

http://web.inter.nl.net/users/hvdh/lossles...ss/lossless.htm



Infact OptimFrog is unusable (in a practical way), La default is definitely better (in a practical way).

Sorry, I can't perform a test on 15 discs with my Duron 800 in one hour

What I suggested is to test again the respective performance of the different lossless format with this new release of OptimFrog. I know that in the past LA was the best, but now ? Is it always true ? Undoubtedly, without any new test ?

optimfrog linux binary crahes if the output file already exists.

YESSSS!

OptimFROG 4.504b (tested in http://web.inter.nl.net/users/hvdh/lossles...s/lossless.htm) and new OptimFROG 4.505 are identical (about compression ratio and speed).

I didn't know it.

I've just tested on another track (orchestral/percussion)



You were right : LA seems to be the best in compression/speed ratio. Nevertheless, I 'm not sure that I understand what you said previously :

Optimfrog is really usable in a practical way : ape tags, seekable... and good speed & ratio at -high and -extra setting (more confortable than LA default).

Good job, ghido


EDIT :
for comparison, MonkeyAudio (3.96b6) :
-c3000 (high) = 15.7 MB for 10,7''
-c4000 (extra) = 15.5 MB for 18.5''

and FLAC 1.10 :
-5 = 16.3 MB for 12''
-best = 16.2 MB for 38''

manageable (speed, especially decoding task) high compression.

Edit:
VERY good job, Michael (Bevin)

At least ofr is better than la for the piano.ofr above
and most of the killer samples

piano.ofr (extra) 64.7 kb
piano.la (high) 179 kb

Winamp CPU usage
ofr ~2%
la ~30 %


This is a nice sample from Frank, kill all lossy and lossless too
http://www.personal.uni-jena.de/~pfk/MPP/a..._Test_2.wav.bz2

OFR = 4kb
LA = more then 1 MB

LA is tuned for 2:1 compresssion it and will always be 2:1 for version 0.4
Sometimes OFR could do a 10:1 compression.

The crash problem under Linux was shortly solved since morning A friend of mine recently shown me the uC libc (micro C libc) package, together with gcc 3.2.2. I recompiled it with the same options as the full libc version and renamed the archive to OptimFROG_4505_Linux_uC.zip (as it was linked using uC libc). I made also available the full libc version, OptimFROG_4505_Linux.zip. The advantage of using uC libc is that the static binary has only 219 kB instead of 560kb...

The problem was that I thought that gcc 3.2.2 fixed the exception handling problem present in gcc 3.2.0 used to compile the full libc version (when compiling with -fomit-frame-pointer -O2, any user exception crashes the program; the workaround is to use -maccumulate-outgoing-args). For the uC libc version I didn't initially put the workaround switch...

Also, I would like to make a few remarks about OptimFROG:
- decoding is at least 40% faster than encoding
- extranew and bestnew modes benefit from SSE extensions, not present on the testing machines, so it's a slight time disadvantage for it
- it also supports up to 32 bits integer samples at the same speeds
- and others I should better not tell

Thanks,
Florin Ghido

great news, thanks B)

I have played with this 'piano' sample and got very funny results, that I think are worth sharing
compressed with newest versions I have at best settings:



so, this sample is very easy to compress (and even uncompressed it's 352kbps), but it seems to be a "killer sample" for many lossless codecs. nice work, Ghido

btw, since La results are pretty bad, I guess Michael will fix this soon

@kotrtim: La sometimes gives compression up to 15%, and simply can't be "always 2:1" :B

Yep.. don't want to sound too negative but the OFR description should probably also include "asymptotically the slowest compression speed of any lossless audio archiver available" *8-)

Spent about 10 full minutes hammering out an .OFR of a single tune just then, on my Athlon 1200. v4.505, 1.05 plugin, f2k 0.62a, --mode bestnew --optimize best. Tried to play the track and got the following error:

ERROR (CORE) : error opening file for playback : file://I:\Rip\Jon Hopkins-Opalescent(OptimFrog)-Jon Hopkins-Halcyon.ofr

I have here a lot of DAT recordings with 32 kHz.
For these recordings OptimFROG works by a factor of 2 and more better than all other compressors.

I have found a bug: files encoded with "--mode bestnew --speedup 1x (or 2x)" are not decodable: I get a "error occured" message and wav file full of zeros.

Having noticed a fair bit of argument as to which encoder (La or OFR) compresses best, I thought I might add a few comments ...



As previously noted by another poster, the idea that La is limited to 2:1 compression is patently false.

However, La IS tuned to compress best on typical music files (your standard rock/pop album, which tends to compress around 2:1). As a result it performs best on such music. Samples such as the above are interesting from a technical point of view (I've had a look at the sample and will work on improving La's performance on it), however such samples do not tell us much about the encoders' performance on real world music.

Regarding the OptimFrog 'asymptotically the best compression ratios', I would be interested to know what is meant by 'asymptotically' here as it has never been to clear to me .

Finally, regarding the piano tracks, I did note on my website that with the most recent version of Optimfrog, the Optimfrog compressor did outperform La on one of the samples from my test set. This sample was, surprise surprise, a very quiet piano piece. With La 0.4 I made some improvements on this sample, however obviously have some way to go (if someone could get that piano sample to me where La's output size is close to 3x that of Optimfrogs I'd be grateful - I've never seen a sample with such a huge difference before).

That said, I have yet to see a comprehensive comparison which doesn't show La as having the overall highest compression. Optimfrog on the other hand outdoes La in its features, especially with the latest version in which Ghido seems to have piled on a whole lot of new features. The only thing La has feature-wise which Optimfrog doesn't would be La's frontend, but seeing as it is actually a multi-encoder frontend which works with the other encoders including Optimfrog, it is hardly a reason to choose La. The question 'which encoder is best' is really 100% up to the particular users' needs.

I tried on a short sample I ripped from an AC3 mono track. 48000 hertz, 2 channels.

Original : 17.1 MB
ofr -extra : 4.45 MB -> 367 kb/s (26.02 %)
la -high : 5.47 MB -> 451 kbps (31.99 %)

Impressive difference !

The most recent version of OptimFROG you talk about is more than 6 month older. It would be fair and maybe edifying if you would put the results for the latest OptimFROG 4.505 with 'ofr --mode extranew' and 'ofr --mode bestnew --seek slow' on the LA comparison page

I agree with you that 'which encoder is best' should be named 'which encoder is best for me', because there are many factors that can be taken into consideration when choosing, aside from compression and speed

I just encoded the bonus track from Castlevania: Symphony of the Night, which came out to 27,440,736 bytes. (Using 4.505 with --mode bestnew --optimize best ... is that last option redundant?) It comes out to 28,147,864 with mac.exe v3.97 -c4000.

I didn't time the compression job, but it did take a while. Plus, I can't get it to play in real-time. I'll post some repeated decode timings, using foo_null Speed Meter disk writer. Of course, each pass will take more than the length of the track. (4m11s)

First run:

INFO (foo_null) : decoding took 256609 milliseconds, speed 0.97x

Second run:

INFO (foo_null) : decoding took 264390 milliseconds, speed 0.95x

Must be all the crap I'm doing while running the decode. Oh well.


Oops, some system stats are in order:

1.0GHz Intel Celeron (Coppermine series, P3 core) clocked at 1.12GHz
512MB PC133 RAM (Bus clocked at 112MHz)

The 'piano' sample I've used is the one from optimfrog's site (see link to piano.ofr on the top of this page).
I have uploaded more complete test results here. This sample seems to upset many encoders. I can't tell what's exactly wrong with it, but it seems to have different "smoothness".

As for Short_Block_Test, posted by kotrtim, I have uploaded test results here. first, you can see that LA's and APE's results are the worst. this is for sure very different from the "common situation". but open this file in editor (or just play it). it's nothing like the "real music"! it's just full of zeros with rare impulses! I'm not even sure if this is a good point for sound compressor to compress this file well...

-Eugene

P.S.

@Frank Klemm: what differs two times: compressed_size or (original_size - compressed_size) ?

@mcbevin: could you add description of used individual tracks and results for them to your comparasion page, please? and are you sure that newest OFR has the same compression performance as the version you've tested?

done - see lossless audio comparison - i must say i'm impressed at the improvement between 4.5 alpha and 4.505 - the difference is a lot smaller now between our compressors.



i'll do that next update then .... but as a brief description, theres a very quiet classical piano piece and a quiet orchestral piece - on these two optimfrog bestnew is quite a bit better than la. the rest include songs by oasis and fugazi, one by a reasonably heavy german band, some rap song, an electronic-jazz song, and every.wav (which used to be used from some old standard comparison i've forgotten the name of). on all these la generally does better, causing the overall result to be slightly in favour of la, however obviously if the mix was a little more classical oriented then the result could be different. also worth noting is that most are just excerpts (a minute or two in length) from the whole songs (simply so as to make the tests run faster).



thanks - i'll have a look at it and see if it warrents attention. on account of the short_block_test i doubt i'll making changes to la - as eltoder says its got no resemblance to music - though i do find it interesting that optimfrog handles it so well. clearly optimfrog is doing some things quite differently to the other compressors.