Did an orginal, unmodded Famicom sound like this? (Samples)

I know the NSFPlay default setting is pretty accurate for when an NES is connected through AV but how did an original Famicom sound? From what I've read, including this thread, the Famicom had a slightly muffled sound with higher bass (example). I want to have a playlist of both NES and Famicom songs that sound accurate so I've been testing some different settings. Back in the early 90s I used my NES with an RF connector and it sounded good to my ears. I know RF always gives a hiss but you only hear that in silence. This settings sound like what in my head an 80s system hooked up through RF would sound like. I adjusted the Famicom setting a bit and moved up the APU2 and VRC6 a bit for higher bass.

Legend of Zelda / Legend of Zelda
Lifeforce
Super Mario Bros. 3 / Super Mario Bros. 3
Akumajou Densetsu / Akumajou Densetsu
Mother / Mother
DuckTales / DuckTales

I could be wrong so I wonder if any of you that have played an original, unmodded Famicom could listen to the samples and see which way to go to make it more accurate. I'd appreciate any advice. Thank you.

For what it's worth, my front-loading NES sounds muffled with more bass through RF compared to AV. Perhaps I need to write something that outputs pink (1/f) noise through $4011 for calibrating EQ.

I said most of this already in the e-mail, but probably worth repeating here because others might have some input on it.

The relative balance between APU1 and APU2 is different from machine to machine. This isn't a really a Famicom vs NES thing, but random variation between machines manufactured to loose tolerances. Similarly, if you're adjsting VRC6, the expansion volume is different from cartridge to cartridge, which I think have even looser tolerances than the consoles. Adjusting these is more about "taste" than "accuracy". The RF process does not adjust these relative volumes, this mixing happens in the machine before the RF stage. If we want to accurately reflect RF output, what we really need is a post-processing filter on the emulated signal.

The RF output itself is difficult to characterize. It should be equivalent to some series of filters on the original signal, most prominently there is a strong lowpass, but I don't really have much more advice than that. If someone with an electrical engineering background could explain what an ideal RF demodulator filter should look like, that would be a really good start, I think.

I might try recording RF demodulated output from a television that has external audio, but there's a problem here that most TVs seem to add their own separate colouration to the audio (often they have their own EQ settings). Trying to nail down what an "average" NES or Famicom sounds like is a bad enough problem before you get to RF output, but trying to deal with variation between TVs on top of that makes it so variable I don't know where to begin. If we're talking about your experience playing it through a TV speaker, that's yet another device adding its own colour and variation to the sound, and that's a hella strong modifier.

Like, for the "example" video you posted, we're looking at Famicom + RF modulator + RF demodulator + TV processing + TV speaker + Reflections from the room + Camcorder microphone. There's no way I could even guess what all of those things have done to the signal in anything more than a vague way. I think if you're experiencing a bass-boost, it's probably just the TV; from my experience the RF process itself seems to have a strong high-cut and a weak low-cut (or conversely a mid-boost?), but I'm lacking proper sources of information here.


Currently the best I'd suggest with NSFPlay to simulate RF is just to increase the lowpass strength until it sounds as dull as you think it should be.

I've been wanting to add a bit more comprehensive post-processing to NSFPlay, possibly more filters than just the simple highpass/lowpass (e.g. bass boost if you want it), maybe a compressor or nonlinear distortion of some sort too. Something for me to work on when I do the next version... maybe I'll make and record some frequency sweep NSFs to try and get some real examples I can analyze.

Maybe find a VCR or DVD recorder with RF in and A/V out? Alternatively, this might be a good use for one of the RTL2832U software-defined radios, so that one could directly record the modulated audio band. (Channel 3 and 4 audio are at 65.75MHz and 71.75MHz)

I've studied how the modulators work. Unfortunately, I never seriously looked at how the demodulator works. This seems to be a good source, at least for me. There aren't really any intrinsic and non-varying filter constraints, though. The simpler designs involve watching the amplitude of the demodulation change as a function of the gain of a resonant circuit, but we haven't apparently used those designs for decades, now.

FM audio, both in radio and NTSC TV, is supposed to have 75µs pre-emphasis applied. It doesn't look like the right highpass filter is present in the NES's RF modulator, but I can't tell. However, the TV's RF demodulator should include a de-emphasis filter that decreases the volume of higher frequencies; this deemphasis is a 1st-order lowpass with a corner frequency of 2.1kHz.

Hmm, that's interesting. So is the usual dullness of NES audio through RF due to a lack of pre-emphasis, rather than a limitation of RF technology itself?

If my interpretation is right, and I'm not confident I am, then it would describe what we're hearing.

But at least when I look at the RF path in the Mitsumi modulator: http://console5.com/wiki/File:NES-001-S ... Switch.png I don't think I see one. The only possible audio preemphasis would be the seven components in the center (including the 5600Ω resistor, the transformer EK522, the 2SC1740 NPN BJT and 820Ω resistor, as well as three anonymous capacitors) ... and that doesn't look right to me.

