It would help to have the Programmer field for the track list. For situations where one person composed the song, another made the NES version, and the copyright isn't the either of their names. So without a Programmer/Arranger/Whatever field, with no other place to go, this kind of stuff will probably end up in the ripper field or somewhere else that doesn't make any sense.

What's a good way for hardware NSF players to detect the footer and its information? Should there be a header WORD to tell the player the location of the footer?

...

In other news, a group of us are working on a site to archive complete, original NSF works. We may or may not include game releases. The site will be PHP based and have a lot of scripts to convert NSF 1.0 to the accepted 2.0 and also database which 2.0 NSFs are not backward compatible by reading the NSF 2.0 feature byte. Hopefully the site will provide a smooth transition between 1.0 and 2.0.

While looking over this copy of the NSF spec for a good place to stash the length of the music program, I discovered something: "There is no rate but 411ah, and NTSC is the video system of 411ah."

The official NSF spec recommends playing NTSC tunes at $411A = 16666 µs per update. This is accurate for those few (about two if I remember correctly) games that use the APU Frame IRQ to time their music code.

But the PPU runs closer to 60.1 Hz than 60.0 Hz. By my calculation, $40FF = 16639 µs would be more accurate to the hardware for the vast majority of games, which time their music code with vertical blanking.

I'm still planning to try to implement NSF2 in NSFPlay sometime in the near future. There are a few things I propose:

1. If init does not return, it should signal when playback is supposed to begin; the current solution GME and other players use, waiting some arbitrary number of seconds, is not ideal. Perhaps the first write (any value) to $401A could trigger the beginning of playback, or maybe add a new bit to $401A that signals the system to begin calling PLAY at the specified interval. This should automatically be triggered if init returns.

2. Use the NSFe format for the extra data appended to the format; i.e. just stick a properly formed NSFe file on there. You should omit the 'INFO'/'DATA'/'BANK' chunks, obviously, since they're already built into the NSF header and ROM sections, but all the rest of it works quite well in my opinion. (Even the 'auth' chunk can be used to override the 32 byte strings in the header if you need to exceed the length limit, or want a ripper name in there.) New metadata can easily be added as new chunk types. It also has the advantage that unimportant data unknown/unspported by the player can easily be ignored. This also will make it much easier for software that wants to support both NSFe and NSF2.

3. Add an optional 'text' chunk to the NSFe format that's just a null terminated string of any length, letting the ripper describe the file any way he chooses. This is probably more useful and easier for a player to display than trying to add additional optional information fields.

4. B00daW is suggesting we move the register addresses somewhere that doesn't conflict with the newly discovered test registers. Perhaps move them to $401C-$401F?

I'd like to see individual track information saved into the file, including an indication of whether a track is a song, jingle or sound effect. Then with your magical NSF player plugin for winamp, you can enqueue only songs and not sound effects.

This. A thousand times this. Nothing infuriates me more than NSFs that contain sound effects and jingles (I'm a little more flexible on the jingles). And in some cases (just due to either the ripping or the original source data format) sound effects are interspersed with actual songs.

Having this would allow for NSF players to provide the ability to play only tracks of a certain type, e.g. only songs, only jingles, songs + jingles, etc..

I'd suggest using 2 bits somewhere in the file format to define the "track type":

%00 = Song%01 = Sound effect%10 = Jingle%11 = ???

And maybe 2 bits isn't enough room. Maybe folks would want more granularity, so possibly extending that to 4 bits (16 choices) would be ideal. Or for starters, allocating 4 bits but labelling the top 2 bits "reserved for future expansion use". Gotta think ahead.

What's the difference between a "song" and a "jingle", especially in a game like WarioWare where each level is 3 seconds long and followed by 1.5-second win/lose jingle and a 1.5-second next level jingle?

New metadata ideas are easy to add to an extensible format like NSFe. (This is part of why I suggested we just embed NSFe chunks at the end of an NSF2, rather than create yet another metadata format.)

Of course, adding something to the format doesn't by itself do anything. Someone has to care about producing that metadata. Only about about 350 NSFe tagged NSFs exist that I know about, and even at this point very few players support NSFe.

Many NSFe files were made with the playlist containing only the music tracks, and the full NSF embedded underneath having all the sound effects too. NSFPlay lets you disable the playlist in the options to get at the full track list (though it's not terribly convenient; better playlist control is on my to-do list). So... there is a partial form of what you're requesting already.

Anyhow, if you do want that feature, I'd recommend implementing it as NSFe for the time being (rather than waiting for NSF2 support), and get to work tagging some files! (I guess you'll need to modify NotSoFatso, NSFPlay, or some other player to verify...) NSFe files would be easy to auto-convert into NSF2 metadata, I'm sure, whatever form it might take.

I guess there's never really been a central authority for NSF files, just many independently maintained collections scattered around, so trying to get people to tag things consistently is a problem. It seems nobody has really wanted to take up that responsibility the way, say, VGMrips has for VGM.

What's the difference between a "song" and a "jingle", especially in a game like WarioWare where each level is 3 seconds long and followed by 1.5-second win/lose jingle and a 1.5-second next level jingle?

There is universal standard or definition, if that's what you're looking for. It's going to vary per game.

A "jingle" would be something like game over music, or a special tune that gets played when you find an item/achieve something, rather than actual in-game background music. That's the delineation, in my mind anyway. Konami games are filled with these.

Regardless, there definitely needs to be a delineation between sound effects and songs.

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum