I am converting audio files of several different formats to mp3 using SoX. According to the docs, you can use the -C argument to specify compression options like the bitrate and quality, the quality being after the decimal point, for example:
sox input.wav -C 128.01 output.mp3 (highest quality, slower)
sox input.wav -C 128.99 output.mp3 (lowest quality, faster)
I expected the second one to sound terrible, however, the audio quality between the two sounds exactly the same. If that is the case, I do not understand why one performs so much slower or what I would gain by setting the compression to higher "quality".
Can someone please tell me if there is a real difference or advantage to using higher quality compression versus lower quality?
P.S. I also checked the file size of each output file and both are exactly the same size. But when hashed, each file comes out with a different hash.
The parameters are passed on to LAME. According to the LAME documentation (section “algorithm quality selection”/-q), the quality value has an effect on noise shaping and the psychoacoustic model used. They recommend a quality of 2 (i.e. -C 128.2 in SoX), saying that 0 and 1 are much slower, but hardly better.
However, the main factor determining the quality remains the bit rate. It is therefore not too surprising that there is no noticeable difference in your case.
For me faster with simple
time sox input.mp3 -C 128 output.mp3
real 0m7.417s user 0m7.334s sys 0m0.057s
time sox input.mp3 -C 128.02 output.mp3
real 0m39.805s user 0m39.430s sys 0m0.205s
Related
Can you provide a link, or an explanation, to the -q:v 1 argument that deals with video/image quality, and compression, in ffmpeg.
Let me explain...
for f in *
do
extension="${f##*.}"
filename="${f%.*}"
ffmpeg -i "$f" -q:v 1 "$filename"_lq."$extension"
rm -f "$f"
done
The ffmpeg for loop above compresses all images and videos in your working directory, it basically lowers the quality which results in smaller file sizes (the desired outcome).
I'm most interested in the -q:v 1 argument of this for loop. The 1 in the -q:v 1 argument is what controls the amount of compression. But I can't find any documentation describing how to change this value of 1, and describing what it does. Is it a percentage? Multiplier? How do I adjust this knob? Can/should I use negative values? Integers only? Min/max values? etc.
I started with the official documentation but the best I could find was a section on video quality, and the -q flag description is sparse.
-frames[:stream_specifier] framecount (output,per-stream)
Stop writing to the stream after framecount frames.
.
-q[:stream_specifier] q (output,per-stream)
-qscale[:stream_specifier] q (output,per-stream)
Use fixed quality scale (VBR). The meaning of q/qscale is codec-dependent. If qscale is used without a stream_specifier then it applies only to the video stream, this is to maintain compatibility with previous behavior and as specifying the same codec specific value to 2 different codecs that is audio and video generally is not what is intended when no stream_specifier is used.
-q:v is probably being ignored
You are outputting MP4, so it is most likely that you are using the encoder libx264 which outputs H.264 video.
-q:v / -qscale:v is ignored by libx264.
The console output even provides a warning about this: -qscale is ignored, -crf is recommended.
For more info on -crf see FFmpeg Wiki: H.264.
When can I use -q:v?
The MPEG* encoders (mpeg4, mpeg2video, mpeg1video, mjpeg, libxvid, msmpeg4) can use -q:v / -qscale:v.
See How can I extract a good quality JPEG image from a video file with ffmpeg? for more info on this option.
This option is an alias for -qscale:v which might be why you didn't encounter it during your research (eventhough my resultat came first with "ffmpeg q:v" on google).
This link explains how the qscale option is not a multiplier or a percentage, it's a bitrate mode (so it's to bitrate). For a given encoder, the lower this number the higher the bitrate and quality. It usually spans from 1-31 but some encoders can accept a subset of this range.
I have tried PyRubberband, librosa, praat-parselmouth and pysox. All off them work but I still hear some noise or small artifacts in the output. Also, they shift the audio around 100 ms.
How can I tune them to get the best possible quality or can you suggest any library which does it better?
UPD: FFMPEG approach:
ffmpeg -i input.wav -af asetrate=48000*1.1,aresample=48000,atempo=1/1.1 output.wav
I would guess that of the four mentioned, PyRubberband is probably the best algorithm. Depending on how much you want to shift pitch, you will never reach perfect results. This has to do with the fact that (as far as I know) they all use a phase vocoder, which transforms the signal into the frequency domain, shifts and then transforms it back into the time domain using the imperfect Griffin-Lim algorithm. Griffin-Lim tends to introduce small phase artifacts, which leads to a slightly metallic sound.
To learn more about time scale modification/pitch shifting, I recommend this overview article by Driedger.
I'm making an mp3 from a flac file with ffmpeg. This is usually hum-dum for me.
Tonight, for some reason, the converted audio is distorting when I use the same commands I've always used. After troubleshooting, it appears the problem is the "-out_sample_rate" flag.
My command:
ffmpeg -i input.flac -write_id3v1 1 -id3v2_version 3 -dither_method modified_e_weighted -out_sample_rate 44.1k -b:a 320k output.mp3
The audio in the mp3 is then incredibly distorted by a jacked gain resulting in digital clipping.
I've tried updating ffmpeg, and then problem remains. I've tried converting various sample rates (44.1k source files, 48k source files, 96k source files) to both 44.1k and 48k mp3s, problem remains whenever there's a conversion.
I'm on macOS, and I installed ffmpeg via homebrew.
Any ideas?
Are you sure the distortion comes from resampling?
Even the poorest resampling algorithm doesn't distort. More typical artifacts from poor resampling are harsh high frequencies due to aliasing and quantisation noise.
FFmpeg's resampler isn't the very best but it isn't bad at all. It shouldn't lead to distortion at all. Enough for average use.
How much headroom does the source file have?
If not enough, the resampling or the MP3 conversion may lead to clipping. The MP3 encoder removes frequencies from the signal (even at 320kbps) so the waveform will alter.
So reimport the encoded MP3 into an audio editor and look for clipping.
If not sure, which step the distortion comes from, split the command up and look, which step leads to clipping:
ffmpeg -i input.flac -write_id3v1 1 -id3v2_version 3 -dither_method modified_e_weighted -out_sample_rate 44.1k intermediate.flac
ffmpeg -i intermediate.flac -b:a 320k output.mp3
There should be a headroom of at least 1dB left before it gets converted to MP3. If not, lower the gain before.
If the resampling of the intermediate.flac leads to a significant gain in amplitude, the original input.flac is poorly mastered. If so (and the quality is really important), do the SR conversion in an audio editor (i.e. Audacity, it does a better resampling job than FFMpeg) and apply a limiter between the resampling and dithering step to lower the few strong peaks nicely.
If that doesn't help: What exactly does input.flac contain? Music? Noise? Speech? and is it selfmade or taken from something else?
I want to make a sound that is too high to be detected by the human ear. From my understanding, humans can hear sounds between 20hz and 44000hz.
With sox, I am making a sound that is 50000hz. The problem is I can still hear it. The command I am using is this:
sox -n -r 50000 output.wav rate -L -s 50050 synth 3 sine
Either I have super good hearing or I am doing something wrong. How can I make this sound undetectable with SOX of FFMPEG?
Human hearing is generally considered to range between 20Hz and 20kHz, although most people don't hear much above 16kHz. Digital signals can only represent frequencies up to half of their sampling rate, known as the Nyquist frequency, and so, in order to accurately reproduce audio for the human ear, a sampling rate of at least 40kHz is needed. In practice, a sampling rate of 44.1kHz or 48kHz is almost always used, leaving plenty of space for an inaudable sound somewhere in the 20-22kHz range.
For example, this command generates a WAV file with a sampling rate of 48kHz containing a sine wave at 22kHz that is completely inaudible to me:
sox -n -r 48000 output.wav synth 3 sine 22000
I think part of your problem was that you were using the wrong syntax to specify the pitch to sox. This question has some good information about using SoX to generate simple tones.
I have received a request to encode DPX files to MOV/MJPEG rather than MOV/H.264 (which ffmpeg picks by default if you convert to output.mov). These is to review compositing renders (in motion), so color accuracy is critical.
Comparing a sample "ideal" MOV to the current (H.264) output I can see:
resolution: the same
ColorSpace/Primaries: Rec609 (SD) versus Rec709 (HD)
YUV: 4:2:0 versus 4:4:4
filesize: smaller
The ffmpeg default seems to be better quality and result in a smaller filesize. Is there something I'm missing?
Maybe it's because MJPEG frames are independent of each other, so any snippet of video can be decoded / copied in isolation. With an inter-frame compression algorithm like H.264, the software has to scan data for potentially numerous frames to reconstruct any given one.