I was hoping someone could explain, perhaps with some math, if multiple resampling operations are never, sometimes, or always a lossless process?

Just some examples. Assume nothing else is done to the PCM, other than the resampling itself:

44.1 --> 88.2 --> 44.1 (never lossless, sometimes lossless, always lossless)

44.1 --> 48 --> 44.1

44.1 --> 192 --> 48 --> 44.1

etc etc

Any resampling is never lossless. Resampling, by definition, changes the audio data.

In general practice those operations would not be lossless. However, I believe that with care they could be lossless.

For example, the 44.1 --> 88.2 --> 44.1 could easily be lossless because the first operation is simply generating in-between samples (the original samples can be retained) and then the last operation could simply delete the generated in-between samples. That would be lossless.

The 44.1 --> 48 --> 44.1 case is much more difficult, but I believe that a lossless scheme could be devised because the 48 version has redundant information just like the 88.2 case above (but in a much more complex way). I have spent some time figuring out how a lossless version of this could be implemented, but I'm not sure it has any real value.

I can't explain it in mathematical terms, but if you understand how digital (sampled) audio is stored, I think you can figure-out this stuff by yourself. There is a brief introduction to digital audio on the Audacity website.

Since we don't know what's in-between the samples, we have to interpolate (as I'm sure you know). Nothing is lost when you upsample to an exact multiple. But when you upsample to a non-even multiple, the original data-points are permanently lost and new data-points are generated via interpolation. If you re-sample back-down to the original sample-rate, these original data-points can only be approximated with a new interpolation.

Here's something to think about... When you interpolate and throw-away the original samples, you can (and often do) reduce the peak value of any given half-cycle. But, you can never increase the peak with interpolation. So.... The original peaks cannot be exactly restored by re-sampling back to the original sample-rate. In fact, you are likely to reduce the peaks again with the 2nd interpolation!

I think most real-world resampling uses filtering (even upsampling*). In that case, there's lots of mathematical manipulation of every sample, and all of the samples will be altered to some extent, even with exact 2X or 4X upsampling. (A filter will usually introduce "rounding effects".)

Of course, I don't worry about these tiny, inaudible, side-effects...


* P.S.
If you want to know why filtering might be used with upsampling, think about what a 10-20 kHz "sine wave" on a CD "looks like" without any filtering.... It looks more like a square/rectangular wave with a frequency that jumps-around between 22.05kHz and 11.025kHz... Interpolation will "smooth-out" the waveform to some extent, but you can still end-up with a screwy waveform that the higher sample-rate Nyquist filter won't properly re-shape.

This is not true. Unless you are using 1st order (linear) interpolation, it's quite conceivable (and common) to generate peaks above the two neighboring values.

In theory resampling up and then back down can be lossless with infinite precision and 2n-1 tap sinc interpolation (for a waveform of n samples). In practice you will always lose data.

More (very technical) information is available here - http://ccrma-www.stanford.edu/~jos/resampl...erpolation.html
The last image on this page also shows an example of reconstructed samples above the original.

Eeek! Now, we're in danger of clipping.... Of course, we can compensate for that... which involves more adjustments, and approximation/interpolation, and maybe rounding/truncation. That's probably one of the reasons that practice deviates from theory.... but I'm in over my head.

The "technical link" is way beyond my understanding of DSP... But, with "Fourier Transforms" and "bandlimited interpolation", it appears (to me) to be something like a combination of filtering and interpolation (which is what I would expect).

P.S. For me, it just seems that there will always be uncertainties, because we are generally stuck with integers for both the "X" and "Y" values. (Unless we are using floating-point audio files, which gives us more resolution in the "Y" direction.) All of our calculations/manipulations, which don't usually generate exact integers, have to be rounded to the nearest integer. Once we've done that, we've lost data, and we can never get that data back.

If you consider the transformation:

A->B->A'

Where A is a set of data points and B is the set of transformed data points, as long as every set A results in a unique set B, it is in theory possible to perform the inverse transform B->A. An extreme example of how to implement this is to generate every possible set A' and see if it transforms to B. The one that transforms to B is therefore the inverse transform of B. One would hope that there is a more practical way to implement this.

In this case as long as A->B is an upsampling operation, the results B should be unique. For downsampling this is obviously not the case.

The problem here is quantization. Ignoring the effects of bit depth, what you have said is theoretically correct. As soon as you introduce quantization, unique A can map onto non-unique B. The most obvious case for integer quantization is, as DVDdoug pointed out, clipping.

To answer the original question, for all the cases. In practice? No. In theory? No. With perceptual transparency? Yes, most likely.

Well, it's not clear what the OP was after. But it is certainly possible (and trivial) to design a complementary pair of programs that would do high-quality 44.1 --> 88.2 --> 44.1 resampling losslessly.

But yes, in the other cases the possibility of clipping would limit the quality of the resampling that you could perform and still have a lossless process.

Again, I'm talking about custom programs designed for this exact purpose. Any real-world resampling will always be irreversible.

Assuming the same bit depth for A and B, the total number of possible sets A is 2^N, where N is the total number of bits in A. If upsampled to twice the sampling frequency then the total number of possible sets B is 2^2N, so there are 2^N possible sets B for every single set A. This pretty much rules out B randomly happening to match more than one set A.

As for clipping, for two different sets A to clip identically to set B also seems to me to be highly improbable, though I don't have a proof for that.

Can someone explain (or point to a resource) how the interpolation in the upsampling can cause clipping?



No other operations occur, other than the upsampling and downsampling.



And how about non-multiple resampling like 44.1 --> 48 --> 44.1 ?

If, for example, the data are upsampled 2x then the standard way of doing this is by filling in zero for every other point, then applying a FIR filter of some length to create meaningful values for them. This FIR filter will have some coefficients that are less than one, some that are negative, and some that are greater than one. If the data happen to work out just right then the coeffecients that are greater than one will not be sufficiently cancelled by the ones that are negative, and the resulting value will be greater than any of the values that were being filtered.

Think of a sinusoidal waveform, with the sampled data having a value just before the maximum and one just after. Resampling to generate the point between them will produce a value greater than either of them, rounding off the top of the sine wave, or, perhaps, clipping at full scale.

The link I gave to the jos resampling paper shows a perfect example

Define "lossless". If I upsample by 2, and downsample by 2, but slip one sample at the 2x rate, with filters that have both ripple and rejection below .24 LSBs, and I do this in duo-deca-precision, is that lossless or not?

Let's say I take a 44.1 cd track and upsample it to 88.2 to do some editing on it, and my client asks for the results in both flavors, 88.2 and 44.1, for whatever reason.

From 00:00 - 00:12, I create a fade in, and from 03:47 - 04:02, I create a fade out. I decide everything else sounds fine and give my client the resulting 88.2 wav and a downsampled 44.1 wav.

Ideally, (00:12 - 00:3:47) in the downsampled 44.1 version would be absolutely identical to that same segment in the original 44.1 cd track. Correct or no?

No, not identical, especially if upsampled and downsampled to 16 bits. Upsampling will create roundoff errors (or dither may be applied) and the same for downsampling. If you want the final 44.1 to be identical in the middle section then apply the fade-in/out at 44.1, then upsample that to 88.2

I was under the impression dithering was only used when changing word-length (16 -> 24 bits, 24 --> 16 bits, etc). Is dithering required and/or standard for sampling rate conversion also?

Normally you would prefer to perform any processing, such as resampling, at a higher bit depth so that roundoff errors are insignificant, then dither when you reduce to the final bit depth. Sampling rate conversion, since you are multiplying data points by fractional values and then summing them, gives you extra bits that are either carried along in the calculation or truncated or dithered.

In this case, if you upsampled to 88.2 and kept 24 bits, then downsampled, still in 24 bits, then you would dither to go back to 16 bits. But if you upsampled to 88.2 16 bits then you would want to dither at this point, as well as when you downsampled to 44.1 and 16.

As a rule of thumb, I suppose, you will probably want to dither every time you process and save as 16 bits, but if you save as more than 16 bits then don't dither.

While there are no doubt a variety of ways to go about the process, in practice, resampling from 44.1kHz to 88.2kHz is not simply the interpolation of new samples between the existing samples. Every sample value in the 88.2kHz result is a recalculated vaule. I’m writing about what CoolEdit does, but most of us know that CoolEdit & Audition do better quality resampling than most programs.

How is a "recalculated" value different to an "interpolated" value? Sure, it's not a linear interpolation, but it's still interpolation.

If you have perfect filters, no quantisation, no time shift - then yes.

If you have a system specifically designed to be reversible, then yes.

Otherwise, no. You can't get the same numbers back that you started with.

Typically, within the passband of the real world (i.e. imperfect) filters used, you will get the original signal back, but it will have some additional noise, and a fixed non-integer sample delay - either of which would prevent you from getting the same numbers back that you started with, but neither of which _should_ cause an audible change to the audio signal.

If you compared the original signal with the multiple resampled signal in the analogue domain it would be near impossible to detect a difference if you use good converters for the D/A and if you included a low pass filter in or after the D/A that was lower than the limit of the filtering using during the resampling.

The numbers may be different, but the signal they represent is the same - just time shifted slightly, with some amplitude- (and possibly phase-) changes at the top of the frequency range (where exactly? it depends on the filters used for resampling - there might be some distortion up there too).


Of course bad resampling could wreck the whole audible range, adding aliasing, phase distortion, amplitude distortion, more noise than necessary etc.

Cheers,
David.

I believe he was distinguishing between half of the values being the original values and the other half interpolated, vs. all of the values are the result of calculations and are not necessarily equal to the corresponding original point.

Oh, I see. I did seem to misunderstand his original post. The point remains, however, that for upsampling by an integer ratio, there is nothing to be gained by recalculating the original samples - interpolating the intermediate samples is all that needs to be done. This is a property that polyphase filter banks take advantage of to greatly increase the efficiency of operations like these.

Hopefully a simple example will illustrate. Suppose one has some sample points (measurements of something in the real world other than digitization of an audio signal). Suppose we plot those points on a graph. Then we draw connections between those points, defining a trend line for whatever it is we measured.

Any particular point along the drawn line may be considered an interpolation of the data between the measured end points of that segment. We have new (assumed or calculated) values, but the unchanged measured values are still part of out plot.

When CoolEdit/Audition (and at least some other programs) resample, say from 44.1kHz to 88.2kHz, we end up with twice as many samples. Each sample is a number. None of the numbers in that twice as many samples is the same as any of the numbers in the original samples. The program has not simply interpolated new values between the existing values, it has calculated the value for every sample of the result.

When doing editing inside of Audition on a 44.1/16 wav, does the edit operation (adding an effect for example) do any kind of internal upsampling such that the edit is higher precision and then downsampled when finalized? Or do I need to upsample the entire wav first?

I don't have Audition, but I did use Cool Edit back in the day and have been considering purchasing Audition.

It won't change the sampling rate, but it will work at higher numerical precision (i.e. bit depth) internally and dither back to 16-bit afterwards.

There's no need to change sampling rate, but working at higher bit-depth (or floating point) until you finalise the edit will be beneficial in reducing the accumulation of noise. Working in floating point also eliminates the danger of clipping distortion until you finally dither down to 16-bit after editing.

If it does do that, then it's a little odd. As far as I can see, integer upsampling can be performed optimally without changing the original samples. Remember, though, that this isn't linear (trend line) type interpolation - this is bandlimited interpolation.

I’m not explaining or defending, just pointing out what I see. If the original sample values are lost, because of whatever reason, then there is no mapping back to them with these kinds of calculations, no?

The bandlimited interpolation algorithm offered in that paper seems to be geared towards a hardware implementation. I wonder if it still holds merit with the growth of software-based systems?

Also, can someone provide real-world examples of the two scenarios mentioned (which I bolded)?

Fair enough, sorry for the pointless argument.


Actually, I can - but not from the audio world. My research work is on the simulation of radar/sonar return signals. One of the important phenomena in radar is the Doppler shift - this is the frequency (or phase which is equivalent) shift caused by scattering of the radar signal by targets moving relative to the receiver or transmitter. As the Doppler shift can change on the order of the length of the signal (especially for continuous wave (CW) systems), the simulator needs to be able to apply time-dependent "warping" on the phase and frequency of the signal. We use a similar method to simulate the effects of local-oscillator phase noise on the received signal.

In audio, this same approach could be used to simulated Doppler in a game's audio processor, or simulate the effects of time dependent phase and frequency shifts on a signal (imagine simulating a trombone).

Another application where the change in frequency with time is significant is SETI, the search for extraterrestrial intelligence. In analyzing the data looking for a coherent signal, one of the factors which is taken into account is that a signal source may be in orbit around a planet. This would result in "chirping". The SETI at home application applies varying degrees of skew to the data in order to cancel this effect.

Sample playback synthesis (commonly knows as "samplers") such as the E-mu Emulator or Akai S1000