snestracker VS Dn-FamiTracker

Ripping samples is a rather flawed approach. SNES sounds aren't just a sample being played, they will have custom reverb values and individual ADSR envelopes applied to them. The samples alone will often sound like trash or unrecognisable if that meta data is missing and/r if they are played in the wrong key. You can use Bazz's SNES Tracker debugger to rip complete instruments from .spc files, then output those .sti instruments to .wav or hell just use them natively in SNES Tracker to make your tune there.https://github.com/bazz1tv/snestracker

The README says "the latest version of SNES Tracker is available exclusively via Patreon a few weeks before it becomes available on github". In https://github.com/bazz1tv/snestracker/releases, v0.2.0 was released in 2020-09-29 and says "the next version, v0.2.1 is already released to Patreon!" In reality, v0.2.1 was released publicly months later on 2021-02-19, with a tasteless notice saying "Note: the next version, v0.2.2 and v0.2.3 is already released to Patreon! This includes a critical bugfix (app hanging)."

The public Github repository you linked hasn't been updated in 11 months (v0.2.2 source and releases last updated in 2021-03-15), and v0.2.2 actually dates back to 2020-11-08 on Patreon. The Patreon (https://www.patreon.com/bazz1) was last updated in 2021-03-14 with v0.2.4, yet continues to take money for the past 11 months of silence. I've heard that he's stopped supplying builds to Patreon subscribers, and only giving them to Twitch subscribers.

This is my first time looking at his Twitch, and wow that's a lot of livestreaming uploads. I don't know if SNES Tracker is still being developed or not, and if Twitch subscribers receive newer builds of the tracker. In any case I'm definitely not subscribing.

I tried cloning the repo to view the current publicly released state. It has over 100 MB of files previously in history but deleted in a more recent commit, polluting non-shallow clones. I couldn't get it to build easily, so I downloaded the prebuilt Windows v0.2.2. The user interface is bare-bones and written in SDL, though I didn't poke around very deeply.

In any case I'll consider checking on his Twitch streams, and see if he can help me, though I prefer interacting with other people who don't behave in ethically dubious ways. I've already figured out how to make the S-DSP output sound. I'm currently working on learning S-SMP/SPC700 programming, writing/picking a hardware driver, (if I write my own driver) picking efficiently-implementable behaviors while remaining musically useful, or (if I pick an existing driver) learning the driver and build system. Eventually I want a characterization of the SNES's analog frequency/phase response (DAC impulse response plus analog filtering) so I can implement it in software. I feel eliminating unneeded audio latency, and implementing aliasing-free hardware-accurate resampling/filtering, are aspects that most emulators (even accurate ones like bsnes/higan) get wildly wrong, which I can improve with effort.

I've been using FamiTracker since 2017 and it no longer opens on my (Windows) computer. It just creates a dump file. After figuring out JSR was gone, I tried downloading Dn-FamiTracker 0.5.0.1, but the x64 and x86 versions just open an invisible window.

The original version of FamiTracker is no longer maintained and the website recently went offline, but most people are using the fork Dn-Famitracker these days - you can get it here. It's free software, so there are no restrictions on releasing music made with it commercially.

Dn-Famitracker is the most relevant since it's the only one still in active development and has all the features from previous builds and then some. It's considered the definitive edition of Famitracker: https://github.com/Dn-Programming-Core-Management/Dn-FamiTracker/releases

Most modern FTers are using a fork anyway, the current favourite is Dn-FamiTracker. All FamiTracker tutorials & resources should still work fine for you since the only differences are additions and updates for driver compatibility and such.

Go for Dn-Famitracker instead, it's a fork of the original famitracker with a few more features. Here's the github, if you're interested. https://github.com/Dn-Programming-Core-Management/Dn-FamiTracker

