Mao's vgmlpfnd Method
This tutorial was written by Mao (RN22), with editing for formatting and grammar/clarity by (Jazz) Jackalope.
When I do some looping in one of the .vgm files that I'm working on, and it's complicated to find the exact loop with vgmlpfnd: I use Audacity as a helping hand, to mark the start and the end loop points of the .vgm file. Using .wavs doesn't mean that you dont have to use vgmlpfnd for this.
If it gives you numbers for your VGM, then most likely vgmlpfnd is the best tool to find exact loop points you can use, even complicated ones. It's all about trial and error to find the good ones in all the commands.
First, you might wanna convert the vgm file into wav, using any of the audio software tool you have. I, for instance, use VGMPlay to convert vgm files into wav. Then, in some audio software like audacity, import the wav file you've just converted.
After you've managed to import the wav file, go ahead and drag the vgm file on vgmlpfnd and hit Enter/Return until it asks for the smallest minimum commands that is possible to find the exact loop for your .vgm file.
Then, go back to audacity, to start marking the start and the end sample that you might wanna loop with. You can find them by listening carefully, or by the Manual looping tutorial method. For example, I marked my start sample as 01:03.05; then, for my end sample I marked 03:15.29.
Back to vgmlpfnd, go ahead and type the minimum commands that i've mentioned earlier, which is 128. (Better not to go below this number, or it'll pick up commands that don't affect the loop.)
I know some of you are thinking, "What are these? There's a bunch of command samples going on. How am I supposed to find the exact loop?" You're not alone, my friend. Your task when finding the loop of your .vgm file is to find the CLOSEST sample possible. So if the starting point of 01:03.05 is closest to 1:03.06, go ahead and use that. The same goes for the end point, which shows up in Block Copy on the same line.
There, you've find the exact loop that you're looking for. But it doesn't mean you're done. Go ahead and listen to the .vgm file you've just trimmed and looped on. If something goes wrong, I apologize, but you have to do it again.
If you're looping vgms with a strange sound driver that doesn't find the right loop ("!") in vgmlpnd, it can get tricky. You can have a number in "Source Block" that's close to your marking point, but then for that same Source there can be many samples in "Block Copy, and it's hard to tell which is closest. If you have to try other points, it can get overwhelming.
Here's my tip. If you're using "CMD" in Windows, you can press the "Pause" or "Pause/Break" button located on your keyboard to make vgmlpfind pause. Then you can slowly scroll through the lines, keeping your eye on the Block Copy column, to find the end point that's closest to your mark.
But (in Win 11), if you're too lazy to scroll, you can just ctrl+shift+f - and then your cmd is updated to a terminal. Now you can type your end point of 03:15.29 in this example into the Find tab. If you get no results, cut it to 03:15 to find samples close by.
And, of course, you have to check to to be sure the Source Block still matches the one you're using, or is close. If it doesn't, you might have to scroll looking for other close-by Source samples, and use the Block Copy as your guide to find the start and end of the loop.
Now, in Win 7, you can get the same effect with a little more work. In the cmd window, you can right click -> Select All -> press Enter/Return. Now you can paste everything in a new Notepad window, and use Ctrl+F there.
If you need to get more lines out of vgmlpfnd, just press Ctrl+F to continue in the cmd window.
If you're using another operating system, things may be different, but the basics are similar. And if you know how to use .bat files or something like them, you could make one that runs vgmlpfnd on all tracks in a folder and puts the result of each into a text file.
Now I, (Jazz) Jackalope, am here to give another example. My example should be helpful because it shows a way to proceed if your first tries fail, without having to go back to Audacity for new numbers.
There were two awful songs (looping-wise) I faced from Aladdin (MD/G)'s beta. One I solved by Valley's advice pertaining to vgm2txt, about looking for all channels going off one after another. For Rug Ride, I used the Manual looping tutorial to find initial points. This gave me 1:14.704/3294426 as loop, and 3:27.424/9147414 at the end.
Now I ran vgmlpfnd with 110 for the Minimum Commands. This gave me a promising line:
3294498 01:14.71 9147486 03:27.43 371 00:00.71
Unfortunately, not so much did it work when trimmed. I had to go forward in the list, mentally adding the same number to both sides to compare down the list.
To narrow down what pairs I should try next, I used a trick I learned: Larger Cmds numbers in the Block Information column make it more likely the loop is a good one. so my next stop was this line:
3360731 01:16.21 9213721 03:28.93 912 00:02.23
Notice the big number of 912. Unfortunately! This line also had clipped notes. I had to continue yet further...
3899802 01:28.43 9752789 03:41.15 741 00:02.82
This line actually did work! No issues, as far as I could hear. And it was a lot more convenient than trying to dig through text files.
If you compare the numbers of my marked loop and the working line, you will find something interesting. The seconds on both sides each increased by 14. The milliseconds, after the ., are trickier. 704 to 43 is a difference of 730 milliseconds. So technically, this side increased by 13.730. Comparing 424 to 15, you find the same: about 730 milliseconds.
As you can see, the math is not really the same for the actual sample numbers; one is off by one sample. That's why comparing based on time (HH:MM:SS + milliseconds) is the best way to find compatible lines using this method. Of course, once you found the right lines, it's the sample numbers that you'll be using with vgm_trim.