> You continously join together two processes into one argument that does
> in fact use two entirely different algorithms.
> 1/ Click detection
> 2/ Click removal.
> They´re NOT the same.
Yes, they are not the same, but they are DEPENDENT.
If you cannot detect the click, then you surely cannot remove it.
> 1/ The bandwith you get from wideband transducers and >96 kHz sampling
> can possibly, depending on the click detect algorithm, help differenting
> between clicks and music.
Exactly - this is what I've been proposing all along!
> 2/ This excess bandwith has nothing whatsoever to do with the click
> removal process that uses the audio before and after the actual click to
> resynthesise the audio in place of the actual click.
Which could very well be true, however...
if you cannot detect the click, then you cannot remove the click. So the
primary focus should be on detection and using processes that improve
detection, and once detected, the focus should be on removal.
IMPORTANT: From a preservation perspective, there are the noise reduction
algorithms that are available today, and there are the future algorithms
that we haven't even thought of. These future algorithms may in fact be
able to take advantage of higher frequency information that today's
algorithms might not. I still firmly believe that archiving at 24/88.2 or
24/96 is prudent from a noise removal perspective, even if it may be
overkill for the audio signal.
> Only if the click detection algorithm made a wrong decision.
> This may not having anything to do with bandwith.
But, as you acknowledged earlier, it also MAY have something to do with