How to Insert Looped .WAV Samples

I'd put this in my Sample Tool tutorial thread but I've only gotten it to work in AddmusicM.

Here's a step by step process. You'll need your ROM, AddmusicM, your .WAV file, and a program called OpenMPT (optional, but it will make looping your samples infinitely easier. Just note that it can occasionally have troubles running under Wine in Linux, but it can work.)

1. Find the .WAV that you want to insert (this should be obvious...)
2. Open OpenMPT, go to File -> New -> then select any of the options; file type doesn't really matter here. I'll use IT for the sake of it.
3. Click the Samples tab.
4. Click the open button in the top left of the interface and select your .WAV file.
5. Under Loop you should see two text boxes. The first one is labeled Start and the other End, the signify where the looped portion of the sample should start and end respectively.
6. Play around with those values and press the play button to listen to your sound (it looks like two beamed eighth notes and is horizontal to the open button.) Note that BOTH values MUST be divisible by 16 or the process will not work right when it comes time to insert your sample!
7. Once you've found the perfect loop values, click on the zoom drop-down control (By default it says Auto) and select 1:1. This will zoom in to the maximum amount, ensuring absolute precision, which you'll need.
8. When you hover your mouse over your sample data (the big red squiggly line) you should see something at the bottom of the window that says "Cursor:" then a number. This number changes depending on where in the wave your cursor is.
9. Move your cursor until the displayed number is exactly equal to what you set as the ending loop point in the text box above.
10. Now click and drag from that point to the very end of the wav, making sure to select everything from that point on, and delete it by pressing the delete key.
11. Now save your modified .WAV in the same folder as Sample Tool. Just do it, trust me. You'll see why in a second.
12. Sample Tool comes automatically packaged with a tool called SNESBRR. You're going to use this program, and since it is command prompt only, copy cmd.exe to that folder.
13. In that command prompt, type in "snesbrr.exe -e -l LLLL IIII.wav OOOO.brr" where LLLL is the value in the Start text box of OpenMPT, IIII is the .WAV file, and OOOO is your output file. Remember that none of your file names can have spaces!
14. Grab a calculator. Multiply the starting loop point by 9/16 (or 0.5625). Now convert that to hex (if the result was a decimal you've done something wrong.).
15. Open up your new .brr file in a hex editor and insert (do NOT overwrite anything!!) the number you just calculated in reverse byte order to the beginning of the file. For example, if you got C85 then you would insert 85 0C.
16. Save and you're done! Insert your sample using AddmusicM and enjoy your looped samples!

This was a rushed job since I was excited that I finally figured out how to pull this off, if anybody notices something wrong or thinks I didn't explain anything well enough I'll update it.

Er...what? If AddmusicM only used looped samples then we'd get looping drums, pianos, and all sorts of other things and our songs would sound like garbage.

But if you save an .SPC using this method you should be able to rip the resulting looped sample in Sample Tool to use with $E5, if that's what you're asking.

You sort of do...you insert the loop point at the beginning of the sample, but there's data in the actual .brr file that tells whether or not that number is used for looping. The number must match up with the .brr data or the file will not loop correctly.

By default non-looped samples are assumed to have a loop point of 0, and since there's nothing else in the .brr file that tells it to loop, it won't.

It's an SPC limitation. And quite possibly the most annoying possible limitation it has. Essentially, it takes the loop value that you specify, and multiplies it by 16. This allows for very long samples, but very imprecise looping values.

Also, as far as I know, the sample rate doesn't matter; I think Snesbrr automatically converts it for you. I don't know for sure, though (lower sample rates will use less space, though.).

Yes, both matter, unfortunately. Essentially, the sound is compressed, so it takes every 16 bytes of data and shrinks it to 9. If the length wasn't a multiple of 16, then the last byte couldn't be properly compressed.

In OpenMPT, go to the sample editor, highlight the part of the sample you don't want, then hit the delete key. As to the size of the .WAV getting bigger, that shouldn't matter. snesbrr.exe should convert it down to the correct size once it saves the .BRR.

Nope, but doing the opposite isn't much harder. As for it not playing...I'm not sure what's wrong. I assume you mean that it's not playing in the program, which I've never encountered. I'm afraid I can't help you there, sorry.