Thank you for sharing. A couple of questions about the VGM format from the point of view of a non coder 
, just out of curiosity and for the general knowledge. Checking the wikipedia explanation about VGM format, it's not very clear. As you told in the newspost, this format logs the commands sent to the soundchips. Even the files are very small, I would say similar to the original ones. Which tool is normally used to extract this data?
I understand that a music composed on MSX (Moonblaster, Trilotracker, MuSICA or whatever) stores the musical notes, instruments and more data related. What is the difference between a VGM music file and original one then?.
Thank you for sharing. A couple of questions about the VGM format from the point of view of a non coder , just out of curiosity and for the general knowledge. Checking the wikipedia explanation about VGM format, it's not very clear. As you told in the newspost, this format logs the commands sent to the soundchips. Even the files are very small, I would say similar to the original ones. Which tool is normally used to extract this data?
I understand that a music composed on MSX (Moonblaster, Trilotracker, MuSICA or whatever) stores the musical notes, instruments and more data related. What is the difference between a VGM music file and original one then?.
On a MSX game or music player (MuSICA, Performer OPX, MGSEL or even Moonblaster) we have a music driver program which plays the music from a "music data" (music sheet which tell the driver which notes to play and which tempo to use) table. It processes the said music data and along with other tables which might be part of the music data (musician defined instruments)or the driver itself (music player built in instrument patches data, voices and samples) it create a list of register writes which when ultimately written to the sound chip causes it to produce sounds.
VGM works by logging register writes generated by the music driver, saving them to disc as the song is played.
If it's so efficient, why wouldn't all trackers have some kind of rendering/compiling feature to VGM?
Or, perhaps emulators could be used to retro-implement that...
Yes it shouldn’t be too hard to create a VGM recording script supporting various sound chips for openMSX. Typically it’s done with modified emulator source code (some have it built-in), but tcl scripts make things quite easy. I think there was a link a few pages back to a little script to record the FM-PAC, shouldn’t be hard to adapt to support other chips.
VGM’s biggest limitation is that it’s not so efficient in space. For example all the Final Fantasy music combined is 872 kB (261 kB zipped), and Sonyc’s FM-PAC music is 401 kB (90 kB zipped). Both of these are 1-disk games. (I’m mentioning the zipped size because it indicates how much space can be saved by a gunzip-capable player.)
However, a lot of that space is used by wait commands. Because the Z80 and OP* sound chips are not so fast and VGM has a 44100 Hz precision, waits are inserted by the logger after nearly every register write. For music played back on the VDP interrupt, that isn’t really necessary… I just made a little test-tool which reduces the timer resolution to 60 Hz (by collapsing waits), turns out it cuts the file size by about 25%. The Final Fantasy music’s combined size is reduced to 643 kB (90 kB zipped), and Sonyc’s is reduced to 295 kB (16 kB zipped). Looks like this does wonders for the compression too 
.
Knowing now how many waits are present in these VGMs, I should probably optimise that part of the code path a little more .
