vgmrips

VGMTrans feels like a waste. Nothing happens when attempting to open certain files.

VGMTrans doesn't work with VGM files. Look at the readme for supported formats. Try GBA/DS ROMs and SPC files. And they only work if the sound driver is supported. Some CPS2 QSound games also work, but the ROM filenames inside the zip have to exactly match the ones in the xml.

ES5506 is not supported?
vgm_cmp and vgm_sro does not work.

Sorry, but yes - there is no support for ES5505/06 at all.
I made a few test rips (to verify that they play fine in VGMPlay), but haven't worked on the tools yet. (Especially the ES5506 is going to be a challenge due to 24-bit data split over multiple VGM commands.)

Okey, May I then submit the ES5505/06 packs? (Do not optimize)

ES5506 rips from SSV games work fine (Twin Eagle 2, Dyna Gear, Vasara etc). I would guess other games like Macross Plus would also work.

Taito ES5505 do not work at all (not only are the files huge, but they play incorrectly), so don't bother.

Give me two weeks and I'll try to at least get vgm_sro to support the ES5506.
Looking at the ES5506, I'm thinking about adding an additional VGM command for them. (And I need to correct myself - commands have 32-bit data, though that doesn't really make a difference.)

Okay, I will wait.



It is probably Only the Super Real Mahjong P7 is not correctly play in SSV games.
Sample vgm :Super Real Mahjong P7 - Opening
http://www.mediafire.com/download/8pvl6 ... srmp7_0.7z

Sample mp3 :Super Real Mahjong P7 - Opening
http://www.mediafire.com/download/c54wc ... mp7_op.mp3
The source of the MP3 is a board recording of Nico Nico Douga.
http://nviewer.mobi/player?video_id=sm9334332

When comparing both vgm is missing is sound.

It seems like that game uses bank switching for the ES5506 samples. Even though there seems to be code in MAME for it, it does not sound properly there either. Strange...

I just updated the tools in the OP.
Not much has happened really, except for a few fixes, Virtual Boy VSU support in vgm_cmp and SCC(+) support in vgm_trim.
It should also warn you about a broken zlib DLL now instead of silently generating broken VGMs.

ES5505/6 support didn't made it, sorry. (I partly added it to vgm_sro, but the ROM banks are handled in a very crappy way currently. I'd like to redo parts of the emulation here.)

Thanks for the updates! ^^

EDIT: I just tried the opl_23 tool and I finally figured out how to successfully convert OPL2 VGMs into OPL3. I may begin publishing my own DOS packs soon!

With this particular VGM I tried converting it to OPL3 and it took away more than half of all the sound, so I decided to leave it as OPL2.

BUT, when I trimmed the OPL2 VGM, it did that same thing, more than half of the sound just disappeared.

Did you happen to log that song with the "normal" DOSBox instead of the modified one we have on vgmrips?
The "normal" DOSBox uses a vgm_cmp like algorithm* when logging and that often causes instrument definitions to be incomplete even when starting a song. (and it sometimes screws frequencies up when looping)
The trimming points look good from what I saw by comparing the VGMs via vgm2txt.

Anyway, why were you trying to convert OPL2 to OPL3? There is really no reason for that. If DOSBox writes a DRO for OPL2, the sound uses none of the OPL3 features, so it plays back on identically OPL2 and OPL3.
(And opl_23 can only convert between DualOPL2 and OPL3 anyway.)

* in fact, the VGM you posted gets only 3 bytes smaller when using vgm_cmp on it, so I'm pretty sure DOSBox did some optimization while logging.

I believe I was using the one posted here in the forum, but I'll download it again just to make sure.


Because when you set OPL mode to auto (which I think is already like that by default), DOSBox behaves with the kind of backward compatibility that a Sound Blaster 16 with the physical OPL3 chip does when playing OPL2 music. It does sound differently in DOSBox than it does when you convert a freshly logged .DRO to .VGM.
Changing the OPL mode to dualopl2 did it for me. I did some little testing with the intro music from Darkseed, and converting dualopl2 to opl3 gave me the sound I was looking for - what you actually hear while playing the game in DOSBox with the OPL mode set to auto, and I think, the sound you'd get if you played the game with a Sound Blaster 16 with a physical OPL3 chip instead of an OPL2.


In that case I'm definitely going to recheck the download, or use the SVN build if the problem persists, lest you don't recommend it?

EDIT: I downloaded DOSBox again from here and the problem persists. Here are the files attached from my second attempt at trimming it (at which I realised that the actual cycle was a bit ahead of where I had set it - not that that made much of a difference).


EDIT #2: This particular DRO/VGM log worked with the DOSBox SVN Build R4000 available here. This particular build waits until receiving any OPL commands, resulting in an automatically trimmed DRO log (at the beginning), to which I added a 3072 samples silence just in case.

Hmm... there could also be the rare case of the sound engine itself optimizing out commands. (Which seems to be the case for this intro.)
In that case, you can use to write additional data to the beginning of the VGM.

About the SVN build: The detection of DualOPL2/OPL3 in the official build is weird and broken, that's why I don't use it. It also doesn't always trim correctly. (It worked fine in your case.)

There is no need to add additional silence to the beginning. You shouldn't do that as there are no benefits. (The sound chip doesn't get more time to initialize, because initialization just takes place at a later time, just in case that's what you wanted.)


There should be no differences between using the OPL2 itself or using the OPL3 in OPL2 fallback mode. If there are audible differences, it's probably due to emulation oddities.
Anyway, feel free to post examples. ("oplmode=auto" results in "oplmode=opl3" for SB16, btw.)
Using DualOPL2 just duplicates all commands in most games. I think I've only seen proper DualOPL2 support in XMI-based games so far.