Does seem like an improved effort then (much prefer the chase mechanic to random encounters). Curious why it did not get a release, though I suppose it would have been a while since the Chaotic Century anime and Genesis (newest anime at time of release of this) never quite properly made it to the US with Fuzors tanking hard before then so yeah. Might have also been a rights thing but I am not that invested to go find that out.
N1 Japanese should be more than suitable for this sort of thing -- Japanese wordplay might be an ask but anime game that might not have kanji/might be recognisably only using a very limited set for a certain age in school of the time is a different matter entirely. Harder part will probably be the debate over whether to be true to the Japanese, the dub, the manga, the models or go something else.
Compression wise then LZ says most things.
https://www.romhacking.net/utilities/826/ https://www.romhacking.net/utilities/789/ are usually what we suggest.
The first bytes of the file are usually going to be 10 (older ROMs) or 11 (newer ones, slightly better compression but might not be compatible with the BIOS provided decode functions), and 40 in some rare examples (Golden Sun and one other that I am aware of but have not pulled apart many late stage games). Most things handling DS files will handle them though, indeed crystaltile2 if you are using that will probably have it on the right click of the DS ROM file viewer (the DS icon on the right hand side of the top menu)
The binaries (be aware Crystaltile2 might falsely detect the binaries as being compressed) will instead be using BLZ from cue's tools.
I will have to look at the ROM to see. Most of the time I would expect whatever is used for the menus and library/bestiary to be the same as the script, though there are plenty of exceptions.
Pointers for text will usually be at file level (usually at the start of the file), most of the I look to see if there is a end of section marker (maybe 75% of games have one, or something you can plausibly use for one and going manual to get a decent chunk to work with is not the worst either), find all in a file and compare to the hex at the start of the file (if it is straight there then great, if it is a fixed difference then you have offset pointers which will usually start at the start of the text section, and if they are out by an increasing but same amount then relative). Some archives will have pointers be in a separate file, though usually in the same directory or immediately up in the tree. Some menu text will be fixed length, though if you have descriptions rather than simple text then that is less likely.
I will note for English text then many Japanese games on the DS will use shiftJIS ( http://rikai.com/library/kanjitables/kanji_codes.sjis.shtml ) or EUCjp (same site will have a link) but not have the ASCII backwards compatibility. Some will opt to use the Roman characters included in that, others will hack it further. NFTR is the main font format for the DS but plenty went custom. Forcing your input method to output Roman characters in the shiftJIS space is tricky, so instead I tend to use jwpce, JWPxp, njstar or one of the other Japanese text editors and it will have the option to force it (try the J A and whatever buttons on the top right of the screen). I don't know offhand if there is a cute trick you can do from U16 to get to that space like you can with capitals and lower case for ASCII when you add/subtract a certain amount.
Forcing it into stuff it already understands is easier, however they tend not to use the best fonts for the Roman letters and you are still dropping 16 bits a character when you could be using 8 (not so bad for files most of the time -- even 16 bit pointers will be in the more space than you will likely need for text range but memory can be a concern for some things).
Line of English text of different size is a solid proof of concept. Everything else (give or take truly figuring out the encoding) is so much tedium from that point.
N1 Japanese should be more than suitable for this sort of thing -- Japanese wordplay might be an ask but anime game that might not have kanji/might be recognisably only using a very limited set for a certain age in school of the time is a different matter entirely. Harder part will probably be the debate over whether to be true to the Japanese, the dub, the manga, the models or go something else.
Compression wise then LZ says most things.
https://www.romhacking.net/utilities/826/ https://www.romhacking.net/utilities/789/ are usually what we suggest.
The first bytes of the file are usually going to be 10 (older ROMs) or 11 (newer ones, slightly better compression but might not be compatible with the BIOS provided decode functions), and 40 in some rare examples (Golden Sun and one other that I am aware of but have not pulled apart many late stage games). Most things handling DS files will handle them though, indeed crystaltile2 if you are using that will probably have it on the right click of the DS ROM file viewer (the DS icon on the right hand side of the top menu)
The binaries (be aware Crystaltile2 might falsely detect the binaries as being compressed) will instead be using BLZ from cue's tools.
I will have to look at the ROM to see. Most of the time I would expect whatever is used for the menus and library/bestiary to be the same as the script, though there are plenty of exceptions.
Pointers for text will usually be at file level (usually at the start of the file), most of the I look to see if there is a end of section marker (maybe 75% of games have one, or something you can plausibly use for one and going manual to get a decent chunk to work with is not the worst either), find all in a file and compare to the hex at the start of the file (if it is straight there then great, if it is a fixed difference then you have offset pointers which will usually start at the start of the text section, and if they are out by an increasing but same amount then relative). Some archives will have pointers be in a separate file, though usually in the same directory or immediately up in the tree. Some menu text will be fixed length, though if you have descriptions rather than simple text then that is less likely.
I will note for English text then many Japanese games on the DS will use shiftJIS ( http://rikai.com/library/kanjitables/kanji_codes.sjis.shtml ) or EUCjp (same site will have a link) but not have the ASCII backwards compatibility. Some will opt to use the Roman characters included in that, others will hack it further. NFTR is the main font format for the DS but plenty went custom. Forcing your input method to output Roman characters in the shiftJIS space is tricky, so instead I tend to use jwpce, JWPxp, njstar or one of the other Japanese text editors and it will have the option to force it (try the J A and whatever buttons on the top right of the screen). I don't know offhand if there is a cute trick you can do from U16 to get to that space like you can with capitals and lower case for ASCII when you add/subtract a certain amount.
Forcing it into stuff it already understands is easier, however they tend not to use the best fonts for the Roman letters and you are still dropping 16 bits a character when you could be using 8 (not so bad for files most of the time -- even 16 bit pointers will be in the more space than you will likely need for text range but memory can be a concern for some things).
Line of English text of different size is a solid proof of concept. Everything else (give or take truly figuring out the encoding) is so much tedium from that point.