Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: OptimFROG suite version 4.520b available! (Read 29088 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

OptimFROG suite version 4.520b available!

Reply #25 –
ghido: Do you have any plans of releasing OptimFrog decoder as an open source application?

OptimFROG suite version 4.520b available!

Reply #26 –
Good work Florin, things are running a little smoother now on my old PC since 4.509. The upcoming version sounds promising.

Is it ok to use --seek fast with Dualstream ? The file it makes is not identical to --seek normal , but I cannot hear any differences.

OptimFROG suite version 4.520b available!

Reply #27 –
Quote
ghido: Do you have any plans fo releasing OptimFrog decoder as an open source application?[a href="index.php?act=findpost&pid=369545"][{POST_SNAPBACK}][/a]


It's not really proper to ask those things, you know?

I'm sure Ghido already knows of the possibility of releasing his codecs under an open source license, and he knows the pros and cons involved. If he ever decides to go ahead and do it, I'm sure we'll get to know.

OptimFROG suite version 4.520b available!

Reply #28 –
Why can't I encode files which have Russian filenames ? It tells me that the filename is incorrect or something. The encoder seems to accept only English language in filenames . Is that correct ? 

OptimFROG suite version 4.520b available!

Reply #29 –
Quote
WAV: 64 240 044 bytes
OFR default: 19 757 040 bytes
OFR maximumcompression: 19 845 239 bytes
Unfortunatelly I don't have the Speex version anymore (originally it was over 24h long and I couldn't find a way to split it other than by converting it to WAV), but I can upload the OFR file, just tell me where.
[a href="index.php?act=findpost&pid=369543"][{POST_SNAPBACK}][/a]

I did a quick check on the file. The cause is that maximumcompression uses much more complex models compared to normal. According to information theory, for each extra model parameter you have to pay it's overhead (which is generally surpassed by the gains). However here, as the sample is only 8 kHz Mono, and mostly noise-like sound (it may be looked also like a synthetic, colored noise - due to its generation by Speex), the parameters don't pay off and therefore you have this very small amount < 0.14% of extra size.
Anyway, this is very unlikely in practice, because the models have solid theoretical backgrounds, and the worst case regret is bounded and very small. To illustrate this with a comparison on 1191 files (Audio CD tracks, with total size of 52 GB), normal mode was better than bestnew mode on a single file, and that with only 0.12%.

Quote
ghido: Do you have any plans fo releasing OptimFrog decoder as an open source application?
[a href="index.php?act=findpost&pid=369545"][{POST_SNAPBACK}][/a]

Not in the near future.

Quote
Good work Florin, things are running a little smoother now on my old PC since 4.509. The upcoming version sounds promising.

Is it ok to use --seek fast with Dualstream ? The file it makes is not identical to --seek normal , but I cannot hear any differences.
[a href="index.php?act=findpost&pid=369591"][{POST_SNAPBACK}][/a]

Thanks
When using quality mode, there should be practically no difference between the two modes. But when using averagebitrate, each block must meet approximately its bitrate constraint by adjusting the quality factor. In the case of --seek fast, the constraint on the bitrate must be met on both blocks that would constitute a single block in the case of --seek normal. Therefore, I think that using seek normal (default) would have some small advantage in types of music where there is a high, sudden structural complexity change (like silence / quietness in classical genre).

OptimFROG does not base it's quantization decision only on a simple feedback bitrate control (which may create am unwanted reaction loop, i.e. we predict badly at beginning of a transient, therefore we increase quantization to keep the bitrate low, therefore we predict worse due to the added noise, and increase quantization again, etc.) , but it has an advanced distortion model which maximizes both the objective and subjective distortion and is completely decoupled (architecturally speaking) from the actual compression.

Quote
Quote
ghido: Do you have any plans fo releasing OptimFrog decoder as an open source application?[a href="index.php?act=findpost&pid=369545"][{POST_SNAPBACK}][/a]


It's not really proper to ask those things, you know?

I'm sure Ghido already knows of the possibility of releasing his codecs under an open source license, and he knows the pros and cons involved. If he ever decides to go ahead and do it, I'm sure we'll get to know.
[a href="index.php?act=findpost&pid=369743"][{POST_SNAPBACK}][/a]

That's for sure, you'll be among the first to know

Thanks,
Florin Ghido

OptimFROG suite version 4.520b available!

Reply #30 –
Quote
Quote
WAV: 64 240 044 bytes
OFR default: 19 757 040 bytes
OFR maximumcompression: 19 845 239 bytes
Unfortunatelly I don't have the Speex version anymore (originally it was over 24h long and I couldn't find a way to split it other than by converting it to WAV), but I can upload the OFR file, just tell me where.
[a href="index.php?act=findpost&pid=369543"][{POST_SNAPBACK}][/a]

