Hydrogenaudio Forums > Problem with sox <--> speexenc

Full Version: Problem with sox <--> speexenc

Hydrogenaudio Forums > Lossy Audio Compression > Speech Codecs

schlauf

Oct 13 2004, 10:54

Hi there,

today I wrote a little batch file in order to simplify my speex encodings done from EAC (audiobooks). It is called from within EAC and contains the following command line:

CODE

@n:\sox\sox.exe %1 -r 16000 -c 1 -V -t .wav - resample | n:\speex\speexenc.exe -w --quality 10 --vbr --vad --dtx --comp 10 -V - %2

This should downsample to 16kHz and reduce channels to mono, then encode with "high quality" speex settings.

When run, everything works as usual, but when I play the resulting .spx file, I only get distorted sound without recognizing the original. What is wrong?

Thanks in advance,

Michael

PS: BTW, I heard rumours that applying a lowpass filter before encoding with speex could result in better quality, is that true? If so, at what frequency should be cut off?

Ariakis

Oct 13 2004, 11:28

Well, about the quality... are you actually sending speech only, or music? Because Speex's VBR is designed for voice and therefore performs horribly on music. Nowhere near as well as its CBR at the same bitrate.

schlauf

Oct 13 2004, 12:02

of course, pure speech (as I said: audiobook) ....

My guess would be that anything with the piped output as I'm used to do it from Un*x systems mangles up the output on my Windows system, but I cannot find anything wrong with it, actually ...

schlauf

Oct 13 2004, 17:43

Interesting ... I just found out the following: when splitting the command from above - quoted here, again -

CODE

@n:\sox\sox.exe %1 -r 16000 -c 1 -V -t .wav - resample | n:\speex\speexenc.exe -w --quality 10 --vbr --vad --dtx --comp 10 -V - %2

CODE

@n:\sox\sox.exe %1 -r 16000 -c 1 -V -t .wav -TEMP.WAV resample
@n:\speex\speexenc.exe -w --quality 10 --vbr --vad --dtx --comp 10 -V TEMP.WAV %2

everything works perfectly. But, since both programs officially support piped input/output, I'd like to dispose of this workaround and get it working with real piped data .... what is it I'm doing wrong?

schlauf

Oct 13 2004, 19:03

In the same context, I found

CODE

@n:\applic~1\sox\sox.exe -V %1 -t raw -u -w -s -c 1 - avg | n:\applic~1\sox\sox.exe -V -t raw -r 44100 -u -w -s -c 1 - -r 16000 -t .wav - polyphase

not to work as expected, although each of the statements executed after another via temporary files worked just fine. What is it that I do not understand about pipes in Windows??

Oct 14 2004, 03:13

Well, stock sox has problems with reading from stdin on Windows, still should output to stdout w/o problems, afaik.
Maybe try the build from http://shnutils.freeshell.org/shntool/ if it sorts things out.

schlauf

Oct 14 2004, 05:26

QUOTE(ak @ Oct 14 2004, 11:13 AM)

Thanks a lot, the modified SoX works just fine ;-) Since I'm interested in the technical reason why one compile works and the other one doesn't, do you have an idea why this behaviour occurs?

Oct 14 2004, 05:44

Not really.
Well stdin works because of a patch (at shntool page), why doesn't stdout work in the build you used, no idea, what version was it btw?
If you get one from sf.net ( http://prdownloads.sourceforge.net/sox/sox12176.zip?download ), it should work as well, except maybe stdin.

schlauf

Oct 14 2004, 05:53

QUOTE(ak @ Oct 14 2004, 01:44 PM)

what version was it btw?
If you get one from sf.net ( http://prdownloads.sourceforge.net/sox/sox12176.zip?download ), it should work as well, except maybe stdin.

Up to now I had tried with the latest version from SF .... so actually this version is still buggy, too.

Yesterday I filed in a bug report, hopefully it will help developers ....

Thanks again,

Michael

kode54

Oct 14 2004, 23:44

On Win32, stdin and stdout must be set to binary mode for pipes to work properly:

CODE

setmode(fileno(stdin), O_BINARY)
setmode(fileno(stdout), O_BINARY)

At least, minigzip.c does this on Win32, cygwin, OS/2, and MSDOS. You could try adding those lines at the relevant places in sox and recompiling. Or, at least, reporting this as a bug. I'm not sure how this is affected by different versions of Microsoft's C run-time.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.