Innaccurate lengths with 0.9's converter Options

[Cyaneyes]

I ran into a frustrating situation today converting some FLAC to Optimfrog..

I was using foobar 0.9 since I have a dual core CPU and it's much faster/more convenient to do the conversion.. but when I looked at the resulting ofr files with foobar 0.8.3 they all had incorrect lengths reported (much too long). It's not just foobar reading them wrong either, ofr.exe runs into an unexpected end of file when they are decoded.

I was using the same command line as I had in 0.8.3, namely "--encode --mode extranew --md5 --recovery --time - --output %d" which still works perfectly in 0.8.3.

Is there something I need to add to get accurate lengths with 0.9's converter? I see the "Encoder requires accurate length" checkbox is gone from the previous foobar.

[Peter]

You need to encode through temp files (%s) instead of stdin. This simply can't be fixed with stdin because length of source file is not always known accurately without having decoded entire file in advance; encoders should expose additional switches to handle "truncated" WAV files like wavpack does.

[sony666]

Sorry for the revival, but this is interesting.

Do you recommend using tempfiles for all commandline encoders (especially LAME), or only OFR?
Or only under certain circumstances, like exporting a large cue/wav to single mp3s which I do often.

thanks

[rutra80]

AFAIK: tempfiles should be used only with encoders which require source's accurate lenght, these are optimfrog & wavpack only (though in case of wavpack you can use the -i swith for piping). You can safely use pipes with LAME and everything else.
BTW Peter, any chance to have an option which would decode files to memory before encoding? It would be faster than tempfiles and no disk space would be wasted.

This post has been edited by rutra80: Apr 25 2006, 19:53

[sony666]

aha thanks

[rutra80]

There's a workaround for piping into OFR via fb2k v0.9 converter - use "--raw --headersize 44" combination. The problem is that it will work only with input files which have CDDA parameters (raw mode defaults to them). For other files you need separate Converter entries with addidtional switches like "--channelconfig", "--rate", etc.

I have some additional good news:

• foo_ofr.dll for fb2k v0.9 should be ready in a week or two (with support for embedded cuesheets perhaps)
• there's a ray of hope that next versions of OptimFROG will have a switch equivalent to WavPack's -i switch

This post has been edited by rutra80: May 7 2006, 21:09

[Mr_Rabid_Teddybe...]

AFAIK: tempfiles should be used only with encoders which require source's accurate lenght, these are optimfrog & wavpack only (though in case of wavpack you can use the -i swith for piping). You can safely use pipes with LAME and everything else.
BTW Peter, any chance to have an option which would decode files to memory before encoding? It would be faster than tempfiles and no disk space would be wasted.

Pretty useless information, but for the sake of completion: Shorten also requires "accurate length", or the files get corrupted headers.