OptimFROG version 4.910b [2011-02-10] Options

[madoka@ex-sounds]

I was really surprised

New release* (stable beta) for OptimFROG Lossless, DualStream, and IEEE Float, SFX module, and SDK:
OptimFROG_All_Windows_x86_4910b.zip (691 kB)
Updated input plug-in for foobar2000 v1.1.x, with cue sheet support (source code included):
foo_input_ofr_130.zip (250 kB)
* Release for all the other supported platforms within two weeks.

URL: http://losslessaudio.org/

Change Log:

What is new in this version (4.910b):
- fully backward compatible with previous versions
- slightly better compression for highnew, extranew, bestnew modes, and also for --maximumcompression
- parsing WAV files with invalid data chunk size in WAV header using --incorrectheader (for foobar2000 and other command line format converters using pipes who cannot compute the WAV file length in advance and generate a 4 GB header instead)
- many internal source code improvements

- [other] updated foobar2000 input plug-in for foobar2000 1.1.x
- [other] updated OptimFROG SDK to version 1.300 (included here)

[shadowking]

Whoa ! I am so glad Ghido is back.

[Steve Forte Rio]

Great news

[_m²_]

I was absolutely sure that Windows on ARM was going to be the news of the year, now I see I was wrong.

Great!

[_m²_]

So who will be the first to benchmark it?

[madoka@ex-sounds]

Ugh, Bit comparison results are Differences found (Length mismatch) using pipes for lossless trancecoding

Foobar2000 settings 1 (with --incorrectheader):

CODE

--encode --mode bestnew --incorrectheader --raw - --output %d

Result 1:

CODE

Comparing:
"Z:\music\[JAZZ]\JOHN COLTRANE & JOHNNY HARTMAN they say it's wonderful.tak"
"E:\[music temp]\JOHN COLTRANE & JOHNNY HARTMAN they say it's wonderful.ofr"
Length mismatch : 5:21.173333 vs 5:21.173583, 14163744 vs 14163755 samples

Foobar2000 settings 2 (without --incorrectheader):

CODE

--encode --mode bestnew --raw - --output %d

Result 2:

CODE

Comparing:
"Z:\music\[JAZZ]\JOHN COLTRANE all or nothing at all.tak"
"E:\[music temp]\JOHN COLTRANE all or nothing at all.ofr"
Length mismatch : 3:35.293333 vs 3:35.293583, 9494436 vs 9494447 samples

My settings are wrong or ???

EDIT: sorry, my poor english.

This post has been edited by madoka@ex-sounds: Feb 14 2011, 18:11

[Case]

Your settings are wrong. You can't use --raw when encoding WAV files.

[madoka@ex-sounds]

Your settings are wrong. You can't use --raw when encoding WAV files.

Case, thank you for advice

But I could not encode without --raw. And I tried encoding WAV files with --raw, but still Bit comparison results are Differences found (Length mismatch) using pipes

Settings 1:

CODE

--encode --mode bestnew --silent --md5 --incorrectheader --raw - --output %d

Comparing 1:

CODE

Length mismatch : 3:00.386667 vs 3:00.386916, 7955052 vs 7955063 samples

Settings 2:

CODE

--encode --mode bestnew --silent --md5 --incorrectheader - --output %d

can not encode

Settings 3:

CODE

--encode --mode bestnew --silent --md5 --raw - --output %d

Comparing 3:

CODE

Length mismatch : 3:00.386667 vs 3:00.386916, 7955052 vs 7955063 samples

Settings 4:

CODE

--encode --mode bestnew --silent --md5 - --output %d

can not encode

Do you have any ideas? (Sorry, my poor english.)

[db1989]

It looks as though Case is on the right track. Note the magnitude of the mismatch in each case: 11 samples.

11 samples x 2 channels x 16 bits = 44 bytes = the size of the WAV header, which would be read as audio if --raw is enabled.

[eevan]

I'm also having trouble with pipe encoding from foobar2000. Here are my parameters: --encode --incorrectheader --mode highnew - --output %d
And the response...

CODE

Source: "H:\Music\Kuenstliche Welten.flac"
  An error occurred while writing to file (The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters) : "H:\Music\Kuenstliche Welten.ofr"
  Additional information:
  Encoder stream format: 44100Hz / 2ch / 16bps
  Command line: "C:\Program Files\foobar2000\Codecs\ofr.exe" --encode --incorrectheader --mode highnew - --output "Kuenstliche Welten.ofr"
  Working folder: H:\Music\

Encoding via temporary file (%s) works ok...

[romor]

I reported same foobar behaviour with Speex encoder: http://www.hydrogenaudio.org/forums/index....showtopic=86579

