How the VGM is Logged.

It may seem curious that the speed of the emulator will not affect a vgm output as it might if you were recording it from your computer or a live system. What you hear is not necessarily what you get. You can log as fast (1/9) or as slow (10hz) as you want and the output will not change. In fact if you open the Technical Information window (Alt+I) in MEKA, and look at the row that says PSG, the information listed there is what is logged to the vgm every 735/882 frames. If you see several commands written to the same register within a frame (usually happens close to the beginning) only the last ones written to the register count. If you set a breakpoint in meka's debugger to the UpdateSound function, or the audio port $7f (b io 7f) you can step through and match what you see in the technical window to the output. If you test with a track that always logs the same, you can log first and then compare what you see to the output after you've run vgm2txt with the vgm. Then reload your save and step through with the debugger, watching the values change. In some cases there might be minor differences in the pitch or volume values. The tone data is organized as a 10bit hex value. The lower 4 bits (max $F) are the latch data and the upper 6 are the succeeding value (max $3F). So if you were to see $50 8B 50 0A in the vgm txt or in a hex editor, you would expect to see Tone 0: 0AB, i.e. 00B (low 4 bits) + 0A0 (upper 6) followed by whatever the volume was set to. In order to understand this, please consult the VGM Spec (focus on 1.10 and commands for the SN76496. Info on that chip is available here). Vgm2txt helps considerably by translating the binary information into understandable terms. Even so, you may have a difficult time understanding these pages unless you understand binary and hex somewhat. Look up sources to study if you don't and want to understand more about the format.

How accurate is Frame Accurate?

VGMs at smspower are meant to be in frame accurate format. This may sound as if the output is extremely precise. In practice, what this means is that all events occur at 1/50 (Pal) or 1/60 (NTSC) of a second. This means that all properly logged non voice/sample accurate vgms have loop lengths (in samples), and total samples that are evenly divisible by 735 or 882 (frames). In practice, it also means that the vgm format is not 100% what it would be in the original. Pragmatically, this is not necessarily meaningful, and too subtle to notice. It is difficult to notice anything under .10 of a second (4410 samples) and the variations are sometimes far less than 735 frames. Other sites do not do this. Sample accurate VGMs are expected for vgm standards on other sites and other systems outside SG/SMS/GG. But here, frame accurate samples are expected for everything that isn't voice because...standards. It's possible this was originally done to make vgms easier to work with and to decrease file sizes. This was before any of the modern vgm tools were available. You can always log a sample accurate vgm and compare the output. Unless you are going to be combing through differences at the sample level, you will not notice. In fact, there are many cases where vgm tracks do not have loops that can be detected by the loop finder. They do not loop evenly, mostly because most tracks have volume shaping going on that doesn't sync with the tones. So while the tones may remain the same from loop to loop (sometimes not exactly due to pitch shifting) each loop may in fact differ subtly in ways that are difficult to detect unless you are comparing wave files closely. So in practice frame accuracy doesn't hurt anything. But it is a standard of this site, so please follow it if you intend to submit any work to the vgm section.

If you use other emulator's to log, some like FUSION produce sample accurate vgms. It will be good to check and run everything through the VGM Frame Accuracy tool (vgm_facc) to make sure the pack complies with the standards on this site.


Return to top
0.128s