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 29118 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

OptimFROG suite version 4.520b available!

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/.

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/

Thank you again,
Florin Ghido

OptimFROG suite version 4.520b available!

Reply #1 –
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

OptimFROG suite version 4.520b available!

Reply #2 –
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
Mit freundlichen Grüßen aus Österreich, Matthias

OptimFROG suite version 4.520b available!

Reply #3 –
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

OptimFROG suite version 4.520b available!

Reply #4 –
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.
Mit freundlichen Grüßen aus Österreich, Matthias

OptimFROG suite version 4.520b available!

Reply #5 –
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/
; -----------------------------------------------------
; ENCODER = ofs.exe
; PARAMETERS = --correction "@source@"

OptimFROG suite version 4.520b available!

Reply #6 –
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?
Microsoft Windows: We can't script here, this is bat country.

OptimFROG suite version 4.520b available!

Reply #7 –
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]


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.

OptimFROG suite version 4.520b available!

Reply #8 –
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.
Microsoft Windows: We can't script here, this is bat country.

OptimFROG suite version 4.520b available!

Reply #9 –
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?

OptimFROG suite version 4.520b available!

Reply #10 –
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?

OptimFROG suite version 4.520b available!

Reply #11 –
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

OptimFROG suite version 4.520b available!

Reply #12 –
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).

OptimFROG suite version 4.520b available!

Reply #13 –
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).

OptimFROG suite version 4.520b available!

Reply #14 –
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

OptimFROG suite version 4.520b available!

Reply #15 –
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?

OptimFROG suite version 4.520b available!

Reply #17 –
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

OptimFROG suite version 4.520b available!

Reply #18 –
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?
They have an Apple Mac G4 running Mac OS 10.2

OptimFROG suite version 4.520b available!

Reply #19 –
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?
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

OptimFROG suite version 4.520b available!

Reply #20 –
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.

OptimFROG suite version 4.520b available!

Reply #21 –
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.

OptimFROG suite version 4.520b available!

Reply #22 –
Quote
True. But I want to restrict the user from cd out off his home directory.[{POST_SNAPBACK}][/a]


[a href="http://www.schwie.com/brad/macosxsftpchroot/]http://www.schwie.com/brad/macosxsftpchroot/[/url]

OptimFROG suite version 4.520b available!

Reply #23 –
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

OptimFROG suite version 4.520b available!

Reply #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.