OoT uses a binary search algorithim to find files in the file table. Make it a table that is not binary search friendly and you will eventually have problems with the game not finding the file you are looking for. A binary search friendly list is one that has the values in order (smallest to largest or vice versa), so if a file is moved but it keeps the same entry the game will not be able to find the entry in the filetable.
E.G:
1, 2, 3, 4, 5, 6, 7, 8
If you do a binary search for 7, the algorithim will check the 4th entry (half way through), see it is too small, then check the next half way point (6), then it will see the next half way point (7), and return 7 as the result of the binary search. If you switch 2 and 7, you'll get a problem:
1, 7, 3, 4, 5, 6, 2, 8
Algorithim checks at 4, sees it's too small, moves up to 6, still too small, goes to read 2, and runs into undefined behavior when it reads 2.
This is why using the stock DMA table in OoT/MM is a pain in the ass. The Debug ROM seems to know it is decompressed and therefore does not care about file table offsets unless the table points to a compresed file - at least this is the behavior in emulators.
Why does the game use a binary search? It is much faster to look up files, especially when you have over 1.5k files. DMA transfers take up a lot of time so the programmers wanted to speed up the process.
How do we work around this in a practical manner?
Option 1: Make a tool which rebuilds ROMs and puts everything in order and fixes all the tables.
Option 2: Make a hack which changes how DMA transfers work.
I have pondered and unsuccessfully attempted the first option.
I have successfully implemented the second option, with LZO compression to boot. I would like to port this hack/tool to other ROM versions. Hardware tested with no errors.