vgmrips

I just tried your VGM sample with by SB16 (with OPL3 chip) and to my surprise the untrimmed VGM logs sounded right sometimes and sometimes they didn't.

I found out that if I seek +5 seconds at the right time in your sample of Friend, I get the chip to a state where the drums sound correct. Then all songs sound fine. ("fine" like "in the OST")
If I do it wrong, both songs sound bad.

Sorry, but there's nothing I can do about that right now. If I have lots of time someday, I'll try to investigate why it happens and how to maybe get it right.

And here comes the updated VGM Tool Collection. I planned to update them a few days earlier actually, but I wanted to check a few things before making the update.

Updates:

• added FM ADPCM (YM2608/2610), K054539 and K051649 support to vgm_cmp
• added UPD7759 support to vgm_sro
• fixed a tiny bug where vgm_sro didn't stripped DeltaT data
• added K051649 and OKIM6295 support to vgm2txt
• fixed vgm_ptch, doesn't destroy v1.70 VGMs anymore
• fixed detection of dual v1.10 chips in vgm_ptch (for version check)
• added version check to vgm_ptch
• fixed dual-chip mode for some chips (that were never used in dual-mode) in vgm_sptd
• added special split option for Hexion
• added GBGBC shortcut (and some undocumented features) to vgm_tag
• added OKIM6258 and K054539 support to vgm_trml*
• fixed dual-chip support for some chips in vgm_trml* (only related to chip save-states and restored commands)
• added "-silent" option to vgmlpfnd and made it ignore OKIM6258 data writes
• added dual-chip support to vgmmerge
  Note: vgmmerge supports only v1.51 chips + NES + GameBoy
  Data blocks and DAC Streams are merged correctly, too.

* trimming library used by all trimming tools (vgm_trim, vgm_sptd, vgm_spts)

Download is in the OP.

Happy ripping!

The obligatory field test with vgmmerge:
https://dl.dropbox.com/u/1287967/djtBMX ... getest.vgm

2x YM2612 + 2xSN76496 (where one PSG chip is in GG stereo) (VGM Music Maker)
1x GB DMG (DefleMask)

Also I think I found a bug with merging 2xYM2612 with respect to DAC. Here are my files: https://dl.dropbox.com/u/1287967/mergeglitch.rar

d1 and d1-2 have the same bank
d2 uses a different sample bank
merge_1 and 2 is d1 and d2 merged in different orders.
merge_3 and 4 is d1 and d1-2 merged in different orders

_________________
-dj.tuBIG/MaliceX

Sorry, but it's impossible to merge v1.50 VGMs that use data blocks due to the way they work.
Merging v1.60 VGMs into 2x YM2612 DAC works. (see this mid2vgm 2612 merge test)

Confirmed, thanks for the clarification.

On that note, it probably should be noted that such merges are currently subject to each YM2612 log must use the same sample bank. (See this amended example, exported as v1.60: https://dl.dropbox.com/u/1287967/mergeglitch_take2.rar)

_________________
-dj.tuBIG/MaliceX

The problem is not the sample bank. The problem is, that the commands for improved DAC handling in v1.50 can use only the first chip, so the DAC commands for both chips end up played on the first one.

But yes, I should make a note that it is impossible to merge two v1.50 YM2612 DAC VGMs.

I'm having issues with vgmmerge!

I tried merging two 2A03 VGMs together, but the result isn't quite what I expected. Here are the files.

It looks like it actually adds a second 2A03, but crams all the writes to the same chip instead of keeping them separate like it should. Not sure if I'm doing something wrong or not, but I thought I'd report this problem.

I didn't know if is a bug with the game or with vgm_sro, but in Dynamite League, it didn't strip OPNB Delta-T data (unused, but didn't remove them). Maybe has a custom bank-switching for the YM2610 Delta-T Sample ROM?

Ah, sorry. I made a small typo when checking the commands.
I fixed the bin and src archives now. Please download again.

Could be a game bug. (Puzzle de Pon had one of these bugs, too.)
Can you post a sample file, please?

I can confirm that vgm_sro works correctly with Dynamite League.
The game has no DeltaT sample data at all, so there's nothing it can strip (or leave). It has some DeltaT commands to the control register that cause a few warnings though, but the START bit is never set.

You don't need to worry unless you get an "out of range" error.

Thanks.

YMF278B problem of vgm_sro.
Seems to be not working, Are there any plans of support?

This VGM sample, Strikers 1945 - Title:
Edit : I deleted the file

This VGM sample, Strikers 1945 II - Title:
Edit : I deleted the file

This VGM sample, Strikers 1945 III - Result:
Edit : I deleted the file

Same with 315-5560 (MultiPCM), it didn't optmize the Sample ROM and M1 gives two VGM files per track instead of one only (game tested: Virtua Fighter, probally other Sega Model 1 games too).

Yeah, the support for YMF278B and MultiPCM is pretty lacking.
I recommend to rip other games until I get time to work on their support.

They are a bit more difficult to handle than most other chips, because they have a Set-Instrument-command that changes almost all registers for the respective channel.
The chances are better for MultiPCM, btw, since I already made rips of OutRunners (see my WIP topic) and they're just waiting that I care about them.

btw: The reason vgm_sro doesn't support the YMF278B is, that the only rips I made with that chip were made with openMSX and require the yrw801.rom.

vgm_sro Bug?
Loop offset is E4 FF FF FF.

This is the data before using,
Chain Reaction - Cast Entry:
Edit : I deleted the file


Submitted pack I was fixed.