NSFe/NSF2 "time"

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

Post Reply
NewRisingSun
Posts: 1060
Joined: Thu May 19, 2005 11:30 am

NSFe/NSF2 "time"

Post by NewRisingSun » Wed Oct 09, 2019 9:01 am

What exactly is the meaning of the "time" field? The wiki states "When the track has played for the specified time, it should begin fading out", which is not very precise --- I could want a track to start fading after one, two or more iterations of a loop. Who decides when it should fade? The NSFe author, entirely according to his own discretion?

VGM is more precise and way more flexible in this regard: the loop duration specifies the number of samples until the song starts looping. That allows the user to specify how many times he wants a track to loop before it starts to fade. The format then incorporates a "loop modifier" for tracks that sound almost-but-not-exactly the same on subsequent loops.

Could such a feature be incorporated into NSFe/NSF2? If not, could at least there be a recommended practice regarding song lengths (e.g. fade after song has played twice, i.e. looped once, completely) in the specification?

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSFe/NSF2 "time"

Post by rainwarrior » Wed Oct 09, 2019 10:10 am

NewRisingSun wrote:"When the track has played for the specified time, it should begin fading out", which is not very precise
The precision of the field is 1 ms. The fadeout has its own per-track field as well. That should be more than precise enough for this purpose?
NewRisingSun wrote:I could want a track to start fading after one, two or more iterations of a loop. Who decides when it should fade? The NSFe author, entirely according to his own discretion?
Yes that's what the field does.
NewRisingSun wrote:(VGM has loops)
Yes, it does. I don't think the issue is "precision", though.

VGM has an active maintainer who also maintains a central repository and ripping tools, and evaluates new submissions for ripping standards. NSFe, on the other hand, has no active archive maintainers. That's really how VGM has consistency.

Disch made the only collection of NSFe files that I know about: https://disch.zophar.net/nsfe.php

That archive conforms to Disch's ripping standards, whatever they were, assuming they are even consistent with themselves.

I don't know of anyone else who has produced such an archive. Otherwise the use of the NSFe format is very ad-hoc/sporadic as far as I've seen. (I don't claim to know everything that's going on, though.)
NewRisingSun wrote:Could such a feature be incorporated into NSFe/NSF2?
Yes it could easily have a loop field. It won't do anything until players update to use it, but it's an extensible format.

So, you could maybe add a "loop" chunk with a pair of numbers specifying start end end of a loop. I'd recommend keeping them 32-bit and 1 ms resolution to be consistent with other fields. Players that haven't implemented this chunk will continue to use the "time" chunk as before. Non-looped tracks should also fall back to "time" I guess (0s for start and end?).

If you wanna go all the way down the road of duplicating VGM you could even include the "loop base" and "loop modifier" ideas. I dunno how important they really are in practice.
NewRisingSun wrote:If not, could at least there be a recommended practice regarding song lengths (e.g. fade after song has played twice, i.e. looped once, completely) in the specification?
Well, VGM doesn't specify how many loops something should have. It primary considers that a user option, and avoids having so recommend anything by having the loop field. I'd tend to agree with that thought, i.e. loop count is a preference only and should be an option. A lot of NSF players already have a loop detector and option for how many loops, so at least it's probably won't need much new UI to implement similar loop preferences for NSFe.

I don't really think it would be good to imply within the specification that there is a particular standard for how many loops to include in NSFe's "time" field when there isn't one de facto. If you create an archive with a consistent practice it might be worth pointing out that "such and such archive recommends 2.5 loops in the time field", but otherwise I think the specification should describe only how it is used and has been used, rather than stating a hopeful preference. (If you want to dig through Disch's archives and determine if it has a standard, it might be worth mentioning similarly.)

NewRisingSun
Posts: 1060
Joined: Thu May 19, 2005 11:30 am

Re: NSFe/NSF2 "time"

Post by NewRisingSun » Wed Oct 09, 2019 10:29 am

rainwarrior wrote:The precision of the field is 1 ms. The fadeout has its own per-track field as well. That should be more than precise enough for this purpose?
I meant it was not precise regarding what the correct value should be in terms of loop treatment. But now that I have your response, it was actually spot-on in the sense that it should contain whatever the NSFe author wishes it to be.
rainwarrior wrote:Otherwise the use of the NSFe format is very ad-hoc/sporadic as far as I've seen.
The background of my question is that I would like to build an archive of NSF files, NSF2 if necessary in a particular case, that has the NSF2 metadata for all games. The time fields would be filled through automatic loop detection, but I was wondering how I should treat looped songs. The wiki was not explicit whether there was an existing standard or recommended practice, or everybody just makes it up as they go along. Since I now understand it to be the latter, I think I will specify the length of looped songs with one repetition, so that the loop can recognized, and non-looped songs with two seconds of silence afterwards. I believe that is the practice of VGMRips and some other video game music websites.

Post Reply