bbbradsmith
commented
1 year ago I have no plans to add ultra-high frequency support in those ranges. I'm sorry, but there is no plausible audible benefit. The current support of 96kHz already allows improved rolloff implementation for various audio hardware, but above I don't think the returns are significant.
However, I do wish to support an export feature at the native CPU frequency (e.g. 1789772 Hz), not for audio purposes, but for developers looking to investigate the cycle-by-cycle behaviour as a waveform. This is planned.
Currently it is not practical to go higher than 16-bit, but I am considering a floating point investigation for the 3.0 rewrite. However, you should not expect any audible difference, the reason I wish to investigate it is the performance of hardware floating points is much more practical than it used to be when this code was originally written. 32-bit float might happen, but for reasons of performance, not fidelity.
It is necessary to increase the max bit depth and sample rate in the new version of NSFPlay 3.0+, add 24-bit/32-bit float/64-bit float and 192000Hz, 384000Hz, 768000Hz, 1536000Hz, 3072000Hz sample rates. This is necessary for the most accurate reproduction and to ensure that as many frequencies as possible are captured in the audio file (as you can see on the spectrogram, many frequencies are still cut off when playing at 384000Hz)
(001.056) BATMAN Return of The Joker.zip