Separate names with a comma.
Discussion in 'NDS - ROM Hacking and Translations' started by FAST6191, Jan 28, 2008.
wow complete guide for everyone
@Team Fail an interesting request. I should mention I am in no way, shape or form a musician so I will defer entirely to someone else there (the obvious thing being the end point to make sure there is not real difference as it loops- I am sure we have all heard the pop/static at the end of track (or worse dub/ADR)).
If I understand it you have a SSEQ file (I assume straight up SSEQ rather than one embedded in a SSAR or behaving like one (this is one of the reasons some rippers do not work so well) and no multi channel nastiness just yet- if you are and it looks like you are playing with pokemon do consider learning on a simpler rom) you are playing with and you want to loop it while maintaining a working rom*. The simple answer would be just to inject a jump but that would send it for an infinite loop and possibly break the sound (not necessary game crashing but certainly not just a simple change) depending on how it is originally set up so it is worth considering scenarios .
*it would be all too easy to make a 10 print 20 goto 10 type program/sequence or break an additional section if a call is used after your loop starts running.
I have yet to try to do what you want (usually as far as I go is to fiddle with existing commands and maybe blank the odd note (stuff like the trailing sequence on a recognisable riff- the stuff at the end of the zelda success sound in Tetris DS) but usually I do not even go that far (I mainly stick to filesystem related stuff).
Indeed you are probably breaking new ground in DS audio hacking in doing this (between filesystem stuff, complex undubs and stuff like http://jul.rustedlogic.net/thread.php?id=7518 , http://hcs64.com/mboard/forum.php?showthre...mp;showpage=130 and whatever people are doing in the non SDAT stuff nobody I have seen has taken it that far as far as hacking goes).
Tools- your chosen DS rom extraction method is a good start.
VGMtrans (for simple playback although do not count on it to be hardware/game accurate- http://hcs64.com/mboard/forum.php?showthread=17715 ) and maybe crystaltile2 as it has a nice SDAT parser ( http://filetrip.net/f11824-CrystalTile2-2010-06-12.html ).
Ignore any of the SDAT builders/rebuilders- they might be able to half work but if you have to debug their output on top of doing this it is going to get very tedious very fast and you could have just used a hex editor and saved yourself the hassle.
As we are doing experimentation hacking I would consider expanding the SDAT file (just remember to change the file length in the main SDAT header) and kicking your experimental SSEQ to the end of the SDAT so you do not have to rebuild the entire file should you change the length (if you are adding commands you will probably have to).
I suppose first I should link up http://www.romhacking.net/docs/%5B469%5Dnds_formats.htm and http://llref.emutalk.net/nds_formats.htm#SDAT as it is quite nice for this sort of thing. http://kiwi.ds.googlepages.com/sdat.html is worth having around and http://www.romhacking.net/forum/index.php/topic,8407.html is also worth a read (the program available there has some SDAT support as well).
To save you a search if anything references loveemu's sseq2mid you can get it http://code.google.com/p/loveemu/updates/list (look towards the bottom of the page)
SDAT as a whole is something of an API/psuedo programming language (in the case of SSEQ the term software oriented version of midi is rather accurate) rather than a container for music files but I guess you already got that far.
This API though is usually kicked (with considerations for the header/filesystem/pointers of the SDAT file and files contained within- the whole thing that makes most music hacking quite simple) off by a call from the ARM binaries themselves* and can be interrupted by the ARM as well. If you are going to try and do it from within the SSEQ format/player itself it is possible going to get tricky.
*try the music test like you might find in a game you have altered the sounds for and you will see the graphics/text broken with respect to what is playing- the nice thing about those is if you are taking it to ASM level they are a really nice replicable test.
Do also note conversion to and from midi kills these sorts of commands quite well so avoid them and the basic jump function does not jump forward (only backwards).
Looping in any tracker type format is a road to madness with all sorts of gotchas and as the preceding lines probably demonstrated it is no different here.
You have three options that I can see (I could well be very wrong)
Straight up infinite loop (waits for the ARM to break it out of it)- reverse jump and it will jump back again when it gets to that point again
Internal loop counter- not sure exactly how this works but it is a command (probably with internal counter) you can set (although it appears you have to terminate the would be loop). Seemingly aimed at extending very repeated sections of a larger piece (or perhaps with a bit of help causing situational music to last as long as the situation is occurring).
Call function- (assuming you are not in SSAR type scenarios) probably aimed at situational changes or a measure of compression where a loop might not do.
If you are having real problems perhaps you can take a guess at how long the background will be needed for (and overshoot it) and abuse the call function (either nest them or have successive calls and returns) to call the current track or copy your would be loop to another SSEQ and call that and the original back and forth.
llref (both emutalk and romhacking.net versions) above skips this for whatever reason but kiwi.ds' docs have it in.
Pulling the relevant data from kiwi.ds' work (format is
hex version of the command
additional data (if any)- offsets and the like)
Description and other stuff.
Excuse me, but how exactly do you get kiwi.ds editor from the link "http://kiwi.ds.googlepages.com/sdat.html"?
I can't find it anywhere...
As far as I am aware there is no editor on that link.
http://sites.google.com/site/kiwids/ has a few tools but by the editor was released to the now defunct tahaxan site (and you had to sign up to get it).
Still you can get it http://filetrip.net/f5658-NDS-Editor-0-1.html if you want it (you do not- stick with a hex editor as it saves so much hassle in the long run).
Well, I managed this: http://www.youtube.com/watch?v=g61TjA__y9g
That's all I have done. I'm going to have some serious fun trying to get this to work.
What kind of problems does it have in the long run?
If (and that is a big if) the data from your SDAT directory assembles into a SDAT file it may well not be working properly (files in wrong order/not associated properly, perhaps a header issue (more that some SDAT files have slightly odd headers/phantom entries) and owing to the big changes that go on during rebuilding (recall the issues with ndstool when it comes to rebuilding roms- similar idea). Ultimately is just another example of "a good hacker/programmer will change/use as little as possible to achieve the desired result" idea.
It is then easier just to add things to the end of the file and point there for hacking work and then to slide in new files when you are happy with the results- similar theory to hacking text on the GBA- point it all at the end of the rom and save having to repoint everything but when the final script is drawn up you can replace the existing text.
Your Guides are awesome!
Ok. I've learned a few more things, and now I'm back (again). I found an FL Studio plugin magicsseq that inserts loop data into a midi before export. I can't get it to work, so if someone can help, that'd be wonderful.
Anyways, How can I point a .sseq to play from a .sbnk? Like, I want to copy one and repoint the .sdat and repoint it and then point the data in the game to use the custom .sbnk in the game. Is that possible? Or am I not making sense?
I have not really played with FL studio so I am not sure I can do much there.
As for the other one you should be able to do it just but fiddling with the SDAT itself (ignore sbnk and sseq for now).
If you mean truly expanding the music of the game that might get a bit more tricky as you will then find yourself assembly hacking a rom to use a different sound (nothing drastic but still not as nice as messing with SDAT files usually is) assuming something crude like adding one song to the end of the other is not viable (although with SSEQ and a generous selection of jumps that might be possible to truly expand it).
http://kiwi.ds.googlepages.com/sdat.html - 1.3.2 details it (it is where you will find the listings for what SSEQ goes with what bank although take note of the WAVEARC stuff that bank files can use (not all need them but some have them).
Others thanks for the kind words, I have a plan to rework this a bit to make it more readable (I have the plan it is just the hour or two I need to copy and paste things around and do a bit of cleanup and I added the current version of my "offline" rom hacking docs to the first post in the thread- that should be far nicer than the mess I have on the forum.
This is fake, or something is wrong with it.
All I can say is +1 - I get a file of all 00's too (if nothing else there should be the "This program cannot be run in DOS mode" early on in the file). Even if I go and edit yamihoshi.nl site to get a link from it (I have seen odd things in redirect/crosslink prevention before) I get 00's.
Personally I would go manual for all such work if I can though- unless you are actually creating your own music (even then there are better courses of action) it will be better in the long run. It is not like we lack playback options either-> if it comes to it inject your chosen audio into another SDAT file and use the music test of the game in an emulator.
magicsseq supposedly has looping support custom sseqs. However, you can hex edit used a Hex Editor like HxD.
The only clue I got was from here.
Just add 94+XXXXXX at the end of each SSEQ track (XXXXXX = offset to where you want to start the loop, in reversed hex).
I'm not sure what that means. How do you reverse hex. Also is looping samples points or in seconds?
Reversed hex probably means account for endianess- how often when you look at points will something like 0c73 actually mean 730c (or more likely 56ac23de mean de23ac56). It is part of how the processor works and we generally try to keep things as close to the hardware as we can.
SSEQ is a hardware format for music- in simple terms it is kind of like a sheet of music in that it has no audio data itself but it does tell a player how to make some.
Being a computer you can do more than just play notes and set a tempo as per regular sheet music and one of those features is a looping option, the hex code 94 is a jump command and upon seeing it the SSEQ player will jump the position indicated after the command (and then when it gets back there again it will jump again- you have a loop). It is not points or seconds but actual commands- it is the descendant of the goto 10 type arrangement in BASIC.
http://www.romhacking.net/docs/%5B469%5Dnds_formats.htm has a bunch of commands and I detailed a few other options when speaking to Team Fail a few posts back.
Just to further that thread you have a problem with this as it increases file size, this may cause three issues
1) the overall SDAT file is bigger than before. It is easy enough to get around in rebuilding the DS file (just use ndstool/dsbuff/dslazy or nitroexplorer to rebuild the rom or go manual if using something like NDSTS or crystaltile2). The SDAT file itself though has a value for how long the file needs to be in the header though ( http://llref.emutalk.net/nds_formats.htm#SDAT )
2)It might also have a knockon effect for the file section (usually the last so the other sections are relatively safe)- that is covered in the SDAT info stuff. Where it might trouble you is you edit say the third sseq file the ones that follow will be offset- personally I would point it at the end of the file and save the hassle for experimental work.
I have seen spaces between files in SSEQ so this might not be a problem if you do it properly.
3)The SSEQ file itself- much like the SDAT header there is one for the SSEQ. Simple enough really.
Option 2 is you lose a previous command somewhere (beware of any other jumps or calls) in the SSEQ and that way do not change the overall file size.
I see someone read my new tutorial. I found that post intriguing. I'm attempting to try that soon, but I need some time, first. If I can do that, I'll definitely be updating that. XD
I also think that the magicsseq thing utuber was talking about- I think it's a hoax. I'm sure he's lying because he won't reveal his secret, so he releases a fake tool that is all null bytes that looks legit.
I dunno if this has been mentioned yet, (it probably has, just too lazy to look) but it was made for FLStudio 8. I also found a README document from that same site that hosts MagicSSEQ
LINK: http://www.yamihoshi.nl/files/downs/MagicSSEQReadme.rtf I am not sure if the whole .dll is genuine but I will test it sometime tonight and report my results. : )
BTW: That was an excellent tutorial on PokeCommunity, Team Fail. Thanks.
EDIT: Aaaannnndd it crashed FLStudio when loading the plugin. Bummer
That's because the file is fake.
I've been trying to edit a four-file format in TWEWY (One file has tiles, second one I think the tile sizes, third seems to be the animation frames and the fourth the palette), but it seems I'm not capable of editing the position of the tiles.
I've found another clue on the overlay folder (There's one overlay file that has the name of the package where my graphic is), but I'm not sure due to my lack of knowledge on how to edit it/unedit it, since NO$GBA gives me trouble when trying to testplay it. What should I do?
Yes. I should edit that post and mention that magicsseq is completely fake.
I think there is a real one, but whoever has it put out a selfish person.