Forums

Original logs by sherpa. I took them and made a pack out of it. I'm planning to do more soon.

http://www.smspower.org/Music/DokiDokiPenguinLand-SG

Thanks for your contribution.

There are a couple of issues with it - please take a look at the packing standards in particular.

http://www.smspower.org/Music/Help-VGMPackStandards

or an upated

http://www.smspower.org/Development/MusicEngineControl-Tutorials-Your-First-Trac...

A minor issue with the naming ("~" character is discouraged). This tends to be used in japanese titles. Did you obtain the names from some source? It might be nice to make a quick mention of this if you have. Anything that can be checked and provide additional background is welcomed here..

Also, extensions should always be vgm regardless of compression.

These are things many people make mistakes with in the beginning.

Also, the text asserts that Tohru Nakabayashi is the composer, per a claim by a third party. Could you provide some proof of this. Generally, conversations can provide useful information, but are not always reliable. There is also currently no proof it happened. It is better to remain on the safe side and list unknown if you do not know for certain or your only proof is via contact with a third party. Could you (or your friend) provide additional information that would allow the community to check your claim? Otherwise, I would personally merely note the info on the forum post that xxx asserted such and provide as much context as possible so that more knowledgeable members can verify.

Lastly, who is HarmoDevil? This seems to be your pack per the previous post, but HarmoDevil is not a recognized user here. Some clarification would be appreciated. We have a few contributors without accounts, so this is not unprecedented, but it is a bit confusing.

If you can provide evidence (hopefully more than one) of your claim, it would be appreciated. Maxim and other senior members are better judges of what should pass muster, so if they're willing to accept your claim once you have provided proof, so will I.

In the meantime, I hope you'll find this advice useful and be encouraged. Smspower maintains high standards. Errors rarely get fixed later on, so it's better to prevent them in the first place.

Thanks for your efforts. Let us know if you would like help with anything.

To answer your post:

Some of the reasons why the pack is not completely of SMS Power standards is because I'm so used to making packs on VGMRips, where they have different standards. I honestly believe the VGM packs on this site and Project 2612 should be moved to VGMRips.
The names were taken from Sega SG-1000 30th Anniversary Collection. I'll add that to the notes. However, if the "~" is discouraged here, I don't know how I'm gonna rename that track...
I wasn't aware of the extension standards here - I thought .vgz is fine (it's acceptable on VGMRips).
This is not my first VGM pack I've ever done, by the way.
Yosuke Okunari confirmed the composer on the liner notes of Sega SG-1000 30th Anniversary Collection.
I'm HarmoDevil (I use that name on VGMRips as my pack author name). I'll change the pack author to drdevilfx since that's my username here.

Sorry the pack disappointed. :/

Yes, the rules are a bit different between vgmrips and SMSPower.

Most of your issues are obvious if you find the respective parts of the "How To Make VGMs" wiki articles.

drdevilfx wrote

However, if the "~" is discouraged here, I don't know how I'm gonna rename that track...

Tagging rules

Quote

However, in general convert "~" to "-" - "~" is commonly used in Japanese but is equivalent to a regular dash. In general a hyphen "-" is preferred to a typographical dash "–".

drdevilfx wrote

I wasn't aware of the extension standards here - I thought .vgz is fine (it's acceptable on VGMRips).

File Naming / Extension

Quote

The extension must be ".vgm". Compressed ".vgz" files must be renamed to ".vgm".

drdevilfx wrote

I'm HarmoDevil (I use that name on VGMRips as my pack author name). I'll change the pack author to drdevilfx since that's my username here.

I think it's fine if you keep your "original" user name in the pack. But that's just my opinion. The wiki page would have to show your SMSPower nick though.

Here is the new, 'improved' version of my pack.

Let me know if it still doesn't meet SMS Power's standards. I also replaced the screenshot with an edited screenshot by sherpa, though oddly it's based on the screenshot from the Taiwanese version.

Edit: file removed

VGMrips kind of forked from our standards at the time. We dropped vgz because it's meaningless information for consumers of the packs and players don't need it. I'm thinking of dropping vgm7z since it didn't really take off - it'd help the most for big sample heavy packs like on P2612, a few KB makes little difference for us. Much of the packing process could be automated if we had the people interested in the task...

I guess the thing we're the biggest sticklers for is sources for information, there's too much misinformation out there but sites like vgmdb are a big help.

Thanks for the update. Everything looks much better.

Some final suggestions:

Since your vgms are uncompressed, the should be 7zipped and the extension changed to vgm7z. The VGMs should be gzipped (I recommend vgmtoolbox) and renamed to *.vgm extension and zipped (as in your first contribution)

