R(er)ipping for the Out-of-Element Contributor

From vgmrips

This tutorial will show you how to create a VGM package for VGMRips. Whether you're creating a new pack or updating an existing one, the basic needs for each step are the same regardless of system.

If there's anything you feel was left unexplained, or if you feel you need more help on any aspect of the ripping process, please contact us in the VGMRips chatroom. It is also strongly advised that you make a post in the Offical Pack WIP topic on the forum and tell us what game(s) you're working on, so we can avoid other people working on the same project as you simultaneously. The topic will list which sets are currently in progress.

This article was written by (Jazz) Jackalope, with info folded in from DukeNukem's Project2612 ripping tutorial and Vampi's Project2612 algorithm.

Before You Start

You'll want to make sure you can rip the game you want to rip. Each song that loops should be recorded at least 2-3 times, if not longer; most emulators can fast-forward, but I don't recommend this for reasons I'll explain later. Even if you do fast-forward, you'll probably be hearing each song quite often if you trim as well.

For those reasons, I recommend only doing games where you don't ever get tired of hearing most of the music.

If you know you can hear this soundtrack for extended periods, you should make sure it hasn't already been ripped - and, if it has, that it doesn't need to be updated. Some older packs need updates to tags, or for all or some of their tracks to be relogged in more accurate emulators.

Finding out the pack status of the game

On VGMRips, there are several places to check. To find out if the pack has been made or not, look in:

But please note: the non-forum search sometimes fails to find certain results.

If a pack does exist, check the following sources to see if it needs an update:

If it does, grab the most recent copy of the pack: you have to build your rerip off the existing pack anyway, even if you more or less change almost all the contents.

Making your VGMRips account (if you don't have one already)

You have probably already noticed: to check the Pack WIP topic (and make submissions), you 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]f 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 have checked up on your desired game(s), go to the Official Pack WIP topic. To help avoid duplication of effort, make a post naming all your intended rips - not only rerips, but any new VGM rips you plan to make.

There's no standard way to sort and classify your in-progress work. Read 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. (And note if you only plan to do some of the work) When the status of a set has changed - for instance, if you've made progress or decided to discontinue work - remember to go back to your original post and make changes accordingly.

It's 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.

Gather Necessary Programs if you haven't already

Now that you're ready to start your ripping career, it's time to get what you need to rip games. Each step will detail how to use these tools.


The Steps of Pack Creation

Making a pack is a long process; as you can see, if all the details were put in this one page, it would be massive and daunting. That's why each step has its own system/game-agnostic tutorial page, rounded up here as links.

Going Logging

As the first step in making a pack, Logging VGMs is an important step. (That's not insulting your intelligence, its just a reference...) This page tells you how to get a picture of how many and what kind of songs you'll have to rip, including hidden songs not in the sound test. Then it tells you how to create VGM logs.

It also covers (though not quite in order)

  • things you can do if your target game has no sound test/equivalent to log from, and
  • what to do if the sound test is big heap garbage, and other various caveats.


The next two steps can be done in either order. Some find it easier to trim the VGMs, then tag the trimmed files after they're done. Others prefer to completely tag the untrimmed logs, so all trimmed VGMs are correctly tagged already.

Either way, the VGMs definitely need:

Trimming

Why so? VGM Players can loop VGMs perpetually, if you want, but only if the trim points say where the VGM begins and ends. The trickiest step is as important as logging.

Here are the current relevant pages and tutorials:

Once you have the right numbers, you'll use vgm_trim to trim the VGMs. Then, you'll have to listen to each trimmed song to make sure it sounds correct. You can skip ahead in the song to make this faster, though sometimes it makes playback sound weird.

Tagging

Most of what you need to tag applies to the pack's description text/.txt file as well. For your convenience they are united in the aptly-named Filling Out the Tags and Text File. It'll name you spots to find info such as the names of music creators or game developers - as but one of its many useful features.

While you should make sure all the info is correct as best you can, don't let perfectionism stop you from posting your pack. New info is discovered all the time, and tagging can be done and re-done even on compressed VGZs without any issues. Being accurate just means your pack can be accepted faster.

Note: A great thing about tags is, thanks to VGM Tools, it's fairly easy to move them from one VGM to another, without having to re-enter all the information.


To cut these music files down to size, they also need:

Optimizing

This is probably the least intuitive step. But Optimizing VGMs covers key VGM programs and such alchemies of stripping unused chip information. For a very few VGM chips, no optimizations exist and the step is skipped.

After that, there's two more parts that we haven't looked at yet:

Final Touches and Pack Posting

This covers everything that remains: the screenshot and the playlist/m3u file.


(Past this point, there should now be nothing confusingly out of date with the pages above. The structure may be hoary but the info should be relevant.)


R(er)ipping packs

I forgot to bring it back and mention what I said about the Rules topics on the forum, everything that's in them is more or less covered by the tutorials above.


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, You have several cleanup options:

  • 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.
  • Since all the files are tagged, you could use one of the newer VGM Tools, vgm_ren, to spawn 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.
  • 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:
## $N[5-284]
Note: This assumes the file name has five characters at the start, such as "03 - Example.vgm". The hyphen after the track number should be removed, if it exists. If attempting to renumber VGMs that included the game name as well, you'll need to increase the number "5" by the number of characters in the game name. If the hyphen isn't present, change 5 to 3.

Importing tags from an old pack

Note: Since you had to rerecord tracks anyway, consider seeing if vgm_spts and/or vgm_sptd work on your new logs. If they do, you don't have to figure out Start Samples.

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.

If using VGMToolbox and doing tagging first: Many times things don't go wrong, but for some reason I've been encountering strange glitches at times, ones I can't seem to replicate. Bugs such as files stopping working with vgmlpfind, not even to be scanned.

If you encounter bugs yourself, telling us about it in IRC or the forums is helpful... but you might run into my same problem and be unable to repeat the bugs after reloading the program.

If you're concerned, the quickest thing to do is just switch to using VGMTool, or vgm_tag if you don't need to put in Japanese or other wonky characters. But if you want/need to continue using VGMToolbox, first make backups if you haven't already.

See Filling Out the Tags and Text File for in-depth details/a refresher on what goes into those places, especially if you're making a new rip and not an update. The following sections describe the transfer of tag info from VGMs that have them into VGMs that don't; this is useful for VGM packs in any state that need one or more tracks relogged.

Using vgm_tt

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.

Note: If you're using vgm_tt, you might apply your tag changes to the old set (including such things as generating sound test comments). It's not required but should give a bit more peace of mind.

Using VGMToolbox

(If you haven't seen the info above, please be aware that sometimes this program can make VGMs stop working with vgmplpfnd.)

Load your relogs/dumps and the previous rip's tracks in the program as described on its wiki page linked above. 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.

  1. 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.)
  2. 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.
  3. Whether or not the Ripper changed, of course, you should leave that checked. We're about to change it.
  4. 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.)
  5. 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.
  6. If the game being (re)ripped is a Sega Mega Drive / Genesis game, it should say exactly that for the English System.
  7. 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.)
  8. 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.
  9. 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 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.

Finalizing

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.

Way Past Cool Tips 'n' Trickz for Any Kind of Pack

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:

SETLOCAL EnableDelayedExpansion
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.

?

Profit!

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.)


Article license

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.