NSFPlay 2.4

NSFPlay 2.4 is released: https://github.com/bbbradsmith/nsfplay/releases

This one took me a while, but I think I'm back on track now.

For anyone knew to it, it's an NSF player and Winamp plugin for Windows. (Hope to expand to other platforms when I get to version 3.) Next up for 2.5 is a rewrite of 5B and VRC7 emulation.

Two questions:

1. plugins\in_yansf.ini is no longer included with the releases. Is this an effect of change "If in_yansf.ini can't be found or created next to in_yansf.dll, will try to save settings to %AppData%\NSFPlay\ instead"?

2. Binaries across the board are now substantially larger; was this 2.4 release a "optimised release" build, or is this an effect of change "Migrate to VS2017"?

1. in_yansf.ini shouldn't ever have been included, really. It was just full of the default settings (manually updated, potentially out of date if forgotten). Much better to leave it out, and the program will just create it on first use.

Adding the fallback to appdata wasn't the reason for deleting it, but that fallback does require that you don't stick a non-writable in_yansf.ini in your winamp plugins folder (which would block it from trying the fallback).

2. Yes, the binary size just instantly increased with the switch to VS2017. It's not really affected by the optimization settings as far as I found, but I decided the extra 1MB download wasn't worth going on a many hours adventure hunt to figure out. I looked at it for about as long as I thought it was worth looking at, then gave up.

I also thought it was worth staying with VS2017 and not going back to VS2005, for a bunch of reasons.

So... if you have an answer feel free to submit a compiler settings patch, and it'll go into 2.5. Otherwise, I don't care enough. Any work toward fixing this problem (if fixable at all) will be wasted when I rewrite for version 3 anyway.

For people who use NSFPlay Synthesia, HertzDevil has been keeping their repository up to date to at least 2.4b8: https://github.com/HertzDevil/nsfplay/releases

I have a feeling the increased executable size might just be due to VS2017's MFC libraries being bigger? I'm not certain about this. If that's the case though, definitely not going to do anything about it... it'll just be bigger until 3.0 when I throw away MFC altogether (and probably use some even more bloated UI library, hue hue hue...)

Unrelated, I did find a dead code elimination switch that wasn't enabled on in_yansf.dll that got it back to 333k. It hadn't bloated nearly as much as the others though, and it's also the only executable of the four not using MFC.

On a separate note, I set up appveyor. (Tried travis.ci first but got hella confused hella fast.) So, outside of the times I actually want to beta test, anyone can still get unstable builds from there now:
https://ci.appveyor.com/project/bbbradsmith/nsfplay/branch/master/artifacts

Or I guess emuCR has been doing this unofficially for years.

I am having a problem in NSFPlug 2.4 with the N163 volumes, especially together with the mixe chunk.

Please find here a test NSF and recordings (32 MiB because of flac recordings). The test NSF is an NSF version of the program that I used, with the hot-plugging technique, to measure the relative N163 volume of all my N163 cartridges. It first plays an APU square, then an N163 square using one channel, then an N163 square using eight channels, in all volume levels. I tested NSFPlay 2.4 both with default settings and using my custom settings, which involve not using non-linear mixing but without me messing with the volume sliders; the custom settings' .INI file are included in the archive.

First of all, the one-channel N163 square should have the same RMS volume as the eight-channel N163 square, as heard in the hardware recording from Megami Tensei II. In NSFPlay at both default and custom settings, the eight-channel N163 square is slightly louder than the one-channel N163 square (2.2 dB difference). This means that default settings, only the one-channel N163 square is +13 dB louder than the APU square, as the mixe chunk specifies; the eight-channel one is too loud relative to the APU square.

With custom settings, the eight-channel N163 is still 2.2 dB louder than the one-channel one, but the one-channel N163 is 15.1 dB louder than the APU square instead of the desired 13 dB. I assume this is the result of not using nonlinear mixing.

