Firstly, in the case of ai senshi nicol (and all other disks in the dat), all dumps were datted as having the same hash. However, they are not the same. some have a different date code. and all have different "unknown header bytes" which I now believe to be a disk serial number. But aside these few bytes they are the same. What I did was add the correct hashes for all dumps, mark the ones not to be datted as "excluded", and marked one dump as "forced". In this case The dump marked "forced" was one of gponys unmodified dumps.
Hardcorehubz dump was flagged bad, and I added a copy of Hardcorehubz dump with the garbage data removed as a Trusted modification and flagged it "excluded".
To clairify, Yes. this data is infact on the disk. However it has an invalid block type of 05, so usual disk copy methods correctly ignore block type 05. fdsstick seems to be confused by it (maybe?).
There are 4 block types. 01 the disk header, 02 is number of files on disk, the rest of disk will be an 03 block followed by a 04 block. and again an 03 then 04 for every file on disk. 03 is file descriptor block, contains file id, file name and size and other info. 04 is the file data block, it contains the actual data of the file specified in previous 03 block.
At the end of certain disks is a data block with a id of 05. Lets take a look.
Here is a photo of ai senshi nicol side a bin dump at near the end of disk image, you can clearly see data blocks and gaps. Let's look at the address I highlighted e1eb. You can see a byte, $80. This byte is only found in bin/raw dumps. It's a control byte that means basically, end of gap/data block start. after the $80 is the block type id code. Here its $03 which is a file descriptor. You can see various data after that including file number $09, file name "SAVE_DT0", file size 0000A0 and the checksum at the end 3A5E. (you can see other bytes after that, which seem to be other control bytes I don't know what they are. these are also not in the .fds/.qd but only in bin.
Then you see a gap of zeros followed by $8004, the start of the file data block after the 04 is 0x0a (ten) zeros. followed by the checksum 95f0 followed by four "x" the four "x" would seem to mean end of file data block. You can notice above at the beginning of photo, that file data block ends with four "F" why the difference? I don't know.
Now after the next gap of zeros is $8005. data block 05 is apparently invalid (so it seems). You can see the data in this block is nonsense, its just dbb66d repeated over and over. There is not even a checksum for this block. it goes on for much longer than in the photo, until address 13365 (end of bin file).
Here is the .fds dumped by hardcorehubz using fdsstick. You can see the usual stuf about the save file but with the checksum and extra control bytes ommitted. The 05 data block is included, but only 17 bytes of it for some reason. It was much larger in the bin. These 17 bytes included in .fds dump by fdsstick is a mistake/bug.
Here is a dump by gponys. This dump doesn't use fdsstick. But an older disk copy tool.
The 05 block is completely not present. Which is correct.
Even if you say "even though the data is garbage, it's on the disk! It must be included!" Well, just look at this.
This photo shows copying the entire 05 data block from the bin image and pasting it in the .fds. .fds files have a max file size of 65500 per side which ends on address ffdb. Notice the area I highlighted. Including the entire 05 data block would extend the image beyond the max size of 65500 until 65866 bytes!
If this was a .qd file which includes the block checksums, has a max image size of 65536, this would extend to 65902. This is why including this block in the .fds or .qd is a thing which is impossible. The physical disk size is actually larger than the user format area of 65500, there is a pregap of zeros before the main data and a post gap of (usually) zeros after the main data. This 05 data block extends out of the user format area and into the post gap area. This means this garbage data block can only be in the raw bin image dump. And cant be in the .fds or .qd dumps.
Hope that explains it.