OptimFROG foobar2000 0.9.x plug-in available!, OptimFROG Lossless/DualStream Audio Compressor Options

[ghido]

Hello,

Just wanted to let you know that a fully functional OptimFROG input plug-in for foobar2000 0.9.x (rewritten from scratch) is finally available (including the source code) on the OptimFROG site at

http://www.LosslessAudio.org

or directly at

http://www.LosslessAudio.org/DownloadNew/f...ut_ofr_120b.php

Also, the new promised experimental version, although delayed a bit due to some fine tuning and testing, it is now very close to being publicly released...

Thanks,
Florin Ghido

This post has been edited by ghido: May 17 2006, 01:03

[JohanDeBock]

Thanks, looking forward to test the new version.

[shadowking]

Problem transcoding to OFS or OFR via foobar 9.1 :

Weird bitrates (12k) and cannot seek. Works perfectly when using speek frontend.

Can someone try foobar 9.1 converter and advise ?


thanks

[rutra80]

You'll probably find solution in this topic.

This post has been edited by rutra80: May 17 2006, 13:32

[ghido]

Problem transcoding to OFS or OFR via foobar 9.1 :

Weird bitrates (12k) and cannot seek. Works perfectly when using speek frontend.

Can someone try foobar 9.1 converter and advise ?


thanks

This problem is due to foobar2000 0.9.x sending an INVALID wav header content. Previous versions (like 0.8.x) had a setting named "encoder requires accurate length", which worked well.

foobar2000 sets an invalid length in the wav header content such that the resulted file will be able to hold exactly 2^31-1 bytes (the maximum safe size limit for 32 bit files), which translates to a length of 3h:22m:53.943s for the CD Audio format.

OptimFROG has a full wave/riff parser (with odd chunks auto detection) and in fact it ends with an unexpected input EOF error, as the input data ends before what was specified in the header.

I am thinking how to implement a "not so ugly" workaround for use with foobar2000. However, note that (as for all the encoders which save the riff chunks - so they are lossless with regard to the file, not only to the audio data), the decoded wav file will be still invalid (but the ofr will be ok) due to the information in the riff chunks (will show incorrect length).

Meanwhile, you can alternatively use for CD Audio format the settings "--encode --raw --headersize 44 - --output %d" (eventually specifying manually the format if different), or better use "%s" instead of "-" (which creates a temporary file).

In my opinion, I think the right thing would be that foobar2000 to have parameters like samplerate (integer), bitdepth (integer), and channels (integer), (e.g. %s, %b, and %c) so that they could be passed to the encoder and then send raw data (selectable) through the pipe to the encoder.

I fully agree that it is very difficult to compute in advance the number of samples in foobar2000, but I hope we will have in the future a better solution than the current hack (reporting maximum length in the wav header, and then closing the pipe when actual data ends).

Please let me know if you have other ideas...

Thanks,
Florin Ghido

[Peter]

This problem is due to foobar2000 0.9.x sending an INVALID wav header content. Previous versions (like 0.8.x) had a setting named "encoder requires accurate length", which worked well.

Previous versions would also break when actual length of source file was different from reported length. While it sounds unbelievable, there are major formats (such as WMA lossless) that can't accurately report file duration without performing a full decode. Because about every encoder handles "truncated" WAV files, we decided to simulate this behavior. Alternatively, you can go through temporary files to get accurate length signaled in headers.

[shadowking]

Thanks for the info Florin & Peter. I came up with a commandline for FB 9.1 that works:

--encode %s --output %d

[RiCON]

Hi.

Anyone have any idea when a 0.9.4.2 OptimFROG plug-in will be available?

EDIT:
Nevermind.
It's still compatible with 0.9.4.2.
Sorry for the stupid question.

This post has been edited by RiCON: Dec 26 2006, 00:15