Would be interesting to see the sound comparision of this with standard DOSBox's FM emulation. Better in some games to notice the practical imrovement. It's not clear when the significant difference can be noticed.

Nuked OPL is accurate to the real hardware, and there are indeed cases where inaccuracies are clearly audible.

Some examples: from nukeykt himself:
DOSBOX fork with better FM synthesis?

I wonder if setting [mixer] to 49716 also (as required for "nuked" to work correctly (?)) reduces playback quality of other soundsources especially SFX samples. Can anybody comment on that please?

villeneuve wrote on 2021-05-20, 16:32:

I wonder if setting [mixer] to 49716 also (as required for "nuked" to work correctly (?)) reduces playback quality of other soundsources especially SFX samples. Can anybody comment on that please?

Adding to that curiosity, I wonder how the noise spectrum chart looks for the 44.1k/44.1k case -- I thought it was strange that that wasn't posted with the other comparisons. It goes without saying that any rate conversion is going to introduce some unwanted transients (especially when not supersampling prior to conversion), so of course 49k/49k will sound better than (not 49k)/49k, but apples-to-apples would be comparing with 44.1k/44.1k. Hopefully 44.1k/44.1k is cleaner, because it can't just be me that hears a lot of additional sibilance in the demo audio for nukedopl that's been posted here previously. (Then again, nobody seems to hear the to-my-ear painful high frequency artifacts in the MP3 files posted that supposedly reflect on it favorably, so I don't know what the criteria are that people are using to pick the "best" tbh.)

slinkygn wrote on 2021-08-07, 12:05:

Hopefully 44.1k/44.1k is cleaner, because it can't just be me that hears a lot of additional sibilance in the demo audio for nukedopl that's been posted here previously. (Then again, nobody seems to hear the to-my-ear painful high frequency artifacts in the MP3 files posted that supposedly reflect on it favorably, so I don't know what the criteria are that people are using to pick the "best" tbh.)

OK, it's definitely not just my ear. I ran a cross-correlation comparison on the Lion King and Aladdin examples over here DOSBOX fork with better FM synthesis? between the Nuked, compat, and the recordings of the original hardware. The Nuked delta FFTs did show more high-frequency noise compared to the original. And the overall waveform comparison showed compat was actually a significantly closer match than Nuked was.

I reran that as well with the MK2 files that were posted there in a ZIP file, since those were WAV files -- I was hoping they were "clean" and not from a prior MP3 source or anything like that, but it also showed both the high-frequency losses in Nuked and the closer matching to compat. So either those files weren't just straight uncompressed audio at some point in their "lives", or there's a significant problem to the conventional wisdom that Nuked is more accurate than compat.

One interesting thing is that, at least to my ear when I originally noticed these issues, it seemed like in the places where compat and nuked differed from the hardware recordings, they did so kind of in the "opposite" ways -- so nuked would have added sibilance and high-frequency noise, which might sound good or be hard to detect for some listeners on a hi-hat or other cymbal for example but would not be nearly as kind when picked up against mostly low- to mid-freq sounds like orchestral instruments or perhaps voice synthesis. Compat would instead be missing some of that high-frequency "sizzle" that cymbals and such are supposed to have (or at least seemed to on the original hardware recordings), but would have a cleaner response across the board and less HF artifacts.

Those ear "observations" are a little trickier to verify numerically with cross-correlation testing (though not impossible), but I did get a strong hint from the numbers that I was right: as my last test, I compared the nuked and compat versions against each other as their own "references." Sure enough, they are more "dislike" to each other than they are to the original source (almost shockingly precisely so). If they were displaying the same sorts of errors but one was just worse than the other with those errors, they would show more alike to each other than they do to the worst-case match to the reference source (here, the nuked sample).

It should also be noted that while the difference in accuracy of both nuked and compat were each log-2 magnitude significant to each other, both of their individual accuracies were another one to two log-2 orders of magnitude different than the source recording. Taking that into account with the fact that their errors seem to be of fundamentally different natures, it would appear that the conclusion here would be that though compat is technically more accurate than nuked, they are both just plain *different*. So unless you're an ultimate-accuracy junkie (in which case why are you bothering with these, go get yourself an ISA card instead), which one is better will just depend on plain personal preference, and perhaps even vary with which particular game you try them.

Something has changed between SVN 4466 and 4470 that has broken the Nuked patch, at least when compiling in macOS.

When compiling SVN 4470, I now see the following errors in the terminal output:

1adlib.cpp:637:14: error: use of undeclared identifier 'oplemu'
2    else if (oplemu == "nuked") {
3             ^
4adlib.cpp:871:11: warning: enumeration values 'OPL_none' and 'OPL_cms' not handled in switch [-Wswitch]
5        switch ( oplmode ) {
6                 ^
7adlib.cpp:871:11: note: add missing switch cases
8        switch ( oplmode ) {
9                 ^
103 warnings and 1 error generated.
11make[4]: *** [adlib.o] Error 1
12make[4]: *** Waiting for unfinished jobs....
13mv -f .deps/gameblaster.Tpo .deps/gameblaster.Po
14mv -f .deps/dma.Tpo .deps/dma.Po
153 warnings generated.
16mv -f .deps/hardware.Tpo .deps/hardware.Po
17make[3]: *** [all-recursive] Error 1
18make[2]: *** [all-recursive] Error 1
19make[1]: *** [all-recursive] Error 1
20make: *** [all] Error 2

Any suggestions would be appreciated. There were no such errors up to at least SVN 4466.

Looking at the commits on Sourceforge, the relevant changes appear to have been introduced in 4468 and 4469:

4469: "don't do dual writes to OPL3"
4468: "Add proper OPL3 handling of the waveform select to dbopl"

The patch does not apply cleanly, so I guess you must have made an error when applying it. I just verified that it builds against r4470 when applied properly.

EDIT: Where "the patch" is v1.8 (originally against r4088), which is the most current one I could find in this thread.

EDIT2: https://github.com/Ringdingcoder/dosbox-stagi … its/nuked-merge

Thanks, the latest Nuked 1.8 merge from the DOSBox Staging repository works. I saved that as a diff file and it applied cleanly to the 4470 source.

@slinkygn The differences in the Nuked emulator could be explained by it apparently being modeled using the YMF289 as a reference, which uses a different source clock and output sample rate (33.868MHz and 44100 Hz respectively) instead of the YMF262 (14.32MHz and 49716 Hz), in addition to different DACs (1-bit sigma-delta vs. more 'traditional' two's compliment FP-DAC). Though I am quoting a relatively early build, perhaps Nukey changed it later?

A pretty well trained ear can tell a difference between the YMF289 and YMF262: the YMF289 has more high frequency artifacts and the output pitch is very subtly lower than the YMF262's. I grew up with a YMF289-based OPL3 (Yamaha YMF719) so to me, the YMF289 is 'correct' except on things that get a little *too* noisy (such as WHLCHAIR.DFM).