I did a quick check on the file. The cause is that maximumcompression uses much more complex models compared to normal. According to information theory, for each extra model parameter you have to pay it's overhead (which is generally surpassed by the gains). However here, as the sample is only 8 kHz Mono, and mostly noise-like sound (it may be looked also like a synthetic, colored noise - due to its generation by Speex), the parameters don't pay off and therefore you have this very small amount < 0.14% of extra size.
Anyway, this is very unlikely in practice, because the models have solid theoretical backgrounds, and the worst case regret is bounded and very small. To illustrate this with a comparison on 1191 files (Audio CD tracks, with total size of 52 GB), normal mode was better than bestnew mode on a single file, and that with only 0.12%.
[a href="index.php?act=findpost&pid=369994"][{POST_SNAPBACK}][/a]

I created a number of test white noise samples (with Audacity, and some downloaded from random.org), tested all possible modes, and it seems that "--mode fast --optimize high" statistically has the least overhead, would you agree on that? Is white noise the best kind of sample to test overhead?

OptimFROG suite version 4.520b available!

Reply #32 –
for a slightly different question though.. the encode times mentioned in the documentation, as they were achieved on an athlon 1800+.. how come my 2800+ (which runs at 2083mhz as opposed to the 1200 mhz (right?) of the 1800+, and has double the cache) is only marginally faster (25% or so) encoding files?
it seems a bit illogical to me tbh..

oh well, thanks in advance for answering

OptimFROG suite version 4.520b available!

Reply #33 –
can i ask a maybe quite a foolish question?.. 

is there an OptimFrog command-line parameter for eac?..

OptimFROG suite version 4.520b available!

Reply #34 –
Quote
can i ask a maybe quite a foolish question?.. 

is there an OptimFrog command-line parameter for eac?..
[{POST_SNAPBACK}][/a]


