I am trying to read a FM signal and piping it to sox. This is exiting unusually. Any idea what's going on?
Thanks.
$ rtl_fm -f $137M -s 60k -g 45 -p 55 -E wav -E deemp -F 9 - | sox -t wav - abc.wav rate 11025
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Tuner gain set to 44.50 dB.
Tuner error set to 55 ppm.
Tuned to 37480000 Hz.
Oversampling input by: 32x.
Oversampling output by: 1x.
Buffer size: 4.27ms
sox FAIL formats: can't open input `-': WAVE: RIFF header not found
Sampling at 1920000 S/s.
Output at 60000 Hz.
Signal caught, exiting!
User cancel, exiting...
WAV header needs size of the audio content. Normally it is set after the whole content was captured. In your example you pipe the content as you capture it, so header is not set.
You should either use those separately instead of piping, or, assuming this rtl command allows it, pipe raw data. This probably will require to manually specify format (sampling frequency, bitdepth, etc) of the incoming data on the sox side.
Related
My team accidentally on purpose clicked NO when Audacity asked to save the recording. So I left with bunch of *.au files, after using recovery program.
Some of them did have header and still open-able with audacity itself (example : this one), and some other are just complete nonsense, sometimes having the header filled with text from random javascript or HTML code (like this one). Probably hard disk half overwritten with browser cache? I don't know. And at this point, I almost don't care.
The audacity is on default settings, with sample rate 44100Hz. I can open a-113.au using audacity, from standard open files. I also was able to achieve open files using "Open RAW files" from Audacity, using this settings :
so I assume header takes 12384 bytes.
Now, how do I trim 12384 bytes from the file when opened as RAW, with either SoX or ffmpeg? because if I open it as RAW with 0 offset (default settings), it will add the header as a noise.
Current ffmpeg command I used : ffmpeg.exe -f f32le -ar 44.1k -ac 1 -i source destination
Current sox command I used : sox -t raw --endian little --rate 44100 -b 1 -b 32 --encoding floating-point %%A "converted/%%~nxA.wav"
Both still have header as a noise in the converted files.
With ffmpeg, use the subfile protocol.
ffmpeg.exe -f f32le -ar 44.1k -ac 1 -start 12384 -i "subfile:source" destination
When I try to use sox to change the sample rate of a wav file I get a file of noise and garbage and the 2 following errors:
sox WARN rate: rate clipped 579 samples; decrease volume?
sox WARN dither: dither clipped 518 samples; decrease volume?
Although there are question marks there, I never get to answer them. They come up more as a status.
What I am starting with is a PCM file of my own making. The specs are:
16 bit signed
big endian
1 channel
44100 sample rate
I can import the file (0.wav) into Audacity and it's fine.
Then I convert the file into a wav file with the following line:
sox -r 44100 -e signed-integer -b 16 -c 1 0.raw 1.wav
I can import that file into Audacity and it also is fine.
But then when I try to change the sampling rate with:
sox 1.wav -r 16000 2.wav
If anyone knows what I'm doing wrong, or missing, I would appreciate it. Also I put up the original raw here: http://warptv.com/raw.html
This appears to be a problem of endian-ness. Your raw file is stored in big endian byte order, while WAV is, at least most of the time, little-endian.
This being the case you have to explicitly inform SoX about the endian-ness of your raw file, so this can be taken into account when converting. The appropriate switch for this is -B, changing your command into something like:
sox -r 44100 -e signed-integer -B -b 16 -c 1 0.raw 1.wav
With the raw file properly converted into a wav file the subsequent rate conversion as you attempted it should work as expected. At least it did for me.
Playing around a bit with Audacity it appears that it has some method of detecting (or guessing) the endian-ness of raw files that SoX lacks, and that this is the source of the discrepancy you found.
I'm using the following in a shell script :
##For ease of understanding I'll declare the $1 variable here even though it's actually arriving remotely via an ssh2_exec command.
$1="my.mp3"
lame --decode /root/incoming/shows/$1 - | /root/incoming/stereo_tool_cmd_64 - - -s /usr/incoming/settings/setting.sts | lame -b 128 - /root/incoming/processing/$1;
So what is happening? LAME decodes the mp3 file to wav, then it is piped to STEREO TOOL (audio processing script), then back to LAME where it's re-encoded as an mp3 file and the result is written to a different directory.
This all works great but I want to use SOX during this pipe to remove all silence from the start and end of the file, while it's in it's decoded wav state, before hitting STEREO TOOL.
I've tried this but it doesn't work (SOX breaks the pipe) :
lame --decode /root/incoming/shows/$1 - | sox silence 1 0.1 0.1% reverse silence 1 0.1 0.1% reverse | /root/incoming/stereo_tool_cmd_64 - - -s /usr/incoming/settings/setting.sts | lame -b 128 - /root/incoming/processing/$1;
I know the standard way to use SOX would be :
sox input.wav output.wav silence 1 0.1 0.1% reverse silence 1 0.1 0.1% reverse;
But I can't declare the wav file here as it's being created on the fly by LAME.
Is what I'm trying to do impossible or is there a solution that will allow me to do this?
I have a file, sound.au, which file describes as Sun/NeXT audo data: 8-bit ISDN mu-law, mono, 8000 Hz. I'd like to convert this to a WAV that file would describe as RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 8000 Hz. However, I cannot get the right set of arguments to make this conversion and see what it sounds like.
Has anyone performed this conversion or similar before? sox -t auto -w -s -r 8000 -c sound.au sound.wav gets me close, but it's G711 mu-law, not 16 bit PCM.
Thanks.
I don't have an .au file to try, but I suspect sox sound.au -e signed-integer sound.wav would work. You are only trying to change the encoding from u-law to PCM, right? sox should pick up all the necessary input info from the .au header. If it doesn't, maybe you need sox -t auto sound.au -e signed-integer sound.wav.
I want to capture a image through webcam in linux.
So i searched on internet and found out it's can be done using mplayer or vlc.
Following is the command for capturing image by mplayer and its corresponding error.
[root#localhost ~]# mplayer -vo png -frames 1 tv://
MPlayer SVN-r31628-4.4.4 (C) 2000-2010 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing tv://.
TV file format detected.
Selected driver: v4l2
name: Video 4 Linux 2 input
author: Martin Olschewski <olschewski#zpr.uni-koeln.de>
comment: first try, more to come ;-)
v4l2: unable to open '/dev/video0': No such file or directory
v4l2: ioctl set mute failed: Bad file descriptor
v4l2: 0 frames successfully processed, 0 frames dropped.
Exiting... (End of file)
[root#localhost ~]#
Please Help me in solving this error.
I searched on net and found out about v4l2, but still can't solve the problem.
Your error is pretty clear. The webcam apparently is not registering at /dev/video0. In some instances, I've found that encoders or other video devices register under /dev/videoX, where X can be any integer. Try modifying your statement to try different video devices.
You can also try using fswebcam which has a useful feauture of skipping the first few frames
-some webcam show corrupt (or green) images for the first frame or two:
fswebcam --skip 2
It can be set to capture an image every second:
fswebcam --skip 2 --loop 1
I made it by doing this:
mplayer tv:// -tv driver=v4l2:device=/dev/video0 -fps 1 -frames 2 -sstep 100 -vo jpeg; rm 00000001.jpg ; mv 00000002.jpg capture.$(date +%F_%R).jpg.
where:
"tv:// -tv driver=v4l2:device=/dev/video0" specifies the necessary driver and video device. You need to check if that device is the one you want to capture and or exists by doing ls /dev/video*.
-fps 1 -frames 2 -sstep 100 specifies the framerate and it's set to only one per second to ensure you will have enough time to wake up properly the camera, captures 2 frames and in between frames you had 100 fps from the output dropped to help with the camera focus.
-vo jpeg stands for jpg output format images, on my computer png doesn't work with all this configuration.
rm 00000001.jpg deletes the first frame capture, because always it's ging to be obscure, green or no focused, this is caused by the small amount of time neede by the camera to wake up.
mv 00000002.jpg capture.$(date +%F_%R).jpg makes the second frame image switch name from 00000002.jpg for "capture." plus the current date time.