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.)