New XGM driver !

Stef · Post by **Stef** » Tue Nov 25, 2014 10:09 pm

Thanks Bastien

kubilus1 · Post by **kubilus1** » Wed Nov 26, 2014 5:51 pm

So xgmtool crashes when converting: https://dl.dropboxusercontent.com/u/101 ... jae_eb.vgm

This VGM has a ton of samples in it in the old 1.5x style format.

The crash occurs due to a crazy Hz calculation from a dvision by zero around vgm.c line 591. For some reason, endPlayWait is zero. I'm not entirely clear on the logic for the program yet, but it appears that at line 550, the isPCM check is failing which leads endPlayWait to never be updated.

Stef · Post by **Stef** » Wed Nov 26, 2014 6:07 pm

Thanks ! That will help a lot in fixing bugs in xgmtool !
The code is not really elegant :p mainly because i translated it from java and also because my java program was used for prototyping... I was too lazy to redesign it when porting to C :-/

Stef · Post by **Stef** » Thu Nov 27, 2014 12:02 am

I posted a new version of XGMTool on the SVN :
https://sgdk.googlecode.com/svn/trunk/bin/xgmtool.exe

It should fix some problems !

kubilus1 · Post by **kubilus1** » Thu Nov 27, 2014 1:30 am

Cool, that certainly fixes the crash on tjae_eb.vgm file. However, the resulting xgm does not seem to play correctly, it's like some of the samples are missing.

Also, here is another VGM to try converting: https://dl.dropboxusercontent.com/u/101 ... bhb_s1.vgm

In this case, the conversion seems to get into an endless loop.

kubilus1 · Post by **kubilus1** » Thu Nov 27, 2014 1:38 am

I want to add that the Sonic1 vgm sound perfect now with the xgm conversion update!

Stef · Post by **Stef** » Thu Nov 27, 2014 8:58 am

kubilus1 wrote:Cool, that certainly fixes the crash on tjae_eb.vgm file. However, the resulting xgm does not seem to play correctly, it's like some of the samples are missing.

Also, here is another VGM to try converting: https://dl.dropboxusercontent.com/u/101 ... bhb_s1.vgm

In this case, the conversion seems to get into an endless loop.

Actually i only tested the VGM optimization part, i was confident about the VGM to XGM conversion but i was wrong :p
Thanks for testing and reporting bugs, that really help =)

I want to add that the Sonic1 vgm sound perfect now with the xgm conversion update!

Yeah i tested on this one, hopefully it should fix the sample problem with VGM export from deflemask.

Stef · Post by **Stef** » Fri Nov 28, 2014 11:14 pm

kubilus1 wrote:Cool, that certainly fixes the crash on tjae_eb.vgm file. However, the resulting xgm does not seem to play correctly, it's like some of the samples are missing.

Also, here is another VGM to try converting: https://dl.dropboxusercontent.com/u/101 ... bhb_s1.vgm

In this case, the conversion seems to get into an endless loop.

I put a new version on the SVN:
https://sgdk.googlecode.com/svn/trunk/bin/xgmtool.exe

It should fix the missing samples issues.
About the second VGM file, actually it converts correctly but just take age to do it because the VGM contains many play sample commands and so analyzing samples take more time.
I recommend to convert it to optimized VGM with xgmtool for once then you can have quick convert to XGM format.
Although the VGM optimization throw many warning messages (because the small sample can't be correctly restored) i don't really heard any difference in the final music.

Davidian · Post by **Davidian** » Sat Nov 29, 2014 9:34 am

More tests...

Samples in music are now working perfect.

My VGM file was 109 KB before compression. Then 96 KB and finally a 78 KB XGM.

Now I'm gonna test the three samples for sound effects.

Great work Stef

Stef · Post by **Stef** » Sat Nov 29, 2014 11:07 am

Thanks, that is a good news =)
Honestly i think that some bugs remains and i do know that some VGM won't convert correctly (because of sub frame timing) but it is already working nicely in its state.
About the size reduction of your file, looks like you were using an already quite optimized VGM file, in which case the result is not much different.

kubilus1 · Post by **kubilus1** » Sun Nov 30, 2014 11:31 pm

The new version works much better! I think the only remaining issue is samples not playing unless FM channel 6 is already set to PCM mode in the song. Other than that, it appears to be working very well.

An odd thing about that bio hazard battle track, it apparently does not actually set channel 6 to PCM mode, however it feeds data using the PCM commands. I could be missing something, but I couldn't find a command to enable DAC anywhere in that. I just noticed that when digging through these!

Stef · Post by **Stef** » Mon Dec 01, 2014 9:27 am

Yeah the remaining issue is about how the XGM driver handle PCM command, it does not automatically set DAC mode...
I will try to modify it to automatically set the DAC mode on PCM play command and set back to FM when no more PCM are playing. I'm almost certain i don't have enough space to add even a small part of code like this one (i have about only 50 bytes free :p) but i can probably optimize others pieces

About Bio hazard, well that would explain why even if the XGM driver can't restore all PCM play command it does not make any change in the music.
That is also the reason why i did not included automatic DAC mode on PCM play command at first as i already sax invalid DAC write in VGM file.
Maybe i can add this in the XGMTool : if DAC is not enabled just ignore all DAC writes commands.

kubilus1 · Post by **kubilus1** » Mon Dec 01, 2014 4:20 pm

With the Bio hazard battle song, I assumed that this was being used to generate some kind of sound, perhaps the weird stick rattle noise? Perhaps this is just some hacky way to do a pause?

It would be interesting to see if that was the case by changing the 0x80 to the proper 0x7x commands.

If the weird BHB mode is simply a hacky pause then the logic of sending a 0x2b 0x80 at PCM start and a 0x2b 0x00 at PCM end should be sufficient I would think to fix SFX. Keep in mind that this would need to be wrapping every time a string of bytes were written.

For instance if the VGM plays 10 PCM bytes and then does some other FM operation and then plays 10 more PCM bytes, around each 10 PCM bytes, enabling and disabling PCM would need to occur. At least for SFX since there is no telling if the other FM operations would be on channel 6 or not.

If the BHB mode is in fact streaming data to FM channel 6 to make sound, then I really am not quite sure. Perhaps the logic would need to track if PCM mode has been enabled in the VGM by detecting 0x2b 0x80 and then enable PCM mode for SFX playback and return it to whatever the original state was when done.

Stef · Post by **Stef** » Mon Dec 01, 2014 5:38 pm

Yeah, i think the most common way of doing it is to store the current "DAC enabled" state set by the VGM data. Actually VGM data should never affects the hardware DAC enabled state, only changes the variable which store the value. the XGM driver should deal with DAC enabled by its own : set it on PCM play and restore the stored DAC enabled state at PCM end play.

kubilus1 · Post by **kubilus1** » Mon Dec 01, 2014 6:24 pm

VGM data certainly does set and clear the DAC enabled state. Perhaps in XGM format you won't since you can make an assumption on this based on if PCM is being played or not. I assume then you strip the commands from the VGM data itself?