vgmrips

If I use VGMToolbox to edit the text tags in the file, it seems to do something bad to the loop, but I'm not sure exactly what the problem is or how I should correct it.

Example files: https://dl.dropbox.com/u/883356/blktige ... xample.zip (dead link)

In this example, blktiger_24.vgz is the file built by my script starting from an M1 dump, and going through various automated steps to loop, trim, clean and compress the file. At this point the file seems fine if I use vgm_ptch -check:



Now, if I open VGMToolbox (r146) and simply update this file's text tags, vgm_ptch will tell me there is an error. Example file blktiger_24_tagged.vgz. I have done nothing but update the text-- what has happened to the loop?



Does anyone know what has happened here? What is the appropriate way to fix this problem? Is it a good idea to let VGM Patcher fix it (F? R?) or should I do something else?

It happens because M1 writes VGMs with headers that are larger than they need to be. (M1 writes always 0xD0 bytes, but v1.61 needs only 0xC0. This is allowed by the VGM spec., btw.)
When writing the tags, VGMToolbox resizes the header and recalculation of the loop offset goes wrong.

Fixing it with vgm_ptch should be perfectly fine, but use R (relocate) to make it search for the correct offset. F recalculates the loop length.

Thanks!

BTW is there something better than VGMToolbox for tagging?

Also, would running vgm_patch -MinHeader before tagging prevent this issue?

Yes, that should prevent the issue.

I usually use a combination of VGMTool2r5 and bat-files with vgm_tag to tag my files.
It's not better, just an alternative way.

I'm curious since I've also bee using VGMToolbox for tagging, does this happen with other loggers? Your MESS/MAME mods specifically? Or does that happen only for M1 logged VGMs?

Is this how vgm_ptch -check's fixes work?

R = rebuild loop offset based on loop sample length
F = rebuild loop sample length based on loop offset

@rainwarrior: That's exactly how it works.

@Knurek: The latest MAME/MESS versions adjust the header size based on how many bytes are needed. For the NGP chip that's 0x40 bytes, smaller than VGMToolbox may expect. (not sure)
Ootake writes 0xD0 bytes, too, because I forgot to fix the typo. (MAME/MESS get around that because of dynamic header sizes.)
dro2vgm and openMSX and the Gens/GS r7 VGM mod should work.

Okay, I've compared VGMs before and after writing data with VGMtoolbox, only thing that changes in the header are byte 0x05-06 (filesize, I guess).
False alert, is what I'm saying. Thanks though

As Valley Bell identified, it turns out that VGMToolbox was not updating the Loop Start Offset when trimming a header to reflect the header size in the spec for a specific version (0x80 in this case since the attached files are v1.51).

I've decided to take some advice Valley Bell gave me a long time ago and just leave headers for versions v1.50 or greater alone. Anything in between offset 0 and the data start offset will be considered a header. This will allow flexibility for any typos such as this one as well as minimize the possibility for my own oversights regarding header value changes (like I did this time and in the past).

I was hesitant to do it in the past because I didn't like the idea of VGMToolbox outputting files that did not comply with specs (like the attached files, v1.51 files with non-zero values in the reserved section, etc...). I also wanted to be able to handle a scenario where someone may actually put the Gd3 tag in between the header and data sections.

In any case, I'd rather have a useful VGM tagging application, than something that falls into my own opinion of "correct." Also, no one has ever put the Gd3 tag between the header and data sections, so I'll have to hope that pattern continues. With that in mind, I've uploaded VGMToolbox r926 with the revised algorithm in place. You can find it at Sourceforge.