Converter: problem piping to speexenc Options

[romor]

I tried speex for some of my audiobooks and very satisfied with the results. Speexdrop works fine, so does CLI, but I have problem with foobar converter (latest speexenc from rarewares)

Example parameter setting: -w --vbr - %d

Problem:

Encoder stream format: 32000Hz / 1ch / 16bps
Command line: "C:\Program Files\encoders\speexenc.exe" -w --vbr - "out.spx"
Working folder: C:\temp\audiobooks\
An error occurred while writing to file (The encoder has terminated prematurely with code 0 (0x00000000); please re-check parameters)

Now if I use temporary input file "%s" instead pipe "-", conversion is done fine, but not on the fly. However speexenc accepts piping just fine:

CODE

sox in.wav -p | speexenc.exe -w --vbr -V - out.spx

Any comments?

[eleria]

I'm having the same exact error with Tak encoding in foobar.

When I open the folder I see the output file being written but then at the end of the conversion (100%) the output file disappears and BAM "An error occurred while writing to file".
I use Windows 7 with disabled UAC and foobar 1.0 . Tried with older version of Foobar and same result!

Oh and everything works when I use a temporary input file %s instead of pipe "-" though it's not as fast

This post has been edited by eleria: Mar 30 2011, 12:37

[kode54]

Is the Speex encoder designed to accept weird WAV files? Foobar2000 emits piped WAV files with a 0xFFFFFFFF length for both the RIFF chunk and the data chunk, since knowing the lengths ahead of time would require decoding the files twice, as the reported lengths on some files are not exact, or may even be rounded. (For instance, WMA, due to limitations of the ASF container, reports lengths rounded down to the nearest millisecond. Even WMA Lossless.)

[lvqcl]

TAK encoding works fine. Parameters: "-e -p2 -silent -ihs - %d"

[romor]

Is the Speex encoder designed to accept weird WAV files? Foobar2000 emits piped WAV files with a 0xFFFFFFFF length for both the RIFF chunk and the data chunk, since knowing the lengths ahead of time would require decoding the files twice, as the reported lengths on some files are not exact, or may even be rounded.

I don't know such technicalities, but am curious how does speexenc handle sox piping then. And it's not only sox - output from other decoders (like flac.exe etc) which supports writing to stdout is handled just fine

[romor]

Re-reading this it seems that my previous post doesn't say anything, as decrypting kode54' post again if seems that foobar output pipe is limited by supporting some formats (like mentioned WMA) and it must report weird data length to piped end
However majority of encoders does not have issue with this, suggesting that speexenc should handle this situation the same way if possible

Hope it's more clear to those concerned