What that means is that it's impossible to answer generally. If you really, really, really want a general metric, whatever song you want after exporting to whatever format should probably be less than 8KB. The problem with this answer is that it's not strictly impossible to have a larger song. And most devs will probably not want a single song to be that large, but I don't have a number in my head of where a better line is. It depends how much the developer values music. The Super Bat Puncher music is very large for just a few songs if I recall correctly.So that means that I could essentially write a 20-minute prog rock magnum opus for the 2A03 while adhering technically to the limitations of FamiTone2, GGSound, or whatever format the dev requires for his game and I'll have no problems?
Note that this 8KB limitation I'm throwing out randomly only deals with a single song. All of the data for all of your songs could be like 256 KB, and that generally wouldn't be a problem for playback specifically, but it would be taking up a lot of space that the dev might want to use for other things.
Which... is again why this sort of thing is impossible to answer generally.
Okay, let me put it like this: You only get "free reign" through an emulator if you know how to program, because if nothing exists that gives you the space/features you need, you have to add it to the emulator yourself. Just like to get "free reign" on the hardware itself, you need to be able to design/build the PCB that will make it possible. As Tepples said, it's possible to get MP3 quality playback but at that level what's the point of going with NES? A lot feel the same about expansion audio. I don't think there's a commercial USA release that uses expansion audio. If there are, they don't make up more than 1% of the overall library.If the game is being created with the purpose of being played strictly on emulators, then that would mean I have free reign over the length and complexity
But the only universal truth is that it's up to the dev. If they both know how to and want to support whatever, you can do whatever. If they can't or don't want to, you can't. So you must ask the dev. Yes. Every time. Unless you are already capable or are willing to learn to build music engines/whatever yourself to help them.
The answer is no. And honestly, I'm not even sure it's well emulated yet. If you care about your stuff being played on real hardware, you should expect not to use any expansion sounds.I wonder if this additional hardware is easy/cheap to manufacture for homebrews?
Edit: Hmmm... infiniteneslives is at least working on some boards that supported expanded sound. So maybe you can get there at some point.
It's impossible to answer generally. Certain effects (if they're supported), certain instruments might be CPU intensive. The speed of the song itself could matter too, but... impossible to answer generally.I assume that's where the "speed" of FamiTone, GGSound, etc. comes into play, right?
If you only care about emulation, there's still another problem. As far as I know there doesn't really exist good freely available music engines for expansion sound. (Maybe the famitracker driver is one? But that's not particularly good for games.) I could be wrong on this point and there's something that's just as easy to use for them as Famitone2. But if there's not, what this means is that whoever you pair with has to build a thing just to support your music. And this also locks them into whatever mapper the expansion sound is paired with (which affects how programming will go for many things beyond the music.), unless they also want to build a custom thing that supports the music of the expansion sound and also other things they want.Is this not even possible (or realistic) on emulation-only homebrew dev?
I'd say it's not realistic to expect it for homebrew, no. Maybe for those MMC5 conversion hacks, I don't know enough about them.
There's really no such thing as NES specific compression. NES has a CPU like any other. It's limited by RAM and addressing space, but in theory it can do the same things as a modern computer could. Just very slowly. The issue with compression on NES that whatever you want to compress must be able to fit in RAM decompressed, and be able to be decompressed relatively quickly on the weak CPU.I heard that NES data could be compressed from a Reddit post I made asking why there hasn't been a decent ROM hack of Metal Gear yet. There wasn't a lot of info spilt on NES compression, though.
What the reddit post could mean is that Metal Gear uses a lot a custom compression formats that haven't been reverse engineered yet.
Edit: But ROM hacking (outside of certain graphical things) isn't easy in general. You are editing code you did not write, with no documentation, after it has been assembled. The reason hacks are common for certain games is the hard work has already been done, usually due in part to extreme popularity. Super Mario Bros. has a full disassembly, which is like having documented source code. But... someone had to actually go and figure everything out for that to exist. Same for GUI level editors and things. That's the result of a person spending hours with debuggers trying to figure out what pieces of RAM represented. I would assume no one has done the hard work for Metal Gear yet.
Just as a random aside DPCM is not too much fun to support. Even though, yes, Famitone2 does support it, the data for it has to be in a specific place in memory on NES which makes certain things hard depending on what hardware setup a given game uses. My choice to support it is actually causing a lot of problems in a mini project I'm working on.
Say I gave you a famitone2 test package. You make your song, export it, double click a thing and you'll have a ROM that will play whatever music you gave (or give you errors if you didn't obey the limitations somehow). Is that interesting to you? This could at least give you an idea of how large certain songs would be in Famitone2.