Topic: unmo3 writes out malformed IT files

[saga]

IT files generated by unmo3.exe/.dll can not load properly in trackers / players that read the edit history. While bit 1 (0x02) of the "special" flags is not set, it writes out two additional bytes before the MIDI config, which are only supposed to be there if an IT edit history is present. This effectively prevents the MIDI macros and plugin settings from being read correctly. Since many players and trackers rely on these two extra bytes without checking the "special" flag, the easiest solution would be set the flag and keep the two extra bytes there.

[Ian @ un4seen]

Ah, so that's what that "special" flag is for

Here's an UNMO3 DLL update that does as you suggest and sets the flag...

   www.un4seen.com/stuff/unmo3dll.zip

Do you happen to also know what the bit 2 (0x04) "special" flag is used for? It's set by Impulse Tracker too (like bit 1), but manually unsetting it doesn't seem to affect anything, eg. the file can still be loaded/played by Impulse Tracker.

[saga]

Thanks for the quick fix!
0x04 stands for "row highlights present", so it is correct that you don't set it in unmo3. if unmo3 wrote out row highlight information (the two bytes after the song name), this would have to be set, but since you simply put zero in those two bytes (first = rows per beat, second = rows per measure), it is correct to leave the flag blank.

[kode54]

So if "special" bit 1 isn't set, then there isn't supposed to be a word sized count before the MIDI data? DUMB ignores all but special bit 0 and 3, and reads a little endian word before the MIDI data, skipping 8 times that many bytes first. So I guess it's assuming there's an edit history there by the presence of its length field, even if the flag doesn't say it's there?

[saga]

So if "special" bit 1 isn't set, then there isn't supposed to be a word sized count before the MIDI data?

Correct. Luckily most trackers write both the "special" flag and the length=0 field, but early versions of Schism Tracker and (as reported here) old versions of unmo3 don't conform to that. For old versions of Schism Tracker, it's best to check if any of the parapointers would point into the edit history data and if that's true, ignore it. For detecting old versions of UNMO3, I use this code...

Code: [Select]

// Another non-conforming application is unmo3 < v2.4.0.1, which doesn't set the special bit
// at all, but still writes the two edit history length bytes (zeroes)...
else if(dwMemPos + 2 < dwMemLength && pifh->highlight_major == 0 && pifh->highlight_minor == 0 && pifh->cmwt == 0x0214 && pifh->cwtv == 0x0214 && pifh->reserved == 0 && (pifh->special & (0x02|0x04)) == 0)
{
const size_t nflt = LittleEndianW(*((uint16*)(lpStream + dwMemPos)));
if(nflt == 0)
{
dwMemPos += 2;
}
} ... which works because UNMO3 always sets the flag now.

[saga]

Hmm... I just noticed that unmo3.dll from January 19th also sets the 0x04 bit of the special flags now, so it claims to write song highlights, but those are 0/0. I suppose that flag slipped in there by accident?

[Ian @ un4seen]

UNMO3 has, for some reason, always set that flag (along with bit 3) when MIDI config is present. Here's an update that doesn't set it...

   www.un4seen.com/stuff/unmo3dll.zip

Let me know if you spot any more anomalies.

[saga]

Ok, this seems to work now. Thanks for the quick fix once again!