Sox command line to downsample Pcm to Flac Options

[andrewfg]

Can anyone please tell me the switches needed for downsampling hi-res Pcm (Std_In) to lo-res Flac (Std_Out)?

I am trying the following, but at 192000Hz neither the big nor little endian variety works.

CODE

sox.exe -q -t raw -s -b24 -c2 -r192000 -L - -t flac -C0 - rate 48000 => outputs distorted audio
sox.exe -q -t raw -s -b24 -c2 -r192000 -B - -t flac -C0 - rate 48000 => outputs white noise

Whereas (oddly enough) at 96000Hz the little endian works, but the big endian does not.

CODE

sox.exe -q -t raw -s -b24 -c2 -r96000 -L - -t flac -C0 - rate 48000 => works !!
sox.exe -q -t raw -s -b24 -c2 -r96000 -B - -t flac -C0 - rate 48000 => outputs white noise

Don't ask me why, but the fact that at 96000Hz an extra byte order flip makes a difference to the success rate, gives me a gut feeling that sox.exe is somehow hitting an internal timing issue or lack of CPU capacity (e.g. thread timing issue?).

[chi]

Are you using -rate and expecting that to resample?

No, that’s OK as it is. It is not the -r or --rate option, but “-” (standard input/output) and “rate”, the resampling effect, with a space between them.

I am working with four different source types: 2-ch, 24-bit, linear signed integer, big or little endian, 192000 or 96000Hz. The different sets of command line switches in my OP reflect those four source types.

Are you sure about those parameters? Did you, e.g., try to read what you expect to be big-endian as little-endian?

The incoming audio is being delivered from remote audio servers through a TCP socket connection via HTTP; my Whitebear application fetches those streams and squirts them into sox.exe for transcoding through its Std_In pipe.

Is it possible that processing is too slow for 192 kHz input, and that buffers are dropped by the framework?

It sounds more like sox.exe is throwing audio samples in a box, jumbling them around, and taking them out again in an order that is close to, but not identical to, the correct order; or something like that... (I could send you one of them if you need it...)

I should perhaps add that I have no problems when not trying to down-sample the audio. If I take one of my raw stream (any of the above-mentioned four formats) and convert it to flac at the same rate, then the resulting flac plays fine. However if I take the exact same raw stream and (try to) convert it to flac down-sampled to 48000Hz (or 44100Hz) then, as described in my OP, the resulting flac either plays white noise, or munged audio. In other words the problem is set off by adding the "rate 48000" effects switch at the end of the command line...

CODE

sox.exe -q -t raw -s -b24 -c2 -r192000 -L - -t flac -C0 - rate 48000 => resulting flac plays white noise, or munged audio
sox.exe -q -t raw -s -b24 -c2 -r192000 -L - -t flac -C0 - => resulting flac plays fine

This would fit with it being a load problem (the resampling needing more processor resources). You could try if the 96k case stops working when you add some computationally expensive effect(s), like “sinc”. Otherwise, yes, a sample of the affected audio might be useful.