So the "v1.2" is always the same, right? Sounds like a good bet.
A standard CRC32
is four characters. Here's what I tried just now:
-Open the file in a hex editor.
-Delete the first four characters.
-Save the file.
-Compress the file with a standard .zip archiver (I use IZArc).
-Open the .zip file and check the CRC32 of the file. (Most archivers have an option to let you see this one way or another.)
-If the CRC32 is 5EE7D422, then that's how the checksum is calculated.
-If not, try deleting the next character at the start of the file (i.e., the "v" for starters) and repeat the process.
Unfortunately, repeating this for several iterations has not yielded any success so far, and I don't feel like knocking together a program to automate the process, especially since there's no way of knowing if it is in fact CRC32. It could very well be an entirely custom algorithm, but that seems unlikely. (I remember reading about how Final Fantasy V uses a custom algorithm
for its checksum.)
Perhaps there are some generic DLLs included with the program? If it uses some standard library (especially if it has a version number of "1.2"), perhaps that will be a good indicator of where to look.
The alternative to mucking around in the dark would be to somehow debug the program (OllyDbg, maybe?) and see if you can isolate whatever checksum function it tries to run when loading the file. It might even be possible to just disable that function entirely, so the program will load files even with bad checksums.
Or maybe someone helpful will just step in here and tell me I'm completely wrong and solve everything.
ETA: Wikipedia links to this program
which is advertised as supporting a bunch of different CRC checks, except it requires MSVCR110D.DLL to run which is apparently a debug version of the standard redistributable library and I don't think I want to follow this rabbit hole any further.
ETA2: Hex Workshop can probably calculate CRCs on its own; check the menus. Whoopsies.
Perhaps you should upload another MLT for comparison?