The seven components in the center actually look like a lowpass (the BJT, two capacitors, and resistor, should have gain=1 at DC but gain=the ratio of capacitances at high frequency; the corner frequency is determined by the value of those capacitors) followed by a highpass (the 5.6kΩ resistor and its capacitor), which I don't think works out to be the "treble boost" pre-emphasis is supposed to seem like.

Thanks for the replies, guys. Very helpful.



Thanks for the email. Your response and that thread I linked too was enough for the NES settings but it got me thinking about what those young Japanese kids listened to from 1983 on. I did think adjusting the bass might not be accurate...I really love the NES bass; it's addicting but I'm aiming for a somewhat accurate sound.



True. I am trying to find an average middle ground of the Famicom itself and less the speakers, but I guess as of now that's up to each individual to determine. Me, I'm actually trying to remember what games sounded like over 20 years ago. I remember Super Mario Bros. 3 more than anything else and these settings I have here remind me of playing the NES on my Mono TV around 1991. I'm 28 now so it's been a while, ha!



That video was just some random thing I found as it's somewhat hard to find Famicom videos using RF. It did sound like the descriptions of a typical connection, though. From the default setting, I adjusted the lowpass and left the APU2 and VRC6 alone. I put it on the fifth point but it still sounded clean. I remembered the slight hiss RF gives (from using a VCR several years ago) and went one past. For what it is by memory, it sounds good. Anymore past that though and it affects the quality.

There's nothing that simulates RF hiss so that may be cool to include in future releases; something like "Analog Simulation" included in SNESAmp. The truth of why I'm trying to get accurate is besides personal interest, I plan on uploading to YouTube various video game soundtracks that sound as close as possible to the real thing. Most uploads on YouTube, besides being of atrocious quality, aren't very accurate with their settings or song length so I have some ideas to capsule the hard work those composers did and teach the younglings. Any additions to future NSFPlay updates would be great but it's fine for how it is now. Plan to start uploading soon enough.

Contra / Super Mario Bros. 3 / Akumajou Densetsu / Batman / Duck Tales / Battletoads

Over the past few hours, based on a request here, I implemented the Voss-McCartney algorithm to do just that.

I've attached the source code and ROM file of a pink noise generator, which I approximately verified as such by generating a wav file in FCEUX for Windows and analyzing it in Audacity. It also has a sine sweep generator; can anyone explain why it sounds so aliased?

The output is aliased mostly partly because the samples are being fed through $4011. The output of that DAC is only 7 bits wide, and signals in human perception require somewhere around at least 700 levels per stepping to be "fooled" (at least 10 bits, why 16-bit audio works so well).

The only way around the 7 bit limit is dithering.

Two other problems I found:

The test is not producing a genuine sine wave, as expressed by spectrogram (and heard with my ears). Samples have to be run through a non-linear inverse filter to compensate for the DAC's non-linear curve.

There's 60.1 Hz interference because of NMIs. The NMI routine is not compensating (and possibly can't during high frequencies anyway). It's best to turn NMIs off during CPU sample playback.

Edit: aliasing grows toward the end because the sine sample loop is 68 cycles long — a maximum sample rate of ~26,320.

If quantization noise is the primary problem, I'd expect the aliasing to be at least 36 dB quieter than the signal.


Bingo. Then the problem becomes one of measuring this curve in order to build such compensation.


Which in theory should affect little because it cuts off the sweep at the Nyquist rate of 13 kHz.

Even without measuring the curve of a real NES, the actual curve of FCEUX or other emulators is 100% known and you can still use that to test the effect of linearity correction on the distortion of the output.

FCEUX's sound.cpp implements the "Lookup table" model, summing 3*tri+2*noise*dpcm and running that through a table called wlookup2. I tried compensating for it (and fixing the erroneous write that failed to disable NMI), and everything cleared up in FCEUX. I'll try it later on my NES.

It will probably still be audibly aliased because the Nyquist rate of 13,160 Hz is below the identifiable limit of human hearing, 16KHz. As far as I can tell, approaching the Nyquist limit with rectangular transitions between samples appears to produce aliasing at any rate.

The routine could be sped up considerably at a cost of ROM size by precomputing a logarithmic scale for one octave, and playing it back at multiple octave rates.

I was more concerned with foldover back below 10 kHz than with the 13-16 kHz band. There used to be a strongly audible dive toward 0 in the final octave of the sweep. The compensated waveform is not perfect on my NES, as the NES's curve doesn't precisely match FCEUX's against which it was calibrated, but the artifacts are a lot quieter now.

EQ test 0.02 (2017-11-22)

• sinusweep: Compensate for DAC nonlinearity (reported by ap9)
• sinusweep: Turn off rendering to minimize PPU crosstalk
• Correctly turn off NMI handler during playback (reported by ap9)
• pinklfsr: Check for B button press more often