HydrogenAudio

Hydrogenaudio Forum => General Audio => Topic started by: jkauff on 2013-02-05 10:00:51

Title: ffmpeg vs. SoX for resampling
Post by: jkauff on 2013-02-05 10:00:51
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.
Title: ffmpeg vs. SoX for resampling
Post by: db1989 on 2013-02-05 10:28:55
I’m no authority, but there’s always good old http://src.infinitewave.ca/ (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.
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-05 11:33:39
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 (http://ffmpeg.org/trac/ffmpeg/wiki/FFmpeg%20and%20the%20SoX%20Resampler)
Title: ffmpeg vs. SoX for resampling
Post by: jkauff on 2013-02-05 11:36:12
I’m no authority, but there’s always good old http://src.infinitewave.ca/ (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.
Title: ffmpeg vs. SoX for resampling
Post by: db1989 on 2013-02-05 11:40:03
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 (http://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=n0.10.6), 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.
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-05 12:05:57
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.
Title: ffmpeg vs. SoX for resampling
Post by: lvqcl on 2013-02-05 14:56:43
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.
Title: ffmpeg vs. SoX for resampling
Post by: phofman on 2013-02-05 15:32:10
... (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.
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-05 16:23:07
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 (http://ffmpeg.zeranoe.com/forum/viewforum.php?f=10)
Title: ffmpeg vs. SoX for resampling
Post by: db1989 on 2013-02-05 16:50:20
Regardless of different options and builds, something has to be done about the standard of resampling demonstrated by that graph.
Title: ffmpeg vs. SoX for resampling
Post by: ozok on 2013-02-05 17:09:23
I've posted a request for a ffmpeg build with libsoxr support to the link bandpass supplied. I'm waiting for a response.
Title: ffmpeg vs. SoX for resampling
Post by: [JAZ] on 2013-02-05 19:36:31
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.
Title: ffmpeg vs. SoX for resampling
Post by: db1989 on 2013-02-05 19:51:23
Quote
(http://src.infinitewave.ca/images/MagsChart.png)
Quote
(http://src.infinitewave.ca/images/Sweep/ffmpeg.png)

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.
Title: ffmpeg vs. SoX for resampling
Post by: lvqcl on 2013-02-05 20:55:05
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:
(http://audio.rightmark.org/lukin/temp/rmm/Ditherlevel.png)



+ a thread about ffmpeg resampling: http://www.hydrogenaudio.org/forums/index....showtopic=79106 (http://www.hydrogenaudio.org/forums/index.php?showtopic=79106)
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-05 21:29:06
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
(http://i50.tinypic.com/33ku5hc.png)
Artefacts at around -75 (ignoring the main alias).

44100 0dBFS -> 96k
(http://i50.tinypic.com/2w7han5.png)
Artefacts at around -67 (ignoring the main image) and easily audible in the last second.

No surprises when using ffmpeg's soxr option:
(http://i48.tinypic.com/mlmofq.png)

(http://i47.tinypic.com/qs6ye0.png)
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).
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-05 21:39:33
+ a thread about ffmpeg resampling: http://www.hydrogenaudio.org/forums/index....showtopic=79106 (http://www.hydrogenaudio.org/forums/index.php?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.
Title: ffmpeg vs. SoX for resampling
Post by: mavere on 2013-02-06 01:58:06
I’m no authority, but there’s always good old http://src.infinitewave.ca/ (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.
Title: ffmpeg vs. SoX for resampling
Post by: IgorC on 2013-02-06 02:43:41
http://src.infinitewave.ca/images/Tone/ffmpeg.png (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.
Title: ffmpeg vs. SoX for resampling
Post by: Alexey Lukin on 2013-02-06 03:33:38
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).
Title: ffmpeg vs. SoX for resampling
Post by: nu774 on 2013-02-06 04:06:15
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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86676&view=findpost&p=788882)
It seems that their left hand doesn't know what the right hand is doing.
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-06 06:48:03
ffmpeg's resampler isn't that bad ...

You're right, it isn't that bad, it's worse—see esp. 2nd graph above. (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=99286&view=findpost&p=823268)
Title: ffmpeg vs. SoX for resampling
Post by: LithosZA on 2013-02-06 07:17:02
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
Title: ffmpeg vs. SoX for resampling
Post by: ozok on 2013-02-06 12:01:14
zeranoe kindly supplied it after my request.
Title: ffmpeg vs. SoX for resampling
Post by: soulsearchingsun on 2013-02-06 13:34:35
So, where is TOS#8 when everyone agrees on looking at graphs? Not trying to troll, I just smell some bigottery.
Title: ffmpeg vs. SoX for resampling
Post by: pdq on 2013-02-06 13:46:30
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.
Title: ffmpeg vs. SoX for resampling
Post by: db1989 on 2013-02-06 14:27:19
So, where is TOS#8 when everyone agrees on looking at graphs? Not trying to troll, I just smell some bigottery.
There’s no problem with discussing theoretical degradation of signals. IMHO, this (the degradation, not the discussion!) should be avoided wherever possible, whether we can hear it or not. If anyone had said ‘Yeah, it looks awful, and it sounds even worse!’, then TOS #8 might be relevant. I suspect that FFmpeg is encroaching onto audible territory, but I make no claim either way: rather, my point is that there’s no need for it to degrade the signal that much when other algorithms produce conversions that are many times cleaner.
Title: ffmpeg vs. SoX for resampling
Post by: [JAZ] on 2013-02-06 22:36:00
As always, there is tradeoff between speed and accuracy, and in this field, there's even different techniques in play.


There are two good ways to resample:

- Using SINC ( sin(x)/x ) interpolation.
- Using a decimator/interpolator combination.

In both cases, a filter is needed to reconstruct the signal, and the quality of that filter reflects how fast and how clean it is in removing frequency imaging, without adding other unwanted distortions.


Both are relatively slow (They migh be "fast" for downsampling a single stereo sample from 96Khz to 44.1Khz, but now think about a realtime sampler like BASSMIDI, FluidSynth, or any other Soundfont player, where you not only play several streams, but also change their speed while playing).


So there have always existed other "resamplers" (not in the academic sense, but approximations) like:

- ZO (Zero order, or sample Hold). The fastest and worst of them all (See the graph of Secret Rabbit Code, ZOH).
- Linear interpolation.  Quite an improvement over ZO, and still fast (This was being used in 16 and 32 channel trackers back in 1992-1996 with 386 and 486 PC's! See Secret Rabbit Code, Linear. One can apply a filter with this type of interpolation, like in Wavosaur Linear, but it sort of defeats the purpose)
- Cubic interpolation. Cubic interpolation, and other polynomial interpolators are an advancement over linear interpolation, approximating the signal using polinomials. This generally lowers aliasing notably, but they still miss a filter. (See Renoise cubic, or OpenMPT polyphase, which are, again, realtime multichannel trackers with realtime virtual effects).


Any SINC interpolator should give a clean signal, but it is at least 4 times slower than cubic interpolation. It can filter by itself, but to be of good quality, it gets slower (because it needs more taps).


So, while a product that is specific to change the sample rate of a signal should have a good resampler, one should not think that it is the only reasonable way to resample.
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-07 07:57:37
So, where is TOS#8 when everyone agrees on looking at graphs? Not trying to troll, I just smell some bigottery.

I doubt you'd be happy if a straight PCM file conversion (say, from AIFF to WAV) introduced artefacts; why settle for less when resampling is involved?  Even if you can't hear the artefacts immediately, you run the risk that you might hear them later (e.g. on a better system, or after further processing).
Title: ffmpeg vs. SoX for resampling
Post by: phofman on 2013-02-12 14:01:59
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.


Do I understand correctly Audacity 2.0.3 is using new ffmpeg through which it uses libsoxr for the resampling? I would like to add a new resampling option to linux alsa rate plugin. Until recently I thought sox implementation was the best from the quality/speed POW. Using a library compatible with libsamplerate API would make the addition simple as libsamplerate is already supported by the plugin.

Thanks for the info.
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-12 15:13:29
Audacity are using libsoxr directly (native API). LameDrop OTOH, is using the libsoxr's libsamplerate-like API. 

If you're linking to libsamplerate dynamically, you may be able to try out libsoxr before any recompiling, by simply moving/renaming the libsoxr-lsr.so in place of the libsamplerate one (I tried this successfully with pulseaudio and saw a 4-5 times speed up @ SRC_SINC_MEDIUM_QUALITY).

Note however, that varying the sample-rate in real-time is only supported in libsoxr through it's native API, so this trick wouldn't work in that case.

HTH.
Title: ffmpeg vs. SoX for resampling
Post by: saratoga on 2013-02-12 15:50:28

As always, there is tradeoff between speed and accuracy, and in this field, there's even different techniques in play.


There are two good ways to resample:

- Using SINC ( sin(x)/x ) interpolation.
- Using a decimator/interpolator combination.

In both cases, a filter is needed to reconstruct the signal, and the quality of that filter reflects how fast and how clean it is in removing frequency imaging, without adding other unwanted distortions.


Aren't these two ways of implementing essentially the same process since the decimating/interpolating filter will probably have pretty close to a sinc form?

FWIW, I would add polynomial interpolation as the main alternative to sinc interpolation.  Most software uses one or the other.
Title: ffmpeg vs. SoX for resampling
Post by: halb27 on 2013-02-12 17:30:26

... Any SINC interpolator should give a clean signal ...

Can you tell me please which software uses SINC?
Title: ffmpeg vs. SoX for resampling
Post by: [JAZ] on 2013-02-12 19:25:57
@ halb27:  I haven't checked other software, but a sinc method is implemented in Psycle (And at least back to 2003 or so, there was a tracker name Aodix that had a 64point sinc interpolator, for non-realtime rendering).  Here you can see the code of Psycle:

http://sourceforge.net/p/psycle/code/10455...rs/dsp.hpp#l544 (http://dsp.hpp)
search for: static float band_limited

The sinc table is calculated in this other file, and a blackman window is applied to make it finite.
http://sourceforge.net/p/psycle/code/10455...helpers/dsp.cpp (http://dsp.cpp)

This implementation still lacks a filter (I am trying to find a good one that doesn't require too much lookahead, but I might end calling soxr variable rate if I can't find a good way to do it).
I have a file as old as 2001 (I had to doublecheck to be sure of the year), that shows a sinc interpolator and applies a filter modifying the sinc speed. But this way of filtering decays slowly and in what i've tested, alters the frequencies too.




@saratoga: I am not an expert in DSP or maths (I did study the fourier transform at the university, but was applied to signals in general, not specifically to sound).
But with my knowledge of resampling (i.e. what I've tried to know), the sinc interpolation is considered the ideal (which also means not possible in finite time/signals) resampling method because it is the response or an ideal brickwall lowpass filter. Real implementations have to window the sinc in order to make it finite, and in this way, limit the amount of samples needed to calculate the output. (See Psycle's implementation).

In contrast, decimating and interpolating is a two step method which firstly upsamples using the zero-stuffing method, applies a lowpass filter at the lowest of the two samplerates, and then downsamples by getting directly the samples from the lowpassed signal. The difficult part is getting the values to what upsample, wich is the common minimum multiple. (erm.. spelling?)
In some way, this is how a DAC works (except that then, the result is a continuous signal).


I have included the polynomial interpolators in the "other resamplers", since they are, in some way, approximations, or concepts applied to sound when sometimes they originated in graphics ( splines, for example, is more about visuals than samples).
Title: ffmpeg vs. SoX for resampling
Post by: lvqcl on 2013-02-12 19:39:08
The sinc table is calculated in this other file, and a blackman window is applied to make it finite.

AFAIK LAME also uses blackman windowed sinc.
Title: ffmpeg vs. SoX for resampling
Post by: 2012 on 2013-02-13 14:49:07
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.


I would like to add a new resampling option to linux alsa rate plugin.


I already did this. Replicating the libsamplerate code in alsa-plugins with some gluing just works (with some quality modes).

Here is a patch that implements soxr_lsr_{HQ,MQ,LQ} :
http://ompldr.org/vaGc3Ng/Initial-soxr-lsr-support.patch (http://ompldr.org/vaGc3Ng/Initial-soxr-lsr-support.patch)

I shared more info here:
http://www.hydrogenaudio.org/forums/index....st&p=817595 (http://www.hydrogenaudio.org/forums/index.php?showtopic=98306&view=findpost&p=817595)
Title: ffmpeg vs. SoX for resampling
Post by: knutinh on 2013-02-13 15:04:24

@saratoga: I am not an expert in DSP or maths (I did study the fourier transform at the university, but was applied to signals in general, not specifically to sound).
But with my knowledge of resampling (i.e. what I've tried to know), the sinc interpolation is considered the ideal (which also means not possible in finite time/signals) resampling method because it is the response or an ideal brickwall lowpass filter. Real implementations have to window the sinc in order to make it finite, and in this way, limit the amount of samples needed to calculate the output. (See Psycle's implementation).

In contrast, decimating and interpolating is a two step method which firstly upsamples using the zero-stuffing method, applies a lowpass filter at the lowest of the two samplerates, and then downsamples by getting directly the samples from the lowpassed signal. The difficult part is getting the values to what upsample, wich is the common minimum multiple. (erm.. spelling?)
In some way, this is how a DAC works (except that then, the result is a continuous signal).

The "ideal" lowpass filter is a sin(x)/x function of infinite extent. Sampling theory tells us that using such a filter allows for perfect sampling and perfect reconstruction of a continous signal up to (but not including) fs/2.

If you think about it, resampling can be considered to be a reconstruction/sampling process, the same theory applies.

There are many ways to think about this, and many ways to optimize the processing (avoiding multiplications that does not affect the output is a significant one). I believe that you come a long way by only considering lowpass filter design. Linear interpolation, cubic interpolation, (windowed) sinc can all be considered lowpass filters.

-k
Title: ffmpeg vs. SoX for resampling
Post by: saratoga on 2013-02-13 17:32:33

@saratoga: I am not an expert in DSP or maths (I did study the fourier transform at the university, but was applied to signals in general, not specifically to sound).
But with my knowledge of resampling (i.e. what I've tried to know), the sinc interpolation is considered the ideal (which also means not possible in finite time/signals) resampling method because it is the response or an ideal brickwall lowpass filter. Real implementations have to window the sinc in order to make it finite, and in this way, limit the amount of samples needed to calculate the output. (See Psycle's implementation).

In contrast, decimating and interpolating is a two step method which firstly upsamples using the zero-stuffing method, applies a lowpass filter at the lowest of the two samplerates, and then downsamples by getting directly the samples from the lowpassed signal.


A lowpass filter is a windowed sinc.  So you propose two methods, one of which fits a windowed sinc to calculate values, and another which ... fits a windowed sinc to calculate values. 

These are just two ways of implementing the same algorithm, which is preferred is just an implementation detail that depends on the exact needs of the resampler.  Trying to draw some abstract distinction between them is silly.


I have included the polynomial interpolators in the "other resamplers", since they are, in some way, approximations, or concepts applied to sound when sometimes they originated in graphics


They didn't originate in graphics, they originated in 17th century boundary value problems.  They're general numerical techniques, as such both polynomial and windowed sinc interpolation are widely used in audio and graphics. 


( splines, for example, is more about visuals than samples).


What is it you think digital images are made of if not samples?
Title: ffmpeg vs. SoX for resampling
Post by: phofman on 2013-02-13 19:29:40
I already did this. Replicating the libsamplerate code in alsa-plugins with some gluing just works (with some quality modes).


Fantastic, great work. Please would you mind sending the patch to the alsa-devel mailing list to have it included upstream? It would help a number of people. Thanks a lot in advance.
Title: ffmpeg vs. SoX for resampling
Post by: [JAZ] on 2013-02-13 21:11:01
@ saratoga:
As I said, my knowledge of this is average, and I might even use the wrong words sometimes.

That said, I'm not sure I agree completely with what you say.
A -> B  does not necesarily equal B -> A

A sinc filter (which has a sinc function as its impulse response) is a lowpass filter, but a lowpass filter is not necesarily a sinc filter. I don't have the math knowledge to make filters (or understand fully the poles and zeroes), but I understand that the polynomials generated are not just "sinc aproximations".
Just like the most basic lowpass filter is not a sinc filter:  o0 + (i1-o0)*FC


You simplified the two methods I described as to using a lowpass filter. In essence, this is true (we want to get a lowpassed signal to avoid aliasing), but I wanted to differentiate the theory from the result. Example:
A linear interpolation is an intuitive way to find the value between two points, but it is not based on theory that reconstructs the path that a continuous bandlimited signal would take.

In that way, i made a distinction between the sinc method and the decimate/interpolate method because they do have a theory related to sound behind them, but it is not the same theory. (Or, let's say, one is the theory directly, and the other is a derivate of the theory, as in the second one does not necesarily imply a sinc filter, even though it is the ideal one).
I can accept that the decimate/interpolate method is akin of doing a fixed point implementation of a floating point one, so in essence, they do the same. But as an implementation, they reach the solution differently.


About polynomials, I admit I might have been too quick. I overlooked the math history, but again I was mentioning concrete methods while you mention the concepts on which they are based.  Polynomials serve many purposes, and not all of them apply to bandlimited signals.
I mentioned graphics, because the word "spline" does describe that, a line (a visual concept).

Images are indeed made of samples, but.. what is the equivalent shannon theorem for images? I could accept that images are bandlimited (there's a finite spectrum represented by the sampled image colours, but even then, the RGB points are the representation of the image in the time domain?)
Title: ffmpeg vs. SoX for resampling
Post by: Rotareneg on 2013-02-14 04:39:13
Images are indeed made of samples, but.. what is the equivalent shannon theorem for images? I could accept that images are bandlimited (there's a finite spectrum represented by the sampled image colours, but even then, the RGB points are the representation of the image in the time domain?)


You might want to look at the Wikipedia article on the Nyquist–Shannon sampling theorem (http://en.wikipedia.org/wiki/Sampling_theorem#Application_to_multivariable_signals_and_images) as it has a section specifically about multivariable sampling (images for example.)
Title: ffmpeg vs. SoX for resampling
Post by: saratoga on 2013-02-14 06:01:47

@ saratoga:
As I said, my knowledge of this is average, and I might even use the wrong words sometimes.

That said, I'm not sure I agree completely with what you say.
A -> B  does not necesarily equal B -> A

A sinc filter (which has a sinc function as its impulse response) is a lowpass filter, but a lowpass filter is not necesarily a sinc filter. I don't have the math knowledge to make filters (or understand fully the poles and zeroes), but I understand that the polynomials generated are not just "sinc aproximations".


I think you misunderstand.  My point is that the two methods you suggested (sinc interpolation and decimator/interpolator) are basically the same thing. 

I brought up polynomials as an example of a different approach.  My point is that there are basically two families of resamplers in widespread use: sinc-based and polynomial-based.


A linear interpolation is an intuitive way to find the value between two points, but it is not based on theory that reconstructs the path that a continuous bandlimited signal would take.

In that way, i made a distinction between the sinc method and the decimate/interpolate method because they do have a theory related to sound behind them, but it is not the same theory.


To be clear, the decimate/interpolate method always uses a sinc filter (or close approximation thereof) in practice.  Linear interpolation can be combined with decimation/interpolation (using a sinc filter), but in practice never is because that rather defeats the purpose. 


I can accept that the decimate/interpolate method is akin of doing a fixed point implementation of a floating point one, so in essence, they do the same. But as an implementation, they reach the solution differently.


I don't accept that.  What does decimation/interpolation have to do with machine precision?  You can do it integer, fixed point, floating point, decimal, whatever. 

I mentioned graphics, because the word "spline" does describe that, a line (a visual concept).


huh?


Images are indeed made of samples, but.. what is the equivalent shannon theorem for images? I could accept that images are bandlimited


Pixels are samples in 2D spaces, just as voxels are samples in 3D spaces.  The sampling theorem is universally applicable to all N-dimensional spaces. 


(there's a finite spectrum represented by the sampled image colours, but even then, the RGB points are the representation of the image in the time domain?)


An RGB image is simply 3 independent grayscale images recorded using a color filter.
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-14 07:04:21
Can you tell me please which software uses SINC?

First, go to http://src.infinitewave.ca/ (http://src.infinitewave.ca/)
For the top graph, select Test Result = Impulse, then press the > button to look at each resampler in turn:
So the answer is they all use use sinc approximation, but the closer the approximation, the closer the result to the 'ideal'.
Title: ffmpeg vs. SoX for resampling
Post by: halb27 on 2013-02-14 08:07:00
So SSRC high precision is a good approximation to SINC?
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-14 12:48:04
SSRC uses kaiser-windowed sinc.
Title: ffmpeg vs. SoX for resampling
Post by: halb27 on 2013-02-14 18:03:32
Sorry, I don't know what this means in terms of quality. Is SSRC high precision a good choice in this respect?
Title: ffmpeg vs. SoX for resampling
Post by: saratoga on 2013-02-14 18:12:24
Sorry, I don't know what this means in terms of quality.


You can check the quality using this link:

http://src.infinitewave.ca/ (http://src.infinitewave.ca/)

As you can see it is very good.
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-14 21:28:43
It has some problems upsampling though:

(http://i48.tinypic.com/352i5g3.png)
Title: ffmpeg vs. SoX for resampling
Post by: halb27 on 2013-02-14 22:05:33
No problem for me, I'm only interested in downsampling.
Title: ffmpeg vs. SoX for resampling
Post by: saratoga on 2013-02-15 00:53:00
It has some problems upsampling though:


Are you referring to the background signals?  If so, I wouldn't really call them a 'problem' given that they're spectrally flat and -110dB below peak.
Title: ffmpeg vs. SoX for resampling
Post by: Wombat on 2013-02-15 02:42:48
It has some problems upsampling though:

Heh! Just think about what the main purpose of SSRC back in 2001 was when Naoki wrote this little gem. The need of upsampling anything to 192kHz was most likely as far away as rabbits taking over planet mars
Title: ffmpeg vs. SoX for resampling
Post by: bandpass on 2013-02-15 06:00:30
Are you referring to the background signals?  If so, I wouldn't really call them a 'problem' given that they're spectrally flat and -110dB below peak.

Greenish on the graph, so a few dB higher than that (which puts it in the same ball-park as ffmpeg, artefact-wise). BTW, ffmpeg 1.1.1 is now up at http://src.infinitewave.ca/ (http://src.infinitewave.ca/)