Previous Page | Next Page
- by hcs at 2:03 PM EDT on March 28, 2016
- >> Speaking of the format, is it possible to develop a format dedicated to playing the Procyon Studios Digital Sound Elements format?
> I'm not sure what you're talking about? Why develop a format for playing those? The format is already meant to be played?
I guess AnonRunzes means something like NCSF for playing the standard Nitro Composer DS stuff?
edited 2:08 PM EDT March 28, 2016
- by AnonRunzes at 2:47 PM EDT on March 28, 2016
- @psy_commando - "I'm not sure what you're talking about? Why develop a format for playing those? The format is already meant to be played?"
Let's just combine the SMD/SWD formats into one playable format - that'll be DSESF(Digital Sound Elements Sound Format).
@hcs - I guess AnonRunzes means something like NCSF for playing the standard Nitro Composer DS stuff?
Of course I do!
- by psy_commando at 6:12 PM EDT on April 10, 2016
- Welp, really sorry for the late reply.. ^^;
So you guys are suggesting some kind of aggregate format? For easier distribution I'm assuming?
It should be doable then. Actually, I'm aggregating every SWD/SMD loaded + the main sample bank if it exists in my tool when I export a soundfont. So, it shouldn't be too hard to dump that.
If you mean a single DSESF file per track though, that might be a bit more involved. Because you'd need to inject the individual samples into each of those if its a game that uses a single sample bank for all its tracks. I'm still experimenting with rebuilding SWD and SMD files right now.
I'm not too familiar with the NCSF format though. From quickly looking at it, it seems to just pack SDAT files together, and apparently follows the PSF format more or less?
Would it need to have the audio engine code ripped too? I think I read in another thread here that ripping the part of the binaries handling the playback and the samples and etc from memory didn't work 100% too well for some reasons. I'll have to find that thread again..
But regardless, DSE is pretty straightforward internally from having dissected the game at runtime. Everything seems to be calculated linearly.
The LFO system looks a bit more complex though.
So, I've been looking into writing an audio engine for playing those backs from scratch. But I'm not too knowledgeable about audio programming :/
- by CyberBotX at 8:55 AM EDT on April 11, 2016
- Long story short regarding NCSF, the .ncsflib file stores the SDAT, the .minincsf files just store what track from the SDAT to play, but to actually play them back requires a player and that is what the NCSF Winamp and Foobar plugins do, they contain playback code based primarily off of FEOS Sound System by fincs.
So basically, to make something like a DSESF (or whatever it would be called), you'd need to have some sort of player code. Such a player would depend on how similar/different playback of SWD/SMD is compared to playback of Nitro Composer's SSEQs.
- by psy_commando at 4:07 PM EDT on April 12, 2016
- @CyberBotX:
Thanks for the summary! That clears things up!
I'd say its pretty different from looking at the documentation for nitro composer stuff.
I tried looking for similarities between the two at first, but there were only a few of them. I guess that's probably why nobody bothered reversing the format until recently.. :/
But to be honest, it was a lot simpler than I expected to reverse this, thanks to how many similarities it has to sf2/dls and midi. So its still a bit surprising nobody really tackled it before.
I'd assume the nitro composer format must have been a lot more annoying to figure out.
But yeah, it really looks like DSE does more extra processing stuff that nitro composer.
The volume envelopes for samples for one are AHDSR, with some extra parameters.
And it has up to 4 "LFO"s per preset, each LFO supports all common basic waveforms and random noises, and can affect pitch, volume, pan, and probably cutoff(hard to tell if its resonance/Q or something like that, because the DS DSP tend to sound really "ringy" IMO). And each LFO can have a delay, fadeout, rate, and depth, and possibly something else I didn't figure out yet.
Also, preset splits seem to have finer control over how samples are associated to notes and velocity ranges.
And I'm guessing there's probably more differences too that I'm forgetting about.. ^^;
I'm not sure what you mean exactly about the player code? Wouldn't it need to be written almost from scratch for DSE anyways? What is the player code right now actually? Is it just something someone wrote from scratch, or is it emulated/reinterpreted ARM assembly being fed data?
Sorry if that sounds dumb XD Its just because, my only prior experience looking into ripped game audio was with SNES SPCs, and apparently that those contains part of the game's audio engine, and its just emulated.
Info dump:
Here's their page with the specs:
http://www.procyon-studio.co.jp/dse/spec.html
(Its in japanese, but with the screenshots and google translate you can sort-of figure out what's going on)
Here are a few of the UI screenshots translated (Those really helped figuring out the missing bits) :
LFO
Programs
Voice Control
Also the SMDL format is very very similar to a MIDI file. And the SWDL format, is very similar in concept and content to Soundfont or DLS. (The SWDL format is actually more powerful that Soundfont AND DLS.. There's so much control over a lot of little things like note stealing, and etc.. And you don't seem to have a minimum sample length for looping them.. )
Here are the wiki pages I put up on ProjectPokemon about the format. It seems to be mostly universal with other games:
DSE Overview
SWDL
SMDL
And here are my (messy) personal notes I store on my dropbox and update as I go. Its a bit more up to date than the wiki right now, because I just began dealing with DSE files from version 0x402. (The more common version 0x415 is what's on the wiki right now)
Notes
I'd also share my code, but its an horrible confused mess patched and hacked over and over again, and probably will be more confusing than helpful ^^; Its up on my github though.
Oh, and I really recommend, if anyone else ever wants to poke at the format too, to get the US version of "Pokemon Mystery Dungeon : Explorers of Sky" to experiment with.
Mainly because the memory locations where most of the processing data is stored is conveniently labeled with "mseq" and "mdev", so its really easy to locate using an emulator and something like cheat engine. All other games using DSE that I tried didn't have those location labeled at all, including Explorers of Time/Darkness.
Plus, all the offsets in the game code in my notes are based on that one game. AND best of all, if you get a complete savegame off gamefaqs, you get this thing called "Sky Jukebox" (Main menu->Other->Sky Jukebox), which allows you to play any tracks from the game at will, and its so very helpful!
edited 4:07 PM EDT April 12, 2016
edited 4:11 PM EDT April 12, 2016
edited 4:12 PM EDT April 12, 2016
edited 4:13 PM EDT April 12, 2016
- by CyberBotX at 9:03 AM EDT on April 13, 2016
- Well, I did have help in the form of an incomplete specification for SDAT which helped me figure out most of what I needed to create NCSF. There were a few things here and there, such as the specification of the PLAYER blocks and the random/variable actions of SSEQ, that I had to do more digging on.
It does sound like you'd probably have to write some player code from scratch, or possible try to reverse engineer it from an existing game's binary. I believe that fincs said that was how he created the sequence player in FEOS Sound System, by reverse engineering Nintendo's player from an existing game. But basically, it isn't emulation. fincs' code would parse the sequence and get the sound data it needed. His version would then pass the sound data to the DS's sound system to have it play, whereas my version had to fake some of what would've gone to the DS and instead pass the sound data to the player (Winamp or Foobar).
- by psy_commando at 3:42 PM EDT on April 13, 2016
- Alright, thanks. That makes sense.
Its pretty much what I was heading for with the audio engine I was working on I think.
Speaking of which, how are you "synchronizing" notes/events in real time? I haven't found a smart solution to that problem yet.. Besides making a separate thread that keep track of the time using a high resolution system clock.. But that didn't work too well..
edited 3:42 PM EDT April 13, 2016
edited 3:43 PM EDT April 13, 2016
- by CyberBotX at 9:05 AM EDT on April 14, 2016
- I'm not exactly sure what you mean by "synchronizing" here. But if it does help any, here is the source code of the SSEQ Player portion of my NCSF plugin for Winamp:
https://github.com/CyberBotX/in_xsf/tree/master/src/in_ncsf/SSEQPlayer
kode54's Foobar plugin uses mostly the same code as this. The player part is composed of the Channel, Player and Timer sets of files. Everything else there is for loading up the SDAT.
- by psy_commando at 5:21 PM EDT on April 14, 2016
- I meant, like with a midi sequencer, you have a midi clock that you use to determine when to play a certain event based on the number of ticks so far.
But thanks for the link! I'll take a look!
edited 5:21 PM EDT April 14, 2016
- by CyberBotX at 9:16 AM EDT on April 15, 2016
- Ah, I think I see what you mean now. I am not sure how to explain it in a simple manner, but the player fakes the DS's ARM7 clock rate and uses that as an indicator of when to process the next part of the sequence. If you look at the Player::Run() function, you can see that it uses a tempo count to handle this, which is information that comes from here:
http://www.feshrine.net/hacking/doc/nds-sdat.html
It does say that it isn't precise but that the difference is too small to be noticed.
Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6 7
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source