I'd also recommend, changing the package history format to yyyy-mm-dd rather than dd--mm--yyyy as you have it. Though used widely enough, I personally have not come across that standard much, and I also personally find it to be a good idea to be in sync with the release date tag format which is yyyy-mm-dd. Older packs often omit this section, so there is no hard recommendation here. Rather a suggestion.

As far as the ripper tag goes, thanks for updating it to the username you use here, though I agree with VB that it needn't be a hard requirement. Still, since the VGM page will link to your user name here, it's less confusion if the name(s) in the text match. Also, if you didn't redo the vgm logs yourself, any user who contributed to the final vgm log should be in the tags as well, separated by semicolon. (in this case me). I don't think order matters, though I tend to prefer historical, since you are creating a historical document. There might be cases where it might be appropriate not to include it. I've also included previous rippers even where I decided to do everything from scratch. It indicated the pack had a previous history, and I prefer to maintain that.

On the other hand, some of the earlier logs I'm not as proud of (even if there isn't anything verifiably wrong with them) and I did them so people would have something to listen to and (maybe) work on, not so i could piggy back on future work (that would start to feel absurd rather quickly). I think some earlier packs may not have given credit to the original ripper ouside a forum mention and maybe the text, so maybe it's ok. A lot of old packs are based on old logs that hung in limbo for a while before someone decided to pull together a pack.

I'll leave it as a judgement call, but I prefer things to be deliberate rather than overlook minor errors. I can see myself not liking it if the next several packs all co-credit me: it might be accurate, but the info starts to seems less meaningful as time goes on, and possibly distracting. Still, it's early enough, and I feel not inappropriate to discuss these issues.

Thanks for the new set. Just a little more and it will be ready for posting.

This new pack should now address the issues you've noted. I guess it's now ready to be added to the site? I'll remove earlier files from above posts, since people needn't download those.

Almost :)

You mixed the standards:

uncompressed vgm > vgm7z
gzipped vgm > zip

Your previous pack had uncompressed files in a zip, and this one has gzipped files in a vgm7z. The reverse of what is desired.

It might help to work in separate subfolders with duplicate files so you don't mix up the files and standards. If you use vgmtoolbox, compressed files remain compressed and uncompressed remain uncompressed. vgmtool r5 will gzip files when you edit their tags.

There should be two archives: a vgm7z and a zip. 7zip the uncompressed vgms and zip the compressed vgms. Hope that is clear enough.

You're almost there!

It's simple enough to repack it, I just automated that and there's nothing more to do. I really wish we had a shareable tool to wrap all this up, from tagging to packing.

sword dude, was it the japanese version you owned or the taiwanese? I hadn't come across a jp version so I used the tw. I wan't aware there was an existing dump, but there it is.

I thought I had deleted drdevilfx's first pack, but it was in the recycling bin, and it had the japanese version's screenshot. As a friendly service I am including it here, properly processed.

Maxim, I assumed based on your post that it was up already, but I see it isn't. I was holding back a bit, one because after the initial feedback, drdevilfx responded quickly and concisely, so I'm assuming a greater payoff of we just let him figure it out on his first pack, I'm sure he'll maintain proper standards moving forward. I'd prefer to avoid too much hand holding on his first pack. Admittedly, what remain are the least important aspects of making a pack, and arguably, as you indicated, they don't really make much sense in the modern day era as they did originally. The payoff isn't there as it is with vgms for other systems.

The included screenshot is 210 x 210 and has been run by pngout. Screenshots are generally too small for there to be any difference in the space it takes on a hard drive (due to often being smaller than the cluster size) and arguably irrelevant on the bandwidth end due to current broadband availability in many countries.

For future reference, I use irfanview since it includes a pngout plugin. It is a dll version, and probably older than the command line that was last updated in early 2015. There also seems to be a paid windows version, but it doesn't look like it's been updated in years.

I took your screenshot ingame and:

1) resized the canvas (not image!) to 210 x 210 (we want it square)
2) I then pasted over the meaningless text with the background color.
3) I then cut and moved the remaining images to be a bit more centered
4) Finally I saved and exported the file using the pngout option in irfanview and used the default settings.

Only the first and last steps are "required" for standards. The use of 210 was arbitrary, you could have resized everything 256 x 256 (canvas). 192 x 192 would have cut off the text. Feel free to repeat these steps yourself to get a feel. In some images, creating a proper image can take a bit more work due to having artwork in the background.

