IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
OptimFROG version 4.910b [2011-02-10]
madoka@ex-sounds
post Feb 13 2011, 06:10
Post #1





Group: Members
Posts: 92
Joined: 23-February 04
From: tokyo, japan
Member No.: 12207



I was really surprised w00t.gif

QUOTE
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:
QUOTE
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)



--------------------
<name>madoka</name>
<uri>http://codecs.ex-sounds.net/</uri>
Go to the top of the page
+Quote Post
shadowking
post Feb 13 2011, 10:18
Post #2





Group: Members
Posts: 1523
Joined: 31-January 04
Member No.: 11664



Whoa ! I am so glad Ghido is back.


--------------------
Wavpack -b450
Go to the top of the page
+Quote Post
Steve Forte Rio
post Feb 13 2011, 22:01
Post #3





Group: Members
Posts: 443
Joined: 4-October 08
From: Ukraine
Member No.: 59301



Great news w00t.gif
Go to the top of the page
+Quote Post
_m_
post Feb 14 2011, 16:24
Post #4





Group: Members
Posts: 231
Joined: 6-April 09
Member No.: 68706



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

Great!
Go to the top of the page
+Quote Post
_m_
post Feb 14 2011, 17:43
Post #5





Group: Members
Posts: 231
Joined: 6-April 09
Member No.: 68706



So who will be the first to benchmark it?
smile.gif
Go to the top of the page
+Quote Post
madoka@ex-sounds
post Feb 14 2011, 18:05
Post #6





Group: Members
Posts: 92
Joined: 23-February 04
From: tokyo, japan
Member No.: 12207



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

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


--------------------
<name>madoka</name>
<uri>http://codecs.ex-sounds.net/</uri>
Go to the top of the page
+Quote Post
Case
post Feb 14 2011, 18:55
Post #7





Group: Developer (Donating)
Posts: 2181
Joined: 19-October 01
From: Finland
Member No.: 322



Your settings are wrong. You can't use --raw when encoding WAV files.
Go to the top of the page
+Quote Post
madoka@ex-sounds
post Feb 15 2011, 05:27
Post #8





Group: Members
Posts: 92
Joined: 23-February 04
From: tokyo, japan
Member No.: 12207



QUOTE (Case @ Feb 14 2011, 09:55) *
Your settings are wrong. You can't use --raw when encoding WAV files.

Case, thank you for advice smile.gif

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 crying.gif

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


--------------------
<name>madoka</name>
<uri>http://codecs.ex-sounds.net/</uri>
Go to the top of the page
+Quote Post
db1989
post Feb 15 2011, 15:37
Post #9





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



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.
Go to the top of the page
+Quote Post
eevan
post Feb 15 2011, 16:02
Post #10





Group: Members
Posts: 537
Joined: 9-April 07
From: Belgrade, Serbia
Member No.: 42357



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


--------------------
If age or weaknes doe prohibyte bloudletting you must use boxing
Go to the top of the page
+Quote Post
romor
post Feb 15 2011, 16:57
Post #11





Group: Members
Posts: 668
Joined: 16-January 09
Member No.: 65630



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


--------------------
scripts: http://goo.gl/M1qVLQ
Go to the top of the page
+Quote Post
madoka@ex-sounds
post Feb 15 2011, 18:59
Post #12





Group: Members
Posts: 92
Joined: 23-February 04
From: tokyo, japan
Member No.: 12207



QUOTE (dv1989 @ Feb 15 2011, 06:37) *
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 ohmy.gif
I'll try other files next weekend.

thank you smile.gif


--------------------
<name>madoka</name>
<uri>http://codecs.ex-sounds.net/</uri>
Go to the top of the page
+Quote Post
Case
post Feb 15 2011, 21:10
Post #13





Group: Developer (Donating)
Posts: 2181
Joined: 19-October 01
From: Finland
Member No.: 322



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.
Go to the top of the page
+Quote Post
_m_
post Feb 15 2011, 21:37
Post #14





Group: Members
Posts: 231
Joined: 6-April 09
Member No.: 68706



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. wink.gif

This post has been edited by _m_: Feb 15 2011, 21:38
Go to the top of the page
+Quote Post
_m_
post Feb 16 2011, 10:51
Post #15





Group: Members
Posts: 231
Joined: 6-April 09
Member No.: 68706



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
Go to the top of the page
+Quote Post
bbrabant
post Feb 16 2011, 21:04
Post #16





Group: Members
Posts: 44
Joined: 4-April 07
Member No.: 42201



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............................8qdata
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
Go to the top of the page
+Quote Post
[JAZ]
post Feb 16 2011, 21:09
Post #17





Group: Members
Posts: 1754
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



ohmy.gif

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
Go to the top of the page
+Quote Post
soiaf
post Feb 16 2011, 23:01
Post #18





Group: Members (Donating)
Posts: 73
Joined: 13-May 05
From: Dublin, Ireland
Member No.: 22024



QUOTE ([JAZ] @ Feb 16 2011, 21:09) *

ohmy.gif

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.
Go to the top of the page
+Quote Post
bbrabant
post Feb 17 2011, 14:26
Post #19





Group: Members
Posts: 44
Joined: 4-April 07
Member No.: 42201



QUOTE ([JAZ] @ Feb 16 2011, 23:09) *

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
Go to the top of the page
+Quote Post
[JAZ]
post Feb 17 2011, 19:17
Post #20





Group: Members
Posts: 1754
Joined: 24-June 02
From: Catalunya(Spain)
Member No.: 2383



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
Go to the top of the page
+Quote Post
RazorBoy143
post Mar 14 2011, 14:30
Post #21





Group: Members
Posts: 28
Joined: 17-July 10
Member No.: 82340



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
Go to the top of the page
+Quote Post
RazorBoy143
post Mar 15 2011, 02:13
Post #22





Group: Members
Posts: 28
Joined: 17-July 10
Member No.: 82340



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.
Go to the top of the page
+Quote Post
_m_
post Mar 15 2011, 08:12
Post #23





Group: Members
Posts: 231
Joined: 6-April 09
Member No.: 68706



QUOTE (RazorBoy143 @ Mar 15 2011, 02:13) *
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
Go to the top of the page
+Quote Post
Mardel
post Mar 17 2011, 14:17
Post #24





Group: Members
Posts: 27
Joined: 12-March 08
Member No.: 51986



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 (30271597 bytes) vs. 28,8 MB (30227287 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 (30149057 bytes)

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

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


--------------------
Wavpack -hh or TAK -pMax
OggVorbis aoTuVb6.03 -q 4
Go to the top of the page
+Quote Post
Mardel
post Mar 17 2011, 15:47
Post #25





Group: Members
Posts: 27
Joined: 12-March 08
Member No.: 51986



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 (513730940 bytes)

TAK: 359 MB (377376940 bytes)

OFR_fast: 361 MB (378611707 bytes)

OFR_normal: 359 MB (376798789 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 laugh.gif ).

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


--------------------
Wavpack -hh or TAK -pMax
OggVorbis aoTuVb6.03 -q 4
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th July 2014 - 20:29