I think we probably need to investigate what you are doing and what you attempting to do. An array or index being off sounds like something edited something and it messed up the maths it did on it (if it is a value of 0 where it should be literally anything else then that can lead to all sorts of fun when dividing, subtracting, multiplying and whatever else).
So you have a game and want to edit some music. Just for fun right now but with an eye to being able to do it practically later in the day, which is perfectly fine.
You made a new song (mid2sseq or whatever giving you one, don't much care if it is an edit to the existing one, some random midi you found somewhere or one you wrote other than source of it might change how some of the conversion tools change things and some of the loop editing tools also have their downsides).
You now want to put it in the SDAT file.
I should have noted I do like to a SMAP file available when I am editing SDAT files just to have a reference I can easily read to hand, VGMtoolbox should generate one of these. Crystaltile2's SDAT viewer is an almost acceptable alternative as well.
For whatever reason you don't want to overwrite the existing one (if the new SSEQ is the same size or smaller than the old one do consider it as it saves a lot of hassle) so instead want to repoint to somewhere else. Initially you thought you might like to have it load a SSEQ from somewhere else in the ROM but that might not be practical, or at least would require a serious tweak to various file handlers.
Traditionally if there is nothing else to cannibalise (many games have tracks not used in the final game) you instead extend the file and put it at the end.
There are a few programs that will attempt to sort things (tinke, some sdat builders, maybe crystaltile2, don't know what happened to VGMtrans) but they are quite iffy really when all is said and done and usually cause more problems than they solve. You can try importing a SSEQ with those anyway (or rebuilding if it is one of those) but for the rest of it I will assume they have failed.
What any given game will want changed here will vary (sometimes a lot of the data in the header of various formats is pretty much redundant as far as the final game is concerned) but we will be good little hackers today and change everything that might bother it.
In the case of the SDAT format there are probably several layers of the format to wade through that might want changing here with each wanting their say.
The SDAT itself will note its own size. This might be redundant but until you can argue otherwise assume it is not.
After the "Generic Header Format" part common to many DS formats, which has a size value, will be the SDAT's initial categorisation of itself. I think we might have had a miscommunication there or you might have skipped over that part if you were going off the romhacking.net description as it downplays that part and you should have had to scroll back up.
https://web.archive.org/web/20080324141531/http://kiwi.ds.googlepages.com/sdat.html does more for me here, though the C programming style description can be annoying to deal with if you have not dealt with such things before.
Size wise sticking in the description section of the SDAT itself you are pretty much only changing "Size of FILE Section" if you are adding on a replacement file. If you were adding whole new files into it (and not removing others) then other things would change as everything get shuffled forward to account for things. FILE being the last section helping with this one (if it was not then everything else would get shuffled, I imagine this is by design).
Assuming you are not changing the audio bank, volume or anything else then you can leave all that alone. Sometimes if you are injecting a new file, such as from another game (I have an example the hacking docs here about injecting phoenix wright games with audio from sequels/prequels, the track needing its corresponding bank), you might want to change the instruments (bank files) but skip that for now.
For editing purposes you will however be changing some data within the FAT section too as it notes where files ultimately live (FILE section mainly just housing files with FAT describing where they are, such things being easier on memory requirements as you are not randomly scanning through megabytes of stuff to get a few bytes). As this should be just values within the FAT section there should be no size change, just overwriting to reflect the new location and size of new file.
Finally we get to the FILE section itself which has a Section Size in it, change this to its new one.
That should be everything.
The earlier stuff where I pondered whether you could read from elsewhere the ROM by faking it out would possibly also come into play here if this was what was happening
The way this would work is the DS does not keep the ROM in memory like older systems. It has a command (B7 on
http://problemkaputt.de/gbatek.htm#dscartridgeprotocol ) to read data from the ROM. What a given game will do here might vary but the idea of putting it somewhere else would hope that the ROM when running goes all the way down the line collecting locations within the FILE, then of FILE within the SDAT, then of SDAT within the ROM, adds the lot up and says this much data at this location. If you faked this out (and maybe the relevant values above as well in case it tries to be clever and checks it has a real value within the expected size range, though it would be acceptable to skip this for a first test as checking for legal values is not something you normally do in game programming -- it is called Read Only Memory for a reason, even on a PS4 you still don't want to be wasting resources, and you usually rely on people knowing what they are doing for the game you are about to spend potentially millions to publish) you could possibly get it to read outside the file and later into the ROM (the SSEQ wanting to appear at a point later in the ROM than the SDAT (theoretically you have 32 bits to note the location and that is gigabytes which is more than enough).