The desmume save file format is merely a raw save file with a FOOTER.

This was chosen in order to maximize compatibility with other emulators,
which tend load the savefile as-is and let the game read out of whatever range
it is expecting. To assist with this, before writing the save file, desmume
will pad the raw save file out to the next highest known length. Note that this
may sometimes be incorrect if the savefile hasnt been written through to the end
during initialization. This could cause other emulators to fail to recognize the
save file.

Additionally, the footer makes it easier to analyze save files, because the
game's data will be at the correct addresses starting at offset 0x0000.

The footer format can be identified by locating the 16Byte ascii string 
"|-DESMUME SAVE-|"
at the end of the file. This corresponds with the following save structure:

struct Footer {
	u32 actually_written_size;
	u32 padded_size;
	u32 save_type; //(not currently used)
	u32 address_size; //address bus size
	u32 save_size; //size parameter of the save type (not currently used)
	u32 version_number; //should be 0
	char cookie[16];
};

note that padded_size should be where you see the end of the raw save data
and the beginning of desmume-specific information, including some junk before
the actual footer.

actually_written_size is the highest address (plus one) written to by the game.

The new desmume savefile system tries to make as few decisions as possible,
which is the reason for the behavior of actually_written_size and the disuse
of save_type and save_size.  If few decisions are made, then few mistakes can
be made. That is the idea, anyway. We'll make decisions later if we need to.
save_type and save_size are reserved in case we do.