Performance on data at the edge of kernels

As noted in this paper, DeepClean performance suffers when using data from the edge of inference kernels. This can be seen pretty plainly if you measure DeepClean's average MSE as a function of kernel position. In the context of DeepClean's limited receptive field, the reason for this seems to be that the DeepClean convolutional filters learn to model signals using both past and future data, since that's what's available for most samples in the kernel. At the edges, only either future or past data is available, and so the quality of its predictions decline.

@saleem-muhammed has been working on several schemes to address this that would be good to implement in this repo, including weighting edge predictions more heavily in the MSE loss and stitching together the edges from several consecutive batch samples to produce a single timeseries long enough which to compute a stable PSD for the PSD loss (related to #23).

However, this latter solution has a lot of wasted compute: since DeepClean's receptive field is only 193 samples long (and might be shorter at the edges depending on the padding strategy, this needs to be double checked), most of the forward computation doesn't end up contributing to the gradient. How do we extend this method in a way that doesn't perform extra compute on the forward pass and is general to any receptive field size? Are there other strategies we could adopt in light of the receptive field of DeepClean to ensure that edge performance is prioritized, and how does this affect our inference time kernel size and averaging strategy?

Start with the DeepClean inference-kernel and loss code, then review the 193-sample receptive-field assumption, the MSE edge behavior, and the PSD-loss discussion in #23. Compare the proposed edge-weighting and stitched-timeseries approaches, including their forward-pass cost and effects on kernel size and averaging. Done requires an agreed strategy, implementation, and measurements showing improved edge performance.