Everything posted by waffleoRai
The oscillators are partially implemented for playback, but not for SF2 export. I think the volume and pan oscillators are working (need to properly test) for playback. For pitch and LPF(?) the oscillator value calculation works for all wave shapes, but the interpolator can't handle extremely rapid pitch changes at the moment (I intend to debug this at some point because it's kind of a big problem, think it has to do with the counter resetting), so the code that loads the pitch oscillators into a playback sample is currently commented out. LPF oscillators aren't implemented beyond the general oscillator value calculation, and that's also because I did something wrong writing my LPF classes causing them to output silence. Now I think I might be able to encode the oscillators in SF2 as modulators, but the only reason I haven't thus far is laziness. There's also a weird bug with pan scaling and the envelopes are a rough estimate for now. Other than that, seems to work alright. I'm able to open the resulting files in Polyphone and play them back nicely. Just needs a bit of tweaking to sound as accurate as possible. I definitely intend to fix/add these things, just haven't done so yet. The explorer GUI tool is here. I don't really consider it polished enough to officially "release" quite yet (especially since my last few changes broke it), but I like using GitHub to bounce my code between computers cleanly so eh. It's all Java since Java is my crutch language and I keep going "eh, it'll just be a quick little applet, don't need to pull out the C...". I believe the JAR in /jar/ was built before I broke the type detection system, so if you wanted to check out a vastly inferior version of all the existing DS ROM explorers, that should do the trick . It does detect and play back SMD/SWD though (if not still a bit roughly), so that's something! Noooow unfortunately, the SF2 export buttons on the GUI seem to be outputting air for some reason. The issue isn't obvious so might take me a few to figure out why it's not writing anything. Some link is probably broken in the callback chain. However, the conversion and writing methods themselves absolutely work! At least, last I checked! THESE are in my game formats library -- class is waffeoRai_soundbank.procyon.SWD The little main test in the same package (SMDTest) has an example of how to do it since I export to SF2 as a means of debugging soundbanks, but here's basically all you would need to do to call it directly: String swd_waves_path = "mydir/bgm.swd"; //The file containing the wave data String swd_art_path = "mydir/bgm0025.swd"; //The file containing articulation data, here I just picked Apple Woods String sf2_path = "mydir/bgm0025.sf2"; //Open a FileBuffer. This is my file wrapper class that handles multi-byte fields. //The second arg is byte order as a bool (false is LE) FileBuffer filedata = FileBuffer.createBuffer(swd_waves_path, false); SWD swd_war = SWD.readSWD(filedata, 0); //Second arg is offset from file start to begin reading filedata = FileBuffer.createBuffer(swd_art_path, false); //Open the articulation data file SWD swd_art = SWD.readSWD(filedata, 0); //Parse as SWD swd_art.loadSoundDataFrom(swd_war); //Load the sound data from the sound SWD to the articulation SWD swd.writeSF2(sf2_path); Probably with a try/catch to get those I/O and parsing exceptions. And of course since this is all open source, feel free to look at SWD.java and be like "noooo, that's not good". If yall are interested in using this as a converter, I wouldn't mind prioritizing debugging and cleaning up the SWD stuff. I can also just JAR up a dedicated SWD/SWD->SF2 command line tool. For sure, SF2 lacks some flexibility that would be nice to have... I mostly only use it as the "default soundbank conversion target" because it's usually recognized by a lot of programs? Only thing I could get to import into my version of Kontakt. (Attached most recent output of bgm0025.sf2) bgm0025.sf2
Hey! So, swdl format issue. I apologize if this is the wrong place to discuss this, or if this has been brought up before. I did a quick scan of the various docs and notes and didn't see any mention of this, so I thought I'd go ahead and post on the off chance that someone hasn't come across this yet? I've been writing a little ROM explorer for funsies - thought I'd add a swdl/smdl player since I already had a makeshift but working synthesizer and player GUI as well as code for handling smd files (a couple years back decided to do a dump of the EoT BGM to midi because I like messing with the sequences in protools). Getting to the point, the issue is with sound sample tuning. I've been using Apple Woods (bgm0025) as my test track. This is the creepypasta reject I get when playing it: rotten_apples.mp3 I think my interpolator still has some problems, but does play back sseq/sbnk and playstation seq/vab songs without any tuning issues. The most glaring source of the discord I have tracked back to Programs 52 and 53 in bgm0025.swd (which are identical except for the envelopes, I think 53 is the main one and 52 is used for delay tracks). Tabled the tuning values (as read from the fields specified by the https://projectpokemon.org/docs/mystery-dungeon-nds/dse-swdl-format-r14/) for all the non-percussive programs in bgm0025.swd: Included Polyphone's suggested tuning in the last two columns (dumped to sf2 so I could play with tuning directly). It's prone to being wrong on the octave of the root key, but its fine tune suggestions do seem to be pretty close to the actual notes (once root key is corrected for). No coarse tune in Polyphone suggestions. So here's the weird thing I'm confused about. When I modify the "coarse tune" and "fine tune" fields in the file directly on the ROM and run it through an emulator, I get the exact same results as yall - 0x14 appears to control fine tune by cents and 0x15 appears to control coarse tune by semis. But applying the same parameters to an external player does not produce accurate playback. In fact, in the sf2 dump I generated programs 52 & 53 don't even have continuous regions pitch-wise? It's pretty weird. Yet it seems pretty clear that when I modify these fields and put them back in the game, the tuning is affected by about the amounts changed? And then there's the fact that the default coarse tune is -7st, but the song does not play 7st lower than the sequence? I'm wondering, are there values stored elsewhere or loaded with the driver that scale the tuning somehow? I didn't see any obvious currently unknown values in the swd that could be candidates (most unknown bytes are 0x00 or 0xaa), but I'll probably look again. Hoping to probe into it more this week once I get some quality sleep and some more stuff for work projects done. But if this is something that's already well characterized that my tired brain just skimmed over, absolutely feel free to just point me to the appropriate documentation/notes instead! Again, sorry to sort of throw off the groove of this conversation, but this seemed the most prudent thread to bring it up. Feel free to delete it or move it if you need ! EDIT: Got it. Sort of. Seems to be a low level value telling the player how to tune it to the root note relative to the stored sample rate. For a high level smd player, this value can be completely ignored as the weird sample rates of the values account for the fine tuning already. I did try mapping it as one byte coarse tune and one byte fine tune relative to the sample rates and it doesn't quite add up, so wondering if it's a 16-bit LE value meant to be loaded into a voice control register or used directly by the driver? I soooo don't know, I'm just throwing stuff out there. Anyway, that's that. Just thought I'd note that here in case anyone else happens to have the same issue.