Skip to content

VGMToolbox

Technical discussion about the VGM format, and all the software you need to handle VGM files.

Moderator: Staff

  • snakemeat Offline
  • Posts: 22
  • Joined: 2012-06-04, 5:24:46

VGMToolbox

Post by snakemeat »

Updated VGMToolbox to support the latest VGM format revision (up to 1.61), so you can have a GUI batch tagger if you prefer that interface. Bug reports are always helpful.


Image
  • User avatar
  • ValleyBell Offline
  • Posts: 4768
  • Joined: 2011-12-01, 20:20:07
  • Location: Germany

Post by ValleyBell »

Very nice. I'm sure many people still prefer GUIs over commandline tools.
It works so well I'm probably going to prefer this one over VGMTool. (If it would just have drag and drop, I wouldn't hesitate a second ...)

Some things I've noticed:
  • Your update notes say "No more rebuilding the header.", but the header is still completely rewritten.
  • If you just care about the EOF and GD3 offsets instead of the complete VGM header, you don't need to care about the actual version of the VGM, since the GD3 tag has its own version.
    vgm_tag does it this way, btw.
  • [pack] This pack has a v1.70 VGM. Trying to tag it results either in a wrong version error, or in a bad file (with invalid data offset), if I change the version number to something lower. (This isn't actually valid, but it was good for testing)
  • Your source code mentions the loop modifier, but not the loop base and volume modifier.
  • Trying to move the cursor between the tag text boxes with the tab key makes the cursor jump around randomly.
An additional note, unrelated to VGMToolBox:
I'm not too strict about the versions. i.e. My players also accept v1.50 VGMs with an OKI chip, if the header is large enough.
(On Project2612 I once made a 1.50 VGM with a loop modifier, because foo_gep refuses to load 1.51 files, for example. Aside from the loop modifier, the VGM was a completely valid v1.50 one.)
  • User avatar
  • dissident93 Offline
  • Posts: 204
  • Joined: 2012-02-17, 5:54:01
  • Location: USA

Post by dissident93 »

ValleyBell wrote:Very nice. I'm sure many people still prefer GUIs over commandline tools.
It works so well I'm probably going to prefer this one over VGMTool. (If it would just have drag and drop, I wouldn't hesitate a second ...)
I'm not too keen on using CMDPROMPT commands and executables, so this is an excellent way to batch tag (since I do that loads). And while I don't mind not having a drag and drop feature, for it to be implemented would be even greater!
  • User avatar
  • neologix Offline
  • Posts: 211
  • Joined: 2012-04-22, 4:03:45
  • Location: New York, NY, USA

Post by neologix »

that screenshot's title bar shows an odd title; may want to fix that.

also, if vgmtoolbox supports drag-n-drop file loading i would recommend vgmtoolbox over the soon-to-be released vgmtool update for windows, as i'm not positive phoenix (the gui toolkit wrapper i'm using to make my update cross-platform) has drag-n-drop. i'll ask byuu abt that, tho.

vgmtool 3 will be cross-platform, however, and i hope to add command-line capabilities to it in the future so that someone can run it gui-less.
  • snakemeat Offline
  • Posts: 22
  • Joined: 2012-06-04, 5:24:46

Post by snakemeat »

ValleyBell wrote:Your update notes say "No more rebuilding the header.", but the header is still completely rewritten.
I left the old code in there, but the rebuild function now simply copies a byte array containing the full header to the output stream.
ValleyBell wrote:If you just care about the EOF and GD3 offsets instead of the complete VGM header, you don't need to care about the actual version of the VGM, since the GD3 tag has its own version.
I'll take a look at this idea.
ValleyBell wrote:This pack has a v1.70 VGM. Trying to tag it results either in a wrong version error, or in a bad file (with invalid data offset), if I change the version number to something lower. (This isn't actually valid, but it was good for testing)
I do have code to verify supported versions, but it may not be needed if the above idea works for me.
ValleyBell wrote:Your source code mentions the loop modifier, but not the loop base and volume modifier.
I got to adding up to v1.51 items and realized that rebuilding the header was unnecessary, so I have yet to add that stuff. Also, due to time constraints, I still blindly grab values in spite of the variable header size. In time both of these can be fixed, but should not affect the tagging functions since the raw header is simply rewritten.
ValleyBell wrote:Trying to move the cursor between the tag text boxes with the tab key makes the cursor jump around randomly.
I guess I should fix my TAB order, probably like that on most of my tools ;)