blip_buffer and blip_buf are fairly decent tools for generating an output-rate signal from a high-rate signal (though I use my fork of blip_buffer at https://gitlab.com/exotracker/blip-buffer-exo and/or https://github.com/Dn-Programming-Core-Management/Dn-FamiTra...). When emulating sound chips, the blip buffer adds and subtracts bandlimited sinc impulses from an output-rate delta array, and when exporting resampled audio, it performs a running sum (transforming the impulses into steps) of the delta array and high-passes the running value when writing to the output audio array. The advantage is that you can pick very high sampling rates (like 1.79 MHz) but only burn CPU cycles each time the output level changes (unlike conventional resamplers which are O(input rate + output rate)). Unfortunately blip_buffer has a relatively low SNR of ~50 dB of aliasing rejection even at its widest impulse kernel (as measured by https://gitlab.com/exotracker/exotracker-cpp/-/tree/rewrite-..., though possibly blip_buf is better), and only performs an approximate highpass using integer bitshifts. A usage example is at https://github.com/Dn-Programming-Core-Management/Dn-FamiTra....

Alternatively you can generate a high-rate signal and feed it into a conventional resampler to produce a 44.1/48/96 KHz output. I found that libsamplerate (https://libsndfile.github.io/libsamplerate/)'s medium preset produces audibly transparent output at 44.1 KHz and above, and should have acceptable latency on the order of 1ms (I didn't verify but you could first flush out the startup edge effect with silence, pop all output, then push an impulse followed with silence until the central peak emerges from the output). This has minimal CPU usage for a single stereo 128 KHz input stream (like in exotracker and chipsynth SFC), but I don't know if it burns excessive CPU with 1.79 MHz input.

----

My baseline expectation for production-quality emulators is to generate sound without aliasing, but the gold standard is to properly emulate the audio path as found on hardware, by feeding schematics through SPICE and/or pole-zero math to create an analytical representation of the filters, then verifying them against MDFourier tests (hardware recordings of broad-spectrum sound played by the console). Few emulators attempt to do this; according to https://bel.fi/alankila/modguide/interpolate.txt, UADE (an Amiga emulator) gets this right using a variation of the Blip_Buffer approach with longer precomputed(?) impulse responses specialized for Amiga filtering. Several chiptune tools properly model hardware filters, including the chipsynth family of audio VSTs (commercial); Dn-FamiTracker (an open-source NES composer) emulates FDS lowpass properly without aliasing, but only loosely approximates 2A03 lowpass and global highpass using blip_buffer's configurable filtering (impulse/step visualizer at https://gitlab.com/exotracker/exotracker-cpp/-/blob/rewrite-...).

If you choose to model a hardware filter using IIR filters (mathematical arithmetic based off a hardware model) instead of a large precomputed impulse response (like interpolate.txt and UADE), you'll get more accurate results if you generate audio at a high internal sampling rate, IIR-filter the audio at this high rate (ensuring the filter cutoff is well below Nyquist or half the sampling rate), then feed it into a resampler. If you use Blip_Buffer to generate 44.1 or 48 KHz directly like blip_buffer, and apply a filter with cutoff above 10 KHz or so, high frequencies will not be filtered accurately.

One interesting idea (combining blip_buffer's efficiency at handling sparse signals, and the accurate treble filtering enabled by a high intermediate filtering frequency) is running a blip_buffer-like system (with no highpass but a ~20 KHz lowpass) to downsample from a high internal rate to a fixed 128 KHz (for fixed filtering) or twice the audio rate (for efficient rational-factor downsampling), then performing hardware filtering there before downsampling using a resampler. The downside is that this stacks the latency and artifacts of both Blip_Buffer and the resampler, but if you make Blip_Buffer generate mostly-lowpassed audio and avoid generating nonlinear harmonics in filtering, you can use a faster second resampler that assumes its input is mostly lowpassed (using a narrower sinc kernel).

Correct Link: https://github.com/Dn-Programming-Core-Management/Dn-FamiTracker/releases/tag/Dn0.4.0.1

Thank you! I'd recommend downloading Dn-Famitracker, it's the latest fork of the program that's been made, and features a few quality of life improvements from it's predecessors.