I'll also include my own script for commandline, that I've been using since I started working on the latter end of the logging project. (think it was after Tom made his script for the "which gg games have stereo" project. It assumes that vgmtoolbox has been used. That 7za.exe is in the PATH variable, and that you have some version of winrar installed. Your uncompressed files have been run through gzip compression and are in the same folder. Also screenshots (there should only be one) are in the current folder as well as txt (only one) and in their final version. Finally, it renames the created archive by the base name used on the site and what will appear on the vgm page. It does not delete anything, but it can get a little messy if you don't have everything right and need to redo something.

set "var=DokiDokiPenguinLand-SG"

mkdir 7z
mkdir zip

move *.vgm .\7z
copy *.m3u .\7z
copy *.png .\7z
copy *.txt .\7z
rename *.gz *.vgm
move *.vgm .\zip
copy *.m3u .\zip
copy *.png .\zip
copy *.txt .\zip
7za a 7z.7z .\7z\*
"c:\Program Files\WinRAR\WinRAR.exe" a -afzip -ep "zip.zip" ".\zip\*"
rename *.7z %var%.vgm7z
rename *.zip %var%.zip
rename *.png %var%.png
pause

I don't currenlty have my system set up, but I was going to offer to do it myself if drdevilfx hit another snag and wasn't eager to try again.

drdevilfx (and new users reading this post):

ValleyBell has provided some useful info above. For others transitioning from VGMRips, you'll find the standards are a bit different here (no vgz files). One thing you may overlook if you are used to working on other systems is that vgm logs at smspower are frame accurate, not sample accurate as you may be used to. So, if you make your own logs in the future, excluding voices and rare events, you should log everything frame accurate (I recommend MEKA) and run everything through vgm_facc (Make frame accurate) until you really know what you are doing. For historical reasons that made sense at the time, the standard here at smspow is a "frame accurate" vgms, so updates occur 50/60 times a second, not x=<44100/s. You will not find single wait 7x commands or anything complicated generally, but does make logs a bit easier to read.

The other things you are likely to overlook are how images are processed, how things should be named and the fact that we keep two archives here vgm7z and zip. We appreciate contributions and new work, so please keep at it, this feedback is not meant to discourage. SMSpower does have standards though, and I think most of us would rather pass on work that falls below a certain threshold (not the case here :)

Hope this helps[/list]

Doki Doki Penguin Land (SG-1000).png (1.24 KB)

sherpa wrote

you should log everything frame accurate (I recommend MEKA) and run everything through vgm_facc (Make frame accurate)

You either log everything frame accurate or run vgm_facc. (because the former makes the latter redundant)
The only emulator that makes logs that vgm_facc works properly with is Kega Fusion though. In all other emulators the timing drifts slightly, due to the frames not being exactly 1/60 second long.

Yes, I should clarify, that when you are a beginner in working with frame accurate files, you would also normally need to run facc because it's one thing to log a frame accurate file (emulator setting) and another for after you have trimmed and optimized it and have it remain facc. If you cut at samples based on the vgm2txt tool, you will not have this issue, but there are old tutorials here and elsewhere where you cut based on a wave file (I started this way) and you will need to run facc if it isn't frame accurate (good chance unless you're calculating start/loop start/loop end MOD 735/882==0). Some old files one this site are not actually frame accurate since they were made before you made your tool. It was a while before i stopped using facc as it was a while before I developed a process that prevented the issue in the first place.

facc is not meant to be used on sample files or vgms where the adjustment is 200-300+ samples.

And good point about emulators affecting the output and the timing drift. I did not know that about Kega Fusion, but it does log sample accurately (one of the reasons i don't use it often), and frame accuracy can be considered an imperfect, but "good enough" compromise between keeping file sizes small and accuracy that has been the standard on this site for a while. The drift you speak of does make work with some sets more complicated than it would normally be (no true loops in facc), though there are many other things that cause this as well (pitch effects, etc).

I didn't want to get too detailed into this at this point, even though drdevilfx/HarmoDevil is not a beginner, but just pointing something out that may be an issue for people who are used to working with different tools and standards, and I have no idea how they work or where errors are likely to occur in their process.

The VGMs are frame accurate, by the way. I was already aware of that standard (also the same on VGMRips) because the readme of the VGM Tool Collection tells me to make SN76489 VGMs accurate.

Anyway, I'll post the vgm7z and zip later. Thank you for the edited screenshot.

I think it's now ready to be added to the site. I personally feel all posts above should be removed for convenience's sake.

Congratulations. Your pack is up. Link in the first post.

That's another thing that's different about smspower compared to VGMRips. They have a chatroom that makes it easy for community members to connect in real time (and chat history for those who want to catch up on what they missed). I think smspower had one ways back (might still have it) but most of the action occurs in the forums and updates to the wiki.

VGMRips also has a section dedicated to new vgm packs/updates, but it gets routinely cleaned out and refreshed after a period of time or quota is reached. The only text that gets preserved is what is specifically selected by the pack author for preservation. Usually something short.

Smspower isn't like that. Everything gets preserved, including messy little conversations and sometimes even poor behavior. In fact, deleting posts is strongly discouraged. It's not outright banned, as you do have the ability to edit your own posts (but please don't delete them). Admins can edit or delete anyone's, but generally they ask, a little short of insisting that you have good reasons for it. SMSpower has a lot of history, you can still go back and read interesting tidbits about the early days. The development section usually seems to get more action than the music section- many members here at smspower are very knowledgeable and comfortable working with hardware. If you have a project you are working on, it's not unlikely the answer is buried somewhere. It's happened more than a few times that I spent a good deal of time trying to figure out something that had already been discussed years prior, in equal or superior quality to what I had accomplished. It's a good idea to search the forums and other sections when you work on anything new.

I don't know if you have the ability to edit your posts or post links. By the time I wanted to I already had the ability to do those things. Minor edits are ok, but if you start deleting your posts, there may be holes in the conversation, and that isn't want's preferred. Some people have done it though rarely. Sometimes it might be ok, such as if you were posting incorrect or irrelevant info, but i personally tend to leave such posts up as well, I think they all contribute-and it's probably better to err on the side of caution. Unlike the wiki, the stuff on the forums is not backed up. You can't view post history and you can't undelete. Once it's gone, it's gone.

Congrats on your first pack at smspower. Once you've established yourself as someone who can go from a-z without guidance or correction, you will generally see less populated posts. It's something organic, not planned that tends to happen early on. You can also private message individuals if you want to ask something, but in general, if it is something that someone else might benefit from, I believe the general preference is that you post the question in the forums. Most of my posts here, have been generally targeted at you, but really for the benefit of anyone who comes after you.

I originally also came from VGMRips. I originally intended to contribute for a short while, but the community grabbed me. On the other hand, If it weren't for the VGMRips chatroom, I would probably never gone far enough to be able to contribute here. The two sites have rather different flavors and advantages, and I'm glad they both exist.

Welcome to smspower.

I have to admit that the flaws of the submission process on vgmrips are at least partially my fault. I wanted to mimic the "workbench" behaviour from tasvideos, and make it that a new pack is reviewed and approved in a new topic like it is now, but once it was approved, I wanted to make an automated post which said something like "the posts above this one are about the approval process, and the posts below can be used to comment on the finalised pack". In the end, I can't remember why we never implemented that, and simply decided to delete everything related to the approval and keep only the comments themselves. At another certain point I even considered a hybrid solution like Overclocked ReMix, where judging topics are locked and preserved, and separate comment topics are created, but we didn't take that route, either.

Anyway, if I'm not wrong, Vampirefrog said he wanted to redo the entire thing in a specialised CMS (I used phpBB2 because it's the only community software I'm familiar with), and while I don't know its current status (the new enforced https makes it extra hard for me to browse vgmrips these days), I'm sure it will make a much smoother experience for future submissions.

As for the different standard, I went with what made the most sense to me back then, we'll never find a "perfect" system which will satisfy everyone, just like Project2612 and smspower always had slightly different standards too. I still think it's good to use the vgm and vgz extensions to differentiate between compressed and uncompressed files, for example, just like I think screenshots shouldn't be resized or edited at all, but rather included "as-is" (e.g. 320×224 for a Mega Drive / Genesis screenshot).

That said, the more, the better. A file can always be renamed eventually to suit someone's taste. If you're used to delve into hundreds of downloaded mp3s which range from "artist - title" to "title - artist" to "album - ## - title" to whatever, managing vgm packs from the three main vgm websites should be a piece of cake.

Author	Message
drdevilfx Joined: 08 Oct 2015 Posts: 17 Location: Scotland	[VGM Pack] Doki Doki Penguin Land (SG-1000) Posted: Mon May 09, 2016 4:23 pm Last edited by drdevilfx on Thu Jul 07, 2016 11:35 am; edited 1 time in total
	Original logs by sherpa. I took them and made a pack out of it. I'm planning to do more soon. http://www.smspower.org/Music/DokiDokiPenguinLand-SG

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Tue Jul 05, 2016 1:41 am
sherpa Joined: 28 Nov 2014 Posts: 365	Thanks for your contribution. There are a couple of issues with it - please take a look at the packing standards in particular. http://www.smspower.org/Music/Help-VGMPackStandards or an upated http://www.smspower.org/Development/MusicEngineControl-Tutorials-Your-First-Trac... A minor issue with the naming ("~" character is discouraged). This tends to be used in japanese titles. Did you obtain the names from some source? It might be nice to make a quick mention of this if you have. Anything that can be checked and provide additional background is welcomed here.. Also, extensions should always be vgm regardless of compression. These are things many people make mistakes with in the beginning. Also, the text asserts that Tohru Nakabayashi is the composer, per a claim by a third party. Could you provide some proof of this. Generally, conversations can provide useful information, but are not always reliable. There is also currently no proof it happened. It is better to remain on the safe side and list unknown if you do not know for certain or your only proof is via contact with a third party. Could you (or your friend) provide additional information that would allow the community to check your claim? Otherwise, I would personally merely note the info on the forum post that xxx asserted such and provide as much context as possible so that more knowledgeable members can verify. Lastly, who is HarmoDevil? This seems to be your pack per the previous post, but HarmoDevil is not a recognized user here. Some clarification would be appreciated. We have a few contributors without accounts, so this is not unprecedented, but it is a bit confusing. If you can provide evidence (hopefully more than one) of your claim, it would be appreciated. Maxim and other senior members are better judges of what should pass muster, so if they're willing to accept your claim once you have provided proof, so will I. In the meantime, I hope you'll find this advice useful and be encouraged. Smspower maintains high standards. Errors rarely get fixed later on, so it's better to prevent them in the first place. Thanks for your efforts. Let us know if you would like help with anything.

drdevilfx Joined: 08 Oct 2015 Posts: 17 Location: Scotland	Posted: Wed Jul 06, 2016 2:12 pm
	To answer your post: Some of the reasons why the pack is not completely of SMS Power standards is because I'm so used to making packs on VGMRips, where they have different standards. I honestly believe the VGM packs on this site and Project 2612 should be moved to VGMRips. The names were taken from Sega SG-1000 30th Anniversary Collection. I'll add that to the notes. However, if the "~" is discouraged here, I don't know how I'm gonna rename that track... I wasn't aware of the extension standards here - I thought .vgz is fine (it's acceptable on VGMRips). This is not my first VGM pack I've ever done, by the way. Yosuke Okunari confirmed the composer on the liner notes of Sega SG-1000 30th Anniversary Collection. I'm HarmoDevil (I use that name on VGMRips as my pack author name). I'll change the pack author to drdevilfx since that's my username here. Sorry the pack disappointed. :/

ValleyBell Joined: 15 Sep 2009 Posts: 377	Posted: Wed Jul 06, 2016 3:55 pm
ValleyBell Joined: 15 Sep 2009 Posts: 377	Yes, the rules are a bit different between vgmrips and SMSPower. Most of your issues are obvious if you find the respective parts of the "How To Make VGMs" wiki articles. drdevilfx wrote However, if the "~" is discouraged here, I don't know how I'm gonna rename that track... Tagging rules Quote However, in general convert "~" to "-" - "~" is commonly used in Japanese but is equivalent to a regular dash. In general a hyphen "-" is preferred to a typographical dash "–". drdevilfx wrote I wasn't aware of the extension standards here - I thought .vgz is fine (it's acceptable on VGMRips). File Naming / Extension Quote The extension must be ".vgm". Compressed ".vgz" files must be renamed to ".vgm". drdevilfx wrote I'm HarmoDevil (I use that name on VGMRips as my pack author name). I'll change the pack author to drdevilfx since that's my username here. I think it's fine if you keep your "original" user name in the pack. But that's just my opinion. The wiki page would have to show your SMSPower nick though.

drdevilfx Joined: 08 Oct 2015 Posts: 17 Location: Scotland	Posted: Wed Jul 06, 2016 4:33 pm Last edited by drdevilfx on Thu Jul 07, 2016 11:35 am; edited 2 times in total
	Here is the new, 'improved' version of my pack. Let me know if it still doesn't meet SMS Power's standards. I also replaced the screenshot with an edited screenshot by sherpa, though oddly it's based on the screenshot from the Taiwanese version. Edit: file removed

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Wed Jul 06, 2016 6:24 pm
	VGMrips kind of forked from our standards at the time. We dropped vgz because it's meaningless information for consumers of the packs and players don't need it. I'm thinking of dropping vgm7z since it didn't really take off - it'd help the most for big sample heavy packs like on P2612, a few KB makes little difference for us. Much of the packing process could be automated if we had the people interested in the task... I guess the thing we're the biggest sticklers for is sources for information, there's too much misinformation out there but sites like vgmdb are a big help.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Thu Jul 07, 2016 6:36 am
sherpa Joined: 28 Nov 2014 Posts: 365	Thanks for the update. Everything looks much better. Some final suggestions: Since your vgms are uncompressed, the should be 7zipped and the extension changed to vgm7z. The VGMs should be gzipped (I recommend vgmtoolbox) and renamed to *.vgm extension and zipped (as in your first contribution) I'd also recommend, changing the package history format to yyyy-mm-dd rather than dd--mm--yyyy as you have it. Though used widely enough, I personally have not come across that standard much, and I also personally find it to be a good idea to be in sync with the release date tag format which is yyyy-mm-dd. Older packs often omit this section, so there is no hard recommendation here. Rather a suggestion. As far as the ripper tag goes, thanks for updating it to the username you use here, though I agree with VB that it needn't be a hard requirement. Still, since the VGM page will link to your user name here, it's less confusion if the name(s) in the text match. Also, if you didn't redo the vgm logs yourself, any user who contributed to the final vgm log should be in the tags as well, separated by semicolon. (in this case me). I don't think order matters, though I tend to prefer historical, since you are creating a historical document. There might be cases where it might be appropriate not to include it. I've also included previous rippers even where I decided to do everything from scratch. It indicated the pack had a previous history, and I prefer to maintain that. On the other hand, some of the earlier logs I'm not as proud of (even if there isn't anything verifiably wrong with them) and I did them so people would have something to listen to and (maybe) work on, not so i could piggy back on future work (that would start to feel absurd rather quickly). I think some earlier packs may not have given credit to the original ripper ouside a forum mention and maybe the text, so maybe it's ok. A lot of old packs are based on old logs that hung in limbo for a while before someone decided to pull together a pack. I'll leave it as a judgement call, but I prefer things to be deliberate rather than overlook minor errors. I can see myself not liking it if the next several packs all co-credit me: it might be accurate, but the info starts to seems less meaningful as time goes on, and possibly distracting. Still, it's early enough, and I feel not inappropriate to discuss these issues. Thanks for the new set. Just a little more and it will be ready for posting.

drdevilfx Joined: 08 Oct 2015 Posts: 17 Location: Scotland	Posted: Thu Jul 07, 2016 11:34 am
	This new pack should now address the issues you've noted. I guess it's now ready to be added to the site? I'll remove earlier files from above posts, since people needn't download those.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Thu Jul 07, 2016 6:17 pm
sherpa Joined: 28 Nov 2014 Posts: 365	Almost :) You mixed the standards: uncompressed vgm > vgm7z gzipped vgm > zip Your previous pack had uncompressed files in a zip, and this one has gzipped files in a vgm7z. The reverse of what is desired. It might help to work in separate subfolders with duplicate files so you don't mix up the files and standards. If you use vgmtoolbox, compressed files remain compressed and uncompressed remain uncompressed. vgmtool r5 will gzip files when you edit their tags. There should be two archives: a vgm7z and a zip. 7zip the uncompressed vgms and zip the compressed vgms. Hope that is clear enough. You're almost there!

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14740 Location: London	Posted: Thu Jul 07, 2016 6:51 pm
	It's simple enough to repack it, I just automated that and there's nothing more to do. I really wish we had a shareable tool to wrap all this up, from tagging to packing.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Fri Jul 08, 2016 3:52 am
