Okay, well... Where is it?

I meant where is his compiler? All we have is Slimeball's for now.

With that [NSFs are programs] in mind, consider the FTM as the source to this program. Just like a .cpp file is (at least part of) the source to a C++ executable, the FTM represents the code that was entered to output the NSF file you get when you export.

Just as a C++ executable will contain various constants from the .cpp and .h files (mostly ASCII text strings), an NSF will also contain the constants from its source file, in this case all usable data from the FTM, which would be effectively be the contents of the entire FTM, having its patterns and sequences reindexed, song names and module comments removed, etc. It suffices to say the NSF, broken down to its constituent binary data, is no more than the 128-byte NSF header, around 6 KB of sound engine code, and a practically bijective mapping of the FTM sound data. Any data residing in the FTM required for sound playing in 6502 must also be present in the NSF, hence conversely, any NSF corresponds to at least one FTM which contains the same sound data, and this FTM can be reconstructed from suitable inverse operations of FamiTracker's NSF export code.

In other words, provided one is proficient in 6502 and C++, anyone having access to the assembly source of the NSF engine and the FTM handler source code will be able to recognize the identity of sound data between the NSF and the FTM. This is unlike the PSD case as, when the PSD is "flattened" to a JPEG or PNG, too much information is lost from rasterization that no identical, unique (not just equivalent) layers/vector forms can be effectively retrieved from the picture.

Intellectual ownership of an isolated, raw FamiTracker NSF can only manifest in the 32-character copyright field of the NSF header, significantly less than a raw FTM that potentially has kilobytes of module comments. Thus to say either that "the NSF cannot be shown to be identical to some FTM reconstructed/decompiled from it" (which is not the case in the topic), or "the NSF is a means of securing and/or obfuscating the source sound data of the FTM from other persons" is ill-informed and bogus.

Anyone wanting to obfuscate a FTM easily, so as not to allow a satisfactory reconstruction from this bijective relationship, can use Rainwarrior's NSF importer hack and then export another NSF from that (no N163 allowed), viz. FCM10 Cover #39, Cover #87.

goluigi: While the commercial NSF sound engines are not released with another more primitive form of sound data, it remains pretty straightforward to construct new MML dialects or higher frontends specialized for the sound engines, for sound hacking purposes (AddMusicK, Puresabe's MM3-6 MIDI inserter, smps2mid, so on).

Slimeball, jrlepage: My decompiler is written in Game Maker Language as if there already aren't better choices for binary I/O scripting. I don't think there is any sort of conspiracy if the decompiler is fairly smaller than the smallest possible Game Maker executable yet everyone in the posts can use that (plus the source code is severely larger than what I have).

Dr_Mustache: Upload that FTM anyway (I made that entry).

Slimeball, jrlepage: My decompiler is written in Game Maker Language as if there already aren't better choices for binary I/O scripting. I don't think there is any sort of conspiracy if the decompiler is fairly smaller than the smallest possible Game Maker executable yet everyone in the posts can use that (plus the source code is severely larger than what I have).

jsr, I think if he doesn't post it, somebody will end up doing it later. Unfortunately, considering that Famitracker is open-source, it was only a matter of time before a tool like this surfaced. HertzDevil even wrote a similar tool a while ago (though he decided to keep it to himself).

I'd make something fake for the laughs, but no, this is not fake.