IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
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
saratoga
post Nov 19 2012, 00:04
Post #2





Group: Members
Posts: 4961
Joined: 2-September 02
Member No.: 3264



What format is the PCM you're feeding sox?
Go to the top of the page
+Quote Post
chi
post Nov 19 2012, 02:04
Post #3





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



Well, your audio seems to be little-endian, in any case.

To go on, we’ll need to know at least where standard input is coming from – is it something processing a file, or directly from an audio input? Also, more about the kind of “distortion” might be useful: Are chunks of the audio missing? Is the pitch wrong? Unexpected noise? Etc.
Go to the top of the page
+Quote Post
andrewfg
post Nov 19 2012, 19:08
Post #4





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



QUOTE (saratoga @ Nov 19 2012, 00:04) *
What format is the PCM you're feeding sox?

-s -b24 -c2 -r192000 -L <= signed integer, 24-bit, 2-channel, 192000Hz, Little Endian PCM
-s -b24 -c2 -r192000 -B <= signed integer, 24-bit, 2-channel, 192000Hz, Big Endian PCM
-s -b24 -c2 -r96000 -L <= signed integer, 24-bit, 2-channel, 96000Hz, Little Endian PCM
-s -b24 -c2 -r96000 -B <= signed integer, 24-bit, 2-channel, 96000Hz, Big Endian PCM


--------------------
AndrewFG (Whitebear -- http://www.whitebear.ch/mediaserver )
Go to the top of the page
+Quote Post
andrewfg
post Nov 19 2012, 19:45
Post #5





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



QUOTE (chi @ Nov 19 2012, 02:04) *
Well, your audio seems to be little-endian, in any case.

See prior answer. 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.

QUOTE (chi @ Nov 19 2012, 02:04) *
To go on, we’ll need to know at least where standard input is coming from – is it something processing a file, or directly from an audio input?

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.

QUOTE (chi @ Nov 19 2012, 02:04) *
Also, more about the kind of “distortion” might be useful: Are chunks of the audio missing? Is the pitch wrong? Unexpected noise? Etc.

Unlike in the other three cases, it is not white noise in this case. I can actually recognise the music. But the sound it is all munged up. It is not a question of wrong pitch, or swapped channels or whatever. 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 post has been edited by andrewfg: Nov 19 2012, 19:47


--------------------
AndrewFG (Whitebear -- http://www.whitebear.ch/mediaserver )
Go to the top of the page
+Quote Post
JJZolx
post Nov 19 2012, 20:22
Post #6





Group: Members
Posts: 396
Joined: 26-November 04
Member No.: 18345



Are the results (white noise, distorted audio, works) the result of streaming the audio to some particular player or of playing converted files?
Go to the top of the page
+Quote Post
saratoga
post Nov 19 2012, 20:27
Post #7





Group: Members
Posts: 4961
Joined: 2-September 02
Member No.: 3264



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


Are you using -rate and expecting that to resample? Because:

QUOTE
A user must pass enough information to SoX on the command line so that it knows what type of data it contains. Audio data can usually be totally described by four characteristics:
rate
The sample rate is in samples per second. For example, CD sample rates are at 44100.


So if you pass in 96k audio and then give sox -r 48000 I expect it to get quite screwed up. Perhaps you want to use the resample command instead?
Go to the top of the page
+Quote Post
andrewfg
post Nov 19 2012, 23:06
Post #8





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



QUOTE (JJZolx @ Nov 19 2012, 20:22) *
Are the results (white noise, distorted audio, works) the result of streaming the audio to some particular player or of playing converted files?


Either. Both. If the audio plays wrong when streamed directly, it also plays wrong when saved to a file and played later...


--------------------
AndrewFG (Whitebear -- http://www.whitebear.ch/mediaserver )
Go to the top of the page
+Quote Post
andrewfg
post Nov 19 2012, 23:08
Post #9





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



QUOTE (saratoga @ Nov 19 2012, 20:27) *
Perhaps you want to use the resample command instead?


Yes. That is exactly what I want to do. That was my original question.


--------------------
AndrewFG (Whitebear -- http://www.whitebear.ch/mediaserver )
Go to the top of the page
+Quote Post
saratoga
post Nov 19 2012, 23:12
Post #10





Group: Members
Posts: 4961
Joined: 2-September 02
Member No.: 3264



QUOTE (andrewfg @ Nov 19 2012, 18:08) *
QUOTE (saratoga @ Nov 19 2012, 20:27) *
Perhaps you want to use the resample command instead?


Yes. That is exactly what I want to do. That was my original question.


So you figured it out?
Go to the top of the page
+Quote Post
JJZolx
post Nov 20 2012, 02:43
Post #11





Group: Members
Posts: 396
Joined: 26-November 04
Member No.: 18345



I just tried this out for myself and it worked fine in all four cases. I started with 24/96 and 24/192 FLAC files and tested it two ways, each with the same results. First by using flac.exe to decode the FLACs to individual .pcm files with the desired endianness, and feeding these files into SoX, and then by just piping the output of flac.exe directly into SoX.

Here are the command lines for the latter. The SoX parts are exactly like yours:

CODE
flac.exe -dc "File96.flac" --force-raw-format --sign=signed --endian=little -- | sox.exe -q -t raw -s -b24 -c2 -r96000 -L - -t flac -C0 "File96_L_48.flac" rate 48000
flac.exe -dc "File96.flac" --force-raw-format --sign=signed --endian=big -- | sox.exe -q -t raw -s -b24 -c2 -r96000 -B - -t flac -C0 "File96_B_48.flac" rate 48000
flac.exe -dc "File192.flac" --force-raw-format --sign=signed --endian=little -- | sox.exe -q -t raw -s -b24 -c2 -r192000 -L - -t flac -C0 "File192_L_48.flac" rate 48000
flac.exe -dc "File192.flac" --force-raw-format --sign=signed --endian=big -- | sox.exe -q -t raw -s -b24 -c2 -r192000 -B - -t flac -C0 "File192_B_48.flac" rate 48000


You're not actually starting with PCM files, are you? I'd guess that whatever you're piping into SoX isn't the format that you expect.

This post has been edited by JJZolx: Nov 20 2012, 02:50
Go to the top of the page
+Quote Post
chi
post Nov 21 2012, 02:38
Post #12





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:14
Post #13





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



QUOTE (JJZolx @ Nov 20 2012, 02:43) *
I just tried this out for myself and it worked fine in all four cases. I started with 24/96 and 24/192 FLAC files and tested it ... by just piping the output of flac.exe directly into SoX.


I confirm that I tried the same pipeline test as you [input file => flac (decode) => sox (resample) => output file] and got the same (positive) results as you. I even tried yet a longer pipeline ([nput file => flac (decode) => sox (resample) => sox (resample again) => output file] to check if the issue was related to the endpoints of the pipeline. However basically it always seems to work in such cases.

QUOTE (JJZolx @ Nov 20 2012, 02:43) *
You're not actually starting with PCM files, are you? I'd guess that whatever you're piping into SoX isn't the format that you expect.


Yes I am using a pcm source, and yes it is a good pcm stream. I know this is because if I use the same pcm with the same sox command line but without the resample rate switch, then the output is properly audible; the process only fails on high bit rates and where there is a resample rate switch in the command line...


--------------------
AndrewFG (Whitebear -- http://www.whitebear.ch/mediaserver )
Go to the top of the page
+Quote Post
andrewfg
post Nov 22 2012, 11:36
Post #14





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

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: 17th September 2014 - 19:05