sherpa Joined: 28 Nov 2014 Posts: 365	sword dude, was it the japanese version you owned or the taiwanese? I hadn't come across a jp version so I used the tw. I wan't aware there was an existing dump, but there it is. I thought I had deleted drdevilfx's first pack, but it was in the recycling bin, and it had the japanese version's screenshot. As a friendly service I am including it here, properly processed. Maxim, I assumed based on your post that it was up already, but I see it isn't. I was holding back a bit, one because after the initial feedback, drdevilfx responded quickly and concisely, so I'm assuming a greater payoff of we just let him figure it out on his first pack, I'm sure he'll maintain proper standards moving forward. I'd prefer to avoid too much hand holding on his first pack. Admittedly, what remain are the least important aspects of making a pack, and arguably, as you indicated, they don't really make much sense in the modern day era as they did originally. The payoff isn't there as it is with vgms for other systems. The included screenshot is 210 x 210 and has been run by pngout. Screenshots are generally too small for there to be any difference in the space it takes on a hard drive (due to often being smaller than the cluster size) and arguably irrelevant on the bandwidth end due to current broadband availability in many countries. For future reference, I use irfanview since it includes a pngout plugin. It is a dll version, and probably older than the command line that was last updated in early 2015. There also seems to be a paid windows version, but it doesn't look like it's been updated in years. I took your screenshot ingame and: 1) resized the canvas (not image!) to 210 x 210 (we want it square) 2) I then pasted over the meaningless text with the background color. 3) I then cut and moved the remaining images to be a bit more centered 4) Finally I saved and exported the file using the pngout option in irfanview and used the default settings. Only the first and last steps are "required" for standards. The use of 210 was arbitrary, you could have resized everything 256 x 256 (canvas). 192 x 192 would have cut off the text. Feel free to repeat these steps yourself to get a feel. In some images, creating a proper image can take a bit more work due to having artwork in the background. I'll also include my own script for commandline, that I've been using since I started working on the latter end of the logging project. (think it was after Tom made his script for the "which gg games have stereo" project. It assumes that vgmtoolbox has been used. That 7za.exe is in the PATH variable, and that you have some version of winrar installed. Your uncompressed files have been run through gzip compression and are in the same folder. Also screenshots (there should only be one) are in the current folder as well as txt (only one) and in their final version. Finally, it renames the created archive by the base name used on the site and what will appear on the vgm page. It does not delete anything, but it can get a little messy if you don't have everything right and need to redo something. set "var=DokiDokiPenguinLand-SG" mkdir 7z mkdir zip move .vgm .\7z copy .m3u .\7z copy .png .\7z copy .txt .\7z rename .gz .vgm move .vgm .\zip copy .m3u .\zip copy .png .\zip copy .txt .\zip 7za a 7z.7z .\7z\* "c:\Program Files\WinRAR\WinRAR.exe" a -afzip -ep "zip.zip" ".\zip\" rename .7z %var%.vgm7z rename .zip %var%.zip rename .png %var%.png pause I don't currenlty have my system set up, but I was going to offer to do it myself if drdevilfx hit another snag and wasn't eager to try again. drdevilfx (and new users reading this post): ValleyBell has provided some useful info above. For others transitioning from VGMRips, you'll find the standards are a bit different here (no vgz files). One thing you may overlook if you are used to working on other systems is that vgm logs at smspower are frame accurate, not sample accurate as you may be used to. So, if you make your own logs in the future, excluding voices and rare events, you should log everything frame accurate (I recommend MEKA) and run everything through vgm_facc (Make frame accurate) until you really know what you are doing. For historical reasons that made sense at the time, the standard here at smspow is a "frame accurate" vgms, so updates occur 50/60 times a second, not x=<44100/s. You will not find single wait 7x commands or anything complicated generally, but does make logs a bit easier to read. The other things you are likely to overlook are how images are processed, how things should be named and the fact that we keep two archives here vgm7z and zip. We appreciate contributions and new work, so please keep at it, this feedback is not meant to discourage. SMSpower does have standards though, and I think most of us would rather pass on work that falls below a certain threshold (not the case here :) Hope this helps[/list] Doki Doki Penguin Land (SG-1000).png (1.24 KB)

