Skip to main content

Topic: ffmpeg vs. SoX for resampling (Read 16379 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • jkauff
  • [*][*][*]
  • Members (Donating)
ffmpeg vs. SoX for resampling
I just found out that TAudioConverter, although it has SoX support, uses ffmpeg for bitdepth changes, resampling, and dither. I don't use those functions very much, but I'm curious if anyone has done a quality comparison between the two.

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
ffmpeg vs. SoX for resampling
Reply #1
I’m no authority, but there’s always good old http://src.infinitewave.ca/

SoX 14.4.0:
Quote
Let’s, er, let’s hope FFmpeg has evolved by leaps and bounds since that version was released only about half a year ago.

  • bandpass
  • [*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #2
Let’s, er, let’s hope FFmpeg has evolved by leaps and bounds since that version was released only about half a year ago.

It has, it now uses SoX

Quote
January, 7, 2013, FFmpeg 1.1
We have made a new major release (1.1) It contains all features and bugfixes of the git master branch. A partial list of new stuff is below:
...
- SOX Resampler support in libswresample

You have to give a command-line option though:
http://ffmpeg.org/trac/ffmpeg/wiki/FFmpeg%...SoX%20Resampler

  • jkauff
  • [*][*][*]
  • Members (Donating)
ffmpeg vs. SoX for resampling
Reply #3
I’m no authority, but there’s always good old http://src.infinitewave.ca/

SoX 14.4.0:

FFmpeg 0.10.4:

Let’s, er, let’s hope FFmpeg has evolved by leaps and bounds since that version was released only about half a year ago.

Well, FFmpeg is now up to version 1.1.1, and Peter has incorporated it into fb2k, so I think we can assume the program's improved. Whether it's improved for this functionality is another question. Of course, there's a 14.4.1 version of SoX just out, too.

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
ffmpeg vs. SoX for resampling
Reply #4
I did notice the large disparity in version numbers between 0.10.4 and now, but I found that 0.10.6 was released as recently as October, so I had to emphasise that the resampling may or may not have had the massive improvements that it so blatantly needs.

Edit: I just saw bandpass’s post, which I missed due to jkauff posting in the interim. Phew! That’s a relief.
  • Last Edit: 05 February, 2013, 06:41:21 AM by db1989

  • bandpass
  • [*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #5
Well, FFmpeg is now up to version 1.1.1, and Peter has incorporated it into fb2k, so I think we can assume the program's improved. Whether it's improved for this functionality is another question. Of course, there's a 14.4.1 version of SoX just out, too.

Oddly, SoX itself is a little behind the curve: 14.4.1 contains the same (slow, by comparison) version of the resampler that's been there for some years, so until SoX 14.5 is released (couple of months I think), the ffmpeg route will give better performance (about 2-3 x faster).

Don't know if it made it into 1.1.1 or not, but I saw that ffmpeg has also recently ported (most of) SoX's dither code.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
ffmpeg vs. SoX for resampling
Reply #6
Downloaded TAC(0.7.5.938)(portable).7z. It contains FFmpeg version N-49352-gc46943e built on Jan 26 2013 (Zeranoe build).

And this build wasn't compiled with --enable-libsoxr option, so TAudioConverter resampling should be similar to FFmpeg 0.10.4 from post#2.

  • phofman
  • [*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #7
... (slow, by comparison) ...
the ffmpeg route will give better performance (about 2-3 x faster).


I am not sure speed is the correct measure of quality.

  • bandpass
  • [*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #8
I am not sure speed is the correct measure of quality.

The conversion quality is the same (graphs for the newer version are @ infinitewave under Audacity 2.0.3); the performance is higher cos it's faster than before.

And this build wasn't compiled with --enable-libsoxr option

Zeranoe takes ffmpeg build requests at: http://ffmpeg.zeranoe.com/forum/viewforum.php?f=10

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
ffmpeg vs. SoX for resampling
Reply #9
Regardless of different options and builds, something has to be done about the standard of resampling demonstrated by that graph.

  • ozok
  • [*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #10
I've posted a request for a ffmpeg build with libsoxr support to the link bandpass supplied. I'm waiting for a response.

  • [JAZ]
  • [*][*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #11
Let’s, er, let’s hope FFmpeg has evolved by leaps and bounds since that version was released only about half a year ago.


Quoting the FAQ:

Quote
Are most SRCs really that bad?
No. If you look at the decibel scale to the right from the graphs, you can see that the range of these graphs is very wide: down to -180 dB. The distortions generated by most properly designed SRCs are below -100 dB and can hardly create audible artifacts. However SRCs differ in the transition band of the low-pass filter and in the amount of pre-/post-echo and aliasing. The bottom line is that most tested SRCs range from fairly good to excellent, but the graphs are very sensitive to emphasize the differences.

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
ffmpeg vs. SoX for resampling
Reply #12
Quote
Quote

Seems to me that those reflections of the actual input signal may still be quite a bit above –96 dB. Does that fall within the remit of “properly designed SRCs”? Even the background static does not look far below –100 dB.

Besides, even if that explanation were applicable, is it really anything other than hand-wringing when there is no real excuse for the algorithm to perform to such a poor standard? Other free programs can resample with many, many times less noise. Why give a free pass to some SRCs just because their distortions might not be audible? Again: “might”.

I thought this was a site that focusses on perceptual quality, sure, but doesn’t skimp on theoretical quality when there’s no good reason to do so.
  • Last Edit: 05 February, 2013, 02:53:05 PM by db1989

  • lvqcl
  • [*][*][*][*][*]
  • Developer
ffmpeg vs. SoX for resampling
Reply #13
the noise floor on a CD is around -110 dB, considering that the spectrogram display shows a power spectral density, not the waveform level. So, the regular 16-bit dithering noise is actually represented by this color. Here is the graph of the CD noise floor with a standard TPDF dither:



+ a thread about ffmpeg resampling: http://www.hydrogenaudio.org/forums/index....showtopic=79106
  • Last Edit: 05 February, 2013, 04:01:36 PM by lvqcl

  • bandpass
  • [*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #14
FFmpeg native is even worse going the other way (i.e. upsampling); here's a look at the latest (1.1.1):

96k 0dBFS -> 44100

Artefacts at around -75 (ignoring the main alias).

44100 0dBFS -> 96k

Artefacts at around -67 (ignoring the main image) and easily audible in the last second.

No surprises when using ffmpeg's soxr option:



and it's around 3 times faster than the native one.

It would be good if FFmpeg could drop the native resampler completely, but it's still needed for drift compensation in some circumstances (between async clocks on 2 soundcards, I think).

  • bandpass
  • [*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #15
+ a thread about ffmpeg resampling: http://www.hydrogenaudio.org/forums/index....showtopic=79106

I think that complaint was mainly about the roll-off which, as can be seen at infinitewave, is appalling, starting at 12kHz. This was recently improved in 1.1.1 though.

  • mavere
  • [*]
ffmpeg vs. SoX for resampling
Reply #16
I’m no authority, but there’s always good old http://src.infinitewave.ca/


That's a fascinating site.

I'm curious though, why are some so bad? It doesn't look like anyone should need to reinvent the wheel so to speak, as there are amazing open-source (SoX) and proprietary (Adobe Audition) options, and hell, even Apple CoreAudio from 5 years ago is decent.
  • Last Edit: 05 February, 2013, 09:01:31 PM by mavere

  • IgorC
  • [*][*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #17
http://src.infinitewave.ca/images/Tone/ffmpeg.png

ffmpeg's resampler isn't that bad but some lines are at -105 -100 dB which is a bit above inaudible threshold (-110 dB).
Obviously SoX has much more headroom.
  • Last Edit: 05 February, 2013, 09:51:24 PM by IgorC

ffmpeg vs. SoX for resampling
Reply #18
These spectral peaks are not bad only for a 1 kHz tone, but they get much worse for higher-frequency tones (as can be seen on a spectrogram).

  • nu774
  • [*][*][*][*][*]
  • Developer
ffmpeg vs. SoX for resampling
Reply #19
Apple CoreAudio from 5 years ago is decent.

Highest setting of Apple CoreAudio resampler has really (unnecessarily) high SNR, but is 10x or more slower than SoX (at least on Windows).
And even Microsoft resampler of Windows Media Foundation (CLSID_CResamplerMediaObject) has reasonablly good quality / performance, but read this bug on Win7 WaveOut:
http://www.hydrogenaudio.org/forums/index....st&p=788882
It seems that their left hand doesn't know what the right hand is doing.

  • bandpass
  • [*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #20
ffmpeg's resampler isn't that bad ...

You're right, it isn't that bad, it's worse—see esp. 2nd graph above.

  • LithosZA
  • [*][*][*]
ffmpeg vs. SoX for resampling
Reply #21
Quote
ve posted a request for a ffmpeg build with libsoxr support to the link bandpass supplied. I'm waiting for a response.


I see there already is a new build with libsoxr support

  • ozok
  • [*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #22
zeranoe kindly supplied it after my request.

ffmpeg vs. SoX for resampling
Reply #23
So, where is TOS#8 when everyone agrees on looking at graphs? Not trying to troll, I just smell some bigottery.

  • pdq
  • [*][*][*][*][*]
ffmpeg vs. SoX for resampling
Reply #24
So, where is TOS#8 when everyone agrees on looking at graphs? Not trying to troll, I just smell some bigottery.

Unless someone claims that there is an audible difference, I don't have a problem with looking at spectra.