In order to become familiar with the code and structure of Audacity and of wxWidgets, I started simply and added a small modification to Repair.cpp, of which the main purpose was to clarify about that unnecessary 128 sample restriction. I widend it to 150 as to remove any suggestion that a power of 2 has a theoretical basis.
I also added a warning about too many Repair effects concentrated on a short section. They will introduce a new type of distorsion due to the still unsolved discontinuities in the frequency content, which sounds like gargle. (This warning would better be shown with a ‘don’t show again’ select box direct after selecting Effect->Repair, but that is still too complex for this ‘newbie’)
Although the Least Squares AutoRegressive Interpolation applied in Repair.cpp is based on an excellent math theory and generates very convincing waveforms when applied in the time domain, it does not generate a waveform which has the frequency content close enough to that of the original wave section which it tries to recover. That is IMHO the main course of the said gargle distorsion.
I think that the Least Squares AutoRegressive Interpolation should rather be applied in the frequency domain, twice on each harmonic of the signal. That’s an awfull lot of extra CPU load, but if the result would appear to be excellent, I would like to leave my computers even for days working on that type of audio restauration.
With this in mind, I have planned the following coding actions with increasing complexity (at least for me):
a small modification of Repair.cpp as explained above.
adding the possibility to store audio positions on the fly while recording, for breaking down the recording in separate tracks afterwards.
applying the Least Squares AutoRegressive Interpolation in the frequency domain as indicated above.
If there are others already involved in action 2) and/or 3), I would love to be informed.
Someone here such as Steve or myself may try out a patch posted here and suggest improvements (though neither of us are C++ programmers, especially me) but nothing would happen to the patch until posted to audacity-devel.
I’ve tried that - it works fine. As far as I can tell the “128” limit is arbitrary, though as Gale mentioned it becomes rather too slow if increased by much. Programmers tend to have a preference for “round” numbers, but because computers are working in binary “100” is not a round number whereas “1000 0000 binary” (80hex) is.
“Markers” (labels) can be added on the fly with Ctrl+M. Does that do what you want or do you mean something else?
Sounds great, though not at all easy to do. The start/end of the selection still needs to be interpolated or smoothed in some way in the time domain to avoid creating clicks. The task is fraught with problems but imho has enormous potential if it can be efficiently and effectively achieved. I’ll be happy to try out any patches that you come up with for this.
It’s not really so complex. Audacity is a mature project - to maintain the quality and stability of the core code it is necessary for new stuff to enter through the appropriate gateway. Because it is open source, anyone is allowed to modify the code, but (very reasonably) nothing gets into the official code until it has been reviewed and tested. We can do some testing here on the forum and probably offer suggestions/advice about user elements. For significant new features (as opposed to bug fixes) there can also be a “proposal page” on the Audacity wiki so as to allow broader discussion of the feature. I look forward to seeing what you come up with.