I believe that the mixe setting should apply similarly regardless of how many N163 channels are used, and whether the APU uses linear or non-linear mixing. Please tell me if you believe that NSFPlay does everything right and that only my settings are screwy, or my assumptions are wrong.

Okay, so in your SMT recording, there seems to be a ~0.27 dB difference between the 8 and 1 channel tests. On NSFPlay with the more accurate serial mutiplex mixing, it's showing ~0.1. With the default less accuract mixing it's 2.21.

With your custom settings, the 1 channel version has a difference of ~15dB instead, but this is due to turning off the more accuracte nonlinear mix of the APU square. That option is not the default, and I had not been testing it for reference to NSFe mixe. (I should have, sorry.) I don't remember what the correlation between APU nonlinear and linear mixes is, offhand, but probably APU volume 15 should match between the two and it should be linear from 0 to that endpoint... maybe it was using 2 x square 15 as the endpoint instead? Will take a look at it later, but using this option does unfortunately invalidate the reference mixes (until I revise that). Better modelling of the nonlinear mix of the APU is on my to-do list for 2.5 anyway, so it's an appropriate time to review this anyway.

The NSFe mixe chunk seems to be doing the correct thing, though. You specified 13dB and it delivers that for the reference test (1 channel vs square). So that part is fine.


Back to the N163 issue, for this particular test there is some very audible distortion with the 8-channel tone, and looking at the shape of the wave there seems to be a difference between this and how it's emulated in NSFPlay, so I think from the start the comparison is going to be thrown off by this. Despite this difference, the more accurate serial mutiplex mixing seems to be reasonably close (0.15 dB?) to your recorded version, so I feel I should consider it valid for the time being, at least until the emulation difference is resolved and I can make a finer comparison.

The less accurate (but default) non-multiplexed mixing does seem to be a problem here. 2 dB is significant. I don't know if it's overemphasizing that emulation difference, but yes there's a clear disparity that I will look into. It's a little bit difficult to make up a non-accurate form of mixing like this but also keep its relationship to the more accurate version simple and transparent.


Could you share source code for your NSF? I'd like to see how you're setting the phase of the 8 tones. It might be possible to create a more "fair" test that doesn't have as much distortion by writing 0 to all of their phases quickly, or doing something else to synchronize them more closely?

There's a bunch of very fine/nitty details about the N163 internal update that haven't been documented yet, e.g. what the registers read at various cycles in the sequence. I know there's at least some difference between this and NSFPlay's own internal update, but I haven't gone diving quite that deep into figuring out these timings (this level of detail is approaching a need for a decap IMO, though there is definitely more I can determine through hotswap tests still).

Sure. I guess in the meantime, I will just use serial multiplex mixing and the nonlinear APU mixer.

The reason I don't like the nonlinear mixer is that in addition to modifying the volumes, it also distorts the waveforms, which results in a somewhat dirty sound with very loud games, and also some aliasing on games with very high notes, such as Deep Dungeon 1. This aliasing sounds somewhat similar to what one gets without proper band-limited synthesis of the square waves, but in this case is caused by the non-linear mixer and is heard on the real hardware as well.

I have found that I can get what I want --- clean waveforms but correct volumes --- by doing the proper nonlinear mixing on Triangle/Noise/DPCM, but doing a linear mix on the two squares and scaling by the combined volume setting rather than the instantaneous output:
With "Pos" being the current waveform position, and Square0.Vol" being "Vol =envelope? volume: Envelope;". That gets me the best of both worlds: clean, distortion-free square waves, but still at correct volumes, correct enough for the "square.nes" part of blargg's apu_mixer.

The squareSumFactor array was obtained via:With 0.258483 just being a normalization factor, so that the last entry is at 1.0000.

Here is an example of what I mean, from the intro of Majou Densetsu II: Daimashikyou Galious. The first time rendered with the above code but with Settings::NonlinearMixing=false, the second time with Settings::NonlinearMixing=true, which matches the output of real hardware and nonlinear-mixing emulators. You might need headphones to hear the difference.