I have a heavily "overflowed" WAV file (samples written in float 32-bit format): instead of [-1.0,+1.0], the samples range goes as far as [-5.0,+5.0].
Using SoX to get raw PCM audio samples from WAV file:
sox --bits 32 --channels 1 --encoding floating-point --rate 48000 input.wav output.raw
I get warnings:
sox WARN sox: `input.wav' input clipped 1163400 samples
sox WARN sox: `output.raw' output clipped 605664 samples; decrease volume?
When I look into the output, I see the samples were clipped, and the range is [-1.0,+1.0] now. However, that is not what I want.
I would like to have exactly same output as input, just in different format (RAW instead of WAV). I need to use command line tool for the task. Is there a way to prevent SoX from doing the clipping?
I got the answer from the SoX mailing list.
The required behaviour isn't possible, however, in this specific case there is a workaround. Overriding input sample encoding as 32-bit signed integer instead of float, the values will be copied untouched; since the output is headerless, it doesn't matter what SoX thinks the samples are.
So, this works:
sox --bits 32 --channels 1 --encoding signed-integer --rate 48000 input.wav output.raw
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
24-bit sample sizes are not at all uncommon for PCM/WAV data, so I was surprised to see this:
Invalid sample format 's24'
... when I ran this:
ffmpeg -i input.oga -y -f wav -ar 44100 -sample_fmt s24 -ac 2 output.wav
When I look at the ffmpeg FAQ page it says that it doesn't support signed 24-bit sample sizes.
Fair enough, but I'm having a hard time accepting that this very powerful tool which supports an impressively large number of formats is somehow missing support for this really common sample width.
All I can think of is that maybe it's a build configuration issue.
So this question is...
Is there some way to configure ffmpeg to include support for signed 24-bit WAV output?
There is no sample format to compactly store 24-bit samples, but they can be stored in 32-bits with padding. For that, select a 24-bit PCM encoder
ffmpeg -i input.oga -y -f wav -ar 44100 -c:a pcm_s24le -ac 2 output.wav
Run ffmpeg -encoders | grep 24 to get a list of all 24-bit encoders.
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 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 have been using FFMPEG for some time for audio file conversions. I just downloaded the newest version and the command below:
ffmpeg -i x.flac -ab 128k x.mp3
no longer produces a 128k file.
It produces a 48k file no matter what the -ab command requests. Any suggestions?
According to the documentation
`-ab bitrate'
Set the audio bitrate in bit/s (default = 64k).
So this is the bitrate, which means that per second by default 64k bits are used for storing sound information. So only a one second file would return a 128k file.
If I misunderstood your question and you mean that the bitrate is 48k instead of 128k then double check if ffmpeg is not using variable bit rate. If this is not the case I suggest you submit a bug report.