VGM Tool Collection
All you need to work with VGMs. Last update: 2022-12-30
Technical discussion about the VGM format, and all the software you need to handle VGM files.
Moderator: Staff
- ValleyBell Offline
- Posts: 4791
- Joined: 2011-12-01, 20:20:07
- Location: Germany
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.
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
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
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.
Code: Select all
vgm_trim mysong.vgm -50000 0 -1
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?
http://vgmrips.net/forum/viewtopic.php?f=17&t=2239
Thanks!
I'm running into a few issues with using vgmmerge.exe.
Can you check out my WIP thread for Violent Storm?
http://vgmrips.net/forum/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.
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.
- Attachments
-
- DACBOTH.vgm
- (35.9 KiB) Downloaded 377 times
-
- DAC2.vgm
- Has space at the front to accommodate [DAC1.vgm].
- (18.56 KiB) Downloaded 366 times
-
- DAC1.vgm
- Has space at the back to accommodate [DAC2.vgm].
- (18.56 KiB) Downloaded 419 times
-
- TONEBOTH.vgm
- (1.15 KiB) Downloaded 379 times
-
- TONE2.vgm
- Has space at the front to accommodate [TONE1.vgm].
- (694 Bytes) Downloaded 402 times
-
- TONE1.vgm
- Has space at the back to accommodate [TONE2.vgm].
- (691 Bytes) Downloaded 378 times
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.
Code: Select all
0x8n : YM2612 port 0 address 2A write from the data bank, then wait
n samples; n can range from 0 to 15. Note that the wait is n,
NOT n+1. (Note: Written to first chip instance 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.Tom wrote:Either use v1.60 or limit yourself to one DAC only.
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.)
- Attachments
-
- DACPBOTH.vgm
- (12.2 KiB) Downloaded 335 times
-
- DACP2.vgm
- (8.67 KiB) Downloaded 361 times
-
- DACP1.vgm
- (3.83 KiB) Downloaded 356 times
- ValleyBell Offline
- Posts: 4791
- Joined: 2011-12-01, 20:20:07
- Location: Germany
Summary of the vgmmerge fixes/changes I just did:
- fixed a typo that prevents the GG stereo command from being changed
- 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.Tom wrote: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.
- ValleyBell Offline
- Posts: 4791
- Joined: 2011-12-01, 20:20:07
- Location: Germany
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)Tom wrote: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.
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.
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.
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've included an attachment for reference. It's "Stage 1, 4" from Sonic Boom; I'm working on that game's VGM rip.
- Attachments
-
- stage14_trimmed.vgm
- (1.03 MiB) Downloaded 369 times
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.
Check out my Soundcloud.
I might get back to VGM ripping someday.