The 8 bytes after a drumroll are NOT just padding, as
`fumen2osu.py` assumed. There is some kind of metadata here;
I just need to determine what it stands for.
On at least one song I've tested, this creates a perfect match,
meaning that we now have the ability to create a fumen file
from a "song" object.
The next challenge is reading TJA files into "song" objects.
The original `readFumen()` function ignored storing information
that was irrelevant for writing osu files.
Now, however, we store this information for the purposes of
*writing* valid fumen files.
Although much of this information is probably irrelevant, doing so
ensures that we can get a 1:1 match between input and output,
which builds a solid foundation for converting TJAs to fumens.
This seems to contain metadata that was ignored by the
original `readFumen()` function. I'm curious to explore
what these values represent, and how they vary from
fumen to fumen.
Having multiple note values map to identical strings
(e.g. "Don", "Ka", "DON", "KA") caused issues when
writing these strings back to .fumen files.
So, we make sure that each note type has a unique
string associated with it.