[madoka@ex-sounds]

It looks as though Case is on the right track. Note the magnitude of the mismatch in each case: 11 samples.

11 samples x 2 channels x 16 bits = 44 bytes = the size of the WAV header, which would be read as audio if --raw is enabled.

This is a very interesting comment
I'll try other files next weekend.

thank you

[Case]

It seems --incorrectheader option isn't working as it should. The encoder still errors out with message "description: size of data is too large". You must use temporary files until the option is fixed.

[_m²_]

Since nobody was willing to test ofr, I did a quick and dirty benchmark.
Used settings:
--bestnew --optimize best --experimental

File 1, Behemoth - Slaves Shall Serve

CODE

             size(B)  time(s)
uncompressed 32594060 0
ofr v4.600ex 23657409 519.390
ofr 4.910b   23662345 593.375
tak 2.0      23859687 0

File 2, Felix Nowowiejski - Organ Symphony VI op. 45 No. 6: Intermezzo

CODE

             size(B)  time(s)
uncompressed 41644556 0
ofr v4.600ex 10048455 666.468
ofr 4.910b   10018654 662.390
tak 2.0      10601201 0

Obviously it's nowhere near representative, but nevertheless I have mixed feelings.

This post has been edited by _m²_: Feb 15 2011, 21:38

[_m²_]

Tested 2 more tracks:
Funkadelic - Maggot Brain

CODE

             size(B)  time(s)
uncompressed 109172780 0
ofr v4.600ex  53109679 1568.843
ofr 4.910b    53026835 1452.750
tak 2.0       53972701 0

Seal - Kiss from a Rose

CODE

             size(B)  time(s)
uncompressed 50791484 0
ofr v4.600ex 31223277 673.171
ofr 4.910b   31219121 857.828
tak 2.0      31828198 0

[bbrabant]

I also tried Optimfrog pipe encoding with foobar.
I encoded a 44100 hz 16 bit wav to ofr with --mode fast --raw --incorrectheader --output %d. Then decoded the ofr back to wave and compared this wave to the original wave.
The two waves were not identical.
I examined both wave headers with a hex editor. The first (original) wave has a 36 bytes header and the second wave has a 60 bytes header. The audio data is the same in both files only the headers are different.

CODE

Original wave header
RIFF¤«}.WAVEfmt ........D¬...±......data
52 49 46 46 A4 AB 7D 02 57 41 56 45 66 6D 74 20 10 00 00 00 01 00 02 00 44 AC 00 00 10 B1 02 00 04 00 10 00 64 61 74 61

Decoded wave header
RIFF¼«}.WAVEfmt (...þÿ..D¬...±......................€..ª.8›qdata
52 49 46 46 BC AB 7D 02 57 41 56 45 66 6D 74 20 28 00 00 00 FE FF 02 00 44 AC 00 00 10 B1 02 00 04 00 10 00 16 00 10 00 03 00 00 00 01 00 00 00 00 00 10 00 80 00 00 AA 00 38 9B 71 64 61 74 61

I also used EAC3to to pipe the wave to optimfrog and I got the same result. The two wave headers were different.
Only by using the -simple command with EAC3to the two wave headers were identical.
Somehow the wave header is changed with optimfrog pipe encoding.

Don't know if this behavior is by design. My understanding of lossless audio encoding is that the resulting wave has to be same as the original wave.
So I hope this header issue can be fixed.

Greetings,

Ben

[[JAZ]]

This looks worse than anticipated. The difference in the header is probably just the fact that it exports with a WAVEFORMATEXTENSIBLE and the original has a WAVEFORMATEX. That's nothing to worry about,

But the part after "data" is the actual audio, and there are differences! (and curious ones at that), see the 01 00 swapped by FE FF (sign shift?)
And the 6th byte, A4 to BC

This post has been edited by [JAZ]: Feb 16 2011, 21:09

[soiaf]

This looks worse than anticipated. The difference in the header is probably just the fact that it exports with a WAVEFORMATEXTENSIBLE and the original has a WAVEFORMATEX. That's nothing to worry about,

But the part after "data" is the actual audio, and there are differences! (and curious ones at that), see the 01 00 swapped by FE FF (sign shift?)
And the 6th byte, A4 to BC

That change of the 5th byte is indeed expected, its to show that the total size of the file (including header) is larger. BC = 188, A4 = 164, (188 - 164) = 24
24 is the difference in size between the original header and the newly generated header.

The FE FF is just part of the new header, not actual data.

[bbrabant]

This looks worse than anticipated. The difference in the header is probably just the fact that it exports with a WAVEFORMATEXTENSIBLE and the original has a WAVEFORMATEX. That's nothing to worry about,

I also checked how TAK is handling the wave header with pipe encoding in foobar. Tak also reconstructs the wave header when it decodes the tak archive back to wave.
Tak seems to write the waveformatex header which is the same as the original wave, so I did not notice the difference before.

As I stated before only the wave headers are different with optimfrog. The audio data is the same in all cases, with or without pipe encoding.
With pipe encoding the wave header has to be reconstructed and that is why the headers are different.
My apologies, there is no need for a fix.

greetings,

Ben

[[JAZ]]

doh! I had read the Hexadecimal representation as the data coming after the data tag. Sorry for my confusion too.

This post has been edited by [JAZ]: Feb 17 2011, 19:17

[RazorBoy143]

I solved the problem by using the --headersize option to specify that the wave header size should be 44. So my foobar2000 command line ended up looking like this:

CODE

--encode --mode high --silent --md5 --incorrectheader --raw --headersize 44 - --output %d

And both the original and duplicate passed the bit comparison test...

CODE

All tracks decoded fine, no differences found.

Comparing:
"C:\Downloads\Keith Urban - Defying Gravity (2009)\01. Kiss a Girl.tak"
"C:\Documents and Settings\Default User\My Documents\My Music\01 - Kiss a Girl.ofr"
No differences in decoded data found.

...and both CRC and MD5 tests.

CODE

Item: "C:\Downloads\Keith Urban - Defying Gravity (2009)\01. Kiss a Girl.tak"
MD5: 6D5F53CF747872BFF68E5FFE3EE6E09B
CRC32: E9DA2CEB
No problems found.

Item: "C:\Documents and Settings\Default User\My Documents\My Music\01 - Kiss a Girl.ofr"
MD5: 6D5F53CF747872BFF68E5FFE3EE6E09B
CRC32: E9DA2CEB
No problems found.


All items decoded successfully.

I got the info from a post Optimfrog's developer posted here:

http://www.hydrogenaudio.org/forums/index....st&p=393273

[RazorBoy143]

Checked the CPU usage while OptimFROG tracks were playing within foobar2000:

1) Fast
2) Normal
3) High
4) Extra

