duration calculation
Issue #1
new
The nosefart project (http://nosefart.sourceforge.net/) has some broken song duration approximation support. It's implemented by tracing the memory access, when no new data is being read, all content has been read and an approximation of song duration is made. This is not entirely true as there might be forever permuting patterns, but it's a best effort and it works decently. It's however very poorly implemented and crashes on quite a few songs. Having a proper implementation in game-music-emu would be very nice.
I have a source code import of nosefart here: https://github.com/nesouri/nosefart/tree/master
And I've managed to extract a diff containing the duration hacks when comparing it to the XBMC version which does not have these hacks, attached diff. Perhaps might be of some help.
Comments (3)
-
repo owner
-
reporter
The diff contains a lot of crap, but among the crap, there's stuff related to #ifdef NES6502_MEM_ACCESS_CTRL, which is the part of the diff that does the song data reading tracking. The attached diff was only intended as a source of inspiration showing one strategy to calculate duration. Detecting silence does for example not work with looping music, which most music is. Detecting looping music gets somewhat tricky when there's an intro. Detecting looping music is impossible if the song is forever permuting. The strategy in nosefart does seem pretty decent, just sum up until related memory has been read at least once, if I understand correctly.
-
Account Deactivated
Continue at new repo: https://github.com/libgme/game-music-emu/issues/3
- Log in to comment
Thanks for the report Daniel.
I agree it would be good for game-music-emu to be able to estimate the duration of an NSF-based song.
The diff isn't really very useful for implementing a new duration estimator (though thanks for going to the effort regardless). E.g. in this case the diff appears to me to be a routine adaptation of 32-bit code to work on 64-bit machines, certainly there's no large change in the program logic.
Implementing a duration estimator would need to be done in such a way that it doesn't crash, obviously, otherwise it would be unsuitable for inclusion in a library (it wouldn't do to crash an application using libgme just because the wrong song were loaded). It might be easier to go the route of trying to detect silence (which would also fail in the presence of looping tracks, but seems easier to safely handle).
However I'm not sure that I would have time to invest in adding even that... though if someone did implement it, it might be doable in generic fashion so that all supported track types can gain the benefit instead of just NSF.