lidnariq wrote:
I don't think it's a clever idea to append a chunked format to the existing iNES format.
I wasn't trying to do something "clever", I was trying to suggest something "extensible".
lidnariq wrote:
It's impossible to support every single possible way someone could inject audio data...
...except with an easily extensible format? It's incredibly possible with chunks.
lidnariq wrote:
We probably should limit it to the actual set of hardware used by games before the homebrew era.
Why? There's plenty of desire to run homebrew. There's already
homebrew that just barely exceeds iNES 2 PRG size constraints that I think might be valuable enough to run in an emulator.
lidnariq wrote:
And I'd definitely object to "someone put an MP3 player in a NES cartridge, let's embed MP3s into .NES files"
I certainly don't think such a thing would warrant reservation of the 16 precious remaining bits of the header, but with an extensible format with optional inclusions it wouldn't be any kind of burden on any emulator author to simply not-support and ignore it entirely.
Similarly, if you don't want a ROM with MP3s in it, that's no problem for you... you don't have to download that ROM! Someone else would probably care about it though!
An extensible format means it's possible for people to add new bits of data they have a use for without having to play some political game of deciding whether it's important to be part of the format or not. Anybody that thinks it's important can pick it up and add it, anyone that doesn't can ignore it without changing a single line of code in their emulator.
lidnariq wrote:
I mean, UNIF, MAME/MESS format, and byuu's thing are over there. I see no need to recapitulate that argument.
All of those format arguments indicate a
large desire to include other information in the file that maybe
you think isn't important, but other people do. The whole reason I suggested chunks was to
avoid argument and arbitration about what can go in the file-- it makes it very easy to ignore anything you don't care about!
It even makes it easy to write a tool that can just strip out metadata types that you don't like from your ROM collection.
Anyhow, the reason I suggested it is that it's very easy to implement, simple, practical solution to a general problem that seems to continually arise. This thread is maybe narrowly about one specific case of that problem, but I'm certain it will keep coming up. I don't really understand the downside to it (?), so it's a serious suggestion on my part.