CPU usage was either barely even there or non-existent with these settings. On balance, very efficient with compression & speed. But the last three?

5) HighNew
6) ExtraNew
7) BestNew

With the HighNew setting, I found that, on my system, CPU usage for foobar2000 rose to around 20% - 25%. By the time I got to the BestNew setting, It got into a range of 50% - 70% and above. Compression times? For HighNew, it took 15 minutes for an 11 track album, and increased to 30 minutes using the BestNew setting. That's why I wasn't surprised when I had gapless playback problems, either.


In terms of file size, using the Extra setting would be the same you'd get by using TAK 4 Max, but it'd double your compression time. So, speed-wise, I found I was better off using OptimFROG's High setting. Same compression time, and it only cost me 1MB more in total album size. It also saved 3MB more space compared to Monkey's Audio at the High setting while achieving the same compression speed. Reliability? It's up there with FLAC, TAK, WavPack, and definitely is a great alternative to Monkey's Audio if one wanted to switch over to OptimFROG.

[_m²_]

Checked the CPU usage while OptimFROG tracks were playing within foobar2000:

1) Fast
2) Normal
3) High
4) Extra

CPU usage was either barely even there or non-existent with these settings. On balance, very efficient with compression & speed. But the last three?

5) HighNew
6) ExtraNew
7) BestNew

With the HighNew setting, I found that, on my system, CPU usage for foobar2000 rose to around 20% - 25%. By the time I got to the BestNew setting, It got into a range of 50% - 70% and above. Compression times? For HighNew, it took 15 minutes for an 11 track album, and increased to 30 minutes using the BestNew setting. That's why I wasn't surprised when I had gapless playback problems, either.


In terms of file size, using the Extra setting would be the same you'd get by using TAK 4 Max, but it'd double your compression time. So, speed-wise, I found I was better off using OptimFROG's High setting. Same compression time, and it only cost me 1MB more in total album size. It also saved 3MB more space compared to Monkey's Audio at the High setting while achieving the same compression speed. Reliability? It's up there with FLAC, TAK, WavPack, and definitely is a great alternative to Monkey's Audio if one wanted to switch over to OptimFROG.

I'm using bestnew, optimize-best, experimental. I encoded ~50-100 albums (different genres), checking savings after each of them, though I don't log them and I believe the average is amount saved is around 2% (TAK p4m=100%), varying greatly from little under 1% to ~15% with most albums being in 1%-2.5% range.
BTW it shows futility of single file or even single album tests. You can accidentally find one on which savings are way different from average.

This post has been edited by _m²_: Mar 15 2011, 08:14

