R(er)ipping for the Out-of-Element Contributor
Any new or even veteran contributor should find at least some helpful info within, but the aim of this tutorial is walking one through the process of redoing a pre-BlastEm Sega Genesis/Mega Drive pack formerly from Project 2612. You will encounter according bias.
This article was written by (Jazz) Jackalope.
- 1 Before You Start
- 2 R(er)ipping packs
- 3 Posting packs on the VGMRips forums
- 4 Way Past Cool Tips 'n' Trickz
- 5 ?
- 6 Article license
Before You Start
First make sure you have the proper tools. This means to use the most accurate emulator for your target system/chips. For Sega Master System games, that's Meka. For the Genesis, that would be the most current nightly build of BlastEm (at the time of this writing, that's the one released on April 8). On this Wiki, the page Category:Emulators with VGM logging now has a table that lists the emulators allowed for VGMRips rips.
If you already know you have the staying power to at least fully re-log a game (a reason I recommend only doing games where you don't ever get tired of hearing most of the music), then the next thing you should do is make sure relogging the game is necessary. For each game you wish to do, check the following places in order:
- This site, including the Offical Pack WIP topic] to see if anyone's already mentioned plans to rerip that game
- The according joshw.info for your target system (https://smd.joshw.info for Genesis)
- The relevant other site(s) for your target system, if any (includes a handier list of JoshW links).
Many Genesis packs have "updates" that only consist of changing the text file to meet VGMRips standards, so don't go off the current update date. You have to build your rerip off the existing set anyway, so this is a good time to grab it. Check the text file of the pack to confirm what the true last update was.
To check the Pack WIP topic (and make submissions), you'll need an account on the VGMRips forums. Try making one, if you don't have one already. There's been much trouble with the sending of activation emails, which may require an admin to activate your account when possible. ValleyBell has explained the trouble:
Apparently some mail services (especially gmail) still doesn't like our activation mails.
I pruned the registered-inactive users from the last two months. So if you tried to register, just try again and maybe contact me on IRC. (I'm usually online, except during the European night hours between 0:00 AM and 8:00 AM CEST.)
If the timing is wrong, you can still try anyway; just be patient and wait for a response, or try again after a few days if your attempt was overlooked.
When you can log in, and you've confirmed a need to rerip your desired game(s), go back to the Official Pack WIP topic. As you've gathered, there contributors note the sets they plan to make or are currently making, to avoid duplication of effort. Being a contributor, you should do the same and make a post naming all your intentions - not only rerips, but any new VGM rips you plan to make.
There is no standard way to sort and classify your in-progress work. Look to other posts in the thread for examples, then list your sets however feels natural to you and your workflow. Just make sure it's clear how much progress you've made, and have yet to make, on your sets. When the status of one of your sets has changed - if you've made progress, for instance, or have decided to discontinue work - remember to go back to your original post and make changes accordingly.
It is not necessary, and in fact discouraged, to make multiple posts in the WIP thread. Anyone who wants to know the current status of your projects knows where to look.
The process of reripping is more or less the same as for, well, a fresh new rip. In general, follow the most up-to-date ripping instructions for your target system. For Genesis rippers, this means the Project2612 ripping tutorial (RIP Project 2612). (While modernizing that, I've moved a lot of Genesis/MD-specific not-rerip-specific info there from here.)
Grab yourself the most recent set of ValleyBell's VGM tools. I'll tell you how to use VGMToolbox to easily import existing tags from an old pack shortly.
When you proceed to tags and the text file, keep in mind the relevant post in the Submission Topic Rules. (The topic is rather dated, as all posts came from before VGMRips included Genesis packs; hence BlastEm, now requisite for Genesis rips, isn't in the list of allowed emulators mentioned in the last post.)
Since you will need to record your updates to the pack, it's a good idea to note them down as you go, rather than try to remember them all.
At the end of ripping, you will have trimmed, tagged, and possibly optimized VGMs or VGZs, with rather excessive filenames. To easily remove all that gunk, put all your finally-finished files in one folder, then run vgm_name in that folder; it will take care of all the suffix removing for you. Or, if your system can run it, the Batch Renaming features of IrfanView work perfectly well for non-image files and can remove or substitute text as you instruct it. For instance, when you've manually sorted the pack's VGMs in the Batch "conversion" window, the following pattern will renumber them accordingly while keeping the file names intact:
At any point after all files are tagged, you could also use one of the newer VGM Tools, vgm_ren, to respawn your desired filenames in the right format with the right numbering. This is extremely convenient; it only requires a playlist with the files listed in game/soundtrack order. But if your English titles have characters not allowed in a filename, you'll need to fix up those filenames both for the VGMs and in the playlist.
In most cases, that shouldn't be a problem. But for a beginner, vgm_name is easy and friendly enough.
Not as easy as it seems. At the least, you should check your game's entry on The Cutting Room Floor to see if any unused songs or hidden sound tests/level selects have been discovered for it. (The level select will be helpful if you can't rip from a sound test.) Then, even if you have access to those, beware songs in the game that can't be accessed from the sound test and must be logged where they appear in-game.
There are certain Genesis games that, for full accuracy, should be (re)ripped at 50hz (PAL/Europe settings). These games are being researched/documented on the 50Hz Mega Drive Games page, a work-in-progress. (If you have solid information or fixes for this list, it'll be most appreciated!)
There may be songs you're unable to access under your own steam, if you're not able to hack the game yourself (and can't use something like UNIBIOS or gems2rom). Don't be afraid to ask for help. If you're acting in good faith and trying to apply what you learn, the community members are very patient even if you're the most blithering dope on the face of the planet.
As you relog, you should make notes of any tracks that start with beginning silence. You might even make a brief recording of this silence, by starting playback immediately after starting the log, instead of after the second-long safety buffer. This is also the one case where it's helpful to have another song already playing when you start logging, rather than being something you should avoid.
Speaking of that, if you don't have the option to stop a song's playback, just play a jingle or other song that ends, and wait for it to conclude. It's not quite identical, but better than nothing.
If relogging from a sound test, I also recommend taking screenshots of each song's entry and renaming them to keep a reference of the tracks' numbers/names. Should any of the songs ever need relogging, the next reripper (who could be you yourself) won't need to dig around in the sound test to find each of them.
You can also use those screenshots to conveniently verify existing tags. (Verify level names too, if necessary. Don't go off memory, especially if you have a level select.)
Alternatively: Depending on your emulator, you may be able to rename the log (or name it before recording starts) with the Sound Test number/name and track title/location. If you can and do (re)name the logs as you go, and plan to note down the ST numbers/names in the VGM Comments, screenshots (and renaming those) may not be necessary.
(In #Way Past Cool Tips 'n' Trickz, I tell how to get those numbers into the Comments without having to hand-add them one by one. If there's multiple numbers, though (like for World of Illusion), it can get tricky. Beginners will probably just want to get accustomed to the basic tools first.)
You should be able to use fast-forward features of the emulator to skip to two loops without mangling the log. But I recommend doing so only if you've already spent large amounts of time becoming familiar with the game's music. Even then, I don't recommend it except for individual songs you really cannot stand.
Why not fast forward to make recording faster? Some songs are vastly longer than one would think. Take the example of Green Grove Zone, Act 2 from Sonic 3D Blast. Two contributors logged and trimmed the song previously (the latter adding ~one minute to the length), and both were dead wrong. With correct trimming, the full song is in fact eight minutes long due to a playback bug; neither ripper noticed.
Given cases like that, even if you're familiar with the song, I recommend listening carefully to it again as you record, and skewing towards longer logs against shorter ones. It takes time and care to discover subtle true loops that come >five minutes into a detailed song and make you go "Are you kidding me that's how long this is." This may mean you have to listen alertly to a song you really rather can't stand for many, many minutes while trimming. The logging phase is where you should find out if you actually want to try to trim the (entire) pack yourself.
If you plan to rip the beta version of a game as well, this also helps you find differences between its and the final's songs, since both versions will be fresh in your head.
Once you're done with your initial logs, I recommend compressing all of them into one Ultra-compressed 7z archive, then backing up this archive in more than one place. You'll be grateful later on to have copies of your original logs, and the 7z compression makes them take up a much less irritating amount of space.
If your VGM begins with a tiny one-sample wait
When trying to find start points for a Genesis/Mega Drive game meant to run at 50hz, I sometimes encounter something like the following:
0x000002B0: 70 Wait: 1 sample(s) ( 0.02 ms) (total 1 (00:00.00)) 0x000002B1: 50 9F SN76496: Latch/Data: Volume Ch 0 -> 0xF = 0% 0x000002B3: 50 80 SN76496: Latch/Data: Tone Ch 0 -> 0x000 0x000002B5: 50 00 SN76496: Data: 00 0x000002B7: 50 BF SN76496: Latch/Data: Volume Ch 1 -> 0xF = 0% 0x000002B9: 50 A0 SN76496: Latch/Data: Tone Ch 1 -> 0x000 0x000002BB: 50 00 SN76496: Data: 00 0x000002BD: 50 DF SN76496: Latch/Data: Volume Ch 2 -> 0xF = 0% 0x000002BF: 50 C0 SN76496: Latch/Data: Tone Ch 2 -> 0x000 0x000002C1: 50 00 SN76496: Data: 00 0x000002C3: 50 FF SN76496: Latch/Data: Volume Ch 3 -> 0xF = 0% 0x000002C4: 50 E0 SN76496: Noise Type: 0 - Periodic, High (6927Hz) 0x000002C6: 61 00 A5 Wait: 42240 samples ( 957.82 ms) (total 42240 (00:00.96))
That one-sample Wait is something I suspect could cause the commands coming after it to be dropped by vgmlpfnd. I could be wrong, but just in case, a rerecording of the offending VGM can get rid of it after 1 or more retries. (Use vgm_tt, VGM Toolbox or VGM Tool to transfer any tags you have to before deleting the suspect log.)
On the other hand, if unlike the above example there are tons of commands and varying small Waits even in the silence safety buffer, the engine is just constantly sending commands and you'll have to find a starting sample that just doesn't cut off any important ones. (Discovering which commands are important is a skill.)
First, acquire the most recent-version pack from the VGMRips site/forums. (You've probably already done so if you've been following from the beginning.) Extract all of these files where you please.
There are several programs you can use to tag VGMs:
- VGMToolbox: Probably the easiest to use for beginners, but rarely it can eat VGMs. (By the way, if using it to gzip VGMs, don't forget you'll need to rename them to use the VGZ extension yourself.)
- Valley Bell's vgm_tag: A command line tagger, also useful for batch tagging and changing/removing a single field in a VGM tag. By looking at Vampi's Project2612 algorithm, you'll find a .bat file to help you use it conveniently.
- VGMTool: This dated tool is never to be used for trimming files, but it still works fine as a tagger. It will be most convenient for modifying tags for a single VGM at a time.
vgm_tt is one of the VGM Tools: it can transfer tags from an old set to a new one, so all that remains is to update the tags with the new Ripper and any other needed changes. However, it doesn't seem to match VGMs based on relative loop points, so for a full-on rerip only matching by name is useful. Said names must match exactly, including the file extensions; if you've needed to change track names or ordering, you'll have to do the same in the old set before vgm_tt will match them. While IrfanView or another batch renamer makes renumbering less tedious, I think it's too much of a pain to use vgm_tt over other methods in these cases. (Unless you use vgm_ren?)
Alternatively, it's fully possible to make a .bat of vgm_tt lines like these examples:
vgm_tt -tag "01 - Old Vgm.vgm" "01 New Vgm.vgm" vgm_tt -tag "C:\old\vgm\path\02 - Fu.vgm" "C:\new\vgm\path\02 Dog.vgm"
which, when run, will work on each pair of files (which can be in the same folder) rather than folders. Nothing needs renaming this way, but in exchange you have to get the old vgms and new ones paired correctly in every single line.
(Now a whizzo-bango text editor offering drag-and-drop of lines, rectangular selection (to paste in the drag-n-dropped filenames) and some way to collapse excessive spaces can help here - but, it's beyond the scope of this document to explain to those not already accustomed to such features. So for larger sets and foolproof caveman copy+paste, the jury's out on whether creating such a .bat is less tedious than other methods.)
If you do take advantage of vgm_tt, there's still work to be done: you'll still have to replace the old Ripper, change the date to use hyphens instead of slashes (if needed), and make any other changes that are needed. Again, this can be done en masse with vgm_tag or VGM Toolbox.
Load your relogs/dumps and the previous rip's tracks in the program as described in vgm-guide: in sum, you want Misc Tools -> VGM Tools -> VGM Tag Editor, wherein you can drag and drop VGMs on the big blank space below "Source Files".
(Be careful to make sure you can easily tell your logs from the old ones. I prefer to drop in one set and then the other, even if it requires more scrolling later on.)
Before you start tagging, look at all of the existing tags to see if there's anything you should keep in mind as you import. For instance:
- Has the previous dumper/tagger left any Comments? In my opinion, you should preserve the existing comments unless they're truly no longer applicable (such as complaints about the difficulty of trimming, which may go differently now).
- If the game has multiple music artists involved, have tracks already been tagged with credit for each individual composer? You don't want to accidentally lose this effort. (Although you can just extract the old pack again if it comes to that.)
- If multiple people contributed logs to a pack, you'll see more than one name turn up in the Ripper field as you go. If so, copy each name you see and paste it somewhere convenient.
Having finished the previous step, you know which parts of the tags are the same across all the pack's songs. It's time to import.
- Select one of the old pack's songs. Then use Ctrl/Shift+Click (or equivalent) as needed to select all your untagged songs. Now unselect the one from old rip; the tag information from it should remain filled out. (If it doesn't, reselect only that song and try again.)
- Uncheck all of the tag entries that you saw change in contents among different VGMs. Typically, this will be the Artists, the Comments, both, or nothing.
- Whether or not the Ripper changed, of course, you should leave that checked. We're about to change it.
- If the game is a port of an Arcade game, you can, and should, also add in the appropriate Artists for tracks coming from the Arcade version. (These are often different from the Artist(s) given credit for the conversion.)
- If the numbers of the Date are separated by slashes, change them to hyphens. If you need to update the date anyway, be sure to use hyphens.
- If the game being (re)ripped is a Sega Mega Drive / Genesis game, it should say exactly that for the English System - unless the game was only released in a single region. If it wasn't and yet it doesn't, fix it to use both names.
- Cut the existing name out of the Ripper field (and push it somewhere else). Enter your preferred handle on VGMRips there. (If you're a returning contributor from years ago, even if your handles have changed I recommend using your previous one for consistency on this site.)
- If you don't need to preserve any existing Comments, and if there's anything you plan to add to all comments, like scaffolding for adding Sound Test numbers/names, put that in now as well.
- Previously, I suggested to make a note of the original tagger in the Comments. Usually, though, this information applies to all the songs in a pack; in that case, it's preferred to note them in the pack's text file (which is likely already done, thanks to the update history). The Comments are meant for track-specific information, so you only really need to make such a note for any tracks tagged by someone who only touched a aubset of tracks.
- Now press Update Tags.
With this, a great deal of tedious hand-copying work has been gutted from the process. But some yet remains.
You must now transfer Titles at the very least (unless you already know you'll need to change all of them). First select a VGM from the old rip, and then the same track from your new rip. I uncheck all the fields that have already been completed during the previous step, but for those fields that match exactly between the old and new log, that is probably not necessary. (Just be careful not to destroy your changes so far. If you're not confident, make another 7z backup.) Either way, re-check the Title fields which became unchecked when you selected more than one VGM.
If you need to add things to the VGM's individual Comments, like sound test numbers, add them now. Once the new entries are ready, Update Tags, then select your VGM alone to make sure the new tag is complete and correct.
(You will notice that the old VGM log also has its tag modified. There's no way to avoid that happening short of copy and pasting all relevant information - but since it's a file from the old log you're replacing, it doesn't make any difference.)
Repeat this process for each track. If there's only one piece of info you need to bring over from the old tag - that is, just English titles from a game not released in Japan - it's both fine and faster just to copy and paste that one entry in each case. Because you're changing only one field, if you're comfortable with command line use, you might find it more convenient to use ValleyBell's vgm_tag at this point. An example:
vgm_tag -Title:"Granny Bag" your_vgm_here.vgm vgm_tag -Title:Subterranean a_different_vgm_here.vgm
vgm_tag opens opportunities for dynamic field generation, which means you can can make a .bat file that Titles them based on the filename. I explain the general method in Tips 'n' Trickz below, but again you may want to get accustomed to hand-tagging first.
Before you consider the tagging done, double-check your work again and make sure you've added any updates that need adding (such as credits-by-track, Japanese names, composer corrections, and so forth). I particularly recommend checking all sources you know of (including those in Databases) to confirm the game's true release date, or that a discrepancy in reporting exists. (Note that GamesDB isn't necessarily reliable, while Sega Retro is a better bet due to providing sources, many of which you can verify on the spot.) If you need help, ask.
I recommend also making a 7z of your tagged files. If you've confirmed all these files still work, and tagged before trimming, this new backup can safely replace the one from the logging step and any you may have made during this step.
The most crucial piece of advice I can give you, when using vgmlpfnd, is this: The "!" "perfect loop lines" are not always 100% reliable. The indicated loop may be too short ("A A A B A A A B" may detect only "A" instead of "A A A B") or it may contain more than one loop ("A B A B A B" may result in a loop of "A B A B" instead of just "A B"). Don't consider looping finished until you've checked that the loop really matches the song's loop.
The second most crucial piece of advice is, try using a lower Minimum Number of matching Commands if you don't get anything useful on the first try. I try 300 and then 100 as needed.
If you thought you'd be clever and use loop samples from different lines that seem right (Yo), I must sadly burst your bubble. Within the same millisecond, many commands can occur. This crude method can't tell or even hint to you when the surrounding commands actually match up. You may still need to drill into a text file created by vgm2txt (see the page for a small tutorial!) and/or examine the waveform to confirm when the commands actually match.
(Even so, you can still use VGMPlay to help you find the locations of the correct samples. But when seeking to the loop points, beware that sometimes funkotronic things can happen to the notes, such as being cut off.)
Trimming off the extra at the beginning of a song may cause hiccups like a volume reduction or broken instruments if you cut it too close. Double-check your beginning trims against the untrimmed VGM to be sure.
Also, while you should generally trim the silence up until a song starts, some songs begin with intentional silence, which you should keep in the trimmed log. Compare to in-game audio to make sure you've trimmed such a song correctly.
If all else fails and you find you can no longer trust your ears, it's perfectly acceptable to ask for help or even outright delegate the work of trimming to someone else. That said, it's well worth getting accustomed to the trimming process and doing as much as possible yourself.
First, make sure you actually have to optimize your files. For instance, while Genesis/MD tracks should be optimized, Master System/Game Gear songs should not. vgm_trim is counted as an optimization, but must always be performed, and performed before any others.
To clarify, the proper chain of optimization (for Genesis packs, that is) is vgm_trim (which you have probably already used on all files at this point), optvgm, and then vgm_cmp. Vampi's Project2612 algorithm contains a .bat file "opt.bat", which uses optvgm and vgm_cmp in the correct order.
Conversion to VGZs is done automatically as packs are processed. Having completed all other optimizations, you can ignore the gzipping part and send in un-GZ-compressed VGMs.
A lot of the screenshots for existing Genesis sets are poor quality; if reripping such a game, you probably should make a new one in BlastEm. Be sure to check that other regions/variations of the game (if any) don't look different; if they do, take screencaps of all of their title screens too.
For each screencap, trim the scanlines (extra space) automatically (if auto trimming won't remove space that is legitimately part of the image) or by hand. (IrfanView's batch converter is useful for this, even if it feels like overkill for one file.)
As stated by ValleyBell, "In general, we want screenshots in at 1x scale with no blurring. In some cases, aspect ratio corrections are allowed (e.g. for PC-98 images with 640x200, resizing to 640x400 is fine), but for MSX rips you shouldn't need to make use of that."
(If you don't know what that "aspect ratio" part means, it's the width-times-height ratio of the screenshot. You can try to find out the proper ratio for your target system, or try submitting your pack/update and see if it passes muster or is rejected.)
Next, although the screencaps are extremely small, it is worth compressing them. For this step, I suggest FileOptimizer, ImageOptim, or Trimage (or an equivalent). I've only tried the first of these programs, but the others use the same principle. Tom's post in the submission guidelines mentions PNGout, but this program is also included in FileOptimizer, and probably the other two. With these tools, you can sometimes shave entire megabytes off of larger PNG files, and you pretty much have to do nothing to get more compression than PNGout alone.
The "Best" compression level of FileOptimizer is not something that should be used with files much larger than emulator screencaps (say, a 1mb file or larger). Diminishing returns set in in terms of time and processing power versus bytes saved. For such files, the Normal compression is more than sufficient.
For pack screencaps, though, go ahead and use the Best compression level; it shouldn't take much more than a minute, if that, to ensmallen each screencap.
Updating the text file
(Most of this section is just me repeating information from Valley Bell and others.)
For the updated text file, just generate new song timings with vgm_stat and update the original text file with that. [To get vgm_stat to produce playlist numbers, which are necessary, you must give it an .m3u playlist file - which you'll need anyway for the final pack. You'll need to create a new one (and rename it) if you've changed any track filenames, rearranged tracks, or added new ones. A quick way to make the playlist correctly, without also having to go in and remove extraneous lines, is to use this command from the prompt or in a .bat file:]
dir *.vg* /b /on > "playlist.m3u"
Make a note in the "Package history" section in the bottom stating you relogged the files [among any other changes, including to track names]. Add your name to the "Package created by" field. Keep the notes intact unless you want to add some information. [I would suggest noting anything special that needs doing to get at the songs, if you can do so briefly.]
Remove the Complete Music Dump line, if it exists. For Gen/MD games, change the system to "Sega Mega Drive / Genesis" for consistency, unless the game was only released in a single region or you needed to record at 50hz. In that case, use only the appropriate name (Mega Drive for E or J exclusive games or games ripped at 50hz; Genesis for U exclusives).
(Of course, if you're working with a different console, you should use the appropriate system name instead.)
If you imported Composers from an Arcade version, note that you did so and credit the tagger of that pack.
If you change the track order in an existing pack, that's something you should note in the "Pack history" section in the txt.
Posting packs on the VGMRips forums
The Submissions forum as a whole is for posting new fully-completed rips. Only completed pack updates, and fully-contained incremental updates (such as adding one song that has been trimmed, tagged, and, if applicable, optimized), go in the Pack Update Topic thread in that forum. If you are reripping a game but have not finished, or intend only to do some of the work of finishing the pack, post your progress as a new thread in the Ideas and WIP forum.
Is that clear as mud? Let's break it down:
- A fully-complete pack for a game that hasn't been ripped yet
- New topic in Submissions forum.
- A fully complete update of an existing pack
- New post in Pack Update topic, following both Submission Topic rules and Update Submission rules.
- Any pack in an in-progress state
- New topic in Ideas and WIP forum, following the Submission Topic rules. You don't need to follow the Update Submission rules for a WIP full rerip, until it becomes a completed pack update.
Wherever you're posting. detail what parts of the rip you've completed/changed, and (for WIPs) what work remains to be done. If you've changed tags in the process of tagging, mention how and why. If you plan only to do certain parts of the work, mention that in your WIP thread.
When you make updates to your posted contributions, it is not necessary to bump your according thread in the WIP forum, though you may if you wish. (If these changes modify the status of your rerip, don't forget to reflect the new status in your Official Pack WIP topic post.) For changes to any packs posted in Submissions, including rerips posted in the Existing Pack Updates thread, DO make a new post mentioning those changes. Mods may overlook your modifications otherwise.
Way Past Cool Tips 'n' Trickz
These are fairly basic Quality of Life improvements to the ripping process you may find quite helpful, and (I hope) easy. I didn't want to encumber the previous sections with too many concepts, so I've placed them here.
Rename Logs During Logging
Your operating system may let you try to rename files in use, but prevent you from actually doing so until no program is using them. However, even if you can rename the file, BlastEm doesn't use the filename to keep track of a VGM log in progress.
Renaming a VGM during logging in BlastEm is 100% safe to do. This lets you rename logs while you have all their relevant information on-screen - a fine division of labor.
This fact can be combined with the following trick....
Use a .bat File to Auto-Generate Sound Test Number Comments
As described in #R(er)ipping packs, IrfanView (or any program with similar renaming abilities) makes renumbering VGMs in any order at all a trivial task. This means that as you rename them during logging, you can use their Sound Test numbers (if any) at the start instead, without any issue.
Why put these numbers in the filename? It can make things much less tedious. Consider these lines from the tag creating .bat in step 6.2. of Vampi's Project2612 algorithm:
SET Title=%%A vgm_tag [...] -Title:"!Title:~5,-4!" [...]
These "!Title!" lines are similar to an IrfanView renaming mask. ("5" means to skip over five characters, such as "01 - "; packs on this site don't use hyphens, so this should be changed to 3 ("01 "). -4 means to stop four characters before the end, which leaves out ".vgm" or ".vgz".)
By using a different pair of numbers in the Comment field, we can also create Comments based off parts of the VGM filename.
vgm_tag -Notes:"Sound Test #!Title:~0,2!"
(Just for formality, I like to change "Sound Test" to match whatever term is used in-game - or, there's no "term" to speak of, "Internal music number".)
Meanwhile, if you've already numbered your VGMs and would like to use this technique without undoing all that effort, don't psych yourself into thinking it's a mammoth task. Simply add the Sound Test numbers at the beginning of each filename, without deleting anything that's already there. After the comments are generated, that renaming can be reversed quickly just by using Undo (as long as there's not too many tracks/you didn't do other things in your file manager in between), or by batch renaming to keep only the desired chunk of the filename.
vgm_ren can free you to keep those sound test numbers in place in your backups
I mean, you could anyway by making data-redundant backups, but those can be huge. If the Titles match the Track Name exactly, why do anything but generate the filenames and playlist? Create a playlist using the titles of the VGMs in track order, use vgm_ren on it, and watch. If you goof in any way, all the fixing can be done in the .m3u, after which you just use vgm_ren again.
With an appropriately-sorted .m3u, you can leave the sound test numbers in your backups, generate your trimmed and optimized VGMs, and vgm_ren the finalized files as one of the last things you do before submitting.
If you have a VGMRips account and any questions about this article, please add them to the "Discussion" page linked at the top. I'll try my best to respond as soon as possible.
(To see what changes have been made to this tutorial the last time you looked at it, open the History page linked in the same place. The "diff" links will show you comparisons.)
The contents of this article are given to you under the terms of Creative Commons Zero, which is the equivalent of a public domain dedication (even where such is not otherwise possible) and grants the same rights. Feel free to copy, spindle or mutilate without even worrying about credit.