ValleyBell Joined: 15 Sep 2009 Posts: 377	Posted: Fri Jul 08, 2016 5:44 am
ValleyBell Joined: 15 Sep 2009 Posts: 377	sherpa wrote you should log everything frame accurate (I recommend MEKA) and run everything through vgm_facc (Make frame accurate) You either log everything frame accurate or run vgm_facc. (because the former makes the latter redundant) The only emulator that makes logs that vgm_facc works properly with is Kega Fusion though. In all other emulators the timing drifts slightly, due to the frames not being exactly 1/60 second long.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Fri Jul 08, 2016 6:31 am
sherpa Joined: 28 Nov 2014 Posts: 365	Yes, I should clarify, that when you are a beginner in working with frame accurate files, you would also normally need to run facc because it's one thing to log a frame accurate file (emulator setting) and another for after you have trimmed and optimized it and have it remain facc. If you cut at samples based on the vgm2txt tool, you will not have this issue, but there are old tutorials here and elsewhere where you cut based on a wave file (I started this way) and you will need to run facc if it isn't frame accurate (good chance unless you're calculating start/loop start/loop end MOD 735/882==0). Some old files one this site are not actually frame accurate since they were made before you made your tool. It was a while before i stopped using facc as it was a while before I developed a process that prevented the issue in the first place. facc is not meant to be used on sample files or vgms where the adjustment is 200-300+ samples. And good point about emulators affecting the output and the timing drift. I did not know that about Kega Fusion, but it does log sample accurately (one of the reasons i don't use it often), and frame accuracy can be considered an imperfect, but "good enough" compromise between keeping file sizes small and accuracy that has been the standard on this site for a while. The drift you speak of does make work with some sets more complicated than it would normally be (no true loops in facc), though there are many other things that cause this as well (pitch effects, etc). I didn't want to get too detailed into this at this point, even though drdevilfx/HarmoDevil is not a beginner, but just pointing something out that may be an issue for people who are used to working with different tools and standards, and I have no idea how they work or where errors are likely to occur in their process.