[Mardel]

Hi!

I tested a little with TAK.

OptimFrog with --mode fast --optimize fast options sometimes better than TAK -p4m -cpuMMX.

CODE

D:\fb2k\bin\TAK>takc -e -p4m "Beast Of Man.wav"
Beast Of Man.wav                    ..........  75.82%   12*

Compression:     75.82 %
Duration:        19.56 sec
Speed:           11.57 * real time

-----------------------------------------------------------------------------------------------

D:\fb2k\bin\TAK>takc -e -p4m -cpuMMX "Beast Of Man.wav"
Beast Of Man.wav                    ..........  75.82%   12*

Compression:     75.82 %
Duration:        18.52 sec
Speed:           12.22 * real time

===============================================================================================

D:\fb2k\bin\ofr>ofr --encode --mode fast --time "Beast Of Man.wav" --output "Beast Of Man_fast.ofr"

srcFile: <Beast Of Man.wav>
dstFile: <Beast Of Man_fast.ofr>
Compressing   done.
Elapsed time:     11.375 s
-----------------------------------------------------------------------------------------------
D:\fb2k\bin\ofr>ofr --encode --mode fast --optimize fast --time "Beast Of Man.wav" --output "Beast Of Man_fast_optimize.fast.ofr"
Of Man.wav"

srcFile: <Beast Of Man.wav>
dstFile: <Beast Of Man_fast_optimize.fast.ofr>
Compressing   done.
Elapsed time:     10.796 s

===============================================================================================

D:\fb2k\bin\ofr>ofr --info "Beast Of Man_fast.ofr"

Filename                                         Rate Ch Bits  Duration   Ratio
Beast Of Man_fast.ofr                           44100  2   16   3m46.3s  75.71%

-----------------------------------------------------------------------------------------------

D:\fb2k\bin\ofr>ofr --info "Beast Of Man_fast_optimize.fast.ofr"


Filename                                         Rate Ch Bits  Duration   Ratio
Beast Of Man_fast_optimize.fast.ofr             44100  2   16   3m46.3s  75.71%

And the file sizes TAK p4m: 28,8 MB (30 271 597 bytes) vs. 28,8 MB (30 227 287 bytes).

And the CPU usages (on my old AMD Sempron 3200+)

TAK: 0-6% avg: 3-5%
OFR: 3-8% avg: 5-6%

OptimFrog with normal options (--mode normal --optimize fast) is good enough.

encode time 14.906 s

File size: 28,7 MB (30 149 057 bytes)

CPU usage: 3-11% avg: 7-8%

This post has been edited by Mardel: Mar 17 2011, 14:53

[Mardel]

Ok. Now I tested with a single album (Arch Enemy - Rise Of The Tyrant).

Results:

CODE

D:\fb2k\bin\TAK>takc -e -p4m -cpuMMX "CDImage.wav" "CDImage.tak"
CDImage.wav                         ..........  73.46%   11*

Compression:     73.46 %
Duration:       260.77 sec
Speed:           11.17 * real time

===============================================================================================


D:\fb2k\bin\ofr>ofr --encode --mode fast --optimize fast --time "CDImage.wav" --output "CDImage_fast_opt.fast.ofr"

srcFile: <CDImage.wav>
dstFile: <CDImage_fast_opt.fast.ofr>
Compressing   done.
Elapsed time:    152.234 s

D:\fb2k\bin\ofr>ofr --info CDImage_fast_opt.fast.ofr

Filename                                         Rate Ch Bits  Duration   Ratio
CDImage_fast_opt.fast.ofr                       44100  2   16  48m32.3s  73.70%
-----------------------------------------------------------------------------------------------

D:\fb2k\bin\ofr>ofr --encode --mode normal --optimize fast --time "CDImage.wav"
--output "CDImage_normal_opt.fast.ofr"

srcFile: <CDImage.wav>
dstFile: <CDImage_normal_opt.fast.ofr>
Compressing   done.
Elapsed time:    231.188 s

D:\fb2k\bin\ofr>ofr --info CDImage_normal_opt.fast.ofr

Filename                                         Rate Ch Bits  Duration   Ratio
CDImage_normal_opt.fast.ofr                     44100  2   16  48m32.3s  73.35%

Sizes:
Original WAV: 489 MB (513 730 940 bytes)

TAK: 359 MB (377 376 940 bytes)

OFR_fast: 361 MB (378 611 707 bytes)

OFR_normal: 359 MB (376 798 789 bytes)

I think OFR normal (opt fast) is good enough for archiving. Encode time is 30 sec faster than TAK and the decode time is good too (if you don't want to seek too much ).

This post has been edited by Mardel: Mar 17 2011, 15:49