Vgmlpfnd

With VGM loop finder you can find loops in VGM files. This sounds easier than it is; songs often replay parts of the track as part of the track, so there's actually multiple loops in there. Vgmlpfnd tries to find them all so you can choose which one is correct and then use vgm_trim to trim at the right place. The results are great in my experience; when using the wrong loop point the transition is also very smooth most of the time - though then your track will not match the original one, obviously.

The first argument (besides the filename) is the step size. Leave it at 1; that's the most accurate scanning, just reading all vgm commands. Except, if you have low memory, you can adjust it to speed up process.

Next is the minimum number of matching commands. I usually use 4096 or something like that. It simply means vgmlpfnd will only detect a loop when a list of 4096 vgm commands are detected with the exact same values in the same order. Using lower values might get you more false-positives but, if the tracks loops quicker, can be required.

Next is the start value; just use the default 0 (if you're sure the vgmfile contains 1 track).

If you're lucky, you'll have a single result that's probably the right one. Here's an example:

 Source Block		  Block Copy		Copy Information
 Start	  Time		Start	  Time		Cmds	Time
 477258	00:10.82	2374215	00:53.84	26535	00:34.59
 Done.   

The values you need are Start from the Source Block and Start from the Block Copy. The first value means "where the loop starts" and the second one "where the copy starts", so actually where the original loop ended. You can then use vgm_trim with the inputs 0, 477258 and 2374215 in this case.

vgmlpfnd may report f, ! and e in the results. F means a proper loop has been found, which could be more probable to be the right one than others without an f or !. If a ! is displayed, it means it's almost sure the the correct loop has been found. When you don't get an f or a !, don't worry about it; just check the actual loop time of the track and compare that with the results. Or use values that are apart from each other by a lot.

Note: Now and then, values of a ! line may cause playback hiccups; be sure to double-check just in case.

E means that a loop seems to be found which ends at the end of the file. If you don't have a proper loop and you get an e, you might consider recording a new vgm file which goes on a little longer (possibly even three or four+ loops).

Higher numbers in the Copy Information column may indicate the loop is more likely to really be a loop. Consider the following examples from Puyo Puyo (Genesis)'s Brave of Puyopuyo:

468902  00:10.63        2171155 00:49.23        4970    00:02.77
468902  00:10.63        3873400 01:27.83        4676    00:02.62
468902  00:10.63        5575647 02:06.43        4406    00:02.47

Configuration from Dr. Robotnik's Mean Bean Machine (and yes, the middle line is the correct one!):

1743634 00:39.54        4948219 01:52.20        1617    00:02.16
2186277 00:49.58        5390863 02:02.24        11042   00:16.35
3254474 01:13.80        6459059 02:26.46        5704    00:08.28

Mickey Mania's Whirlwind (recorded at 50hz):

328845  00:07.46  !     1735571 00:39.36        21413   01:47.06
329198  00:07.46        610311  00:13.84        1230    00:06.37
329198  00:07.46        2017038 00:45.74        1230    00:06.37
329198  00:07.46        3423765 01:17.64        1230    00:06.37
329198  00:07.46        4830492 01:49.53        1230    00:06.37

Joe & Mac (Mega Drive)'s first level theme (50hz)

207634  00:04.71  !     2233221 00:50.64        41549   00:59.43
207768  00:04.71  f     376476  00:08.54        2568    00:03.83
207768  00:04.71        2402162 00:54.47        2568    00:03.83
207768  00:04.71        4427850 01:40.40        2568    00:03.83

Chuck Rock II: Son of Chuck (Mega Drive)'s The Apple Tree (50hz):

78146   00:01.77        415760  00:09.43        1230    00:05.26
78146   00:01.77  !     753375  00:17.08        20110   01:22.30
78146   00:01.77        1090989 00:24.74        1230    00:05.26
78146   00:01.77        1766218 00:40.05        1230    00:05.26
78146   00:01.77        2441447 00:55.36        1230    00:05.26
78146   00:01.77        3116676 01:10.67        1230    00:05.26
78146   00:01.77        3791905 01:25.98        1230    00:05.26

and its The Fruit Mountain (ditto):

403461  00:09.15  !     2429261 00:55.09        64764   02:03.27
859756  00:19.50        1197372 00:27.15        1424    00:02.52
859756  00:19.50        3223059 01:13.09        1424    00:02.52
859756  00:19.50        5248747 01:59.02        1424    00:02.52
859756  00:19.50        7274434 02:44.95        1424    00:02.52

Meanwhile, an example of a wrong ! line from Mean Bean's Continue:

339390  00:07.70  !     619010  00:14.04        12848   00:20.27

Why it hooks to this, I don't know, but the loop is far too short. Using smaller values didn't seem to work in this case.

"Does vgmlpfnd work with...?"

Because vgmlpfnd relies on matching commands, small variances during loops can interfere with automatic loop detection. This means that how well it works with a VGM owes only to the track itself - not the sound chip(s), nor even the game. (Consider EarthWorm Jim 2: this tool could find the loop for The Moo Tango (with a long-enough recording), but not so much other tracks.)

As a result, vgmlpfnd's success or failure throughout a soundtrack can't tell us any useful information, or even trivia, about chips, games, composers, or anything else. While it may feel exciting to discover a seeming pattern (like Krisalis games working far better at 50hz recordings than 60), it's unfortunately impossible to glean further patterns, tricks, or facts from it.

The good news, though, is with no meaning to be found you needn't worry about the "Rorshach inkblot" at all.