#ANIM file format/Dpaint
13 messages in this thread
Hi! I hope there's somebody that's familiar with ANIM format files.
While this is addressed to EA, I'll appreciate anyone else's help too if
you think you've got some info.
I spent 8-9 hours working on some animated graphics in Deluxe Paint III
version 3.01, and as I was saving my work for the last time I ran into a
Disk Full error on my hard drive. I had Workbench active, so I started
moving files to a floppy so I'd have some room. Before I got back to
Dpaint, it had already resumed saving the file (maybe sensing that there
was now room, or maybe somehow I hit a key that told AmigaDOS to "Retry"
saving the file). So far so good. This happened a second time, except this
time it waited until I hit "Retry". Fine — I wound up with about a 540k
file.
The end result: somehow the file got trashed. ShowAnim says there's not
enough memory for bitmaps; Movie just says there isn't enough memory.
(There is; I"ve got 3 megs and naturally there's less in memory than when I
created the file with the paint program.) Dpaint just says the file is
damaged. One ray of hope: SuperView CAN display it but there's minor
garbage that pops up at the beginning and stays throughout, and the very
end has major problems. If left running SuperView crashes.
My main question: is there a way to somehow rescue this file? The
beginning is the critical part (because it seems to be reasonably intact),
although I'd love to be able to manually truncate the file to approximately
the point where it's messed up without a trial-and-error go-round with a
sector editor. And my secondary, but no less important, question: has this
problem been looked at in later versions of Dpaint? 🙂
Thanks for any help you can think of.
=Tom=
I think there's a set of utilities in library 14 that may be of some use to
you. It's called CYROUT.LZH, and it has four different anim utilities,
including a anim splitting utility and a utility to extract info from
anims.
Now, if those don't work, there's a more round about way that may work. You
can use the -j option in SuperView to pause between frames, and then use
the utility SCREENX (or any other screen grabbing utility) to grab the
screen while it's displayed. After you have each of the screens saved, use
the program MakeANIM (I think it's in the CRYOUT.LZH archive) to combine
all the screens together.
Let me know how this turns out.
Steve
Thanks much for the ideas, Steve — definitely worth a shot. Although,
the SuperView -j option with ScreenX would take a good while; there're
about 180 frames! Heh. It's a good option to keep in mind for future use,
though. 🙂
=Tom=
Without knowing the file format intimately, I would not be able help you in
this case. If dpaint is telling you the file is corrupt, then there is
something wrong with the structure. If you can find out what got corrupted
and somehow modify it in some editor, then you may be able to save the
file, otherwise you may be out of luck.
Can anyone else help out?
Orlando/EA:HQ
Thanks for the thought, anyway. If you know anyone or anywhere you can
recommend to try for info on the file format, please yell!
=Tom=
Call CATS (Commodore Amiga Tech Support) 215-431-9100. The IFF docs are
also published in the Amiga ROM Kernal Manual. Besides, I would think the
IFF docs, would be here on CIS somewhere buried in a Library. Ask one of
the SYSOPs if they know. I hope you can salvage your file. Let me what
turns up.
Orlando/EA:HQ
Okay, I'll letcha know how it goes. I might try CATS after I check some
of the software libraries. Thanks!
=Tom=
Tom – kinda sounds like perhaps the total IFF file size is wrong in the
header. Can you email me a dump of the first 512 bytes of so of the file?
And tell me how long the whole file is now?
For that matter, hmmm. Do you understand IFF layout? You could use a
sector editor to zap the "correct" size in (a smaller size) which might let
normal tools work right. The second longword in the file is that size. It
should the length of the entire file – 8.
By searching for the words "FORM", 4 byte len, "ILBM","ANHD" in the file,
you'll also run across each frame section. Figure out the last good one,
and reset the main filesize to match the total good section.
I know this sounds muddy, but it's easier than it sounds 😉
Kevin, I'll sure give it a shot! It doesn't sound muddy at all. If I
don't get anywhere with it I'll try emailing you that 512 bytes, but it
sounds like you gave me a good running start. Thanks muchly!
=Tom=
Tom, I should've done this before, but maybe this will help you out also.
IFF always has FORM,size,data. The data itself may include embedded FORMs.
This example is taken from a real IFF. At the very beginning is the
_total_ FORM size which follows. In this case, $00026CB6. The file size
you see on disk will be that plus the 8 byte header, so the total size is
$00026CBE.
0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E
0000: 464F524D 00026CB6 414E494D 464F524D FORM..l6ANIMFORM
0010: 00005AE4 494C424D 424D4844 00000014 ..ZdILBMBMHD….
The first embedded FORM is the main picture, which is $00005AE4 long. So
by adding that count plus the beginning of the actual subform data ($0014),
we determine that the next embedded FORM should begin at $5AE4+$0014=$5AF8.
And yep, sure enough:
5AF0: B100B100 B100B100 464F524D 000024C4 1.1.1.1.FORM..$D
5B00: 494C424D 414E4844 00000028 05000280 ILBMANHD…(….
We found the first of the embedded ANIM forms, which contain the delta data
for each frame. That one is $000024C4 long. Again, we expect the next one
at $24C4+$5B00=$7FC4. And there it is:
7FC0: 00000000 464F524D 00002750 494C424D ….FORM..'PILBM
7FD0: 414E4844 00000028 05000280 01900000 ANHD…(……..
Continue to follow the chain through, and write down the position and size
of each anim chunk. By diddling the original total filesize at the
beginning, you can artificially change the "number" of frames down to the
number which are still uncorrupted in your file. Luck! – kev
——————————————————–
-> Tom, I should've done this before, but maybe this |
-> will help you out also. |
——————————————————–
Wow — that's quite a tutorial! I sure appreciate all your trouble. I'll
do some digging into the file this weekend (actually, a backup copy for
safety) and see what happens. 🙂
If I had only had bought a box 'o floppies before I started this project
I wouldn't have had to delete the intermediate version to save the "final"
version. *sigh*
=Tom=
Glad to help, Tom. Hope it all goes okay. Actually, I kinda like the
ideas others had of playing it back very slowly, and capturing each frame
to disk (if there's room).
I keep threatening to post the IFF specs, and will do so soon. In any
case, best of luck… and let us know if you manage to save any of the
file!
– kev
I'll definitely letcha know how it goes, Kevin. I got stuck working this
weekend so I guess it'll wait awhile longer. *sigh*
=Tom=