NSFPlay 2.1

[B00daW]

I believe I'm partially wrong. The track names appear in "Track Info" on the GUI, but not "Plugin Info" in the "NSF Header" section.

[rainwarrior]

Oh, yeah I didn't put track names in that window.

Actually I'm planning to dump all of the relevant NSFe data into that little misc. frame, but with a button next to it that lets you expand it as a text window and look at all of it easily. Didn't get around to that for this version.

[koitsu]

Minor bug:

nsfplay.txt doesn't document the %L expando for TITLE_FORMAT expansion. I still have no idea what it does, especially when it's used in the default TITLE_FORMAT:

Code: Select all

TITLE_FORMAT=%L (%n/%e) %T - %A

In Winamp 2.5x it seems to generate a whitespace, so the actual default "song string" shown in the player is literally " (xx/xx) Title - Artist" (note the preceding whitespace; sorry, I had to add double-quotes to keep the forum software from stripping the whitespace out).

[rainwarrior]

Yep, I forgot to document it. That's fixed in svn already, just didn't push a new beta for the doc fix. %L/%l is the NSFe track name (the tlbl chunk, i.e. "track label" which is why it's %L).

Is the leading whitespace when there's no NSFe tlbl chunk a problem? I was trying to pick a default string that would work with NSFe by default but wouldn't look too odd if you were just playing an NSF. The space I thought was a reasonable compromise, since the alternative is to have two TITLE_FORMAT options that are selected between by the presence of a tlbl chunk, which I thought would be needlessly complicated. (Also, to clarify, the whitespace isn't generated by the %L. There's just a space after the %L in the title format string.)

[koitsu]

%L isn't a problem, but I think it should act as a no-op (e.g. NULL) if there's no associated NSFe title, rather than print a whitespace. Is that possible?

[rainwarrior]

I was just answering it by editing above. That's what it does. The space is the space that follows it in the string.

[koitsu]

Ahh yes, I see. So what about this: if %L is used and the file being played is NSFe, use the NSFe title. If %L is used and the file being played is NSF, it behaves the same as %T. I guess this could effectively nullify the need for %L entirely, so maybe it would make more sense to nuke that and replace %T's behaviour? Sadly I don't know what the repercussions would be / if it would break existing setups.

Basically what I'm trying to get across is that having both %T and %L in the same playback line seems redundant.

Or with NSFe files, does %T actually represent something completely different than %L (and vice-versa)?

[rainwarrior]

%T is the title of the NSF which is a field present in both NSF and NSFe.

%L is the title of the current track, which is optionally present in NSFe.

e.g. %T="Lagrange Point", %L="Theme of Iris"

If %T is duplicated in %L when %L is missing, you would end up with a title string that looks like "Lagrange Point (1/20) Lagrange Point"

[koitsu]

Ahh got it, got it. Hmm. I wonder how Foobar2000 and some other programs solve this dilemma then (with the "extra space").

I guess one way is after expanding the % expandos you could collapse whitespace (e.g. in perl tr/ //s or the probably-easier-to-understand s/\s+/ /g (\s represents a whitespace in perl regex)) then hand that out as whatever the entire "song string" is. But since this is all in C/C++... well, let's just say I never liked dealing with string parsing/copying/manipulation much in C.

I will state up front I am totally being OCD about it, it's not a deal-breaker in the least, so you can just be like "DEAL WITH IT, GET RID OF %L IN YOUR STRING IF YOU DON'T HAVE NSFe FILES" and that's that, hahaha. :-)

[rainwarrior]

Well, my thinking was that I wanted someone to get what they request from the TITLE_FORMAT string. I don't really like manipulating it "behind their back" since that tends to get counter-intuitive.

However, I might put something in to trim any leading or trailing whitespace, since there's not really a use for whitespace at the beginning or end. That sounds like a good solution to me.

[koitsu]

Okay cool, I'm fine with that too. Like I said: KISS principle in effect, since I don't have any NSFe files, in my case I can just remove %L and stop complaining, hehehe. :-)

Trimming whitespace off the start/end of the entire "song title" string would be wise. However, I would have to advise against trimming whitespace off the start/end of individual NSF/NSFe fields. I know that personally I've caught a few NSFs which had extraneous whitespace in their song titles (the author seemed to think "32 bytes for title" meant "I need to pad the content with spaces" -- sigh, READ THE SPEC!), and I wouldn't have caught those had I not seen them in Winamp.

Oh, and for the hell of it: My own little NSF archive, where I've been trying to clean up all of the existing NSFs whose composers/authors are wrong, fix composer names in Japanese (going with the naming convention of Firstname LASTNAME (family names/surnames in Japanese are usually written in Romaji in all-caps to denote they're a family name)), fixing incorrect sound chip enable/disable bits in the header, and removing sound effects (those should really be in their own files). I've been meticulous about maintaining that readme.txt every time I make a change. All those composers/etc. I really did have to spend quite a bit of time digging up online -- vgmpf, vgmdb, and wikia.com were super helpful but some others I had to dig for (plus get some folks to translate some Japanese pages). Sadly due to the 32-byte limitation in the original NSF header for composer length I can't fit lots of composers in there. This is where NSFe would, obviously, shine.

[Knurek]

