|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
VGM-to-MIDI Converter
Posted: Sat Aug 01, 2009 5:39 am
|
http://spheredev.org/~neologix/beta/vgm2midi.zip
requires the latest version of Sphere (1.5 or higher) Instructions are as follows:
So far, the YM2612, YM2413, and PSG chips are supported with support for the YM2151 coming shortly. This is mainly for me to organize my thoughts while I come up with a plan of attack for writing this in C++ for my VGMTool update. This will be cross-posted at Spherical Forums, SMSPower, and Project2612. ONE ISSUE: I've been told the resulting notation is "too flat" (possibly one whole semitone). I use the same algorithms as Paul Jensen in VGM2MID, so what am I doing wrong, if anything? |
|
|
Posted: Sun Aug 02, 2009 4:49 am |
Welcome back. But Johnnyz already did most of the midis based from all the VGMs, Also, Aren't you going to still develop on GBS2MIDI?
Pretty well done, too. |
|
|
Posted: Sun Aug 02, 2009 5:15 am |
thanks for taking the time to try it out! re gbs2midi, I still intend on picking that up again once I sit down and learn z80.
while midis may have been made from the majority of sms/gg vgms, there still remain two relatively untapped markets - genesis/md vgms & cps-1 vgms. project2612's selection of genesis vgms is pretty large and varied, so i'd expect it to be a while b4 the majority of those are converted and said conversions fixed (for dac & patch change instrumentation and such). as for cps-1 and such, unless mame crew implement vgm ripping for ym2151 (which would be much more likely if vgm had a way of storing the oki(m)6295 dac, probably as data type $01), the only way I know to have ym2151 vgms is to convert *.cym files in vgmtool, and the only CURRENT emulator I know that rips *.cym is kawaks. either way, ym2151 conversion will be implemented b4 I officially continue on the c++ version of the converter. has anyone figured out how to solve my "flat tuning" problem? I was informed on project2612 that it's likely the addition of certain pitchbending that is the culprit, tho i'm abt to go to sleep so I can't confirm it myself yet. |
|
|
Posted: Sun Aug 02, 2009 10:20 am |
If the music is using, say, 450Hz then that doesn't map to any standard MIDI note. If you map everything to the closest note, it'll sound bad, especially if it's using pitch bends or vibrato. So you use MIDI pitch bends to get the exact notes, even if they're not "in tune" with other stuff. | |
|
Posted: Sun Aug 02, 2009 6:16 pm |
I agree, and paul's algorithm in vgm2mid compensated for just such a problem by having it add a pitchbend event to account for the minor differences in tuning, so my rewrite of the algorithm adds the pitchbend too. the issue is supposedly i'm pitchbending to the wrong value (up to a semitone lower), so I need to figure out what went wrong, and I have a feeling I miscalculated the pitchbend (unless otherwise noted, js treats every number as a float, so I have to explictly convert certain variables to integer b4 certain calculations). when I turn on my laptop l8r i'll give it another once-over. | |
|
Posted: Sun Aug 02, 2009 6:55 pm |
I found the problem!!!
since I wrote the midi sequencer from scratch, I was wrongly dividing by 256 to get the pitchwheel msb instead of 128. I changed it and now it's fixed. will update the project link shortly. |
|
|
Posted: Sun Aug 02, 2009 10:31 pm |
http://spheredev.org/~neologix/beta/vgm2midi.zip
project updated to include the fix to the pitch bend problem. should be fine now. next release will (theoretically) have ym2151 conversion. after that, i may or may not add DAC & preset handling before moving on to the c++ version. if anyone knows of a simple, free, open-source c++ midi sequence class (handles midi events & can output to file) please let me know where i can get it, so as to speed up my development of the c++ converter, else i'd have to make one from scratch :/ |
|
|
Posted: Wed Aug 05, 2009 12:06 am |
ok, i'm a little stuck on ym2151 conversion. I have a really basic datasheet (i think from that datasheet website; I don't remember the url) and while it lists the registers, their use, and a rough diagram of usable bits, there's nothing useful to me beyond that (eg. what the bits actually are, register values & their relations to final output, etc).
basically, what I need is a ym2151 equivalent to maxim's ym2612 & ym2413 docs. can anyone help? |
|
|
Posted: Wed Aug 12, 2009 3:48 pm |
It's funny that you should mention pitchwheel problems. I've been (slowly) working on VGM2MID, and I just fixed a (stupid) bug related to pitchwheel events.
As for "off-tune" notes in general, for some reason, many games use a value other than 440 for note A4. It doesn't make a lot of sense, but it seems to happen in a lot of cases. The result is that most notes from the various synth chips don't match up exactly with Midi notes. The only obvious solution is to adjust the pitch after every Note-On event. @neologix: By the way, I'm having problems handling VGM wait commands. Most of the VGMs out there these days appear to be sample-accurate, rather than frame-accurate. I'm having trouble finding a way to map the sample-based waits in the VGM files to pulse-based waits in the Midi files. I tried to increase the number of ticks per quarter note to make the waits more accurate, but most files either come out with an irregular tempo or just too fast. Any insights? |
|
|
Posted: Wed Aug 12, 2009 5:10 pm |
You can get pretty close to the sample rate (44.1kHz) by using a delta-time division of 0x5622, or 22.05kHz (half). | |
|
Posted: Wed Aug 12, 2009 6:37 pm |
I found the "standard" tuning table used by a large percentage of SMS games, which is a little out-of-tune and uses bad rounding to make matters worse.
An unreleased prototype of VGMTool I wrote had a sample-accurate to frame-accurate converter. The problem was, it was horribly buggy. But here's the algorithm: for each (size in [735, 882])
allocate array[size] for each wait command in VGM file figure out the total time at the start of it increment array[time % size] end for check if there's disparity in the array values (suggesting we picked the right size) find highest number in array pick point size/2 away from there as the "frame split point" end for for each (VGM command in file) round to (time - frame split point) % size end for Horrible pseudocode :) If VGMTool could do that for you then you wouldn't have to bother... |
|
|
Posted: Wed Aug 12, 2009 11:23 pm |
based on your old work, i initialize the midi w/30 ticks per frame & a time signature of 4/4, 24 (0x18) ticks per click, 8 32nd notes per beat (basically, a standard time sig declaration); i also have "wait N samples" add a delta time of N/FPS, w/FPS being 44100/the vgm's source frame rate (50 or 60; if 0 use 60). it seems to work for me w/any vgm i throw at it w/any variable wait event. i'm quite sure i'll do cleaner looking time conversion code in the final version. as for pitch, i've pretty much resigned myself to adding minor pitch bend as needed before note ons. i found a fuller ym2151 datasheet on neill corlett's site, so unless someone has a decent ym2151 fnum-to-hz algorithm i'll have to really study this thing. ... anyone? |
|
|
Posted: Thu Aug 13, 2009 8:05 am |
On the YM2151 it's actually quite simple: To bits 0..3 of register 0x28+chn you write the note number, which is the same regardless of the octave. The note sequence from C to B is 14,0,1,2,4,5,6,8,9,10,12,13.
To bits 4..6 you write the octave number, or octave-1 if the note is 14 (C). That's how I do it when I generate VGMs that are using the YM2151 with my MML compiler at least, and it appears to work fine. |
|
|
Posted: Tue Sep 15, 2009 10:48 pm |
alrighty! the project has been updated, so please re-download it.
http://spheredev.org/~neologix/beta/vgm2midi.zip biggest update is the addition of basic ym2151 conversion. i also fixed a potential bug where PAL vgms would be converted to too fast midis. this is now also cross-posted to spritesmind. |
|
|
Posted: Sun Sep 20, 2009 9:41 am |
Hello, I'm new here.
I downloaded the source of the old vgm2mid years ago and worked on it. My version supports: - 4 different MIDI Resolutions up to 22050 - a good Note On/Off-Detection for the square channels - DAC support (one like gym2mid and one using pointers to the sound data block) - a corrected calculation of the delay values (only noticable with high resolution rates) Do you want to see it? |
|
|
Posted: Wed Sep 23, 2009 4:32 am |
Hi ValleyBell. Welcome to the forums.
I'd be interested in seeing your work. I never thought people would be creating derivatives of my project. :) |
|
|
Posted: Thu Sep 24, 2009 11:32 am |
I would love to be able to choose which instrument I would like to use.
The drums would also be split into it's individual tracks and not mixed together, |
|
|
Posted: Thu Sep 24, 2009 4:14 pm |
That's my version of vgm2mid.
It includes the full source for VB6 and some examples. Most changes are commented. There's no YM2151-support. Many DAC-Drums have unique values, so I collected some. (see Prog\InstrumentTable.txt). The DAC-Notes using the sound-data are written to channel 16. I know the zip-file huge (there is a 5MB gym and a 6MB vgm example-file). Do you like it? Feel free to use the code. |
|
|
Posted: Sun Sep 27, 2009 1:50 pm |
ValleyBell, that sounds nice sir! especially in your examples the PS title sounds good!
EDIT: Heres an uploaded version of Shining Wind from the FM version of OutRun 3D. It could sound poo on your soundcard but I use an external MIDI controller here (yes its XG capable). This was made with Paul Jensens edited software :) |
|
|
Posted: Sun Sep 27, 2009 2:05 pm |
Awesome work, ValleyBell. Your implementation is very promising, AND it doesn't rely on external dependancies. I officially recommend it to everyone who is going to read this thread from now on. | |
|
Posted: Mon Sep 28, 2009 2:29 am |
i like it very much! it'll definitely help me towards fixing up DAC implementation and i'm already changing up how i'm implementing ym2612 patch changes. | |
|
Posted: Wed Sep 30, 2009 7:46 am |
I haven't done much editing to this midi but this is the result I got from using ValleyBell's software! I think it came out excellent.
This is the village music from Landstalker. Thanks again! I'll be putting this thing to GREAT use. |
|
|
Posted: Wed Sep 30, 2009 6:39 pm |
I really like the Shining Wind-MIDI. I have a soundcard with good GS/XG-support, but I prefer the FM-Synthesizer. It sounds like a real VGM.
This new version now supports the YM2151 (ported from vgm2midi by neologix - it was a bit difficult to read the code, because there are no spaces). You can even turn the channels off, if you turn the YM2413-channels off. Also new is: - the complete GD3-Tag is now written to the MIDI - Winamp-compatible loop-markers (Winamp has his bugs - just read the line 125 in Midi_f0.bas) - GG Stereo is supported - the sound-data-detection was improved a little - other less important changes By the way: This day I added GYM-Logging to the MAME-Emulator. Does anyone know this song? Sorry for the bad gym, but the game had 2 chips and the data was merged into one file. MAME seems to send many useless commands. I removed them (90% of the whole file!) from the gym and the 16-open.vgm, because they repeat themself many times every tick. @neologix: When does the C++-Version come? I can write C++-Programs, too. I can write MIDI-functions, if you need help. |
|
|
Posted: Wed Sep 30, 2009 8:59 pm |
Many music engines spam the chip with unnecessary data. It's not necessarily MAME doing it.
Why log to GYM instead of VGM? You lose timing accuracy by doing that. |
|
|
Posted: Thu Oct 01, 2009 3:11 am |
re c++ version - i had started work on it on my macbook, but i had to stop cuz its battery decided to inflate on me, so now i can't even put it in the thing, so i can't use my macbook at all. the plan is for it to be command-line first (as well as all the other functions of vgmtool) so the mac version (and eventually the windows & linux versions) of vgmtool can simply act as a gui front-end. unless i found a ready-made class file, the midi class would look almost exactly like the js version i wrote. it was gonna process the vgm as follows:
* if a certain text file didn't exist, first pass would read all the instrument presets & the "data seek to offset" events and write to a text file; a button would exist to let you do this first pass at any time * once the text file is confirmed to exist (it would either be one text file per song or it'd be the song's section in a more "global" text file) the gui would enable two buttons: ** one to open up a dialog - the presets would be previewable (using eke's current genplus-gx ym2612 code) and you'd choose what gm patch it would map to from a dropdown, the dac events from each offset would also be previewable and you could map those to drum events (this would probably be expanded to allow mapping to a note on any instrument, not just drums, for stuff like the orch hits at the beginning of phantasy star 4's "meet them head-on!"); the dialog would have a save button that updated the text file (or the appropriate section of the "global" text file) ** second button is the official convert button; the final conversion would read the preset & DAC note values from the text file and during conversion apply the values as needed that would be the procedure. my bigger concern was the midi functionality. |
|
|
Posted: Wed Oct 07, 2009 9:05 pm |
a small update
The old version cuts the notes of the VGM logs from Sonic Pocket Adventure. |
|