Final Touches and Pack Posting

At this point, you've:

Logged all known songs for your target game
Trimmed all the resulting VGM tracks
Filled out the VGMs' GD3 tags and the text file, plus prepared the M3U playlist
and optimized all the tracks in the pack.

Maybe you might have done some of this in a different order, but the bottom line is: you're near the finish line! There are only two parts left:

Preparing the Screenshot(s)
Submitting your pack

However, these tasks can be a bit tricky. Certainly easier than anything you've faced so far, though.

The Screenshot(s)

Every pack has at least one screenshot: in this case, a picture of the game's title screen with the game/pack/m3u name as its filename. (E.g., "Dr. Robotnik's Mean Bean Machine.png".) There are also a few cases where there'll be more than one:

If this title screen looks different in different regions (such as USA versus Japan versus Europe). In this case, the pack filenames should:
- have letter codes per region, like "Example (U).png", "Example (J).png", and "Example (BR).png"
- be named after the title in that region if it changes, like "Castle of Illusion (U).png" and "Fushigi no Oshiro Daibouken (J).png", and Puzzle Boy (J) / Kwirk (U).
If you included Beta songs in a final-game pack (ideal for smaller numbers of different/changed tracks) instead of in their own pack, and the Beta's title screen is different. The filename should include "(Beta)", and should be named after the beta title if it differs.
- If there are multiple betas with their own title screens, you have to indicate them somehow. Try to find out what the betas are commonly called, or use the build date to tell them apart.
If there are title screen differences based on other causes, like software revision. Mark these according to their commonly known name, which could even just be something like "(Rev B)".
If multiple cases apply to one screencap, apply all of them.

Regardless of the context, the same info below applies to each screencap you're including.

Your emulator should let you take a screencap easily, whether by a menu option or a hotkey, but the output might not yet be ready to go. Why not? Two possible reasons. You might have settings like "Double screen size" or some sort of video filter turned on in your emulator; if so, turn them off for pack screenshots. Probably less easy to contend with is scanlines, extra space put around the image at some point before capture. If you can't turn off the scanlines, you'll need to remove them some other way, as we'll see later.

Note: Aside from that and the other exception listed in Aspect Ratios below, don't edit the screencap under any circumstances. If you want to use a different image, just take more screencaps until you have what you want to use. That'll also be faster, especially if you slow down the emulator speed.

Most games flash text along the lines of "Press Start" on the title screen. You may take one with or without this text; without looks nicer. If there are other moving parts on the screen, use your best judgement, intuition, or personal taste to decide the timing. If you're still not sure, I recommend whichever shot you think best presents the game in one image.

When updating another pack, should I replace the screenshot?

It depends on how old the existing pack is, and whether newer emulators make more accurate images. One certain case is, a lot of the screenshots for existing MD/G or related sets (those imported straight from Project 2612, usually with only text file updates by andlabs) are poor quality. If reripping such a game, you probably should make a new one.

If in doubt, compare the existing pack screenshot to one you've taken and, ideally, to a verified image of what the game should look like. (For an NES, this'll be highly difficult, so ask if unsure.)

Aspect Ratios

The screenshots need a certain resolution based on system. This resolution is also known as the dimensions or the aspect ratio. (Technically, those are three different concepts, but right now you can consider them the same thing.) These numbers are typically given in "[Width]x[Height]" form.

An incomplete list of the correct dimensions for each system follows:

Screenshot dimensions by system and region
System	NTSC	PAL
Genesis/Mega Drive	320x224 or 256x224	320x240 or 256x240
PC-88/98	640x400 usually

Now and then there are some exceptions to dimensional rules. For instance, the IBM PC/AT game BC Racers uses a custom setting to make the screen 288x224. (More info here; the VGA controller can be programmed in a way that allows for odd resolutions.) The evaluators didn't even know about this case beforehand.

Therefore, if you're not sure or your system isn't listed here, ask in the IRC what your image should be, or simply submit your set and someone will tell you if it's incorrect. If you're pretty sure it's a special case, say so and further investigation will ensue; if not, see below. (And if you came back to this page and added the numbers you were told, that'd be swell.)