Sadly due to the 32-byte limitation in the original NSF header for composer length I can't fit lots of composers in there. This is where NSFe would, obviously, shine.

You can go around the field size limitation and strip SFX without modifying files by utilizing NEZPlug M3Us. I've been using them for Portable Music History sets and so far haven't run into any problems. They are supported by at least NEZPlug++, NSFPlug/Play and foo_get, so should work for most people. There should be at least a few dozen examples in my collection (http://nsf.joshw.info)

Also, please try not to use Zophar's archive. It's massively outdated compared to my pack. You might fix some files that have already been fixed ages ago.

[rainwarrior]

Alternatively, NSFe's title/artist/copyright fields are of unlimited length.

[koitsu]

Sadly due to the 32-byte limitation in the original NSF header for composer length I can't fit lots of composers in there. This is where NSFe would, obviously, shine.

You can go around the field size limitation and strip SFX without modifying files by utilizing NEZPlug M3Us.

Politely: I think you missed the part of my paragraph where I said composer. :-) I couldn't care less about "track titles". See the official doc for yourself -- all it allows for is 1) track titles, and 2) a way to avoid certain playback of certain song numbers (i.e. a way to skip effects). I would much rather fix the source NSFs or just move to NSFe entirely -- plus it saves disk space (consider filesystems formatted using 32KByte clusters; one M3U file could be 1KByte, but takes up 32KBytes of actual disk) + doesn't waste an inode. On embedded systems/platforms this matters more than you can imagine.

There are also things like your 1943 M3U which has track 16 as "Unused" -- for all we know it's not actually "an unused song" as much at could be "just some gobbledegook that got included in the rip" or even "an incomplete song by one of the composers / isn't used". I throw crap like that out. I can't tell you how many NSFs I've had where there are tracks included (at the end of the song list) that are just previous tracks with certain channels muted and so on. Doesn't serve a purpose, and should just be part of the effects package IMO. Matter of opinion though.

Also, please try not to use Zophar's archive. It's massively outdated compared to my pack. You might fix some files that have already been fixed ages ago. :)

I should probably use your NSFs as source material! :-) The only reason I used the ones on ZD is because 1) I knew about them (didn't know about your site until now), and 2) most of them seemed to be originally ripped by Kevtris (part of his nsfcoll.zip collection from long ago).

However -- and again, politely: though some of your NSFs have had the same fixes I've done (specifically ones with incorrect expansion chip bits set in the header), every song I've looked at so far lacks composer fixups. Did you actually read my readme.txt in full? Your listing has absolutely no mention of what's been changed/fixed/etc.. Like I said in my earlier post, I've been extremely diligent about tracking every single change I make to the NSFs so that people would know what I changed and what I started with. It's not about being OCD -- it's about providing something that says to people "in case you wanted to know what exactly is different in these NSFs...". It's equivalent to a code changelog, and I cannot stress how important that is.

Anyway, this is getting off the topic of the thread. When I posted my NSF ""archive"" link I was like "I probably shouldn't do this, it's going to cause people to start analysing it and blah blah and it has nothing to do with NSFPlay". I really need to trust my gut instinct more.

[Knurek]

Politely: I think you missed the part of my paragraph where I said composer.

Actually, there are tag fields in the header of the M3U that don't have size limitations. Not sure if this is an unofficial user extension, or something NEZPlug+ has added, but I've seen it used by people both here and in Japan. Here's an example:

Code: Select all

# @TITLE       Soldam
# @ARTIST      Jaleco
# @COMPOSER    Atsuyoshi Isemura, Yasuyuki Suzuki, Yasuhiko Takashiba, Takahiro Ogata
# @DATE        1993-08-06
# @RIPPER      ugetab
# @TAGGER      Knurek

# Atsuyoshi Isemura, Yasuyuki Suzuki, Yasuhiko Takashiba composed the original arcade game's music, 
# Takahiro Ogata did the Game Boy port arrangements

This works out of the box with foo_gep, and you can use this python script to have them display in Nezplug as well (haven't used NSFPlay for ages, not sure if that works with it). Yes, I'm aware that splitting M3U to micro-files will have a terrible effect on systems with large clusters, I guess I could modify that script to allow for just tagging the M3U without splitting it.

There are also things like your 1943 M3U which has track 16 as "Unused" -- for all we know it's not actually "an unused song" as much at could be "just some gobbledegook that got included in the rip" or even "an incomplete song by one of the composers / isn't used".

I think most of those M3Us are converted from NSFe files, so any issues you (or I, believe me) can have should be taken with NSFe submitter. Many of them are just plain terrible, with bad timers, unverified composer data, using bad NSF rip as a base and other errors like that.

However -- and again, politely: though some of your NSFs have had the same fixes I've done (specifically ones with incorrect expansion chip bits set in the header), every song I've looked at so far lacks composer fixups.

I don't think I did many header fixes, truth be told, I left them for some other, better time. Many thanks for those, BTW.
Most of all the rips there should be the latest correct version (there has been a slew of rerips/fixes that Zophar doesn't host) and should have proper filenames with my naming scheme - Game name (US region priority) [Alt game name if different] (System if not default)(YYYY)(Developer)(Publisher).
I'm currently switching to YYYY-MM-DD release date format, up to G letter at the moment.