IPB

Welcome Guest ( Log In | Register )

Sox command line to downsample Pcm to Flac
andrewfg
post Nov 18 2012, 23:06
Post #1





Group: Members
Posts: 84
Joined: 12-May 08
Member No.: 53478



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?).


--------------------
AndrewFG (Whitebear -- http://www.whitebear.ch/mediaserver )
Go to the top of the page
+Quote Post
 
Start new topic
Replies
chi
post Nov 21 2012, 02:38
Post #2





Group: Members
Posts: 45
Joined: 27-November 11
Member No.: 95439



QUOTE (saratoga @ Nov 19 2012, 21:27) *
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.

QUOTE (andrewfg @ Nov 19 2012, 20:45) *
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?

QUOTE (andrewfg @ Nov 19 2012, 20:45) *
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?

QUOTE (andrewfg @ Nov 19 2012, 20:45) *
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.
Go to the top of the page
+Quote Post
andrewfg
post Nov 22 2012, 11:36
Post #3





Group: Members
Posts: 84
Joined: 12-May 08
Member No.: 53478



QUOTE (chi @ Nov 21 2012, 02:38) *
Is it possible that processing is too slow for 192 kHz input, and that buffers are dropped by the framework?


QUOTE (chi @ Nov 21 2012, 02:38) *
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.


I think yes; to both points above...

When I execute the command pipeline from a DOS prompt [input file => sox (resample and transcode) => output file] then it all works fine. But when I execute the same command pipeline as a sub process from my windows application [input socket => sub process input pipeline => sox (resample and transcode) => sub process output pipeline => output socket] then it fails; and only when using high bit rate files, and only when there is a resample rate switch in the command line.

I have even discovered that if I repeat the same command pipeline sub process several times, then sometimes the output audio is good, and sometimes it is not...

So I think there is indeed something odd in the way that sox is sucking in the data from the StdIn buffer, and/or the way it is blowing out the data from the StdOut buffer. And yes indeed it could be high computational load issue that causes bytes to get lost from the input or output buffers.

Note: if the number of dropped bytes happened to be an exact multiple of the audio frame size, then the audio would still sound Ok, whereas if the number of dropped bytes were not a multiple of the frame size, the audio would be munged. So this probably explains my experience with several repeats of the same command pipeline sub process, where sometime the output sounds Ok and sometimes not...




--------------------
AndrewFG (Whitebear -- http://www.whitebear.ch/mediaserver )
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st November 2014 - 04:10