Previous Page | Next Page

by CyberBotX at 6:39 PM EST on November 7, 2014
Well, updated my GitHub with the latest update to the SDAT tools. Like I mentioned in my last post, this allows the NDStoNCSF tool to output an SMAP-like file that can be used to include only the SSEQs that are left uncommented in the file. A good example of this is the nearly 75KB monstrosity of Sonic Rush Adventure's SDAT. (Seriously, what was Dimps thinking?)

Basically, to use this, use the -s or --create-smap option with the filename you want to store the SMAP in (it'll be relative to the output directory). Modify it like in my example above, and then run the tool again with the -S or --use-smap option. Please note that the short versions of the command-line options are case-sensitive!

Hopefully this'll make it MUCH easier to include/exclude SSEQs when creating an NCSF set. Now, at the moment, it doesn't allow you to use the -i and -x (include and exclude) options when using SMAPs, nor does it allow you to use the -a (auto) option. The former is because of how the SMAP handling is being done, but if it turns out that it would be better to allow them to work together, then I may change that in the future. The latter is because the automatic mode is part of the include/exclude process and not really needed when you've already done that work with the SMAP.

I know I said I was gonna have all of the above done earlier in the week, but I got a little under-the-weather from the weekend and it took me a bit to get this done as a result.

My next goal with the tools is to work on more advanced stripping of the SBNKs and SWARs. Ideally, I'd parse through the SSEQs, look for which instruments in each bank are being used as well as which SWAVs in the wave archives are being used, and get rid of the ones that aren't being used at all. That should save some space in the final SDAT's creation.
by nothingtosay at 12:51 AM EST on November 14, 2014
You wouldn't happen to have any idea why StarFox Command doesn't get all its music dumped, would you? It happens both with VGMToolbox doing NDSTo2SF and with your utility. Or maybe it does all get ripped, but some files are just nonfunctional. I get 130 tracks with your utility, but one, SSEQ004b, gives an error message and 26 of them display the default 3:00 length and hang foobar if I try to play them.

2SFs don't have that problem, but I suspect they may have a different one. VGMToolbox also produces 130 2SFs, but 25 are two seconds long, very loud, and seem like they would be sound effects but I don't think they are (though it's been a long time since I played the game), and there's still another one that gives an error message.

You don't have to play long into the game to hear music that doesn't get ripped, and it's definitely sequenced as muting instrument voices in DeSmuME will show. Just wondered if you might have some theory, and I'll provide any more information or help I can if you ask for it.

edited 11:18 AM EST November 14, 2014
by Lunar at 1:16 AM EST on November 14, 2014
Don't suppose Zombie Daisuki is possible with the new music format either, is it?
by Knurek at 4:31 AM EST on November 14, 2014
Nothing that doesn't use stock Nintendo driver is, sadly.
by CyberBotX at 7:54 AM EST on November 14, 2014
An update in the tools department. I haven't updated the ZIP yet, but I have committed an update to my Github that allows the tools to strip the excessive data out of the SBNKs. Right now, only the NDStoNCSF tool utilizes this. I also need to modify parts of it so I can prepare it to be able to strip the SWARs as well.

Replies to the previous posts:

nothingtosay:

From a quick lookover, using a tool I derived from the FSS track handler in the NCSF SSEQ player, those sequences from Star Fox Command that don't time or play properly are probably because of 0-length wait periods. Because of that, they cause the track parser to get stuck in an infinite loop. There really isn't much I can do about that.

Lunar:

As Knurek mentioned, but I'll elaborate, NCSF is basically designed around the idea of playing Nitro Composer SSEQs that are contained in standard-format SDAT files. If a game uses an alternate method for its music, such as ADX streamed files (like The World Ends with You) or Procyon sequenced music (like Luminous Arc), then NCSF won't work for them.

In the case of Zombie Daisuki, they appear to have used the Procyon sound tools, so it can't be dumped with either 2SF or NCSF.

I'm sure at some point in the future, someone will figure out how all the Procyon sound formats work, but as of right now, the only one that has been figured out is the sadl streamed format as it is in Professor Layton and the Curious Village (which isn't the only game to use that particular format). But even if the format for Procyon music is figured out, I'm not sure what I'll do with it as far as NCSF goes. When I named the format, I picked the name because it was meant to handle only Nitro Composer SSEQs, which is technically what 2SF is also doing.
by kode54 at 10:27 PM EST on November 14, 2014
That's not to say that Procyon sound tools games cannot be dumped as 2SF, just that they cannot be dumped automatically using our current dumping tools or techniques. Or am I assuming incorrectly that 2SF supports running arbitrary NDS ROM dumps that happen to produce sound?
by CyberBotX at 11:42 PM EST on November 14, 2014
You are correct, 2SF basically uses a Nintendo DS ROM as its PSF program section, so anything is possible as long as it can run through a DS emulator (like DeSmuME since that is the emulator used by the 2SF plugins out there currently, I believe). So yeah, all it would take is a proper ROM equipped to play Procyon sequences (and maybe streams) and they could be made into 2SFs. The only reason I said that 2SFs only use SSEQs like NCSF does is because the current dumping tools and techniques utilize a ROM meant to play SSEQs. But on top of that, since SSEQs are contained within an SDAT, that also poses a small problem to making an all-purpose ROM for Procyon sequences because they are separate files, not contained within one file.

Personally, I'd rather figure out the Procyon format(s) and do something similar to what I did with SSEQs. Whether that would be an addition to NCSF or a separate format, I can't say for sure.

edited 4:51 AM EST November 15, 2014
by kode54 at 9:57 PM EST on November 15, 2014
Somebody emailed me about such a thing a week or two ago, also asking about Procyon ADPCM from some part of vgmstream. I tried my best to explain how the ADPCM decoder worked for that format, and never heard back from them.
by CyberBotX at 6:32 AM EST on November 16, 2014
Well, from what I've seen, as far as Procyon streams go, there appears to be 2 different formats for sadl. One of them is the one used in Professor Layton and the Curious Village (and I've also seen it in some other games, I can't recall which ones), and one used in Luminous Arc. The Luminous Arc sadl files are in an entirely different format than the Layton one. I'm not even sure why, nor did I ever look into how much difference there actually was.
by CyberBotX at 7:04 PM EST on December 9, 2014
So after some delays in actually getting around to adding in the SWAR/SWAV stipping, plus some bugs that were cropping up (partially because of me) and some other changes in the code, I have finally got that all squared away in the SDAT tools. In the process, I also discovered an unsigned integer underflow if an ADPCM SWAV's loop offset is 0, since the code tries to subtract 1 from that (oops).

I've updated the ZIPs for both in_ncsf and the SDAT tools. I'll get around to doing a pull request to kode54 to update foo_input_ncsf. in_ncsf is now at v1.11.1, and I'll just say that NDStoNCSF in the SDAT tools is at v1.7 (I'm not going to list all the tools).

Going back to the start of the thread to check on things...

Knurek had mentioned the sequence SEQ_glad from Sonic Colors having a volume of 0. Well, that particular sequence isn't even a valid sequence to begin with. It is only 40 bytes long and has 4 commands: turn off note wait, set the tempo to 160, set the patch to 11, set the volume to 127. The end of the track (and the file) happens after that.

Something else Knurek mentioned that will probably require a specification change (and probably manual processing) is edits to the NCSFLIB from the MININCSFs. I haven't really looked into the games he mentioned that would benefit from that, but I'll keep it in mind for a future revision.

I believe the next thing I am going to do for the NDStoNCSF tool is add something to allow it to search for streamed formats, like STRMs inside of SDATs or ADXs, that sort of thing.

As always, if anyone else has suggestions, comments, questions, please feel free to tell me.

edited 12:30 AM EST December 10, 2014

Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=http://www.google.com]Link[/url]

[img=https://www.hcs64.com/images/mm1.png]
Password
Subject
Message

HCS Forum Index
Halley's Comet Software
forum source