That's the general idea of how to preemphasize a sample. To see whether you over- or underemphasized, you can render an SPC file to wave in an accurate SPC player and compare the output in the time domain with a ModPlug Tracker export of square wave samples with the same length and cubic resampling.
Why cubic? It has the same support width as Gaussian resampling: four sample periods. But unlike Gaussian resampling, cubic resampling uses negative weights for two of the samples, which allows it to preserve more of the high frequencies without having to bake pre-emphasis into every encoded wave.
In my tests, the square wave I've been using is this:
Code: Select all
.byte $B0,$9B,$BB,$BB,$BB,$BB,$BB,$BB,$B9
.byte $B3,$75,$55,$55,$55,$55,$55,$55,$57
That corresponds to these sample values:
Code: Select all
[
-7, -5, -5, -5, -5, -5, -5, -5,
-5, -5, -5, -5, -5, -5, -5, -7,
7, 5, 5, 5, 5, 5, 5, 5,
5, 5, 5, 5, 5, 5, 5, 7
]
I haven't had a chance to do rigorous tests on this to see whether I over- or under-preemphasized though.
The ideal preemphasis to compensate for Gaussian resampling is
deconvolution with the Gaussian kernel. If you're building your own BRR encoder, try approximating it by
convolving the sample with [-1, 6, -1]/4 or [-1, 10, -1]/8. The first of these means you take the current sample times -1, the previous sample times 6, and the sample before that times -1, add them, and divide the sum by 4.