Regarding Drag and Drop, I'll look into that feature. I use it in a lot of the other tools in the application and prefer that method of interaction myself.

The title bar text is that way since I just use the application.config file to display the version info (check it out in the Sourceforge version). Since it's running in Debug mode (Visual Studio), I don't have the values set.
  • User avatar
  • neologix Offline
  • Posts: 211
  • Joined: 2012-04-22, 4:03:45
  • Location: New York, NY, USA

Post by neologix »

oh, and i got a response re drag-n-drop in phoenix apps - doesn't happen, and too much trouble for what it's worth. which means i'll have to put buttons/menu items to load files the normal way.
  • snakemeat Offline
  • Posts: 22
  • Joined: 2012-06-04, 5:24:46

Post by snakemeat »

Well, I've added most requests in the thread: Tab order, dynamic header sizes for unknown versions (i.e. 1.70), and drag-n-drop functionality.

BTW: I tested the Super Locomotive v1.70 track and it works well, but it seems like the 1.50 track, "03 Stage Clear" misbehaves when I trimmed the excess header size.

Anyhow, any feedback appreciated, since I had to make some design decisions to support the option of drag-n-drop and/or the type in folder name.

Grab a test copy here.
  • User avatar
  • dissident93 Offline
  • Posts: 204
  • Joined: 2012-02-17, 5:54:01
  • Location: USA

Post by dissident93 »

Awesome! It's working fine for me. Although I'm not sure if this is a bug or not.. With packs with specific song credits of two or more composers, it can be overwritten with just one of them when batch tagging the Game tag, for example.

Is there a way to have the option to blank the artist/ripper/date/system tags out during batch tagging? (Like how track tags do)
  • User avatar
  • ValleyBell Offline
  • Posts: 4768
  • Joined: 2011-12-01, 20:20:07
  • Location: Germany

Post by ValleyBell »

Ah, you're right - it uses the Loop Modifier (for 4x as much loops), so the header das 0x80 bytes. (The data offset is 0x4C.)
When you now resize the header (in this case from 0x80 to 0x40 bytes), you don't just need to adjust the data offset, but the loop offset as well and that is what went wrong.

If you simply add a dynamic header size for all versions >= 1.50, there should be no more problems.
  • snakemeat Offline
  • Posts: 22
  • Joined: 2012-06-04, 5:24:46

Post by snakemeat »

dissident93 wrote:Is there a way to have the option to blank the artist/ripper/date/system tags out during batch tagging? (Like how track tags do)
I've updated the interface to use checkboxes for all fields to indicate which fields to edit. So, where previously fields would be set to read-only or not, I now use checkboxes. In this way, you can select which tags to edit whether batch tagging or tagging a single file. I'd like to hear feedback, because if it seems positive, I may add the same functionality to the xSF tagger.

Grab a copy here.
  • User avatar
  • dissident93 Offline
  • Posts: 204
  • Joined: 2012-02-17, 5:54:01
  • Location: USA

Post by dissident93 »

Perfect, exactly what I wanted.

Post by Sonic of 8! »

The exe it self uses NET. framework 3.0/4.0?
オモいカルチャーをオモチャーと言う - 細野晴臣
  • snakemeat Offline
  • Posts: 22
  • Joined: 2012-06-04, 5:24:46

Post by snakemeat »

Sonic of 8! wrote:The exe it self uses NET. framework 3.0/4.0?
.NET 2.0 should be enough.
  • User avatar
  • RichterEX2 Offline
  • Posts: 191
  • Joined: 2012-03-30, 9:28:37
  • Location: Georgia, USA

Post by RichterEX2 »

Oh lord. Apparently there's a huge issue with the old version I had. After masstagging Sunset Riders...nothing played. Even causes foo_gep to crash with the resulting files. Here's what came out, but for now I'm going back with the newest version to see if that fixes things.

http://www.mediafire.com/?dcfcfl4d558vh0i
  • User avatar
  • ValleyBell Offline
  • Posts: 4768
  • Joined: 2011-12-01, 20:20:07
  • Location: Germany

Post by ValleyBell »

The last version I had, had a few problems with files logged by M1.
The header is a few bytes larger than it needs to be, so it recalculates the loop offset wrong in this case.

Sorry that I didn't report that earlier, but I forgot about it.
Post Reply