Before you resist any further.
There is the original continuous Fourier transform expressed through integral from minus to plus infinity. That Fourier transform spectrum is a continuum (opposed to discrete set) of obviously periodic sine waves.
Because of the continuum many practical non-periodic functions can be represented by superposition of periodic sine waves.
At the moment you use DFT (Discrete Fourier Transform), "you are toast".
The set of sine waves in DFT is discrete, that't why when you reconstitute input signal from its DFT spectrum, you produce a periodic function even if the input function is not periodic.
If you take, for example, exponential decay: f(t) = exp(-t / tau) where tau > 0, and run DFT on it, and then reconstitute the function, then within the N samples the reconstituted function will perfectly match the input one, but outside the buffer it will mismatch.
A numerical example. Suppose N = 8, and sampling period is 1 and tau is 1. I.e. our f(t) is exp(-k) where k is sample number.
Since N = 8, we have:
f(0) = 1
f(1) = exp(-1) = 0.367879,
f(2) = exp(-2) = 0.135335,
...
f(7) = exp(-7) = 0.000911882 - this is our last sample,
f(8)= exp(-8) = (0.000335463 - first sample after our N = 8 samples.
If you run perfect DFT, you'll get the same numbers for f(0) .. f(7), but for f(8) you'll again get 1 because for our N = 8 f(8) is the same f(0) because of periodicity.
No windowing can fix this. That's why simply wait until non-periodic components of your signal die down/out.
Oh, I actually already figured out that it was non-periodic spectra causing the problems, though without the confirmation of math. I knew that windowing was only a workaround for that.
But about windowing distortions, I had the idea that the Hann windows, taken sequentially, overlapped and due to the symmetric bell curve, summed to 1 all across like you would hope for the crossover points of a speaker, thus resulting in no distortion. It seemed so elegant to me and nothing in the articles I (tried to) read suggested otherwise. Is this not how it works? Again I thank you for shining some light on my dim constructions, and this knowledge will be helpful to users new to simulation.
Also: it seems you have adequate knowledge to implement things such as FFT resampling, which to my knowledge is exact as opposed to interpolation, which can be no more than an approximation. There are image editors that do a graphical FFT of the image which you can draw or erase on, and this allows you to do interesting things like remove noise from the image without altering other details. Couldn't the same be done with FFT on a music file? Furthermore, FFT image resizing would also be better than any interpolating resizer, and would be very useful on small images that would be corrupted by interpolation. It surprises me that no one seems to have done this yet, except for researchers:
http://www.kgsepg.com/download.php?...icient,_high_quality_volume_resampling_in.pdf
I would like to try something like this with FFTW, but I just started learning assembly as my first language (Only reasonable...?) and I can tell that may be a long ways off.
But about windowing distortions, I had the idea that the Hann windows, taken sequentially, overlapped and due to the symmetric bell curve, summed to 1 all across like you would hope for the crossover points of a speaker, thus resulting in no distortion. It seemed so elegant to me and nothing in the articles I (tried to) read suggested otherwise. Is this not how it works? Again I thank you for shining some light on my dim constructions, and this knowledge will be helpful to users new to simulation.
Also: it seems you have adequate knowledge to implement things such as FFT resampling, which to my knowledge is exact as opposed to interpolation, which can be no more than an approximation. There are image editors that do a graphical FFT of the image which you can draw or erase on, and this allows you to do interesting things like remove noise from the image without altering other details. Couldn't the same be done with FFT on a music file? Furthermore, FFT image resizing would also be better than any interpolating resizer, and would be very useful on small images that would be corrupted by interpolation. It surprises me that no one seems to have done this yet, except for researchers:
http://www.kgsepg.com/download.php?...icient,_high_quality_volume_resampling_in.pdf
I would like to try something like this with FFTW, but I just started learning assembly as my first language (Only reasonable...?) and I can tell that may be a long ways off.
"I had the idea that the Hann windows, taken sequentially, overlapped and due to the symmetric bell curve, summed to 1 all across" - that is correct. It is also correct for Hamming window. And for triangular window. And probably for many others.
However, this is absolutely correct for stationary signal which, because it is stationary, is also periodic.
With non-stationary signal not everything caused by the amplitude modulation inflicted by windowing cancels out, even though for the majority of practical applications it's quite OK. The bigger is N, the better.
Regarding resampling - how about using "off the shelf" SoX ( SoX - Sound eXchange | HomePage ) polyphase resampling ? See, for example, Sox Resample and Polyphase rate changes and there look for "polyphase conversion".
Anyway, you can't fool nature/math. Resampling is interpolation over 'sinc' function ( Sinc function - Wikipedia, the free encyclopedia ), in order for resampling to be perfect one needs full length 'sinc' function which is infinity.
However, one can choose sufficiently long for any required accuracy length of 'sinc' function.
...
In simple English: overlapping windows is good for streaming audio.
If you are iteratively running simulations and calculating THD or DFT, with small changes to the circuit, maybe you could speed up the settling time by specifying all of the initial conditions, with .ic, e.g. all of the capacitor voltages, et al.
I have found one way to eliminate the sine wave starting spike at turn-on is to add another source with the frequency {Freq+Freq/numcyc}. This gives the input signal a sine burst-like behavior, with an envelope spanning the simulation range. The two sources initially cancel. There is still some abruptness, but it's much reduced from an ordinary sine and it decreases inversely with the total simulation time, as the second source frequency moves closer to the fundamental. This method allows to not use any rev cycles, so simulation starts plotting from the beginning. It is especially helpful in troubleshooting anomalous behavior and oscillation that slows the simulator to a crawl before the plotting starts. It also gives a much better indication of dynamic behavior. I kinda wonder if I shouldn't have been doing this all a long.
The problem with this approach is that it's unconventional, so the results cannot necessarily be interpreted normally, although in my experience it gives equivalent THD figures. One problem is that the peak level is twice as high as the effective level where distortion is measured, so you can't measure distortion at levels higher than half clipping volume.
The problem with this approach is that it's unconventional, so the results cannot necessarily be interpreted normally, although in my experience it gives equivalent THD figures. One problem is that the peak level is twice as high as the effective level where distortion is measured, so you can't measure distortion at levels higher than half clipping volume.
Kean, you seem to approach the problem pure from electronics side, not IT/software side (I thought you learn assembly language?).
From software side, we look at the speed of processing from how the software is written. How it manages memory and files.
From software functionality point of view, we may be interested in some setups and commands such as .SAVE, .SAVEBIAS/.LOADBIAS.
From software troubleshooting point of view, we may be interested in overflows and flaws in the algorithms. Honestly, I think something is wrong but I still don't know what/why.
From software side, we look at the speed of processing from how the software is written. How it manages memory and files.
From software functionality point of view, we may be interested in some setups and commands such as .SAVE, .SAVEBIAS/.LOADBIAS.
From software troubleshooting point of view, we may be interested in overflows and flaws in the algorithms. Honestly, I think something is wrong but I still don't know what/why.
I never thought of making a rig based on savebias stuff. I would have explored this earlier, but when designing an amp so much changes, the operating points are changing all the time, so the saved values are always invalid, so you will have to run extra simulation every time to find the right operating point anyway.
I wondered if something were wrong with LTSpice. After learning more about FFT I think this is normal, it's just other simulators hide it or work around it somehow. There would not really be a problem if the LTSpice solved the operating point to a reasonable accuracy each time.
I wondered if something were wrong with LTSpice. After learning more about FFT I think this is normal, it's just other simulators hide it or work around it somehow. There would not really be a problem if the LTSpice solved the operating point to a reasonable accuracy each time.
You'll see how I set it up in your simulation file above. Run the .op command and note the voltages at the input and feedback caps with the original circuit. Then add that offset to the AC input voltage source and replace the feedback cap with a fixed voltage source. Short the input cap out and run the sim for a long time period because there are still a lot of time constants in the circuit.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.