drdevilfx Joined: 08 Oct 2015 Posts: 17 Location: Scotland	Posted: Fri Jul 08, 2016 7:19 am
	The VGMs are frame accurate, by the way. I was already aware of that standard (also the same on VGMRips) because the readme of the VGM Tool Collection tells me to make SN76489 VGMs accurate. Anyway, I'll post the vgm7z and zip later. Thank you for the edited screenshot.

drdevilfx Joined: 08 Oct 2015 Posts: 17 Location: Scotland	Posted: Fri Jul 08, 2016 6:04 pm
	I think it's now ready to be added to the site. I personally feel all posts above should be removed for convenience's sake.

sherpa Joined: 28 Nov 2014 Posts: 365	Posted: Sat Jul 09, 2016 3:58 am
sherpa Joined: 28 Nov 2014 Posts: 365	Congratulations. Your pack is up. Link in the first post. That's another thing that's different about smspower compared to VGMRips. They have a chatroom that makes it easy for community members to connect in real time (and chat history for those who want to catch up on what they missed). I think smspower had one ways back (might still have it) but most of the action occurs in the forums and updates to the wiki. VGMRips also has a section dedicated to new vgm packs/updates, but it gets routinely cleaned out and refreshed after a period of time or quota is reached. The only text that gets preserved is what is specifically selected by the pack author for preservation. Usually something short. Smspower isn't like that. Everything gets preserved, including messy little conversations and sometimes even poor behavior. In fact, deleting posts is strongly discouraged. It's not outright banned, as you do have the ability to edit your own posts (but please don't delete them). Admins can edit or delete anyone's, but generally they ask, a little short of insisting that you have good reasons for it. SMSpower has a lot of history, you can still go back and read interesting tidbits about the early days. The development section usually seems to get more action than the music section- many members here at smspower are very knowledgeable and comfortable working with hardware. If you have a project you are working on, it's not unlikely the answer is buried somewhere. It's happened more than a few times that I spent a good deal of time trying to figure out something that had already been discussed years prior, in equal or superior quality to what I had accomplished. It's a good idea to search the forums and other sections when you work on anything new. I don't know if you have the ability to edit your posts or post links. By the time I wanted to I already had the ability to do those things. Minor edits are ok, but if you start deleting your posts, there may be holes in the conversation, and that isn't want's preferred. Some people have done it though rarely. Sometimes it might be ok, such as if you were posting incorrect or irrelevant info, but i personally tend to leave such posts up as well, I think they all contribute-and it's probably better to err on the side of caution. Unlike the wiki, the stuff on the forums is not backed up. You can't view post history and you can't undelete. Once it's gone, it's gone. Congrats on your first pack at smspower. Once you've established yourself as someone who can go from a-z without guidance or correction, you will generally see less populated posts. It's something organic, not planned that tends to happen early on. You can also private message individuals if you want to ask something, but in general, if it is something that someone else might benefit from, I believe the general preference is that you post the question in the forums. Most of my posts here, have been generally targeted at you, but really for the benefit of anyone who comes after you. I originally also came from VGMRips. I originally intended to contribute for a short while, but the community grabbed me. On the other hand, If it weren't for the VGMRips chatroom, I would probably never gone far enough to be able to contribute here. The two sites have rather different flavors and advantages, and I'm glad they both exist. Welcome to smspower.

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Sat Jul 09, 2016 9:21 am
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	I have to admit that the flaws of the submission process on vgmrips are at least partially my fault. I wanted to mimic the "workbench" behaviour from tasvideos, and make it that a new pack is reviewed and approved in a new topic like it is now, but once it was approved, I wanted to make an automated post which said something like "the posts above this one are about the approval process, and the posts below can be used to comment on the finalised pack". In the end, I can't remember why we never implemented that, and simply decided to delete everything related to the approval and keep only the comments themselves. At another certain point I even considered a hybrid solution like Overclocked ReMix, where judging topics are locked and preserved, and separate comment topics are created, but we didn't take that route, either. Anyway, if I'm not wrong, Vampirefrog said he wanted to redo the entire thing in a specialised CMS (I used phpBB2 because it's the only community software I'm familiar with), and while I don't know its current status (the new enforced https makes it extra hard for me to browse vgmrips these days), I'm sure it will make a much smoother experience for future submissions. As for the different standard, I went with what made the most sense to me back then, we'll never find a "perfect" system which will satisfy everyone, just like Project2612 and smspower always had slightly different standards too. I still think it's good to use the vgm and vgz extensions to differentiate between compressed and uncompressed files, for example, just like I think screenshots shouldn't be resized or edited at all, but rather included "as-is" (e.g. 320×224 for a Mega Drive / Genesis screenshot). That said, the more, the better. A file can always be renamed eventually to suit someone's taste. If you're used to delve into hundreds of downloaded mp3s which range from "artist - title" to "title - artist" to "album - ## - title" to whatever, managing vgm packs from the three main vgm websites should be a piece of cake.

Forums

View topic - [VGM Pack] Doki Doki Penguin Land (SG-1000)