Automatically determining track lengths?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic

Automatically determining track lengths?
by tepples on 2005-12-28 (#7808)

blargg wrote:

Even if a track has no timing information, a player should fade it out after some number of minutes. The proper solution is for the song file itself to encode the length of tracks in the file itself. If this can be done automatically, great, but do that on the archive copy of the file rather than requiring a player to go through backflips. For the NSF format, this has been solved, and it's called NSFE.

Is there a way to mass-convert NSF files to NSFE with accurate track lengths without having to pay somebody at least minimum wage to sit down and listen to each track in each NSF and write down when to fade them out?

by blargg on 2005-12-28 (#7810)

A nice distributed solution would be to capture this data as a part of people's natural NSF playing behavior. The main piece of data desired is the length to play the song before fading out. The rest can be determined automatically or doesn't matter.

I've written command-line tools to convert between NSF+text file and NSFE (both ways), and have done some experimentation with automatic loop finding by looking at registers and frequency (FFT) data. Even with an automated tool someone would need to check the files for cases where automated detection fails.

I guess I don't listen to game music that much, since I get by fine with my player which fades out after 2.5 minutes (or different if the track specifies a length).

by NewRisingSun on 2005-12-29 (#7845)

Quote:
by looking at registers and frequency (FFT) data
Frequency data?

Under what scenario might the following similiar approach fail: For each frame, make a snapshot of both CPU RAM and hardware registers --- then compare each new frame's snapshot with all previous ones. If a match has been found (all variables are the same), the track is looping or stuck in silence. If no match has been found after, say, five minutes worth of snapshots --- or any time after which it can be said that the music MUST be over by now ---, there must be some "rogue" variables that never get reset upon looping, because they count "how much time has passed since playing started" or something like that.
Determine which variables they are, because they don't match any previous snapshot, and go through all frame snapshots again, comparing each one with all previous ones, but this time ignoring said variables.

Either way, the first snapshot that matches a previous one is the end of the song. If one snapshot takes about 4 KB (more for NSFs from games that had extra RAM), said five minutes would need 4 KB * 60 snapshots per second * 300 seconds = 72000 KB, which shouldn't be a problem with today's harddisks. Since it would run all by itself, speed should not be that big an issue either, and it doesn't need to run in real-time...

by blargg on 2005-12-29 (#7847)

My idea with frequencies was to perform a Fourier transform on blocks of samples. Below is a frequency plot of the beginning of Super Mario Bros. main theme. You can follow the upper light gray bars for the first few notes of the melody.

I figured this might make it easier to look at the important data, since the waveforms might differ.

Your idea about looking at system state sounds excellent. I just threw together a simple version saves 32-bit checksums of the low 2K RAM and it works on several tracks from Destiny of an Emperor. I have it play 5 minutes of the track (only takes a little over a second of host CPU time) and then start at the beginning of the checksums for each 1/60 second frame and find a run of 20 or more that repeat later in the track. I'll have to experiment with the "rogue variables" issue.

Quote:
If one snapshot takes about 4 KB (more for NSFs from games that had extra RAM), said five minutes would need 4 KB * 60 snapshots per second * 300 seconds = 72000 KB, which shouldn't be a problem with today's harddisks.

That also shouldn't be a problem just keeping it all in RAM, with today's memory capacities. It might even be simpler to just keep checksums of the snapshots and then regenerate them when actually needed (by running multiple NSF emulators at once or something).

by NewRisingSun on 2005-12-29 (#7848)

I think there's at least one scenario where my approach fails: if the track itself doesn't loop, but the voices loop out of sync at different times, like in Gradius.nsf song 2.

by blargg on 2005-12-29 (#7851)

I don't think the "rogue variable" problem can be eliminated without making further assumptions. Say a music engine increments a 16-bit value once each frame. Every 4.27 seconds the low 8 bits will loop. How do you eliminate this from consideration?

I was thinking more about what state to monitor and it seems that it would be simpler to examine only sound register writes each frame, looking for total repetition of the same writes. This will never be more strict than looking at total system state, since identical system state will always result in the same register writes, while a given set of register writes could occur from several possible system states. Looking at register writes eliminates the "rogue variable" problem.

The one remaining problem I foresee is songs with tempos that aren't an integral division of 3600 bpm. With these, the song's loop might not coincide with the same tempo divisor fraction as when the song first passed that point, causing slight variation in the timing that would throw off a loop detector. Perhaps it could ignore +/- 1/60 second differences in timing.

by blargg on 2005-12-29 (#7855)

The register writes approach is working pretty well (actually, just a checksum of the register writes right now), and I was able to put in some allowance for +/- 1/60 second jitter. It's given proper times for tracks from several different soundtracks from different games, having trouble on a couple of tracks from each.

At this point I could put together an open-source command-line tool that took an NSF and generated a text file timesheet, which you could then fill in with the track names, adjust times, add playlist order, and adjust any other fields, then feed this and the NSF through an NSFE builder tool to generate the final NSFE. It'd be nice if we had a good automated NSF/NSFE submission site as I described in another thread.

The format is something like this (... parts snipped to save space).

Code:
Game: Snake's Revenge
Author: T. Ogura
Copyright: 1990 Konami/Ultra Games
Ripper: Matt Conte

Playlist:
05 0:24 Introduction
00 0:38 Mission Introduction
...
09 1:23 Ending/Staff Roll
18 0:05 Mission Failed

Tracks:
20 - Pause
21 - Tap
22 - Tap 2
...

by Knurek on 2005-12-30 (#7861)

blargg wrote:
The register writes approach is working pretty well (actually, just a checksum of the register writes right now), and I was able to put in some allowance for +/- 1/60 second jitter. It's given proper times for tracks from several different soundtracks from different games, having trouble on a couple of tracks from each.

Groovy. The big question - does it have loop number support? I'd like to have my track play for two loops (a bit of a standard in VGM community). Doubling the detected time would only work for the tunes that don't have an intro part.

And does your method work with songs that have this structure: loop, loop, small outro, loop, loop, small outro. There was a song in Ys3 that did that (Theme of Chester).

Also, keep in mind that some of us actually don't use NSFE (NotSoFatso works like ass with XMPlay, and actually I prefer the sound of in_yansf (Farty preset)), so even if you integrate a NSFE creator in the detection tool, please keep the text output option, as converting from that to M3U playlists or whatever would be n times easier than from NSFE files.

by Dwedit on 2005-12-30 (#7866)

Is it possible to detect song loops in games like Wizards and Warriors 3 where the song speeds up each time it loops?

by blargg on 2005-12-30 (#7869)

As far as number of loops, that information is available. NSFE doesn't have a block for it, but one could be added, allowing the player to decide how many loops based on the loop start and duration. The normal play time before fade out would be based on the number of loops, but up to final adjustement based on how long it's pleasant to listen for. The loop algorithm currently verifies that the found loop continues through the entire time it sampled (I think I'm using 10 minutes currently), thus songs with sub loops won't throw it off.

I didn't realize that NSFE wasn't the preferred format. Can't someone just modify players to support it? I've got some LGPL code that reads an NSFE and then converts in memory to an NSF for use with a normal NSF sound engine, and allows access to the track names. Or perhaps the issue is that multiple tracks in a single file are problematic, and that this has already been solved in a general way with the use of m3u files?

I'm making two separate tools: loopnsf to find the loop points and output these as a text file, and nsf2nsfe to build an NSFE from an NSF and text file. I'll modularize loopnsf a bit more to make it easy to output an m3u instead. I've also written an nsfe2nsf tool, which could be made to output an m3u from an NSFE, which might be the most helpful of all. They'll all be open-source so you can tweak these things once I'm done. What format should the m3u file be (I'm not at all familiar with m3u)?

I tried it with Wizards and Warriors and it didn't find the loops. So the songs steadily speed up, eventually going really fast? The main goal of the tool is to find the loop times of most tracks, leaving the problematic ones to a person to do manually.

Running on the version of Ys III that I have, loopnsf outputs the following track times (reformatted to save space). Tracks marked with a dash eventually end, which I don't have the tool detect yet.

Code:
0 1 2 3 4 5 6 7 8 9
0 1:36 1:08 2:28 0:56 1:24 1:30 - - 3:38
1 - - - 1:06 - 3:23 0:42 1:42 1:14 2:33
2 1:56 2:32 1:36 0:50 0:28 2:06 -

by Knurek on 2005-12-31 (#7871)

blargg wrote:
As far as number of loops, that information is available.

Joy. Listening to NSFs is gonna get more pleasant soon.

blargg wrote:
I didn't realize that NSFE wasn't the preferred format. Can't someone just modify players to support it?

Well, both NSFPlug (in_yansf) and NEZPlug (in_nez) are open source, so it's possible. Still, both haven't been updated for a while (well, NEZPlug got recently updated by RuRuRu, but that was only compatibility fixes).

blargg wrote:
Or perhaps the issue is that multiple tracks in a single file are problematic, and that this has already been solved in a general way with the use of m3u files?

The thing is - with M3U playlist I can listen to timed songs whenever I want, but if I want to listen to the tunes endlessly, I just open NSF file. No plugin reconfiguration required.

blargg wrote:
What format should the m3u file be (I'm not at all familiar with m3u)?

Extended M3U format used by both NEZPlug and NSFPlug:

# Solstice (CSG Imagesoft) [1989]
# Composer: Tim Follin

(comments start with # at the beginning)

Solstice (1989)(CSG Imagesoft).nsf::NSF,06,Title - Tim Follin - Solstice - ©1989 CSG Imagesoft,177,,1
Solstice (1989)(CSG Imagesoft).nsf::NSF,02,Main Theme - Tim Follin - Solstice - ©1989 CSG Imagesoft,112,113,7

(entry structure is: name_of_the_nsf_file::NSF,[1 based songno(dec)|$songno(hex)],[title(text, no commas obviously)],[time(h:m:s)|time(s)],[loop(h:m:s)|time(s)][-],[fade(h:m:s)|fade(s)],[loopcount])

Use the decimal songnumbers, as the hex ones aren't compatible between NSFPlug and NEZPlug (ie: NSFPlug starts from $0x01, NEZPlug from $0x00).
Time format is a bit tricky.
The first track doesn't loop, so I just set the time (i'm doing seconds, but you can swith 177 with 2:57, both work), skip the loop declaration, and add a 1 second fade to be on the safe side.

The second track loops, so i set the time to the duration of the first loop (112 seconds), the loop to the duration of the second loop (113 seconds), and fadeout to 7 seconds (my personal standard).

This could be done this way too: 112,-,8 (where - means that the loop equals the time).

I could also add a loopcount after the fade (ie, if I like to hear 4 loops, I'd just set: 112,-,8,3).

blargg wrote:
Tracks marked with a dash eventually end, which I don't have the tool detect yet.

Smiles at the yet part.

blargg wrote:
Code:
0 1 2 3 4 5 6 7 8 9
0 1:36 1:08 2:28 0:56 1:24 1:30 - - 3:38
1 - - - 1:06 - 3:23 0:42 1:42 1:14 2:33
2 1:56 2:32 1:36 0:50 0:28 2:06 -

Tracks #7 and 8 do loop. The rest is fine, including the detected times (which are spot on from what I've checked).
I was talking about the Megadrive version of Ys3, seems like the NSF file doesn't have "The Theme of Chester" song. Not sure if it's a incomplete rip, or if the tune just wasn't in the NES convertion.

by kingshriek on 2005-12-31 (#7872)

"The Theme of Chester" is only in the X68k, MD, SFC versions (source: http://homepage2.nifty.com/tkdate/ysmusic/cd/bgm3.html).

by blargg on 2005-12-31 (#7873)

I was thinking more about what conversions to support and it makes most sense to have a loop finder that outputs a text file for building an NSFE, the NSFE builder, and an NSFE to NSF+m3u convertor. This way anyone timing an NSF will always generate an NSFE, thus encouraging them to contribute that to the NSFE archive. Because there are other NSFE tagging tools, the nsfe2nsf+m3u tool will be more useful.

The loop finding algorithm could use more work. I figured I'd get the overall tool organization worked out before discussing refinements. Perhaps at that time everyone can be trying a test build and tweaking the algorithm in parallel. I also stopped being lazy and added the "notice if the track went silent" bit to properly time tracks that end normally.

by blargg on 2006-02-14 (#9542)

I've finally got back to working on the NSF timing and NSFE generation tools. Sorry for the sudden absence from when it was being discussed over a month ago. At this point three command-line tools seem best:

timensf - Automatically times NSF tracks, both those that end and those that loop endlessly. It writes a text file with all the information. You'd then edit this text file as necessary (add track names, fix times, move tracks to playlist).

nsf2nsfe - Takes original NSF and text file to produce NSFE.

nsfe2m3u - Generates M3U and NSF file given an NSFE. This allows any NSFE file to be used, not just those created with the above tools.

They are almost done. I'd like to get things fine-tuned before I release the source code. In particular, the M3U functionality needs to be evaluated. I used Duck Tales as an example and made an archive of the files at each step in the process, going from original NSF to timed and tagged NSFE to M3U:

nsf_tools_example.zip

As for Win32 builds, we'll need someone who can compile the C++ source code.

by NewRisingSun on 2006-02-14 (#9548)

Nice, but consider adding a finer resolution than just seconds.

by Knurek on 2006-02-14 (#9553)

blargg wrote:
I've finally got back to working on the NSF timing and NSFE generation tools. Sorry for the sudden absence from when it was being discussed over a month ago.

I've been meaning to PM you to ask you about it. Nice to know that you were still working on it.

blargg wrote:
They are almost done. I'd like to get things fine-tuned before I release the source code. In particular, the M3U functionality needs to be evaluated. I used Duck Tales as an example and made an archive of the files at each step in the process, going from original NSF to timed and tagged NSFE to M3U:

What about the loop number option I've talked about earlier? Remember that there are songs with intros and then looped part, so simply doubling the detected time won't work.

Also the m3u file doesn't work with XMPlay+NSFPlug. Changing the "<?>" to "?" in track info entries fixes that, not sure if it's NSFPlug quirk or does the extended M3U format doesn't support < and > chars.

blargg wrote:
As for Win32 builds, we'll need someone who can compile the C++ source code.

Define C++ source code. I have a MinGW and VC2005Express installed here (and might try adding Cygwin if those two wouldn't work for your code).

by blargg on 2006-02-14 (#9556)

What's an example of where finer time resolution would make a difference? I could allow fractional seconds, as in 1:20.5 for a song that's 80.5 seconds. I've never understood the need for this, but would like to. NSFE times are in milliseconds, for reference.

Quote:
What about the loop number option I've talked about earlier? Remember that there are songs with intros and then looped part, so simply doubling the detected time won't work.

Currently the only timing information for a track is a single duration. The idea is to make the track act like a normal music track that has a fixed length. I can't see how having data on the intro and loop length helps much, since you can always just tell the player to play the track longer if you want to listen to it more. Most players need built-in end-of-track silence detection anyway, so if you extend a non-endless track then the player will detect the silence and stop at the normal end anyway.

I'd like to stick to standard NSFE fields, and the only supported timing data I see is track duration and fade duration. This also causes anyone timing a track to produce an NSFE, which is a preferable format to an NSF+m3u (in my opinion). Supporting other data would be possible by adding a new block type to the NSFE, but I really doubt that people doing timing and tagging will bother to determine these times, due to their limited use. Again, I'm open to examples where these would really help.

Quote:
Also the m3u file doesn't work with XMPlay+NSFPlug. Changing the "<?>" to "?" in track info entries fixes that, not sure if it's NSFPlug quirk or does the extended M3U format doesn't support < and > chars.

I don't have a Windows machine so I didn't have any way to test the M3U file; I just made it match the format you gave. I really hate those fields being filled in with "?" or any other crap. In my opinion, if the field is unknown, it should be BLANK! I have deal with this in my standalone game music player by replacing things like "?", "<?>", "< ? >" with "" (empty string). Err, back to your topic, I'll make the m3u string filter function easy to extend to cover any other illegal characters. Any suggestions on what to replace them with? Right now we've got these characters: ,<>

Quote:
Define C++ source code. I have a MinGW and VC2005Express installed here (and might try adding Cygwin if those two wouldn't work for your code).

It's pretty plain code making fairly light use of C++. Most of the code (the NSF playback engine) has been compiled on many compilers and platforms already. As long as you know how to compile and build a program, I can fix any compilation errors that arise.

And just to recap, the idea of timensf is not to automatically time every track of every NSF properly, but to get enough of them right that the time spent filling in the gaps and fixing any bad times is much less than timing them all manually.

by Knurek on 2006-02-15 (#9562)

blargg wrote:
I can't see how having data on the intro and loop length helps much, since you can always just tell the player to play the track longer if you want to listen to it more.

Well, timing for two loops seems to be a de facto VGM standard (see snesmusic.org or www.caitsith2.com/gsf. Most of PSF/USF files are also timed this way).
Consider this:

You start with making NSF+M3U, where the time fields are:

ending tracks - time (if no fade -> track is ending)
endless tracks - first_loop_time,second_loop_time,fade,number_of_loops

where fade and number_of_loops would be changable by command line arguments (with defaults being, say, fade=7 and number_of_loops=2).

Then you run a NSFE maker, parsing the M3U file, and set the track duration field to first_loop_time + second_loop_time*(number_of_loops-1) - of course if number_of_loops=0 or undefined, then don't substract and multiply.

No loss of timing information (as the m3u stays, and could be included in with NSFE), and you can easily retime both NSF and NSFE to your needs (changing the number_of_loops and fade would be quite easy given that the M3U is just a normal text file).

Thing is - if you can detect the first loop point automatically, the second one should be doable too. And detecting them manually is about as much work as timing the file from scratch.

blargg wrote:
Err, back to your topic, I'll make the m3u string filter function easy to extend to cover any other illegal characters. Any suggestions on what to replace them with? Right now we've got these characters: ,<>

'*' seems to be a no-no too.
You might consider changing (C) string to '©' (ASCII $A9). Is handled fine here. I've been changing the ',' in author field with '&'.
You can change the <?> to blank field, or 'Unknown Author', no real preferences here...

blargg wrote:
As long as you know how to compile and build a program, I can fix any compilation errors that arise.

Okay, there shouldn't (hopefully) be much problems given that it's a CLI program.

by NewRisingSun on 2006-02-15 (#9567)

blargg wrote:
What's an example of where finer time resolution would make a difference?
Whenever the actual length of a song does not coincide with the boundary of a second, so pretty much always.
blargg wrote:
I could allow fractional seconds, as in 1:20.5 for a song that's 80.5 seconds. I've never understood the need for this, but would like to. NSFE times are in milliseconds, for reference.
The actual song length would be in frames (1/60 second), but if NSFe requires milliseconds, then convert the frames to milliseconds (factor 1000/60).

by blargg on 2006-02-15 (#9585)

What I'm still lacking are the practical problems caused by the limitations. In other words, describe a user scenario where these limitations manifest as a problem:

1) Limiting timing to second accuracy
2) Having a single track duration without any loop points

As for using M3U as the intermediate text file, its format is not near as suitable for easy editing of tags:

Code:
# Disney's Duck Tales
# Composer: <?>
Duck Tales.nsf::NSF,01,Title - <?> - Disney's Duck Tales - (C) 1989 Capcom Co. Ltd.,1:44,2
Duck Tales.nsf::NSF,03,The Amazon - <?> - Disney's Duck Tales - (C) 1989 Capcom Co. Ltd.,1:16,2
Duck Tales.nsf::NSF,04,Transylvania - <?> - Disney's Duck Tales - (C) 1989 Capcom Co. Ltd.,1:22,2

Game: Disney's Duck Tales
Author: <?>
Copyright: 1989 Capcom Co. Ltd.
Ripper:

Playlist:
01 1:44 Title
03 1:16 The Amazon
04 1:22 Transylvania

Tracks:
02 0:06 Select
10 0:03 Game Over
11 0:04 Land Complete

It also needs extension to support a field for the copyright, ripper, and optional playlist. Why does an M3U repeat the game name, author, and copyright for every track? If we can improve the appearance of the M3U, I'd be more open to using it as the intermediate format. Say something like this:

Code:
# Disney's Duck Tales
# Composer: <?>
# Copyright: 1989 Capcom Co. Ltd.
# Ripper:

# Playlist:
Duck Tales.nsf::NSF,01,"Title",1:44,2
Duck Tales.nsf::NSF,03,"The Amazon",1:16,2
Duck Tales.nsf::NSF,04,"Transylvania",1:22,2

# Other Tracks:
# Duck Tales.nsf::NSF,02,"Select",0:06,0

Other tracks commented out so they won't play normally, but so tool can still add their timing information to NSFE.

by Knurek on 2006-02-15 (#9590)

blargg wrote:
What I'm still lacking are the practical problems caused by the limitations. In other words, describe a user scenario where these limitations manifest as a problem:
2) Having a single track duration without any loop points

Well, as long as I *can* specify the amount of loops the timing tool will detect, I don't really care whether it's outputing single time or not (I don't even care for tags much, I will have my player in the background, so tags are just a bonus. It's times that matter).

I must have misunderstood you, because I thought you were saying the timing tool only detects time of the single loop. And now I see that the times for Duck Hunt are indeed two loops. Blah, lateness induced stupidity.

by NewRisingSun on 2006-02-15 (#9591)

blargg wrote:
What I'm still lacking are the practical problems caused by the limitations. In other words, describe a user scenario where these limitations manifest as a problem:
Limiting timing to second accuracy
What I'm still lacking is the practical problem caused by implementing the millisecond field as well. Oh well.
If you round down, you'll lose the end of the song. If you round up, there will be a blip of the first few frames of looping heard before moving on to the next song in the case of looped songs, which sounds stupid, or a variable amount of silence between songs in the case of non-looped songs, which also sounds stupid.

by blargg on 2006-02-15 (#9593)

Knurek wrote:
Well, as long as I *can* specify the amount of loops the timing tool will detect, I don't really care whether it's outputing single time or not (I don't even care for tags much, I will have my player in the background, so tags are just a bonus. It's times that matter).

I think I'm better understanding the big picture. My idea was to write some tools to help with timing and tagging NSF files to produce NSFE files suitable for submission to Disch's NSFE archive, so that everyone benefits from the work. Your idea seems to be a quick-and-dirty tool to privately time NSF files for personal use only, so no NSFE would ever come of it. It only seems worthwhile to write the tools if they help expand the public NSFE archive, and make that as easy as possible, so that many people can run the timing tool, do fixups, and add to the NSFE library.

I'm not opposed to using an M3U as the output of the timing tool, as long as it is easy to edit and can represent the basic NSFE information, including the optional playlist.

NewRisingSun wrote:
What I'm still lacking is the practical problem caused by implementing the millisecond field as well.

Are you proposing to have all time fields in milliseconds (or even 1/60 seconds), or in both mm:ss and milliseconds, or perhaps mm:ss.msec? Only the latter seems practical, but I don't think the M3U file allows for that accuracy.

Propose a way to incorporate it into the toolchain. Maybe we should recruit some people who are willing to time and tag many NSF files using these tools, then ask them what format they're willing to enter times in. They'll be taking the NSF, running timensf on it, then fixing up any bad/unspecified times using a normal NSF player. Most NSF players I know only show seconds, so I don't know where they'd get this accuracy from. I really doubt any taggers will care to write the NSF to a wave file then use a sound editor to get timing points to 1/60 second accuracy.

I still can't imagine any significant audible effects of having only second accuracy. There are two basic track types: those that end, and those that are endless. For those that end, there should be some silence afterwards, so no problem there. For endless tracks, a player should fade them out, so a +/-0.5 second variance shouldn't make an audible difference either.

Timensf does work at 1/60 second accuracy and could preserve this in its output. It also knows the intro and loop times, so could output these if we decide to use an M3U variant as the intermediate format. Ideally it'd be nice to have timing at the native resolution, i.e. 1/60 seconds, but I just can't picture anyone bothering with this when they have to manually time a track.

Quote:
If you round up, there will be a blip of the first few frames of looping heard before moving on to the next song in the case of looped songs, which sounds stupid,

It'd be just finishing fading out by then. On my player I use a 6-second exponential fade, so an extra 0.5 seconds of the loop won't be noticeable. If the player is not doing any fading out, then it already sounds stupid regardless.

Quote:
or a variable amount of silence between songs in the case of non-looped songs, which also sounds stupid.

Wouldn't a player detect the silence at the end of the track and adjust the end-point on its own? It's got to do this for untagged tracks, so it might as well do it for tagged tracks too (only turning on silence detection a few seconds before the end, of course).

by Knurek on 2006-02-15 (#9605)

blargg wrote:
I think I'm better understanding the big picture. My idea was to write some tools to help with timing and tagging NSF files to produce NSFE files suitable for submission to Disch's NSFE archive, so that everyone benefits from the work. Your idea seems to be a quick-and-dirty tool to privately time NSF files for personal use only, so no NSFE would ever come of it. It only seems worthwhile to write the tools if they help expand the public NSFE archive, and make that as easy as possible, so that many people can run the timing tool, do fixups, and add to the NSFE library.

I did write earlier (whether here or on the new rips thread), that I can't really use NSFE. Not that I'm opposed to the idea or something, but the current implementation leaves a bit to be desired (short story - until NSFPlug supports them, no NSFE for me, and that's not bloody likely).

Also, look at the facts - NSFE aren't all that popular. Disch site has what, 300 packs, half of which are Tsu Ryu's works. Compared to 1200+ game NSFs and 1200+ 2A03.org collections that's close to nothing.
Having your tool might speed up things a bit (though there's still the whole lotta work other than timing - I don't really see any givers for tagging an untranslated RPG/Mahjong game), but let's face it - it will be years (if ever) before it catches up.

I don't want to wait years to listen to Lagrange Point or Metal Slader Glory (I mean, listen with times and all). You can call me impatient, you can call me selfish, but that's just the way it is.

Personally I find the way HVSC does things a good one. Standard, untouched SID files, separate textfile with time information (automatically generated, but they're taking correction submissions), another textfile with tag information. I'd change the identification from path based to MD5 hash based, but there are sid plugins that do that already. Too bad nobody's gonna do a similar NSF collection anytime soon.

by blargg on 2006-02-15 (#9610)

Quote:
Also, look at the facts - NSFE aren't all that popular. Disch site has what, 300 packs, half of which are Tsu Ryu's works. Compared to 1200+ game NSFs and 1200+ 2A03.org collections that's close to nothing.

NSFE files aren't that numerous, but I think this is due to 1) NSFE being a much more recent file format than NSF, and 2) the only NSFE tagging tool (that I know of) requiring that one run Windows and use Winamp. One of my goals with these tools was to allow anyone to make NSFE files.

If this argument supports the position of avoiding the NSFE file format, then it applies equally to the M3U+NSF format (unless I'm missing something here).

Quote:
Having your tool might speed up things a bit (though there's still the whole lotta work other than timing - I don't really see any givers for tagging an untranslated RPG/Mahjong game), but let's face it - it will be years (if ever) before it catches up.

Before my tools catch up with what? I don't follow. My understanding is that currently we have a large number of NSF files without any track names or timing information. We would like to have this information. This requires two things: people to add it, and a file format that captures it. The tools are to make timing and tagging take less time. Then we have two candidate file formats: NSFE or NSF+M3U. NSFE is well-documented, avoids having multiple files, and is supported on most platforms. M3U+NSF can be derived from an NSFE if necessary, though it has some fields not captured in the standard NSFE blocks.

Quote:
I don't want to wait years to listen to Lagrange Point or Metal Slader Glory (I mean, listen with times and all). You can call me impatient, you can call me selfish, but that's just the way it is.

What's keeping you from it? Is it only available in NSFE format or something? That was one point of having the NSFE-to-NSF+M3U tool.

Quote:
Personally I find the way HVSC does things a good one. Standard, untouched SID files, separate textfile with time information (automatically generated, but they're taking correction submissions), another textfile with tag information.

Why not use an updated SID file format that can hold all this information in one file? Multiple files creates more of a mess for the end-user, having to keep them together.

Quote:
I'd change the identification from path based to MD5 hash based, but there are sid plugins that do that already. Too bad nobody's gonna do a similar NSF collection anytime soon.

Hmmm, this is a different approach. I take it this has a central database server that people submit timing information to, and then it makes use of the original untouched SID rips that people already have, obtained from elsewhere?

It looks like everyone has their own idea of how NSF timing and tagging should be done. Apparently this discussion needs to be taken to another site of more general interest, so users, NSF player authors, and taggers can all discuss different approaches, and the benefits and drawbacks of each.

by NewRisingSun on 2006-02-15 (#9616)

blargg wrote:
Are you proposing to have all time fields in milliseconds (or even 1/60 seconds), or in both mm:ss and milliseconds, or perhaps mm:ss.msec? Only the latter seems practical, but I don't think the M3U file allows for that accuracy.
In the text file, just add the milliseconds, so instead of 01:33, you write 01:33.667. The milliseconds will be truncated for the M3U file, but since the .NSFe file is created from the .txt file and not the .m3u file (if I understand the process correctly), this doesn't matter.

It is possible to play tracks that normally loop directly one after another without fading IF the song lengths are set precisely, then it will not sound stupid. DeliPlayer does this well for many Amiga sound sets, and I think it sounds quite nice.
Also, it's good to have the actual exact song length for sheer properness, just as it is proper to emulate the NES' waveform at 42 MHz, even though directly creating the filtered signal at 14 MHz produces the same result, as far as I have observed.

You are correct that most people won't open a sound editor to get that accuracy, but with timensf, it should be possible. Then again, most people wouldn't spend the time to rip an .NSF either, and yet some do

blargg wrote:
NSFE files aren't that numerous, but I think this is due to 1) NSFE being a much more recent file format than NSF, and 2) the only NSFE tagging tool (that I know of) requiring that one run Windows and use Winamp. One of my goals with these tools was to allow anyone to make NSFE files.
Another reason is that there's just one site (to my knowledge) that offers NSFe files. If you can get Zophar's and PlanetEmu to host NSFe files, describing them as the preferred format, I'm sure the demand would increase as well.

by juef on 2010-08-02 (#65348)

Sorry for the necrobump, but since p1xl released FlashNSF, I would be very much interested in this tool, but it is unfortunately not online anymore. blargg, would you happen to still have it?

Thank you!