I think it pulls the info from the GD3 tags to display in the ROM, so that would make total sense. How'd you figure that one out?
I'm gonna go write Micheal Stamper - he helped me out with the whole ROM padding thing in VGMplay 3.0 - I'm sure he'll fix this. It's probs something very small in the code.
Also - haven't seen you in 4evr Boo - you should come hang at 8static again!! we miss ya.
Hey, man. Yeah it's been a while. May do 8static one of these days.
Good to know that DeadFish (Matthew) is still alive and active doing his thing. I decided that I would attempt to troubleshoot the issue and determined the amounts of points of failure. I started on a hunch with the GD3 footer information and was right.
Something that also doesn't work in VGM_PLAY v3.1 is his VGC support. Using his VGMConv application, we're able to compress VGM files to an undocumented format that he made, but when processing them with the VGM_PLAY v3.1 application, a strange error saying "OUT OF MEMORY: this may also be a bug," or something of the like appears. If the VGM_PLAY v3.1 application actually banks and decompresses compressed VGM to VGC files, it would mean more available songs per binary file. Taking into account that the compression most likely only compresses pattern and instrument data. Compression of sample information would potentially cause more problems than help. With compression of pattern and instrument data, the only cost would be CPU resources; resulting in a small pause from decrunching between song loads.
I'm hoping that someone creates a binary song format for Genesis and 32X some time soon; like NSF, SID, SGC, etc... Would also be nice if VGM MM takes advantage of 32X PWM, being that the VGM format supports it!
Last edited by B00daW (July 14, 2011 1:17 am)