You have a point there, but the fact still remains that a major amount of the original data can be recovered &, with enough skill, the rest of the missing data can be rebuilt.
I know that there's an NSF code optimizing program that lets you remove redundant opcodes/operands & compress files; with JSR's technique, as was mentioned earlier, reversing NSFs can be automated for FamiTracker-made NSFs, but you'd still have to go the manual route for other NSF files (especially rips from actual games). If a FamiTracker-made NSF were optimized, then you'd have to go the manual way.
Yet, there will always be some way of recovering the data you need. After all, JSR did get one blank instrument & the entire track at 900 BPM, including all notes & effects (even though he didn't get it to loop properly). One blank instrument is all you need, really, as other effects & tracker-specific values would technically be stored as part of the NSF's header. As long as at least one aspect of the process is generalized/arbitrary (such as speed/tempo settings,) the job becomes easier. And if the compilation process of FamiTracker does follow a particular pattern for each different combination of notes, effects & instruments, then the entire process of creating that note/effect can be generalized with a blank instrument, one note & 4 effects at most.
But naturally, it isn't fool-proof.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
You have a point there, but the fact still remains that a major amount of the original data can be recovered &, with enough skill, the rest of the missing data can be rebuilt.
Decompiling a C++ program into pure assembly is simply a bunch of assembly garbage. There's loss of information.
TechEmporium wrote:
Yet, there will always be some way of recovering the data you need. After all, JSR did get one instrument & the entire track at 900 BPM, including all notes & effects. One instrument is all you need, really, as other effects & tracker-specific values would technically be stored as part of the NSF's header.
Yes of course, for NSF format is very possible to obtain a correct disassembly tool. It's very simple. And that scare me. :P
But you are exaggerating saying that it's possible obtain the source code of everything. It's like a JPG file, you can never obtain the un-compressed RAW data from a JPG, there's data that doesn't exist anymore, there's data that can never be obtained again. The same for some uninterpreted languages (C/C++/Pascal, etc).
Not necessarily, but I do understand what you're saying, though. Not everything can be recovered 100%, but much of it can to the point that you can work out what's missing. However, in the case of any compiled language, though there may be something missing, there's always a pattern that you can follow (& JPEG files also follow a similar pattern, though there's still a significant amount of loss).
C (& other compiled high & high-low level) languages are usually the ones that can't be compiled because they try to find the most efficient ASM pattern to follow before actually compiling the source code. I'm sure, though, that FamiTracker as a language is close enough to being at such a low level that it can't really find the most efficient/optimized ASM code pattern to associate each note/effect to (which also explains why you can significantly compress FamiTracker-made NSFs & optimize them without a significant amount of loss).
It all depends on the language, how it's structures & how the compiler tries to compare the language's syntax to match a particular pattern of ASM opcodes.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
You could also convert MCK files to FT format. All you have to do is recognize patterns in volume, pitch, etc, and make corresponding instruments :P I'm also fairly certain that MCK stores macros separately from other data so that'd be easy there too.
You can send me the file if you want it converted back.
Or can we make requests for games to be converted and eat away more of your time that could almost definitely be better spent developing Famitracker?
No this was an offer just for Dave. And I must admit converting back to FTM wasn't as easy as I first thought.
rushjet1 wrote:
Actually I guess it does, I didn't realize FT saved so much info in its NSFs :X
All that info is needed to play back the NSF the same way as in the tracker. Of course some optimization is done and needs to be restored but that's no problem. I believe the same is possible for MCK.
I didn't expect this discussion actually, what I meant to demonstrate was that files converted from register dumps are about as useful as using NSFplug or nsf2midi, which has been available for years. It's still not possible to extract sequences, effects etc. Anyway, I did this with some small modifications to my NSF player and famitracker. It took no more than half an hour to get it right, but it's still very basic and doesn't handle DPCM so I don't have any plans for releasing it, at least not right now.
I put NotSo Fatso into FamiTracker 3.6 and did what was mentioned earlier; playback and log the playback as FamiTracker data.
I decided to try it when I realized it wasn't really as much code as I initially thought (especially doing it from within FamiTracker). Like jsr, I stopped at Square/Noise/Triangle. No DPCM or Expansions, though they are technically feasible (VRC7 would be a real pain, but wait... there's only one real VRC7 NSF anyway).
Anyhow, I'm not about to release a hacked version of FamiTracker. Sorry. I would be willing to help jsr maintain such a feature if he wanted to have it in FamiTracker though.
This gives me a thought though, maybe I want to extend/revise FamiTracker's plugin system to make things like this possible as plugin DLLs. One thing I've kind of wanted is the ability to do arbitrary complex manipulations of data, stuff that wouldn't make sense as a permanent option because it's too specific to one song.
Plug-in system, eh? Perhaps some kind of a DLL that actually allows the NSF export process to be reversed at the lowest level possible (i.e.: the DLL could add an option to import the NSF; you select the NSF file to open, the tracker attempts to extract any DMC files like NSFLive would, the NSF's ASM code is generated by a disassembler & then converted into FamiTracker's tempo settings/notes/effects/etc., while a generic/blank instrument containing the DMC samples is created).
It's something to think about, but I know it's easier said than done.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
No the plugin system I'm thinking of would let your plugin read and modify the open famitracker document at runtime.
This would allow both importers and exporters to be written, but also arbitrary data manipulators (e.g. custom echo plugin, etc.).
The current plugin system only allows reading, and it connects to the NSF export menu in an odd way (well, it's only designed for exporting, so it makes sense for that).
Anyhow, there is no "reversible" NSF export process, except where the exporter is known (i.e. FT/MCK). DMC samples are very doable, I just didn't want to spend the time on it right now.
There are things you can do after doing the direct log, maybe try to detect pattern lengths, maybe try to find repeated volume patterns and make them into instrument macros, but it would probably be even less readable than this one-instrument 900bpm spew. Plugin tools, on the other hand, might give some facility to make that bearable to do manually (e.g. highlight a column and automatically make an instrument from it, stuff like that).
Interesting... So the only real possibility for such a feature would be to create it as its own stand-alone executable & then link it to FamiTracker via a DLL plug-in to call an external application.
What I mean to say is that, if this were ever to be implemented or listed as part of JSR's to-do list (which will never happen except for a possible third-party's work,) an NSF importer could be implemented as a separate executable that can be opened by FamiTracker itself, using a DLL to accomplish this.
But as you said; importing NSFs/reversing the NSF export function would only work where the exporter/compiler is known due to the particular pattern their compilation processes follow... Which still leaves the problem of automating such a process to work with all NSF ROMs universally & efficiently enough to reduce the amount of data loss.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
Well, I don't think we -need- any kind of importer for FTM, MCK, or otherwise modern produced NSFs, since the source material already exists for all of these (barring data loss on the part of the author). For original NES games, trying to come up with a true general "reverse export" is about the same scope as building MAME; i.e. you'll be making something different for every game. I don't think this is a worthwhile goal.
The way NSFs were produced in the first place was someone looking for and isolating the music playback routines in each ROM on a case by case basis. This project would involve not just that, but fully understanding the operation each of those playback routines.
The reason I am suddenly very interested in a more robust plugin system is that it would enable all sorts of experimental ideas to be developed and shared without requiring jsr's attention. It also would it feasible to tie in code for your plugin that should otherwise be kept out of FamiTracker; say you wanted to embed the Python runtime in a plugin and allow people to write their own editing scripts with it. Or say I want to use NotSo Fatso to write a 900bpm importer. The plugin becomes a separate self contained project, easy to manage independently of FamiTracker's development.
Implemented DPCM capture, here's some more test dumps. Each NSF I try seems to expose more things I need to implement to get it working. Some things don't come out quite accurately (especially if it's using hardware length/volume/sweep stuff). Still, the result can be decent enough.
Implemented DPCM capture, here's some more test dumps. Each NSF I try seems to expose more things I need to implement to get it working. Some things don't come out quite accurately (especially if it's using hardware length/volume/sweep stuff). Still, the result can be decent enough.
) 
.png){kind=avatar}