[a href="http://www.saunalahti.fi/cse/EAC/]http://www.saunalahti.fi/cse/EAC/[/url]

OptimFROG suite version 4.520b available!

Reply #35 –
Quote
Quote
can i ask a maybe quite a foolish question?.. 

is there an OptimFrog command-line parameter for eac?..
[{POST_SNAPBACK}][/a]


[a href="http://www.saunalahti.fi/cse/EAC/]http://www.saunalahti.fi/cse/EAC/[/url]
[a href="index.php?act=findpost&pid=370476"][{POST_SNAPBACK}][/a]


thank you a lot...

OptimFROG suite version 4.520b available!

Reply #36 –
Can ofr.exe accept input from stdin ?
mac file.ape - -d -|ofr - file.ofr does not work.
Anyone can post the correct syntax ?
WavPack 4.3 -mfx5
LAME 3.97 -V5 --vbr-new --athaa-sensitivity 1

OptimFROG suite version 4.520b available!

Reply #37 –
Quote
Can ofr.exe accept input from stdin ?
mac file.ape - -d -|ofr - file.ofr does not work.
Anyone can post the correct syntax ?
[a href="index.php?act=findpost&pid=371059"][{POST_SNAPBACK}][/a]


You must use ofr --encode - file.ofr on the input pipe part (you have to specify --encode because the default operation is based upon the "file" extension which is none for "-"). The compressor doesn't know if what it will receive is a WAV (must be encoded) or OFR (must be decoded), so it needs a hint (--encode or --decode). You can also use --silent to suppress console output if the first program (in this case mac) also writes to stderr (which goes to the console, unless separately redirected to a file).

Just as a warning note, my mac version (3.99 official) does NOT output to a pipe, probably you have one that works. You can check if the program really produces output at stdout by using ">filename" instead of "| ofr...". Also, it seems there is an extra "-" in the mac command line at the end. In other words, for the version that has pipe support, shouldn't it be "mac file.ape - -d" instead?

I will come back later this week with an Unicode test version (to support filenames with non English characters), adding APEv2 tags directly during encoding, and some other small improvements...

Florin Ghido

OptimFROG suite version 4.520b available!

Reply #38 –
Quote
You must use ofr --encode - file.ofr on the input pipe part (you have to specify --encode because the default operation is based upon the "file" extension which is none for "-"). The compressor doesn't know if what it will receive is a WAV (must be encoded) or OFR (must be decoded), so it needs a hint (--encode or --decode). You can also use --silent to suppress console output if the first program (in this case mac) also writes to stderr (which goes to the console, unless separately redirected to a file).

Thanks your your reply, the necessary --encode switch make sense but mac file.ape - -d -|ofr --encode - file.ofr still doesn't work for me:
Code: [Select]
--- Monkey's Audio Console Front End (v 3.99) (c) Matthew T. Ashland ---
Decompressing...

OptimFROG Lossless Audio Compressor (Win32/x86), v4.520b [2006.03.02]
Copyright (C) 1996-2006 Florin Ghido, all rights reserved.
Visit http://www.LosslessAudio.org for updates
Free for non-commercial use. E-mail: FlorinGhido@yahoo.com


Exception UNKNOWN in file unknown, line 0
description: destination file not specified for -

Error: 1001

Quote
Just as a warning note, my mac version (3.99 official) does NOT output to a pipe, probably you have one that works.

Yes, i have the one with pipe support and mac file.ape - -d -|wavpack - file.wv works like a charm here.
WavPack 4.3 -mfx5
LAME 3.97 -V5 --vbr-new --athaa-sensitivity 1

OptimFROG suite version 4.520b available!

Reply #39 –
Quote
Thanks your your reply, the necessary --encode switch make sense but mac file.ape - -d -|ofr --encode - file.ofr still doesn't work for me:


Hi, I missed that you didn't have the --output in the line. This "--output" is needed in order to alow multiple input files on the same command line (wildcards is a different feature). It should be

"ofr --encode - --output file.ofr"

In the error text you posted there is the message "description: destination file not specified for -", and I quickly figured what was wrong - your file.ofr argument was interpreted just like another input file. 

Florin Ghido
 

OptimFROG suite version 4.520b available!

Reply #40 –
Quote
--maximumcompression is quite impressive, it's about LA's level now. (haven't testet enough samples yet)


--maximumcompression is not the limit. It activates undocumented "ultranew" encoding mode and can be tweaked further. Since v4.506 --speedup option have been depricated and now not mentioned in command reference but its still working. Also you can apply minimum seek info so it will be:
--optimize best --mode ultranew --seek min --speedup 1x
It slow as hell, about 0.13x realtime on my AMD64 3000+, more than twice slower than --maximumcompression.

And thank to Ghido for pushing lossless compression further. Best wishes

OptimFROG suite version 4.520b available!

Reply #41 –
@Skymmer
Thanks for the "speedup" info.

Quote
--maximumcompression is not the limit. It activates undocumented "ultranew" encoding mode and can be tweaked further.
"Ultranew" instead of "bestnew" (i thought that) or is this an additional parameter?

At http://uclc.info/lossless_audio_compression_test.htm they used the command line "--mode bestnew --seek min --optimize best --maximumcompression".
Then "--maximumcompression" should override the "--mode bestnew"?

Regards
Mit freundlichen Grüßen aus Österreich, Matthias

OptimFROG suite version 4.520b available!

Reply #42 –
Quote
--maximumcompression is not the limit. It activates undocumented "ultranew" encoding mode and can be tweaked further. Since v4.506 --speedup option have been depricated and now not mentioned in command reference but its still working. Also you can apply minimum seek info so it will be:
--optimize best --mode ultranew --seek min --speedup 1x
It slow as hell, about 0.13x realtime on my AMD64 3000+, more than twice slower than --maximumcompression.

And thank to Ghido for pushing lossless compression further. Best wishes
[{POST_SNAPBACK}][/a]

It was just a matter of time until someone would have found it 
Just to let everyone know the truth, "--maximumcompression" is exactly "--mode ultranew --seek slow --optimize best". Although the encoding is very, very slow, the decoding is generally only 15-30% slower than --bestnew mode. There are NO other command line options or combinations of them in the public version that could obtain steady better compression.

If you have only one file under 60 seconds, you can try playing with --maximumcompression --seek min, but this generally produces worse results than only --maximumcompression, and it is not recommended.

I strongly recommend anyone NOT to use --speedup. This option was deprecated for good reasons, and now you can obtain consistent and steady better compression much faster, using the --mode ***new modes. The --speedup option is just not meant for the ***new modes. The fact that it works with them now is simply because it was not disabled the hard way. Moreover, knowing the OptimFROG internals, I seriously doubt that this would consistently improve compression.

Why I did not document ultranew? Simple! Every time when someone new tries, for example, WavPack and OptimFROG, without reference to usage guidelines, will use the maximum mode avaliable from each. And the false conclusion they draw is clear: W is tens times faster than O, O is very slow, etc. They don't know that WavPack at its highest level (wavpack -h) decodes at 50x, and OptimFROG at the FASTEST level (ofr --mode fast) decodes at 34x, ALREADY obtaining 0.63% better compression (result obtained on a 80 CD / 50 GB audio corpus).

The conclusion of the story is clear - the two compressors are not in the same "weight class". WavPack starts at very high speeds and aims when increasing complexity at good compression, and OptimFROG starts at quite high speeds with already good compression  and aims when increasing complexity at the maximum possible compression.

Another reason for introducing --maximumcompression is that various tests for maximum compression were very contorted and mixed and they always seem to miss something, although it was all clear in the documentation.

Quote
@Skymmer
Thanks for the "speedup" info.

Quote
--maximumcompression is not the limit. It activates undocumented "ultranew" encoding mode and can be tweaked further.
"Ultranew" instead of "bestnew" (i thought that) or is this an additional parameter?

At [a href="http://uclc.info/lossless_audio_compression_test.htm]http://uclc.info/lossless_audio_compression_test.htm[/url] they used the command line "--mode bestnew --seek min --optimize best --maximumcompression".
Then "--maximumcompression" should override the "--mode bestnew"?

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

You must use --maximumcompression alone. Here is a quote from the command line help:

>ofr --help
...
  --maximumcompression
        try to obtain the maximum possible compression
        must be used alone, do NOT specify --mode, --seek, --optimize
        WARNING: very slow encoding, mainly for benchmark


If you are very interested into really maximum compression with backward compatibility and no increase in decompression time, I can give you a modified version which adds some secret ingredient  to --maximumcompression (and encoding becomes 4-6 times slower), but obtains consistently and steady better compression (in the range 0.1-0.3%). Just let me know

Thanks for your interest,
Florin Ghido

OptimFROG suite version 4.520b available!

Reply #43 –
Updated the OptimFROG entry on my website http://uclc.info
--maximumcompression --seek min produced slightly better results than --maximumcompression

Quote
If you are very interested into really maximum compression with backward compatibility and no increase in decompression time, I can give you a modified version which adds some secret ingredient   to --maximumcompression (and encoding becomes 4-6 times slower), but obtains consistently and steady better compression (in the range 0.1-0.3%). Just let me know
[a href="index.php?act=findpost&pid=371901"][{POST_SNAPBACK}][/a]

I'm certainly interested. You can send it at comments@uclc.info .

OptimFROG suite version 4.520b available!

Reply #44 –
Is it useful to apply "--seek slow" (i know that's default) on tracks shorter than 60 seconds and "--seek min" on tracks longer than 60 seconds with the --maximumcompression preset?
Or are your words "must be used alone, do NOT specify --mode, --seek, --optimize" seriously serious?

Quote
If you are very interested into really maximum compression with backward compatibility and no increase in decompression time, I can give you a modified version which adds some secret ingredient   to --maximumcompression (and encoding becomes 4-6 times slower), but obtains consistently and steady better compression (in the range 0.1-0.3%). Just let me know [a href="index.php?act=findpost&pid=371901"][{POST_SNAPBACK}][/a]
...

Yes, i'm certainly very interested into really maximum compression.
Please send this mod to: matthias at boindl dot l-tech.org

Thanks
Mit freundlichen Grüßen aus Österreich, Matthias

OptimFROG suite version 4.520b available!

Reply #45 –
Quote
I strongly recommend anyone NOT to use --speedup. This option was deprecated for good reasons, and now you can obtain consistent and steady better compression much faster, using the --mode ***new modes. The --speedup option is just not meant for the ***new modes. The fact that it works with them now is simply because it was not disabled the hard way. Moreover, knowing the OptimFROG internals, I seriously doubt that this would consistently improve compression.


I don't see any reasons to not to use. It's working and provides better compression. At least on my own not so comprehensive tests so let it be undocumented but not disabled. Ghido, please don't disable it and leave playground for hardcore compression lovers.

Quote
Why I did not document ultranew? Simple! Every time when someone new tries, for example, WavPack and OptimFROG, without reference to usage guidelines, will use the maximum mode avaliable from each. And the false conclusion they draw ...


Well, if you fear wrong conclusions then I understand you but you can at least provide such info in the forum.

Quote
If you are very interested into really maximum compression with backward compatibility and no increase in decompression time, I can give you a modified version which adds some secret ingredient   to --maximumcompression (and encoding becomes 4-6 times slower), but obtains consistently and steady better compression (in the range 0.1-0.3%). Just let me know

Well, I also would like to play with it if possible.
skymmer {at} yandex {dot} ru
Thanks.

OptimFROG suite version 4.520b available!

Reply #46 –
/me is waiting for foo_ofr.dll compiled for fb2k 0.9

OptimFROG suite version 4.520b available!

Reply #47 –
OptimFROG commandline frontend has delayed output when using gui frontend with and without pipes. It is not nice to have such behavior with encoder and decoder has no problem with that. Can author make some adjustments in commandline tool ofr.exe in future releases?  This problem is very annoying. I using ofr.exe in GUI frontend. Also with this problem is related percentage progress information, steps are too big when encoding and when decoding are much smaller. This is some kind of inconsistency.