NSF 2.0 Featureset
Page 2 of 3

Author:  Memblers [ Sat Dec 25, 2010 5:59 pm ]
Post subject: 

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.

Author:  B00daW [ Wed Feb 23, 2011 7:02 pm ]
Post subject: 

Let's aim for ease, compatibility, and simplicity for the tags.

Would it be prudent to possibly compress the tag footer with LZSS? Tokumaru has its code here > ...

Game rip NSF2s will want to be rather thorough to separate jingles and SFX from music and allow categorization via players.

The LZSS might come in handy if a modern artist would like to comment on his/her work and to display it in either a CPU or hardware player; as long as it was limited to say 2K.

Let's try to push this forward! I know we'd all like to possibly see some Squeedo cart works emulated and ripped as NSF. ;P

Author:  B00daW [ Sat Jul 02, 2011 6:39 am ]
Post subject: 

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.

Author:  tepples [ Sat Jul 02, 2011 7:31 am ]
Post subject:  There is no rate but 411ah

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.

NTSC subcarrier rate = 315/88 MHz by definition
NTSC NES CPU rate = 1/2 subcarrier rate = 315/176 MHz
Cycles per APU Frame IRQ = 29830
Thus 176/315*29830 = 16667 µs per update.

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.

NTSC NES PPU pixel rate = 3/2 subcarrier rate = 945/176 MHz
Pixels per screen = 341 * 262 - 0.5 = 89341.5
Thus 176/945*89341.5 = 16639 µs per update.

Author:  rainwarrior [ Wed Mar 28, 2012 4:45 pm ]
Post subject: 

I'm interested in supporting NSF 2 for NSFPlay and I have a few questions:

1. If init is not expected to return, when should we begin to execute play? Do we wait for the NMI flag to be set via $2000?

2. Is a non returning init allowed to generate sound if we never get signaled to start the play routine?

3. Is the format ready for a formal draft? Have we settled on a track name/length format? Can it be put on the Wiki, or somewhere else?

4. Are there any NSF 2 files available for testing?

Author:  Dwedit [ Wed Mar 28, 2012 4:55 pm ]
Post subject: 

I really don't understand NSF2 at all. I could understand perfectly a modified NES format where you stick the song number into A, and run it from there, but NSF2 sounds confusing.

Author:  klarthailerion [ Wed Mar 28, 2012 5:47 pm ]
Post subject: 

rainwarrior wrote:
4. Are there any NSF 2 files available for testing?
I don't think so... I don't think the spec was finalized yet.

Author:  B00daW [ Thu Aug 02, 2012 7:11 am ]
Post subject: 

Big ol' necrobump.

I see an issue with the IRQ registers. They are in the same mapping points as the EXT TST APU registers.

If someone were to write code for the EXT TST registers and make a NSF rip, it would work for NSF 1.0 but would not for NSF 2.0.

Author:  rainwarrior [ Sat Aug 04, 2012 6:28 pm ]
Post subject:  Re: NSF 2.0 Featureset

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.

For quick reference, metadata already supported by NSFe:
plst - track order
time - track lengths
fade - track fade times
tlbl - track names
auth - game/artist/copyright/ripper (strings of any length)

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?

Author:  zzo38 [ Tue Aug 07, 2012 6:28 pm ]
Post subject:  Re: NSF 2.0 Featureset

Yes, a time limit (perhaps in video frames?) may be useful if you want to use a playlist instead of having the song loop from the loop point.

Author:  tepples [ Sun Mar 22, 2015 1:51 pm ]
Post subject:  Re: NSF 2.0 Featureset

This bubbled up again in #nesdev recently.

So now we need to define what goes in the footer. One thing I know we'll need is balance for Namco 163 vs. 2A03.

Author:  koitsu [ Sun Mar 22, 2015 3:31 pm ]
Post subject:  Re:

Dwedit wrote:
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.

Author:  tepples [ Sun Mar 22, 2015 3:49 pm ]
Post subject:  Re: NSF 2.0 Featureset

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?

Author:  rainwarrior [ Sun Mar 22, 2015 5:32 pm ]
Post subject:  Re: NSF 2.0 Featureset

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.

Author:  koitsu [ Sun Mar 22, 2015 8:52 pm ]
Post subject:  Re: NSF 2.0 Featureset

tepples wrote:
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.

Page 2 of 3 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group