Hydrogenaudio Forums

Hydrogenaudio Forum => Validated News => Topic started by: ghido on 2006-03-04 06:15:28

Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-04 06:15:28
Hello,

First, I want to thank all the supporters of OptimFROG. The OptimFROG suite Lossless/DualStream/IEEE Float Audio Compressor, version 4.520b [2006.03.02] (beta) and SDK 1.210b is ready to download at http://www.LosslessAudio.org/ (http://www.LosslessAudio.org/).

What is new in this version:
  - successfully ported to Linux/amd64
  - successfully ported to Darwin/ppc (PowerPC G3)
  - many internal source code improvements
  - all the newly created compressed files are completely backwards compatible (can be decoded with previous 4.50x versions)
  - added ID3v2 tag support (all decoders can search for main header, skipping up to 1MB)

  - added --selfextract option, the Win32/x86 sfx stub (statically linked) is only 55 kB in size
  - complete self extracting support for Win32/x86, Linux/x86, and Linux/amd64 (all sfx stubs are statically linked)
  - C source code for sfx stub available in SDK

  - slightly faster encoding and decoding with exactly the same compression
  - compression improved very slightly when using --optimize best option
  - improved compression (0.1-0.3%) when using command --maximumcompression (this option is mainly intended for benchmark)

  - added --correct_audition option to IEEE Float to correct Adobe Audition / CoolEdit conversion bug: when converting from int to float, Audition converts 0 values to random noise with maximum relative amplitude < 5*10^-16; this option carefully corrects this bug setting them back to 0 and significantly improves compression ratio in these files

  - the OptimFROG.dll/.so version 1.210 is binary compatible with the previous versions, now also available for Linux/amd64 and Darwin/ppc
  - fixed a missing check for errors after calling OptimFROG_readTail(...), which could return -1, in Test_C and Test_CPP SDK samples

As always, you can reach OptimFROG Lossless/DualStream/IEEE Float Audio Compressor and its SDK at
http://www.LosslessAudio.org/ (http://www.LosslessAudio.org/)

Thank you again,
Florin Ghido
Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-04 06:23:15
Continued...

What to expect next:
  - development of OptimFROG will greatly accelerate
  - next major version will most probably include:
    * significantly improved compression (soon)
    * recovery information
    * gapless joining of multiple OptimFROG files
    * recovery of data from severely broken files
    * using .ofc correction file when decoding in plug-ins and an additional function for specifying the .ofc correction file in SDK [thanks to shadowking for suggestions of usage scenario of this feature]
    * multichannel support
    * cue sheet support
    * Adobe Audition plug-in
    * integrated GUI interface and automated installer with plug-ins
    * something completely different and new ;-)


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

Please do not hesitate to contact me if you have an idea or feature proposal about you think it will enhance OptimFROG.

Florin Ghido
Title: OptimFROG suite version 4.520b available!
Post by: matthiasb on 2006-03-04 10:17:06
Without flooding a newsthread:
Decoding time (--mode bestnew --seek min --optimize best) has increased from 1.69x to 1.72x (PM1.6GHz, WinCLI), but i didn't see a better compression ratio with the new "optimize best" option.

--maximumcompression is quite impressive, it's about LA's level now. (haven't testet enough samples yet)
Decoding time decreased to 1.03x on my system but still above 1.

How well will the "* significantly improved compression (soon)" work?

Great work, v4.520b is my new ofr.exe
Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-04 12:28:54
Quote
Without flooding a newsthread:
Decoding time (--mode bestnew --seek min --optimize best) has increased from 1.69x to 1.72x (PM1.6GHz, WinCLI), but i didn't see a better compression ratio with the new "optimize best" option.

--maximumcompression is quite impressive, it's about LA's level now. (haven't testet enough samples yet)
Decoding time decreased to 1.03x on my system but still above 1.

How well will the "* significantly improved compression (soon)" work?

Great work, v4.520b is my new ofr.exe
[a href="index.php?act=findpost&pid=369003"][{POST_SNAPBACK}][/a]


The very slightly increase in compression I was indicating about "--optimize best" appears only in some conditions, and is based on the fact that some estimator in the compression engine did not previously investigate fully the area of its parameter space. If it happens that the optimal parameter was not in that area, the new version may obtain an improvement of few kB, otherwise it uses the same parameter as the old version.

Could you give some more details about "--maximumcompression is quite impressive, it's about LA's level now."?
According to what I know from a huge CD Audio corpus (genre balanced) larger than 50 GB, OptimFROG "ofr --bestnew --seek slow --optimize best" already outperforms "la --high" in terms of compression ratio.

The command "ofr --maximumcompression" should give steady better compression than "ofr --bestnew --seek slow --optimize best".

The significant improvement will be, =on average=, somewhere between 0.5% and 0.7%, at an increase of complexity only between 5-15%.

I'm glad you like the new version...

Florin Ghido
Title: OptimFROG suite version 4.520b available!
Post by: matthiasb on 2006-03-04 14:04:03
Thanks for the info.

Quote
Could you give some more details about "--maximumcompression is quite impressive, it's about LA's level now."?
According to what I know from a huge CD Audio corpus (genre balanced) larger than 50 GB, OptimFROG "ofr --bestnew --seek slow --optimize best" already outperforms "la --high" in terms of compression ratio.
50GB?  *thinks about compression time*
Sorry, i tested only a *few* samples and the line "--encode --mode bestnew --seek min --optimize best" in ofr v4.510 and v4.520 wasn't as good as LA0.4b -high. But this was only a short test, not even genre balanced and i used already compressed decompressed files. *takes claim back*

Quote
The command "ofr --maximumcompression" should give steady better compression than "ofr --bestnew --seek slow --optimize best".
Yes, it does.

Quote
The significant improvement will be, =on average=, somewhere between 0.5% and 0.7%, at an increase of complexity only between 5-15%.
That sounds quite good. I'm looking forward to it.
Title: OptimFROG suite version 4.520b available!
Post by: kwanbis on 2006-03-04 15:26:02
i have this as the example/default MAREO's OptimFROG settings, has anything changed? or any better option? by the way, is it possible to add tags? I'm not really into OptimFROG, but i want to give good example for those who want to use it.

; ------------------------------------------------------
; OptimFROG WITH CORRECTION FILE: http://www.losslessaudio.org/ (http://www.losslessaudio.org/)
; -----------------------------------------------------
; ENCODER = ofs.exe
; PARAMETERS = --correction "@source@"
Title: OptimFROG suite version 4.520b available!
Post by: Peter on 2006-03-04 15:34:19
May I ask what your reasons behind "adding ID3v2 support" are? Is it restricted to specific subset of ID3v2 specification (let's say 2.4 with UTF-8 text encoding only), or any revision of ID3v2 with any features defined in relevant specification?
Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-04 16:30:05
Quote
May I ask what your reasons behind "adding ID3v2 support" are? Is it restricted to specific subset of ID3v2 specification (let's say 2.4 with UTF-8 text encoding only), or any revision of ID3v2 with any features defined in relevant specification?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=369057")


Personally, ID3v2 seems rather convoluted for me, but I received some requests. In fact, it's possible that I was not very clear in the log. I added for all decoders the possibility of searching the main header, skipping up to 1MB from the beginning of the file. The motivation was mostly for adding self extract support and I also verified that files prefixed with an ID3v2 decode correctly. So, it's more exactly ID3v2 compatible (which came mostly for free, after finishing the self extract part).

OptimFROG decoders can read ID3v1/APEv2 tags natively, but this is completely disabled in the foobar2000 plug-in. I am a big fan of your foobar2000 plug-in clean and efficient architecture (removal of output data format and tags processing involvment in the plug-in code), data processing path, and appreciate the fact that tags are processed uniformly.

Quote
i have this as the example/default MAREO's OptimFROG settings, has anything changed? or any better option? by the way, is it possible to add tags? I'm not really into OptimFROG, but i want to give good example for those who want to use it.

; ------------------------------------------------------
; OptimFROG WITH CORRECTION FILE: [a href="http://www.losslessaudio.org/]http://www.losslessaudio.org/[/url]
; -----------------------------------------------------
; ENCODER = ofs.exe
; PARAMETERS = --correction "@source@"


The defaults are just ok for DualStream, and quality mode 3 (default) is a very good choice. Anyway, the possibility to choose a bitrate or quality (if supported) would be nice.

Currently the command line encoders cannot add tags during encoding, and this must be done externally. However, it seems that specialized external taggers may do a much better job. OptimFROG decoders can read ID3v1/APEv2 tags natively and can skip ID3v2 tags. If adding APEv2 tags during encoding would be very useful, then I will consider implementing it.
Title: OptimFROG suite version 4.520b available!
Post by: Peter on 2006-03-04 16:44:05
The problem with "allowing" ID3v2 is that someone's app will end actually writing ID3v2 to OFR files (because now it's legal according to you), and then complete tag reader implementation will have to be able to parse all variations "allowed" by the spec in order to be fully compatible with all other apps that claim compliance with the spec. In other words, you have just made potential full implementation of OFR tag parser a lot more complicated, for pretty much no functional gain (cover art etc can be perfectly stored in APE tags as well).
I would suggest taking the Musepack approach - the decoder can skip ID3v2, but actually writing ID3v2 to files is considered a violation of file format specifications.
Title: OptimFROG suite version 4.520b available!
Post by: kwanbis on 2006-03-04 16:44:24
Quote
The defaults are just ok for DualStream, and quality mode 3 (default) is a very good choice. Anyway, the possibility to choose a bitrate or quality (if supported) would be nice.

thanks for the update. how would they be able to select bitrate and/or quality?
Title: OptimFROG suite version 4.520b available!
Post by: Sebastian Mares on 2006-03-04 16:52:04
Quote
I added for all decoders the possibility of searching the main header, skipping up to 1MB from the beginning of the file.
[a href="index.php?act=findpost&pid=369070"][{POST_SNAPBACK}][/a]


What exactly do you mean? Do the decoders search byte-for-byte for the main header or what? Do the decoders take the size information from the ID3v2 header into consideration or do they blindly search the main header by themselves?
Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-04 18:45:12
Quote
I would suggest taking the Musepack approach - the decoder can skip ID3v2, but actually writing ID3v2 to files is considered a violation of file format specifications.
[a href="index.php?act=findpost&pid=369075"][{POST_SNAPBACK}][/a]

I agree with you. I intend for the decoder only to be able to skip an ID3v2 tag (as it's specified for some time in the format documentation - "The decoder will be able to skip this [ID3v2] tag"), and otherwise to not offer any other support for the tag. The skipping process completely ignores the prefixed contents and searches for the main header in an optimized, byte oriented way, and validates it to avoid false positives.

Quote
Quote
The defaults are just ok for DualStream, and quality mode 3 (default) is a very good choice. Anyway, the possibility to choose a bitrate or quality (if supported) would be nice.

thanks for the update. how would they be able to select bitrate and/or quality?
[a href="index.php?act=findpost&pid=369076"][{POST_SNAPBACK}][/a]


You have available the following command line options OptimFROG DualStream:

  --quality qq.qqq    encode at the specified quality, default 3
  --bitrate bbbb.b    encode at the specified average bitrate
  --correction        create or use correction file(s)

Quote
What exactly do you mean? Do the decoders search byte-for-byte for the main header or what? Do the decoders take the size information from the ID3v2 header into consideration or do they blindly search the main header by themselves?
[a href="index.php?act=findpost&pid=369080"][{POST_SNAPBACK}][/a]


The decoders just searches for the fixed starting bytes in the main header in a byte oriented optimized way, and then validates potential candidates to avoid false positives. This means that it doesn't matter what data you have prefixed (it should normally be an ID3v2 or a sfx stub, but it can't be enforced), as long it's not bigger than 1 MB.

Florin Ghido
Title: OptimFROG suite version 4.520b available!
Post by: Sebastian Mares on 2006-03-04 21:37:54
Why not rely on the ID3v2 size information and if that should contain incorrect data, use your approach? This has two advantages: you don't need to "manually" search for the header by traversing the first MB byte-for-byte if a proper ID3v2 tag was found, and ID3v2 tags larger than 1 MB could be supported (not that it makes sense to have such huge tags, but anyways).
Title: OptimFROG suite version 4.520b available!
Post by: rutra80 on 2006-03-05 08:56:17
I noticed that in SDK there's a newer version (1.10) of foo_ofr.dll than on the Download page (v1.09) - should I use it or is it some debug build or something?
And thank you for the new release of course

Edit:
Quote
The command "ofr --maximumcompression" should give steady better compression than "ofr --bestnew --seek slow --optimize best".
[a href="index.php?act=findpost&pid=369022"][{POST_SNAPBACK}][/a]

I just encoded a 60MB big WAV file (1h07m, 8kHz, mono, 16bit - decoded from Speex) and --maximumcompression produced bigger OFR file even than default mode (I used "--encode --maximumcompression - --output %d" in fb2k).
Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-05 14:09:34
Quote
Why not rely on the ID3v2 size information and if that should contain incorrect data, use your approach? This has two advantages: you don't need to "manually" search for the header by traversing the first MB byte-for-byte if a proper ID3v2 tag was found, and ID3v2 tags larger than 1 MB could be supported (not that it makes sense to have such huge tags, but anyways).
[a href="index.php?act=findpost&pid=369142"][{POST_SNAPBACK}][/a]


For SFX, there must be already some code which searches "manually", because it's too complicated and unreliable to peek the information from the executable headers (which could be different formats - Win32/x86, Linux/x86, Linux/amd64, Darwin/ppc, etc.). As the decoder intent is only to be able to skip the prefixed data, which in practical cases would be none or several kB, there is no big overhead.
I also thought about it first, but the main technical problem is with streaming. If the ID3v2 tag says it's 500 kB, and if in fact it is much less, we do not have a second chance of going back (aside from using a very large buffer) to try "manual" search.

Quote
I noticed that in SDK there's a newer version (1.10) of foo_ofr.dll than on the Download page (v1.09) - should I use it or is it some debug build or something?
And thank you for the new release of course

Edit:
Quote
The command "ofr --maximumcompression" should give steady better compression than "ofr --bestnew --seek slow --optimize best".
[a href="index.php?act=findpost&pid=369022"][{POST_SNAPBACK}][/a]

I just encoded a 60MB big WAV file (1h07m, 8kHz, mono, 16bit - decoded from Speex) and --maximumcompression produced bigger OFR file even than default mode (I used "--encode --maximumcompression - --output %d" in fb2k).
[a href="index.php?act=findpost&pid=369233"][{POST_SNAPBACK}][/a]


All the plug-ins [Winamp2, foobar2000, dBpowerAMP, XMMS] have newer (and better) stable versions in the SDK starting with the release of SDK 1.200 (which was July 2005). I didn't packaged individually the new versions yet because I didn't decided myself how it would be better (ZIP file, installer, PIMP, etc.) for the non-technical user.

About the file, it's quite strange, but it may be due to the very low sample rate - 8 kHz (I have only a few files in my audio corpus which are <= 16 kHz).
It would be very helpful if you could send me the file, to see why and how it can be solved (without affecting the decoder). You can send me the OFR file, or a ZIP archive containing the Speex file and the steps required to exactly reproduce the WAV file.
Also, can you tell me which were the three file sizes (in bytes) for WAV, OFR default, and OFR maximumcompression?

Thank you,
Florin Ghido
Title: OptimFROG suite version 4.520b available!
Post by: krmathis on 2006-03-05 14:20:48
Quote
- successfully ported to Darwin/ppc (PowerPC G3)

I cant seem to find a download link for this one! Care to point me to it?
Title: OptimFROG suite version 4.520b available!
Post by: Sebastian Mares on 2006-03-05 19:35:20
By the way Florin, you have an small mistake in the changelog:

Quote
4.520b + SDK 1.210b [2005.03.02]
Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-05 20:13:44
Quote
Quote
- successfully ported to Darwin/ppc (PowerPC G3)

I cant seem to find a download link for this one! Care to point me to it?
[a href="index.php?act=findpost&pid=369298"][{POST_SNAPBACK}][/a]

I'm glad you asked  . I ported it, but not released it yet because I want to do more testing first. The main problem is that I don't have a PowerPC and it was all done using a software PowerPC emulator (providing a virtual PowerPC G3 Blue and White, but 20 times slower than a real machine), where I have installed Darwin 7.0.1 (the free base layer for Mac OS X 10.3 "Panther").

A friend of mine told me that he may be able to run (asking someone else) some test programs for me on a real PowerPC computer at the beginning of this week and send me back the results.

What I wanted to say is that it would be great if I could send you an executable which does some tests, and report me back the results. Ideally would be to be able to log-in and do some stuff (compile and run some test programs), but it may not possible. Could you tell me more exactly what OS and processor do you have?

I was going to ask on this forum if someone with a real system (PowerPC G3 BW or later - a New World ROM machine) can give me for a limited time a login console (text only, ssh), so that I could experiment a little on the real thing.

Quote
By the way Florin, you have an small mistake in the changelog:
Quote
4.520b + SDK 1.210b [2005.03.02]

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

Quite a stupid mistake indeed, I fixed it; thank you 

Florin Ghido
Title: OptimFROG suite version 4.520b available!
Post by: krmathis on 2006-03-05 20:30:57
ghido. No wonder I could not find it... 

I have a 1.5GHz PowerBook G4, running Mac OS 10.4.5.
Not sure how to create a limited ssh login shell, but if/when I figure out how I'll let you in.

In the meantime I'm more than willing to test some binaries and report back to you!


Edit: Perhaps you can try the Sourceforge.net: Compile Farm (https://sourceforge.net/docs/compile_farm)?
They have an Apple Mac G4 running Mac OS 10.2
Title: OptimFROG suite version 4.520b available!
Post by: rjamorim on 2006-03-05 21:22:24
Quote
Not sure how to create a limited ssh login shell, but if/when I figure out how I'll let you in.


Well, it's Unix. Just create a new user account, and it should work for remote SSH connections (considering you have sshd running)

Quote
Edit: Perhaps you can try the Sourceforge.net: Compile Farm (https://sourceforge.net/docs/compile_farm)?
They have an Apple Mac G4 running Mac OS 10.2[a href="index.php?act=findpost&pid=369385"][{POST_SNAPBACK}][/a]


Their MacOS shells have been dead for months

Besides, the compile farms should be used for Open Source projects ONLY (http://pessoal.onda.com.br/rjamorim/devil.gif)
Title: OptimFROG suite version 4.520b available!
Post by: Duble0Syx on 2006-03-05 21:41:15
Quote
Currently the command line encoders cannot add tags during encoding, and this must be done externally. However, it seems that specialized external taggers may do a much better job. OptimFROG decoders can read ID3v1/APEv2 tags natively and can skip ID3v2 tags. If adding APEv2 tags during encoding would be very useful, then I will consider implementing it.
[a href="index.php?act=findpost&pid=369070"][{POST_SNAPBACK}][/a]

Personally I think being able to add tags by defualt woul be useful.  For example, ripping with EAC you'd have to use a 3rd party app like wapet or something else, while easy to do, is still kind of annoying.  Not a required feature, but certainly makes it more competative.  I hope there is another lossless encoder comparison soon, unless there is already a recent one I missed.  Last I checked optimfrog did quite nicely for size and decoding speeds.  Would definitely be nice to see it supported by more things as well.
Title: OptimFROG suite version 4.520b available!
Post by: krmathis on 2006-03-05 22:06:30
Quote
Quote
Not sure how to create a limited ssh login shell, but if/when I figure out how I'll let you in.

Well, it's Unix. Just create a new user account, and it should work for remote SSH connections (considering you have sshd running)

True. But I want to restrict the user from cd out off his home directory.
Title: OptimFROG suite version 4.520b available!
Post by: rjamorim on 2006-03-05 22:45:44
Quote
True. But I want to restrict the user from cd out off his home directory.[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=369417")


[a href="http://www.schwie.com/brad/macosxsftpchroot/]http://www.schwie.com/brad/macosxsftpchroot/[/url]
Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-05 23:31:53
Quote
In the meantime I'm more than willing to test some binaries and report back to you!

Thank you for the offer. I will send you sometime tomorrow the binary by e-mail (but I don't know where). Anyway, if you can't easily make the account with the security stuff (the link provided by rjamorim seems to describe only a way to copy (scp) files) don't bother too much with it; maybe there are other persons who already have it set-up.

Florin Ghido
Title: OptimFROG suite version 4.520b available!
Post by: rutra80 on 2006-03-06 09:22:24
Quote
About the file, it's quite strange, but it may be due to the very low sample rate - 8 kHz (I have only a few files in my audio corpus which are <= 16 kHz).
It would be very helpful if you could send me the file, to see why and how it can be solved (without affecting the decoder). You can send me the OFR file, or a ZIP archive containing the Speex file and the steps required to exactly reproduce the WAV file.
Also, can you tell me which were the three file sizes (in bytes) for WAV, OFR default, and OFR maximumcompression?
[a href="index.php?act=findpost&pid=369295"][{POST_SNAPBACK}][/a]

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.
Title: OptimFROG suite version 4.520b available!
Post by: birdie on 2006-03-06 09:41:40
ghido: Do you have any plans of releasing OptimFrog decoder as an open source application?
Title: OptimFROG suite version 4.520b available!
Post by: shadowking on 2006-03-06 12:53:23
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.
Title: OptimFROG suite version 4.520b available!
Post by: rjamorim on 2006-03-06 21:37:06
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.
Title: OptimFROG suite version 4.520b available!
Post by: Leo 69 on 2006-03-07 16:03:00
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 ? 
Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-07 19:39:02
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
Title: OptimFROG suite version 4.520b available!
Post by: rutra80 on 2006-03-08 09:55:42
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?
Title: OptimFROG suite version 4.520b available!
Post by: DARcode on 2006-03-08 10:43:58
The new release takes the lead here: http://uclc.info/lossless_audio_compression_test.htm (http://uclc.info/lossless_audio_compression_test.htm)
Title: OptimFROG suite version 4.520b available!
Post by: boombaard on 2006-03-09 20:46:50
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
Title: OptimFROG suite version 4.520b available!
Post by: satorippoi on 2006-03-09 21:47:41
can i ask a maybe quite a foolish question?.. 

is there an OptimFrog command-line parameter for eac?..
Title: OptimFROG suite version 4.520b available!
Post by: shadowking on 2006-03-09 22:31:22
Quote
can i ask a maybe quite a foolish question?.. 

is there an OptimFrog command-line parameter for eac?..
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=370470")


[a href="http://www.saunalahti.fi/cse/EAC/]http://www.saunalahti.fi/cse/EAC/[/url]
Title: OptimFROG suite version 4.520b available!
Post by: satorippoi on 2006-03-10 16:22:53
Quote
Quote
can i ask a maybe quite a foolish question?.. 

is there an OptimFrog command-line parameter for eac?..
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=370470")


[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...
Title: OptimFROG suite version 4.520b available!
Post by: [proxima] on 2006-03-12 17:01:54
Can ofr.exe accept input from stdin ?
mac file.ape - -d -|ofr - file.ofr does not work.
Anyone can post the correct syntax ?
Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-12 22:41:06
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
Title: OptimFROG suite version 4.520b available!
Post by: [proxima] on 2006-03-13 00:02:36
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.
Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-13 00:46:07
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
Title: OptimFROG suite version 4.520b available!
Post by: Skymmer on 2006-03-15 16:34:26
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
Title: OptimFROG suite version 4.520b available!
Post by: matthiasb on 2006-03-16 09:19:15
@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 (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
Title: OptimFROG suite version 4.520b available!
Post by: ghido on 2006-03-16 11:14:29
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] (http://index.php?act=findpost&pid=371736")

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
Title: OptimFROG suite version 4.520b available!
Post by: JohanDeBock on 2006-03-16 11:32:37
Updated the OptimFROG entry on my website http://uclc.info (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 .
Title: OptimFROG suite version 4.520b available!
Post by: matthiasb on 2006-03-16 14:49:22
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
Title: OptimFROG suite version 4.520b available!
Post by: Skymmer on 2006-03-16 22:38:28
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.
Title: OptimFROG suite version 4.520b available!
Post by: rutra80 on 2006-03-21 00:12:38
/me is waiting for foo_ofr.dll compiled for fb2k 0.9
Title: OptimFROG suite version 4.520b available!
Post by: wisodev on 2006-03-30 07:10:00
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.
SimplePortal 1.0.0 RC1 © 2008-2020