vgmrips

It really was about time to release an updated toolset.
There are many additions and fixes to the more popular tools like vgm_cmp, vgm_sro and vgm_trim, like support for most of the new VGM 1.71 chips.
On the other hand, tools that are less likely to be used (like vgm_dbc and vgm_smp1) didn't have any development during the last few years.

But at least I fixed dro2vgm's 1xOPL2 conversions and vgm_trim may now warn you about cutting off the end of notes in non-looping songs.

You can download Win32 binaries here.

Hi, I've started a VGM rip and am wondering how to do two things:

1. How do you increase the gain for a specific VGM? Is vgm_vol.exe the right tool to use?
2. How do you add Japanese tags into the GD3? I think this may be specific to the Windows Command Prompt not accepting unicode by default. Any tips here in order to paste Japanese text?

Edit - I found answers to the questions above:
1. Answered here
2. Answered here

Is there a way to join VGMs together?

vgmmerge.exe merges two or more VGMs together, but I'm looking to join VGMs back-to-back to create a new file.

You can insert a delay into the second song using vgm_trim like this:

Change -50000 to the length of the first song (in samples). A negative value inserts silence to the song.

After that you should be able to join the VGMs using vgmmerge.

Thanks for replying, ctr.

I'm running into a few issues with using vgmmerge.exe.

Can you check out my WIP thread for Violent Storm?
viewtopic.php?f=17&t=2239

Thanks!

So there are two issues I've run into with vgmmerge.exe (the version from the 2015-07-25 pack).

1) When merging two Game Gear .vgms, it seems like only the panning commands from the first .vgm specified in the command line are acknowledged. (E.g. the attached TONEBOTH.vgm is the result of running [vgmmerge TONE1.vgm TONE2.vgm TONEBOTH.vgm]. If I switched the TONE1 and TONE2 files in that command, TONE2's panning commands are acknowledged instead.)

2) When merging two Genesis .vgms, sample playback seems buggy? The attached DAC2.vgm has a space at the front to accommodate DAC1.vgm's content, but the DACBOTH.vgm generated with vgmmerge.exe seems to skip the beginning space and instead try to play both tracks at the same time.

2: you can't use the DAC of the second YM2612 in a v1.50 vgm file, as seen in the format specifications:Either use v1.60 or limit yourself to one DAC only.

Note that changing the vgm version by hand from 1.50 to 1.60 won't work. You need to use the DAC stream control instead, which might or might not be supported by your tracker of choice.

1: this is actually interesting instead, it seems that vgmmerge mistakenly writes a 4F command instead of a 3F for the GG Stereo of the second SN76496 chip.

_________________
Also known as nineko.

Ah, thanks for the reply. Switching the .vgm export setting in VGM Music Maker 1.1 from 1.50 to 1.60 fixes my second issue.

EDIT: OK, so here's something else. The two attached Genesis .vgms (1.60 this time) are meant to play different samples at the same time, but vgmmerge.exe's result sounds like the wrong samples are being called? (E.g. where the pedal hi-hat sample would play in DACP2.vgm, a part of the crash sample seems to play instead in the merged file.)

Summary of the vgmmerge fixes/changes I just did:

1. fixed a typo that prevents the GG stereo command from being changed
2. added a warning that merging 1.50 VGMs doesn't work
   added a warning about lack of support for the 0x93 command (which VGM MM uses to play DAC sounds)

I wonder if as a temporary workaround you could get away with regular v1.50 DAC in the first file and v1.60 stream control DAC in the second file. It would be bizzarre and wrong on so many levels but it should theoretically work.

_________________
Also known as nineko.

Thanks, ValleyBell.

I tried this, but there's no difference in the output file compared to before... aside from some of the samples sounding erroneously high-pitched.

The main problem is that I fix none of the offsets - neither for the E0 command (set data block offset) nor for the 93 one (play by data block offset). vgmmerge currently merges only DAC streams properly that use the 95 command. (play by sample ID)

Bug report:
After adding vgm_cmp into DefleMask some users started to report strange stuff going on in the Hardware sweeps of the Game Boy, the thing is vgm_cmp doesn't take into account the Hardware Sweep changes. It simply removes LSB writes of the first square because they are equal to its "stateless register value", but the HW sweep actually changed that value under the hood.
This isn't noticeable on the emulator used by in_vgm/VGMPlay, but can be heard on the actual HW and Gambatte emulator. It is a mix of bad emulation and a bug in vgm_cmp.

I've fixed it on Defle by forcing vgm_cmp to always write the LSB of the first square.

I'm afraid this will require to re-rip every game using hardware sweeps, because they will not play correctly on the actual hardware.

_________________
DefleMask Tracker

When I used vgm_trim on a YM2151 VGM, it stripped Channels 2-8. Why is this happening? Is it a bug, or am I doing something wrong?

I've included an attachment for reference. It's "Stage 1, 4" from Sonic Boom; I'm working on that game's VGM rip.

_________________
I'm HarmoDevil. Formerly Dr Devil, but I still use the drdevil username here.

Check out my Soundcloud.

I might get back to VGM ripping someday.

It seems like you put your trim point after the game writes the patches for those channels. Try an earlier trim point, I usually put my trim point around 500-1000 samples before the waveform appears. You can also try vgm_sptd.

If none of this works, please send the original file as well.