Forwarded question: Could a tracker "import" an NS

[GradualGames]

I received this question on another forum: Could Famitracker (or any tracker) import an NSF file?

As I currently understand it, an NSF basically is a music engine + data. The NSF file format tells an emulator where to find the init and playback code. Therefore, someone could write an NSF from scratch with a new music engine and new data, correct?

So, in order to import an NSF, a tracker would have to recognize every sound engine that's out there and interpret the data correctly. I don't have enough experience with NES music to know just how many NSF music engines might be in existence. My guess is that there are probably dozens, and maybe some for which the source code has been lost. So, while I think it may be *possible* to import NSFs provided you can learn enough about what engine is in the NSF, the feature would appear broken to many users until *every* music engine has been supported. And then, any new music engines written with new data would again break the feature until a new importer was written for it. This forces me to ask: Would it be worth it? I don't think so.

I also suggested that you could run an NES emulator under the hood and collect all writes to the sound registers, and then "reverse engineer" volume, pitch, and duty envelopes, but it might be difficult to tell whether these are new envelopes or an envelope + application of an effect. The results would be imperfect.

[Shiru]

There could be infinute number of music engines. One company could use one engine, but it evolves from game to game, with both minor and major changes. Also, designs of the engines and trackers could be very different, so capabilites of a tracker just isn't cover capabilites of an engine. Source code of most of the engines is lost or never will be public. So generally you can consider NSF import impossible. Of course, you always can reversee-engineer certain engine to get music data, if you really need to, but it has nothing to do with NSF format, you just take binary and work with it.

[MetalSlime]

I received this question on another forum: Could Famitracker (or any tracker) import an NSF file?

As I currently understand it, an NSF basically is a music engine + data. The NSF file format tells an emulator where to find the init and playback code. Therefore, someone could write an NSF from scratch with a new music engine and new data, correct?

Yes. I'm not 100% on this but I think I read somewhere that Sivak released a Battle Kid NSF that was just him assembling only the sound engine portion of his game code. Even if that's not the case, you could do that easily.

So, in order to import an NSF, a tracker would have to recognize every sound engine that's out there and interpret the data correctly. I don't have enough experience with NES music to know just how many NSF music engines might be in existence. My guess is that there are probably dozens, and maybe some for which the source code has been lost.

Yes. Pretty much every company wrote their own sound engine so there would be dozens. And it's also likely that companies expanded/rearranged their own sound engines as time went on, so that the music engine for Mega Man 2 would be close but not exactly the same as that for Mega Man 4. I'm not familiar with the sound engine for Mega Man games btw, just using that as a hypothetical example (they may be exactly the same or completely different for all I know). I don't know if the source code is available for any of them, but you can disassemble the ROMs and get it that way.

I also suggested that you could run an NES emulator under the hood and collect all writes to the sound registers, and then "reverse engineer" volume, pitch, and duty envelopes, but it might be difficult to tell whether these are new envelopes or an envelope + application of an effect. The results would be imperfect.

This seems more practical to me. Bad case scenario you get the right notes spaced correctly and some approximate envelopes. Best case (simple engines) you could import the song successfully.

[Dwedit]

There was this NSF2Midi program that used user-specified threshholds to try to find instruments. Something similar could possibly be made to guess the envelopes, then guess which instrument the song is using, then reconstruct a tracker/midi version of the song.

[cpow]

The tracker "import" function that I implemented in NESICIDE (Windows version, not Qt version yet) simply interpreted APU register writes at the framerate of the PPU. This worked pretty well just to get notes into the tracks...but didn't do anything toward optimizing the tracks based on repeated sequences or anything like that. However, my thought was you could use that method to rip music directly from the running emulator. This would get you a rudimentarily tracked "NSF" or even some in-game music if you used it to track the intro music of Zelda for example. Then, to take that one step further the plan would be to have a back-end tracker worker thread that optimized the tracks and created something akin to what a person might create when tracking the music from scratch. Ie. "repeat order 0 of track 5 indefinitely because there's no DMC samples".

Unfortunately since people like neilbaldwin are blazing trails with 240Hz tracking my method wouldn't support that, but one can see that it potentially could if it just kept track of APU state at some multiple of PPU framerate.