I want to split a long audio file (raw, 48 kHz, 16 bit mono) into smaller chunks of 7 hours each.
I go to the sox directory (which is "D:\sox"), then I call
sox "D:\Dev\Projects\work\audio.raw" trim 0 50400 : newfile : restart
It throws an error saying "Not enough input filenames specified.
What am I doing wrong?
Thank you!
Related
I seem to be having trouble properly combining thousands of netCDF files (42000+) (3gb in size, for this particular folder/variable). The main variable that i want to combine has a structure of (6, 127, 118) i.e (time,lat,lon)
Im appending each file 1 by 1 since the number of files is too long.
I have tried:
for i in input_source/**/**/*.nc; do ncrcat -A -h append_output.nc $i append_output.nc ; done
but this method seems to be really slow (order of kb/s and seems to be getting slower as more files are appended) and is also giving a warning:
ncrcat: WARNING Intra-file non-monotonicity. Record coordinate "forecast_period" does not monotonically increase between (input file file1.nc record indices: 17, 18) (output file file1.nc record indices 17, 18) record coordinate values 6.000000, 1.000000
that basically just increases the variable "forecast_period" 1-6 n-times. n = 42000files. i.e. [1,2,3,4,5,6,1,2,3,4,5,6......n]
And despite this warning i can still open the file and ncrcat does what its supposed to, it is just slow, at-least for this particular method
I have also tried adding in the option:
--no_tmp_fl
but this gives an eror:
ERROR: nco__open() unable to open file "append_output.nc"
full error attached below
If it helps, im using wsl and ubuntu in windows 10.
Im new to bash and any comments would be much appreciated.
Either of these commands should work:
ncrcat --no_tmp_fl -h *.nc
or
ls input_source/**/**/*.nc | ncrcat --no_tmp_fl -h append_output.nc
Your original command is slow because you open and close the output files N times. These commands open it once, fill-it up, then close it.
I would use CDO for this task. Given the huge number of files it is recommended to first sort them on time (assuming you want to merge them along the time axis). After that, you can use
cdo cat *.nc outfile
What does the output of play $file stat -freq mean?
I recently ran the command, here's a sample of the output:
$ play 44100Hz/3660/6517/3660-6517-0024.flac stat -freq
44100Hz/3660/6517/3660-6517-0024.flac:
File Size: 214k Bit Rate: 325k
Encoding: FLAC Info: Processed by SoX
Channels: 1 # 16-bit
Samplerate: 44100Hz
Replaygain: off
Duration: 00:00:05.28
In:0.00% 00:00:00.00 [00:00:05.28] Out:0 [ | ] Clip:0 0.000000 0.412632
10.766602 0.430416
21.533203 0.750785
32.299805 0.839694
43.066406 0.989763
53.833008 0.435572
64.599609 0.404773
75.366211 0.048392
86.132812 0.025195
96.899414 0.011314
...
In:3.52% 00:00:00.19 [00:00:05.09] Out:4.10k [ | ] Clip:0 0.000000 0.889006
10.766602 0.092675
21.533203 0.785106
32.299805 1.693663
43.066406 0.990839
53.833008 0.044969
64.599609 0.096066
75.366211 0.121797
86.132812 0.256809
96.899414 0.122486
107.666016 0.019195
...
How am I meant to understand this?
I hope that this is some Fourier transform and the above output represents a table like
Frequency | Level
But I don't know if that's the really case, or what level would be measured in were that the case.
And what do the lines starting with In:% mean? Ending with Clip:0 ....
Please can someone explain the output of this command to me.
From man page here:
The −freq option calculates the input’s power spectrum (4096 point DFT) instead of the statistics listed above. This should only be used
with a single channel audio file.
As you said, it is a Frequency / Level table.
So the last frequency is more or less the half of your sampling rate.
I tried it with a pure tone (generated in audacity) and it works quite well.
Be careful, if file length exceeds 4096 bytes per channel then you will see several sets of DFT, as the length of each DFT window is 4096. If so, then you will see several tables concatenated.
I don't have any '%'. Did you convert your audio file in mono as said in the documentation?
from man page here:
stat [-s scale] [-rms] [-freq] [-v] [-d]
Display time and frequency domain statistical information about the audio. Audio is passed unmodified through the SoX processing chain.
The information is output to the 'standard error' (stderr) stream and is calculated, where n is the duration of the audio in samples, c is the number of audio channels, r is the audio sample rate, and x k represents the PCM value (in the range -1 to +1 by default) of each successive sample in the audio, as follows:
...
The -freq option calculates the input's power spectrum (4096 point DFT) instead of the statistics listed above.
...
I am trying to use pocket sphinx to transcribe audio files.
pocketsphinx_continuous -infile 116-288045-0005.flac.wav
but I am getting the errors:
ERROR: "continuous.c", line 136: Input audio file has sample rate [44100],
but decoder expects [16000]
FATAL: "continuous.c", line 165: Failed to process file '116-288045-0005.flac.wav'
due to format mismatch.
Here's one of the audio files I need to transcribe: Download from GitHub
Eventually I will batch-transcribe over 5 hours of audio files like these, currently they all throw the same error.
Here's some stats of the same file I'm trying to transcribe:
$ soxi 116-288045-0000.flac.wav
Input File : '116-288045-0000.flac.wav'
Channels : 1
Sample Rate : 44100
Precision : 16-bit
Duration : 00:00:10.65 = 469665 samples = 798.75 CDDA sectors
File Size : 939k
Bit Rate : 706k
Sample Encoding: 16-bit Signed Integer PCM
There might be a problem with some of this file's configuration, I've done some pre-processing to merge it with mp3s, convert from flac to wav, among others.
What's the easiest way now for me to get the transcription working?
Is it possible without re-sampling the files back down to 16kHz. Originally the flac files had a sample-rate of 16kHz, but I had to merge them with 44.1kHz mp3 files. Therefore there's some high-frequency information in them now that may be lost if resampled to 16k.
Resample the audio to 16000 samples then try again.
You can resample like this
sox file.wav -r 16000 file-16000.wav
When searching for an occurrence of text in a PostScript file, I receive the following error:
gsapi_run_string_continue returns -21
The API documentation specifies that return codes > 0 are "Error" but doesn't describe it any more specifically. Full error console output below - error occurs twice identically, only one occurrence displayed here.
GPL Ghostscript 9.15 (2014-09-22)
Copyright (C) 2014 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Displaying DSC file C:/Users/c-toothm/Desktop/PRDFlow12_30_2014_050307/1230ouptut.ps
Displaying page 1
%%[ ProductName: GPL Ghostscript ]%%
%%[ LastPage ]%%
Extracting text using pstotext...
Ghostscript returns error code -21`
--- Begin offending input ---
evice /pop , d
initmatrix [1 0 0 1 0 0] concat colspSet`
0.00 43.32 +
0.94 0.95 +S
(XSFT2200041.img) run
EPSFILE2200041 restore
;
0 0 0 sco 5 Lw N 4950 4742 M 4800 4742 I K
0 0 0 sco 5 Lw N 4950 4752 M 4800 4752 I K
0 0 0 sco 5 Lw N 4950 4762 M 4800 476
--- End offending input ---
gsapi_run_string_continue returns -21`
[duplicate error redacted]
Our production output creates a giant .ps file every day and this error occurs in many, but not all, .ps files when searching for text. Randomly selected .ps files from the web do not throw the error, so this GS build seems OK - definitely a problem with my file.
What "offending input" is being referred to here and what can I do to address it?
I'd need to see the PostScript file to tell you exactly what is wrong, but 'evice' is not a PostScript operator and so that is likely the problem. Also, from ghostpdl/gs/psi/ierrors.h error code -21 is e_undefined which means the interpreter has encountered an undefined token, which is some confirmation that this is the problem.
This could be because the file contains a 'typo' like that (perhaps it should be setpagedevice or something), or it could be because a filter is improperly terminated, or has insufficient data, and consumes extra bytes from the input stream, chewing up your program.
You should start by using the Ghostscript executable and reproduce the error with that (you might also try the display device, to see whether the problem is related to pstotext), that will allow you to give a command line which other people can then duplicate. With that, and a copy of the offending file I can tell you exactly what's wrong, without it, not much hope.
Bear in mind that PostScript is an interpreted programming language, so its pretty much impossible to tell you what's wrong with your program without seeing the code.
FWIW you might like to try the Ghostscript txtwrite device instead of pstotext, the device doesn't rely on tinkering with the language like pstotext does. pstotext is also really old (the last release is coming up on its 11th birthday) and unsupported.....
I am trying to create a script to write an XML file for Apple's ITMSP Transporter files for uploading metadata to the App Store. Requirements for screenshots are filename, MD5 checksum and filesize in bytes.
MD5 checksum is easy and be can be retrieved with md5 -q image.png
I am however having a hard time trying to get the byte size of the image file. If I use du -k image.png command, it returns the size rounded up in kilo bytes. So for example if the actual size is 5722 bytes, du will return 8 (as in 8K or 8192 bytes) which is not correct. And the default for du is in 512 byte chunks but still rounds the value up (so it will return 16 instead of 8).
I am running Lion OSX 10.7.4.
One easy approach is:
stat -f%z image.png
stat normally spits out a bunch of data, but the %z format just selects the size in bytes.
On OSX do stat -f "%z bytes".