by randi » Mon Sep 19, 2005 6:00 pm
Did it, now that I know IMF is little more than a raw dump of OPL commands. Adding support for it was very easy, since I already had code to handle RDosPlay's RAW files. IMFs are essentially a more limited version of the same thing.
However, there are actually three IMF formats. I have chosen to support only one of them: The type with a header, so it can actually be identified automatically. If you have a hex editor, converting from the other two formats is extremely simple:
- If your file starts with the five letters "ADLIB", you don't need to do anything. It already has the header.
- If either of the first two bytes of the file are non-zero, insert two zero bytes after the first two bytes. Otherwise, add four zero bytes at the start of the file.
- At the start of the file, insert the following nine bytes (in hexadecimal): 41 44 4C 49 42 01 00 00 01
- If you did steps 2 and 3 correctly, your file should now be eleven or thirteen bytes larger than it was before.
Example, from a Corridor 7 song.
For this song, the first 32 bytes are:
00 00 00 00 BD 00 00 00 08 00 00 00 20 00 00 00
23 00 00 00 40 0B 00 00 43 00 00 00 60 A8 00 00
This is headerless, so we need to convert it using steps 2 and 3 above.
Step 2. The first two bytes of this file are both zero, so add four more zero bytes to the start of the file. The first 32 bytes of the file now look like this:
00 00 00 00 00 00 00 00 BD 00 00 00 08 00 00 00
20 00 00 00 23 00 00 00 40 0B 00 00 43 00 00 00
Step 3. Insert nine bytes at the start of the file. The first 32 bytes of the file now look like this:
41 44 4C 49 42 01 00 00 01 00 00 00 00 00 00 00
00 BD 00 00 00 08 00 00 00 20 00 00 00 23 00 00
This song has now been converted to the IMF-with-header format. It has grown thirteen bytes in size.
Here is another example from a different song (titlermx.imf).
This time, the first 32 bytes are:
90 2F 00 00 00 00 01 00 00 00 02 00 00 00 03 00
00 00 04 00 00 00 05 00 00 00 06 00 00 00 07 00
Step 2. The first two bytes are not both zero, so insert two zero bytes after them. The first 32 bytes of the file now look like this:
90 2F 00 00 00 00 00 00 01 00 00 00 02 00 00 00
03 00 00 00 04 00 00 00 05 00 00 00 06 00 00 00
Step 3. Add the nine header bytes to the start of the file, which leaves the first 32 bytes looking like this:
41 44 4c 49 42 01 00 00 01 90 2f 00 00 00 00 00
00 01 00 00 00 02 00 00 00 03 00 00 00 04 00 00
This file is now also in IMF-with-header format. Unlike the first example, it has grown only eleven bytes because we only needed to insert two zero bytes for step 2.
Did it, now that I know IMF is little more than a raw dump of OPL commands. Adding support for it was very easy, since I already had code to handle RDosPlay's RAW files. IMFs are essentially a more limited version of the same thing.
[b]However[/b], there are actually three IMF formats. I have chosen to support only one of them: The type with a header, so it can actually be identified automatically. If you have a hex editor, converting from the other two formats is extremely simple:
[list=1][*]If your file starts with the five letters "ADLIB", you don't need to do anything. It already has the header.
[*]If either of the first two bytes of the file are non-zero, insert two zero bytes after the first two bytes. Otherwise, add four zero bytes at the start of the file.
[*]At the start of the file, insert the following nine bytes (in hexadecimal): 41 44 4C 49 42 01 00 00 01
[*]If you did steps 2 and 3 correctly, your file should now be eleven or thirteen bytes larger than it was before.[/list]
[b]Example, from a Corridor 7 song.[/b]
For this song, the first 32 bytes are:
[color=green]00 00 00 00[/color] [color=blue]BD 00 00 00[/color] [color=green]08 00 00 00[/color] [color=blue]20 00 00 00[/color]
[color=green]23 00 00 00[/color] [color=blue]40 0B 00 00[/color] [color=green]43 00 00 00[/color] [color=blue]60 A8 00 00[/color]
This is headerless, so we need to convert it using steps 2 and 3 above.
Step 2. The first two bytes of this file are both zero, so add four more zero bytes to the start of the file. The first 32 bytes of the file now look like this:
[color=green]00 00 00 00[/color] [color=blue]00 00 00 00[/color] [color=green]BD 00 00 00[/color] [color=blue]08 00 00 00[/color]
[color=green]20 00 00 00[/color] [color=blue]23 00 00 00[/color] [color=green]40 0B 00 00[/color] [color=blue]43 00 00 00[/color]
Step 3. Insert nine bytes at the start of the file. The first 32 bytes of the file now look like this:
[color=green]41 44 4C 49[/color] [color=blue]42 01 00 00[/color] [color=green]01 00 00 00[/color] [color=blue]00 00 00 00[/color]
[color=green]00 BD 00 00[/color] [color=blue]00 08 00 00[/color] [color=green]00 20 00 00[/color] [color=blue]00 23 00 00[/color]
This song has now been converted to the IMF-with-header format. It has grown thirteen bytes in size.
[b]Here is another example from a different song (titlermx.imf).[/b]
This time, the first 32 bytes are:
[color=green]90 2F 00 00[/color] [color=blue]00 00 01 00[/color] [color=green]00 00 02 00[/color] [color=blue]00 00 03 00[/color]
[color=green]00 00 04 00[/color] [color=blue]00 00 05 00[/color] [color=green]00 00 06 00[/color] [color=blue]00 00 07 00[/color]
Step 2. The first two bytes are not both zero, so insert two zero bytes after them. The first 32 bytes of the file now look like this:
[color=green]90 2F 00 00[/color] [color=blue]00 00 00 00[/color] [color=green]01 00 00 00[/color] [color=blue]02 00 00 00[/color]
[color=green]03 00 00 00[/color] [color=blue]04 00 00 00[/color] [color=green]05 00 00 00[/color] [color=blue]06 00 00 00[/color]
Step 3. Add the nine header bytes to the start of the file, which leaves the first 32 bytes looking like this:
[color=green]41 44 4c 49[/color] [color=blue]42 01 00 00[/color] [color=green]01 90 2f 00[/color] [color=blue]00 00 00 00[/color]
[color=green]00 01 00 00[/color] [color=blue]00 02 00 00[/color] [color=green]00 03 00 00[/color] [color=blue]00 04 00 00[/color]
This file is now also in IMF-with-header format. Unlike the first example, it has grown only eleven bytes because we only needed to insert two zero bytes for step 2.