Now, why would the emulator not just give you the correct resolution? Because often, they put scanlines (extra space) in the screenshot. This can get pretty confusing if there's blank space that's actually part of the image. If you can figure out what space is extra, you can write down the crop-by numbers for use with all screencaps of that region in that emulator. (IrfanView's batch converter or any equivalent program is useful for this, even if it feels like overkill for one file.)

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.

By the way, .pngs are preferred: for the games we're dealing with, accurate colors are important. Most emulators create these, or can be set to. If you've got a BMP, it can be converted to a PNG with no loss of info.

Compress the Screencaps

Although the screencaps are extremely small, it is worth compressing them. Enough so that this section exists because the process was mentioned in the pre-Wiki Submission Topic Rules. (As described in the section, this tutorial series both includes and replaces that topic as the most up-to-date guidelines.)

Said rules specifically mentioned a program named PNGOUT. But this same program is included, along with other compressors, in a type of program called a "batch compressor." It's not only perfectly valid, but more convenient to use these programs if you can.

Based on your system, you'll be using:

FileOptimizer on Windows
ImageOptim on MacOS
Trimage on Linux-based systems
or some equivalent, such as another batch compressor or FileOptimizer inside of WINE.

I've only tried the first of these programs, but the others use the same principle. With these tools, you can sometimes shave entire megabytes off of larger PNG files, and pretty much need do nothing to get more compression than PNGOUT by itself can provide. Thanks to that usefulness, I'm going to say a quick note about general use versus preparing a pack screenshot.

The "Best" compression level of FileOptimizer should not 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, do use the Best compression level: it shouldn't take much more than a minute, if that, to ensmallen each screencap.

Posting packs on the VGMRips forums

Depending on what your pack is, there's only one specific place it goes. Whether for a new pack or an update, there are rules your post has to follow for proper processing. You may have seen these before: the Submission Topic Rules & Information, and the first post of the Pack Update thread.

At the time these and other info posts were made, VGMRips didn't have this wiki. By now, the Submission Topic Rules are not only partially dated: all the relevant info for a properly-made pack is included within this set of tutorials.

So, if you've been following along and recorded/tagged/created files as instructed so far, you don't have to worry about reading the aforementioned topic and posts. Everything you need to know about proper posting is here.

Where should I post?

If you just dropped in exactly here via link, keep in mind this tutorial has the most up-to-date posting guidelines. Rather than read the Submission Rules topic, just make sure your pack complies with the previous tutorials and read on for posting info.

Now, let's break it down:

A completely new pack that didn't exist before: A new topic in Submissions forum. It closes (that is, stops accepting new threads) when there are 100 non-Sticky threads, and won't re-open until the queue is reduced hugely. So please try to post only a few new pack threads at a time; see below for more info.
An update to any existing, officially released pack: A new post in the Pack Update Topic. These, you can post as many as you want since they're just posts. (And you may post multiple updates in one post.) But, posting more of them can't actually get them accepted faster.
An update (like a correction, typo fix, tag fix...) to any Submitted pack that hasn't been officially released yet: A new post in the same thread as the pack being corrected. If it's your own pack, you may just edit your original attachment or leave your pack link as-is - but you must make a new post mentioning that the update's been made, or the evaluators may overlook it.
(By the way, you don't necessarily have to increase the version number for these kinds of updates; see Filling Out the Tags and Text File for more guidance.)
An in-progress pack/update you want feedback on, hope to get help with, can't currently complete, or don't want to complete: A new topic in the Ideas and WIP forum. You don't need to make update announcement posts here when you make changes to your pack, though you may if you'd like to call attention to them.

(If you're used to other forums, you might know that double-posting (making a new post right after your old one in the same thread) is usually frowned upon. In the Works in Progress forums here, it's okay if your new post comes right after your last one.

(That said, when replying to a post right above yours, there's no need to quote the full post, which will happen if you press the Quote button. It's okay if you trim the Quote down to what you're answering, but many times you'll just want to use the Post Reply button under the post instead. This is actually part of the global forum rules, so it applies even outside the Works in Progress forums.)

For clarity, from here on both complete new packs and complete updates will be called Submissions since they go in that forum. As you've shrewdly guessed, incomplete ones will be called WIPs. Then, if you specifically see terms like "new pack" or "update", you know I'm referring to those regardless of complete-or-WIP status.

Once a pack is accepted, the relevant posts will be deleted to save forum space, except as described in the Pack Comments section below. There might be a few minor differences between your initial submission and the pack on the site. This is normal and doesn't necessarily mean you messed up.

Components of your pack thread/post

When making a new Submission thread, put the System name (e.g. "NES" or "Arcade/System 16") in the description field. This field doesn't exist in Ideas and WIPs nor in replies to the Update thread; in those cases, include this in the post title.

(That said, if you're posting multiple Updates in one post, this might be impossible. Just include the System name in the filename, file comments, or mentioned next to the matching pack link.)

In the post body, you can basically say anything. (If what you have to say is informative enough regarding the pack/game/ripping that one, you might consider folding it into the text file notes or placing it in a Pack Comment.) For certain types of packs, there's some things you do need to include:

Any kind of update: Include a summary of the parts of the pack you've changed. E.g.: if you've changed tags in the process of tagging, mention that you changed them, which parts you changed, and why. If you reripped tracks, mention which ones. If you reordered tracks, mention that. Also, if you haven't already, find more info in the Update rules below.
Any manner of WIP: Include a summary of the parts of the pack you've completed, and state what work remains to be done. If you only plan to do some parts of the pack (like only logging, or only logging and tagging/trimming), mention that so others know they can and should complete it. If you have specific questions, concerns, or problems, describe them so other users know how and if they can help.

You've probably noticed that for an update, a lot of that is similar or even identical to what you need to put in the Update History of the text file. So it can get pretty tempting to just leave it to that. And sometimes this makes some sense, such as when the overhaul almost amounts to a new pack's worth. But by writing down your progress again (possibly with the help of copypaste), you turn your post into a quick and handy guide of what you did and didn't do, if a long time passes and you forgot all that stuff.

(Also, fixing typos you didn't catch before your first posting is probably not worth formally writing down in the text file. But it's definitely something that you should mention in the update post.)

Any Submission can be given a Pack Comment. See the section on them below if you'd like to use this feature.

Last but certainly not least, you can't forget a download of the pack (or packs) itself. Well, you can, but to say the least it would be counterproductive.

As a quick reminder, your finished Submission will include all these things and nothing else: all the fully-trimmed and tagged VGM tracks of the game, the pack's text file, playlist, and all involved screenshots. You don't need to zip up the folder containing these things; just all of them themselves is fine. Since it'll need to be repackaged anyway, either a zip or a 7z file is fine (and you may find the latter is smaller). Name the compressed file after the game name and, ideally, include the System name in parentheses after it.

If your pack is small enough, you can upload it directly as an attachment to your post. Otherwise, it is recommended to upload the .zip to a site like Catbox, MEGA.nz, Dropbox, your own webspace, or some other file host and include a link thereof.

When you post, the forum's file comments feature is helpful if you're posting multiple pack updates at once; you can put all the update info there. Unfortunately, you can't include "Pack comment" lines there; they'll be ignored. If you want to add these, you must do it in the post body, and either clarify what pack receives each comment, or just make separate posts for each one.

Pack comments of Submissions

A "Pack comment" is similar to the Notes of the text file, but it only appears on the VGMRips pack page and pack forum thread. While I'm having difficulty thinking of cases where you'd want to put info in here and not the Notes, I'm sure they exist.

If you want to comment your release in this way, put the line "Pack comment:" in the main post body and write your comments below this line. What's placed there will be included in the final post that's made in the Official Releases forum, along with relevant related discussion from the new-pack thread if any.

For its usefulness otherwise, the file-comments forum feature cannot be used to add Pack Comments: any attempts to add them outside the main post body will be ignored. Therefore, if you're posting multiple pack updates, you must specify which pack each Pack comment line belongs to, as well as whether you want any existing comments to be replaced or changed.

If you don't annotate your post as above, everything else in it will be deleted when the posts are cleared - though evaluators may still keep relevant or interesting info at their discretion. But you shouldn't rely on this if you want specific things associated with the pack.

As for what you should or shouldn't put in these comments, what you say should of course be relevant to the pack. For instance, strange commands like "Here, get my pack quickly." don't belong in the final post, but you can write things like "My first pack" which may be interesting trivia. Of course, it's okay to write lines like "Here is the pack link", but you must put them above the "Pack comment" line.

Update Submission rules

(If you're posting a WIP update, you don't yet need to follow these rules. But you might find it more convenient to do so anyway.)

Remember, when complete, updates only go in the Pack Update Topic.

Updates MUST be applied to packs from the site, whether released or in the queue. Why? To make sure parts of previous updates aren't accidentally lost. Even if you have a copy of the pack already (like from Project 2612), you must get the most recent version from VGMRips if you haven't already done so.

And thus, if you've made it this far without having gotten the original pack, just grab it now and work your changes into that version. (See R(er)ipping for the Out-of-Element Contributor for details on things like comparing your new tags to the existing ones.) In fact, I recommend getting it from the Official Releases forum thread (or checking that thread now if you're updating a submission in the queue) to see if other users have reported issues with the pack that you may have missed.

That said, if the only piece you're updating/that needs updating is the screenshot, you can simply post the new/fixed screenshot(s) for each pack and probably don't need to do all that.

When posting a more extensive update, it's highly recommended you just post the full pack with all files included, changed or not. Other partial pack updates are allowed, but neither preferred nor that convenient. Each partial update must include an updated pack text file, plus a description (in the post, an additional file, or the forum file comments feature) what changes need to be made: e.g. what files need to be renamed, have to be replaced, etc. The only time this would be faster than a full update is if you've only changed a few vgms and the full pack size is too heavy for forum upload.

If updating your own pack, you may replace the existing attachment in your old post or leave the link to stand. But to ensure the update is noticed, don't forget to make a new post in the same thread mentioning it so the evaluators know you've made changes.

Don't forget, when you modify a Submission, a lack of new post means the evaluators will assume they already have the most up-to-date version. If you want to be extra sure you don't forget to make the update announcement post, just put your changes in said new post.

If you're updating something in the WIP forum, you don't have to bump (make a new post in) your thread; just editing is fine, since it still has work to be done before it becomes a submission. You might choose to bump anyway if your update has important changes or info.

If those changes to your WIP change the status too, don't forget to reflect the new status in an edit to your Official Pack WIP topic post. If you've been following from R(er)ipping, you've already made this post; that's plenty for that particular thread, since there everyone knows where to look for that info. What counts as a new status depends on the categories you put in or want to add to your post.

"I've posted my pack; what happens now?"

VGMRips submissions get vetted when evaluators are able, to ensure quality and that the pack fits the guidelines, as set out in this series of tutorials. As there are only two official evaluators at this moment, the process may take weeks or even longer.

Also thus, there's no way to get submissions approved more quickly, even if you post many at one time.

Actually, there is one means to help the process go a bit faster: look at other submissions or even WIPs, and post any issues you notice in their threads. (You might even make the changes yourself, as if updating any set, and post it.) If things were done differently for a special reason, the pack maker can explain why; if they were simply unaware, they now know more quickly than the evaluator can say so and this is one thing fewer to notice is wrong and report.

Sometimes your feedback can uncover issues in the known workflow that nobody noticed before, or oddities of a certain game/OST, or things you may have misunderstood and not known it. Everybody wins, even if you only look at some packs.

?

Profit!

If you learn that some information from these tutorials is flawed or out of date, based on feedback from the evaluators you see or receive, you can help here too. Your VGMRips account empowers you to edit these wiki pages by the Edit link at the top of each page. Don't be too worried, because if you really do mangle the formatting or delete something you didn't mean to, the changes can be reverted or someone else can fix it.

Need more info on how to format, make links, etc.? MediaWiki has some good tutorials from which I learned everything I know.

As you continue your travels, keep in mind that these tutorials will continue to be updated with new info. To easily find out if that's happened since you last looked, check out Recent Changes. You can increase the number of edits or amount of days you can see, and even compare page histories to see exactly what's changed.

Now, happy ripping!