Thanks for your time...
If it helps, as you note it does, the concept of using the "infinite silence" which is often at the start and end of a piece of audio program is a great idea. Yes in that "silence" is a lot of information that has a direct relationship to the program itself. Often this "silence" is used by noise reduction tools to "sample" the characteristics of the background noise to be reduced.
To use the "infinite silence" to inform an upsampling of the program material seems like a great idea. It's almost AI, as it is going to project some of the characteristics of the "silence" into the program. Could have other uses in terms of simulations and convolusions used in reverb plugins etc.
That's some interesting stuff you mentioned. I really appreciate your feedback, and will try to send you a "thumbs-up" when I can get the Forum platform figured out... tried to send a beer, but couldn't seem to. I had almost wondered if the up-sampling (RUP) and noise reduction (QEAR) algorithms might have some uses in cryptography, cryptanalysis, and data-compression but I am shallow in my familiarity with those fields.
Hi DSP-Related Crew:
Results of of integrating some of deanpk's suggestions into the Restorative Up-Sampling algorithm, along with a substantially modified and, thankfully, less lengthy White Paper discussion are available at www.livingstonintegralstudies.com
I view the improvements that he has made possible through generous dialog as being quite marked. Only the DADiSP platform code is currently available, but I am pondering a MATLAB translation. I have yet to check my Noise Reduction (QEAR) outputs, as I get perhaps a little superstitious about looking success or failure in the mirror without the buffer of another human consciousness of good-will "holding space" for me, as it were, but I am waiting on feedback locally.
Although I haven't looked myself at anything other than the Restorative Up-Sampling (RUP) outputs, which I thought sounded good, the results of the (QEAR) Noise Reduction are available to you at the website.
I have written, run, and debugged some MATLAB code for the current versions of the RUP and QEAR algorithms, and this appears on the website posted earlier in this thread. Furthermore, I had embedded a scalar multiplier in the RUP code that seemed to be boosting the higher frequencies of the output at the expense of the lower frequencies. This misguided scaling factor was not called for by theory, and was situated in the middle of a 'for' loop... not the place to adjust final output levels.
Check out the results if so moved...
Again, thanks for your patience with my, perhaps, arcane way of using your forum, and...
Hi Winkie. By any chance would you have MATLAB code that implements your RUP and QEAR processes that you would be willing to share with us?
Hi Rick. I don't have any MATLAB code, but maybe I should, since it's a far more popular platform than DADiSP. I bought DADiSP with near to my last dime, and wouldn't want to study MATLAB coding on the internet in an effort to translate the code without having a chance to actually run and debug it with MATLAB running. Right now, I just can't afford MATLAB, but maybe someday I'll get it done if someone else doesn't do the translation first.
The (RUP) routine translation would likely be pretty straight-forward, but (QEAR) uses DADiSP's filtration module, and it would likely require some expertise to duplicate their process (which generates an impulse function for the filter and then, I think, convolutes it with the signal proper.) I may not be able to do that reliably, even if I had MATLAB, and get the same results as with DADiSP.
Of course, the main thing is to do the restorative up-sample that (QEAR) calls, pass that through a causal low-pass filter, and decimate the result down to the original sampling frequency... so long as a person can do that, any version of the QEAR algorithm written in MATLAB ought to be ok...
Hi Rick and DSP Readers:
I buckled down and wrote some MATLAB code, debugged and ran it on a newly purchased copy of MATLAB, and in the process, found an error in my DADiSP code which affected the output files on the website. I believe the error has been rectified, both in the MATLAB code for (RUP) and the DADiSP code as well. The output files on the website have been updated, and the code appears there. MATLAB code for (QEAR) is pending...
Thanks to Rick for a dialog which seems to have corrected a flaw in my reasoning.
Hi Winkie. I see your MATLAB code for your function 'A = rup(x,v)'. Can you tell use something about the variables 'x', 'v', and the output 'A'? That is, given 'x' and 'y' what should we expect 'A' to be?
I'd like to run your code but I don't know how to generate the 'x' and 'v' data.
I would take the data from a short sound-clip [or record yourself saying something, maybe in an animated voice (and with some percussive consonants) so that some higher frequencies are included.] Store this as an original .wav file for comparison after the fact. Then down-sample this file by a factor of maybe (2^3) or (2^4), so that the down-sampled file shows significant high-frequency loss when listened to. This down-sampled data is your (x).
(v), to get back to the original sampling frequency, is then equal to the exponent on your power of 2 down-sampling of the original signal (v = 3 or 4). Strictly speaking (RUP) is a separable subroutine of (QEAR), so after you listen to A and hear the restored high-frequencies, but mixed with some static, use output A as the input (y) to (QEAR) [MATLAB code posted on website] with (p)...the number of up-samplings "called" by (QEAR) before subsequent filtration and down-sampling to the base sampling frequency... equal to maybe 4 or 5 (p = 4 or 5). I have a hunch that if you down-sample the original to the extreme, quantization error and artifacts are magnified in the output of (RUP) [A].
I have been working on this project in isolation, and without communication, ideas die. I have reached out to a couple of forums, including DSP Related and a select few persons locally, in order to get some fresh air in my mind, needed to see errors (and there have been many) and find answers. There may still be errors, and in fact the whole idea may be a flop, but I figured it was worth the time. On that note, I should say, "I appreciate yours..."
Hi Winkie. I ran your MATLAB code but the following command gave me an error:
XX = F((N):((2*N)));
So I changed that command to:
XX = F((N):((2*N-1)));
Was my change the correct thing to do?
Hi Winkie. Below is my original .wav file (Capt Kirk saying, "Not chess Mr. Spock".):
Below is the original file decimated by a factor of eight:
After applying the decimated signal to your 'rup' routine, below is the output of your 'rup' code:
Rick: Sorry for the error, I labored with that one, too, for a while, and a (2*N) upper limit worked in DADiSP, but not in my MATLAB code. Then I found I was using the wrong array in the line Cnn=size(B), which should have been Cnn=size(C). I changed this in my hard-drive files but neglected to update the website until I saw your post just now. Thanks.
Don't know how much that will change your Captain Kirk output file (though I have a hunch it will be quite significant), but you might consider grabbing the updated (RUP) MATLAB code off the website, or, simpler, just changing that line in your copy of the code, and reinstating the (2*N) upper limit to XX=F((N+1):(2*N)) And then, if you still have the time and interest, running your sound files again, both through RUP with (v=3) and then maybe running the RUP-output through QEAR with (p = 4 or 5). I have debugged the MATLAB (QEAR) code on the website to where it will run without error, but I'm not as familiar with the way MATLAB does filters, so, having simply gone off a tutorial, I might have made an error in translation.
I have been thinking this morning about the source of static in the (RUP) outputs, and if we consider that most signals are not time-limited, just cut-off in their recording length... with "the band playing on"... then zero-padding is a distortion of the actual signal which the down-sample of the inverse DFT randomizes and imports into the signal proper. On the files I used, I could hear the restoration of high-frequency components, but along with static that may come from this explanation.
Pseudo-random noise often has a near Gaussian frequency distribution with its peak centered around half the sampling frequency, so assuming that the spectral "weight" of the noise remains near the same with restorative up-sampling, we can up-sample past our desired sampling frequency, and shift the bulk of that noise to ultra-high frequencies which can be filtered off before down-sampling to the desired frequency. That is what QEAR was designed, at least, to do.
Up-sampling well beyond the desired sampling frequency, followed by low-pass filtering and down-sampling back to desired base sampling frequency [as (QEAR) does] may still clean up much of the RUP residual noise to the point where our time spent on this is not wasted.
Maybe you could re-load the updated MATLAB code for both RUP and QEAR, and Captain Kirk could pay us another visit... ;) ?