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/ (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)
Whoa ! I am so glad Ghido is back.
Great news
I was absolutely sure that Windows on ARM was going to be the news of the year, now I see I was wrong.
Great!
So who will be the first to benchmark it?
Ugh, Bit comparison results are Differences found (Length mismatch) using pipes for lossless trancecoding
Foobar2000 settings 1 (
with --incorrectheader):
--encode --mode bestnew --incorrectheader --raw - --output %d
Result 1:
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):
--encode --mode bestnew --raw - --output %d
Result 2:
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.
Your settings are wrong. You can't use --raw when encoding WAV files.
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:
--encode --mode bestnew --silent --md5 --incorrectheader --raw - --output %d
Comparing 1:
Length mismatch : 3:00.386667 vs 3:00.386916, 7955052 vs 7955063 samples
Settings 2:
--encode --mode bestnew --silent --md5 --incorrectheader - --output %d
can not encodeSettings 3:
--encode --mode bestnew --silent --md5 --raw - --output %d
Comparing 3:
Length mismatch : 3:00.386667 vs 3:00.386916, 7955052 vs 7955063 samples
Settings 4:
--encode --mode bestnew --silent --md5 - --output %d
can not encodeDo you have any ideas? (Sorry, my poor english.)
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.
I'm also having trouble with pipe encoding from foobar2000. Here are my parameters: --encode --incorrectheader --mode highnew - --output %d
And the response...
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...
I reported same foobar behaviour with Speex encoder: http://www.hydrogenaudio.org/forums/index....showtopic=86579 (http://www.hydrogenaudio.org/forums/index.php?showtopic=86579)
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
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.
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
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
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.
Tested 2 more tracks:
Funkadelic - Maggot Brain
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
size(B) time(s)
uncompressed 50791484 0
ofr v4.600ex 31223277 673.171
ofr 4.910b 31219121 857.828
tak 2.0 31828198 0
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.
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
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 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.
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
doh! I had read the Hexadecimal representation as the data coming after the data tag. Sorry for my confusion too.
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:
--encode --mode high --silent --md5 --incorrectheader --raw --headersize 44 - --output %d
And both the original and duplicate passed the bit comparison test...
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.
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=44706&view=findpost&p=393273)
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.
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.
Hi!
I tested a little with TAK.
OptimFrog with --mode fast --optimize fast options sometimes better than TAK -p4m -cpuMMX.
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%
Ok. Now I tested with a single album (Arch Enemy - Rise Of The Tyrant).
Results:
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 ).
RE: Monkey's Audio and its reliability
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've since found out that Monkey's Audio supposed lack of error robustness just isn't true:
http://www.hydrogenaudio.org/forums/index....st&p=434126 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=48642&view=findpost&p=434126)
http://www.hydrogenaudio.org/forums/index....st&p=498272 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=55528&view=findpost&p=498272)
Of course, the ideal setting with that codec is -c3000. Best balance between compression, decompression and playback. The equivalent setting in OptimFROG? The total opposite is the case.
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:
--encode --mode high --silent --md5 --incorrectheader --raw --headersize 44 - --output %d
And both the original and duplicate passed the bit comparison test...
But witch command is for 24 bit files and different sample rates. eg 24/96
EDIT: Solved. For 24/96
--encode --mode high --silent --md5 --incorrectheader --raw --headersize 44 --sampletype SINT24 --rate 96000 - --output %d
No differences in decoded data found.
I have another question. When ofr.exe encode DTS CD wav, playback is noise. Same is in Takc.exe. WavPack and FLAC works with DTS CD.
This is what is changed in WAV header after decode from OFR.
Original DTS CD WAV header
(http://img692.imageshack.us/img692/5803/originalkg.png)
Decoded
(http://img593.imageshack.us/img593/9935/decoded.png)
so, what will be command line for dts cd wav. OptimFrog is best compressor for strong wide range noise.
And what's the length of the original and decoded files?
Same lenght, same number of samples. Bit compare tells: No differences in decoded data found. Only playback is problem. I have dts decoder in foobar. But when playing OFR its strong noise.
Same lenght, same number of samples. Bit compare tells: No differences in decoded data found.
This is strange, because the only difference between those headers is the size of audio data (i.e. number of samples).
Only playback is problem. I have dts decoder in foobar.
And
this is not strange: OFR plugin doesn't support postprocessing that is required by newer DTS decoder plugin. You can use older foo_input_dts ver. 0.2.8.
21 Jun 2015
After an exceedingly long apparent pause, the OptimFROG 5.000 stable release is finally ready! It is the result of a large number of internal code updates and improvements, featuring several new supported platfroms, SSE2 enabled builds, a fully new unified license, updated SDK, updated documentation, and updated website content. You can check all the new release packages on the Downloads page and the comprehensive list of changes on the Changes page.
http://www.losslessaudio.org/News.php (http://www.losslessaudio.org/News.php)
http://www.hydrogenaud.io/forums/index.php?showtopic=109553 (http://www.hydrogenaud.io/forums/index.php?showtopic=109553) ?
I wonder why it's stuck in "news submissions"
Oops. Somehow I missed it completely. Thanks, ChronoSphere.