Idea: MAME Movie Maker

[Trimoor]

For those who miss MAME32's record AVI output feature, I present you a new idea: MAME Movie Maker.

It will be a separate application for rendering audio and video from MAME keystroke input files.

You simply play a game, and tell MAME to record your button presses.  Later, you load that file into MAMEMM, which presents you with options such as lead in and lead out points, resolution, and anti-aliasing.  You then select a video format and hit 'render'.

MAMEMM starts emulating from the point you specified, stepping frame by frame through the sequence, capturing each image.  The end result is a perfect movie with no dropped frames.

This is especially useful for games that don't run at full speed, like San Francisco Rush.

Notice--
This is only an idea.  I have no programming skills, and therefore will not be making this.
If anyone who has skills and is interested, go for it.

[Trimoor]

*bump* (<-what does that mean?)

No one has any comments?
No brave programmer willing to take upon this project for the good of the people?

[PacManFan]

I thought of this when I first put movie support into Kymaera. It would be a little tricky.
The way I envisioned it was that you would run an application, and it would launch each and every game in your rom directory with mame. It would then capture the video for a specified length of time,(either through mame or a 3rd party app),  and save the video to file as an avi with sound.

It sounds simple enough, but there a lot oif detail to work out. I could be up to the challenge, but I've got a lot of things on my plate right now.

-PMF

[Silver]

It would certainly help fill in gaps in the attract videos as well, as you could make-your-own by batch....

(shameless thread hijack: Any pointers to either 1)converting MNG to avi - this is appearing to be extremely hard to do without depacking every single frame to a PNG and reencoding by hand or 2) location of the crashtest MNG pack already converted that apparantly exists?)

You would also need to incorporate that patch that used to float around that let you 'skip' all the rom boot sequences (I think it just skipped rendering them so they were v fast) - the only catch was you needed to know the right # of frames to skip for each game. Howver this would be a good alongside project as anyone could chip in to build a database. Anyone know where the old patch info is held?

[SirPoonga]

If I remember, sometimes the mame keystorke recording gets off. It may not produce the same results consistantly.

[Howard_Casto]

also the "videos" would be essentially useless as they couldn't be played back in any fe short of launching mame in a window.  And that would bog down performance dramatically. 

About the mngs.... the trouble you are running into is in regards to the non-standardized format (which i keep telling everyone about but they tend to ignore it anyway)  it's hard to support a file format that is really a dozen or so formats and even then each format has it's own tweaks depending upon which editor made it. 

Like I always say, garbage in, garbage out. 

[Trimoor]

also the "videos" would be essentially useless as they couldn't be played back in any fe short of launching mame in a window. And that would bog down performance dramatically.

No, it would actually render the video using whatever codec you choose.

You would also need to incorporate that patch that used to float around that let you 'skip' all the rom boot sequences (I think it just skipped rendering them so they were v fast) - the only catch was you needed to know the right # of frames to skip for each game.

Why would you need that?  It doesn't start rendering until the point you specify.  It could even start from a save state instead of the beginning.

Not that it matters......

[mnm1200]

What about all those "initialization" screens as well. Would be no good to sit and record those...

[Trimoor]

What about all those "initialization" screens as well. Would be no good to sit and record those...

It doesn't start rendering until the point you specify.  It could even start from a save state instead of the beginning.

It starts rendering (not recording.  Rendering creates the image from the specified data--the saved state.  Recording captures events while they are happening.) at the save state.  This skips the startup screens.

It then plays out one frame of the game in accordance with the keystroke recordings, pauses, then renders that frame.  It may take slightly longer than recording, but the result is a perfect image with no dropped frames.

Not that any of this matters if no one wants to actually make this program.
It shouldn't be too hard; it can be done entirely in scripts.

[BuZz880]

Back when I used to use Advancemame it had its own scripting capabilities which I found easy enough to use to launch a game, wait some time then record for x number of seconds and exit but those were in MNG format so you still have this conversion to AVI problem unless you use Advancemenu for your FE. 

The final video product wasn't as good as the attract videos out there right now because an automated process doesn't alway start/stop in a place that makes sense. 

I do not know if Advancemame still has this capability or not, I suspect it does, I think I would have been using roughly V.56 or so.

[Silver]

My early point about the patch to skip startup screens was because I got it into my head we were talking about automatic recording, not manual - my mistake.

I'm not sure I see the point of recording keystrokes, to then use the recorded keystrokes to render a mame video. Why not just record the video in the first place?

[Trimoor]

Because some games might not run 100%. (most notably "Cruisin' USA")
Recording video in real time while playing some newer games puts a strain on the hardware, causing skipped frames and/or crappy gameplay.
Adding effects like anti-aliasing or interpolation makes things even slower.
It also allows you to edit the movies before rendering.  Saves time and HDD space.
IIRC, MAME dropped support for recording movies.  This gets around that witout altering MAME. (I hate typing MAME with one hand...)

Or maybe I'm entirely wrong. (You'd think that would teach me not to post at 4 AM)

[Howard_Casto]

Well I was unsure of what you wanted it to do.  On a third read it seems that you want to record inputs, and then play them back and record the output to video???

Why?  First off, the only thing 99.999% of the people want videos of are attract modes, which require no input.  Secondly, all major avi screen capture programs use hotkeys to start/stop capture, so you can easily start up a screen capture app, then start up mame, press the hotkey and record the video in real time.  Your method actually adds a few steps, plus the added hassle of writing a new app that must communicate with mame. 

Imho integrated video capture (like what advance mame does) has always been a bad idea.  Why?  Because it's inefficient.  With any other capture program you can set compression ratios and such and adjust the amount of frames that are captured per second, thus keeping you from filling up your harddrive and eliminating the need for re-encoding later. 

[Lilwolf]

Howard.. Do you know of any really good free/shareware/cheap programs to do it? 

I have a good one at work (SnagIt), but its licensed to the machine so I can t use it for a weekend.

Next question... Whats the chance that one of those could go into a wrapper?

[Howard_Casto]

Well to be honest, the freeware ones aren't all that hot.  However, the cost of these capture programs are usually 20 bucks or less.

I haven't done any in a long while, but I used to use hypercam.  It's very tiny and has good keyboard shortcuts.

About the wrappers...

It's simply not possible, and here's why:

It would be safe to assume that most people don't run mame games in their native resolution rahter they have them stretched up to 640*480 or greater right?

Well capture programs can't keep up when capturing a window that large.  When I capture video I launch mame in windowed mode with the games in their native resolution.  Even if they could, the distortion of shrinking an "enhanced" picture woudl cause artifacts.

Also there is the issue of directx.  In windowed mode it can be captured by most anything.  However, in fullscreen mode it can sometimes prove difficult.  It is possible, but the programs that can do it are generally more expensive. 


I like the idea though... perhaps there have been developements since I looked last. 

[Buddabing]

I think the attract movies are a good idea, but they are so large that it would be better for everyone to generate their own via a script or application. I've been trying for several days to get the attract videos via torrent and it's only 40% done. Plus, the torrent doesn't even cover all games.

There are so many games that it would be unwieldy to launch each individual game to record the start and end of each attract mode. So it would be nice to have an application to automatically do the capture.

The rendering part would be pretty straightforward. The tough part would be how to tell when the attract mode begins and ends.

Just thinking out loud here. The program would have to take a long sequence of frames and find out where there are two identical frames at least x frames apart.

It can probably be done. If I have time I'll see if the loop detection can be done without taking an eon. Then it would be a matter of patching MAME to launch a game, create a series of screen shots until the loop is detected, then terminate. Finally, some kind of postprocessing would have to be done to turn a series of pngs into a movie in whatever format, avi, mpeg, mng, etc.

It certainly is an interesting idea.

Buddabing

[Trimoor]

I guess my original idea was to render avi's to use in ameture movies/videos.
I had a few ideas once for an arcade themed movie, but I couldn't find a way to capture video from MAME.

Bah, if anything turns out of this, I will be happy.

[Howard_Casto]

I think the attract movies are a good idea, but they are so large that it would be better for everyone to generate their own via a script or application. I've been trying for several days to get the attract videos via torrent and it's only 40% done. Plus, the torrent doesn't even cover all games.

There are so many games that it would be unwieldy to launch each individual game to record the start and end of each attract mode. So it would be nice to have an application to automatically do the capture.

The rendering part would be pretty straightforward. The tough part would be how to tell when the attract mode begins and ends.

Just thinking out loud here. The program would have to take a long sequence of frames and find out where there are two identical frames at least x frames apart.

It can probably be done. If I have time I'll see if the loop detection can be done without taking an eon. Then it would be a matter of patching MAME to launch a game, create a series of screen shots until the loop is detected, then terminate. Finally, some kind of postprocessing would have to be done to turn a series of pngs into a movie in whatever format, avi, mpeg, mng, etc.

It certainly is an interesting idea.

Buddabing

This seems like a rather brilliant way to do it if you ask me. 

The only thing that might keep it from working is mame itself.  I dunno if every frame is exactly the same each time it's rendered.  If it is then screencaptures and crc checks would be needed.  Unfortunately, even the most powerful pc isn't going to be able to capture an uncompressed frame, 60 frames per second, and if it does, that's gonna be a big set of files.  Also of note is the fact that some attaract modes are several minutes long.  Take tmnt, for example.... when I captured that one I stopped at leonardo (the 4th time through attract)  and skipped the bios on splinter and april because that was a full 3 minutes and 30 seconds of video! 

It's one of those things that I think is possible, but I'm not sure how to go about it. 

[Buddabing]

This seems like a rather brilliant way to do it if you ask me.

[terryd]

One question, why do the videos need to be full quality?  I think the original idea was to make the videos play in an FE...  Therefore one could take the original movie (whatever format) full resolution speed, etc...  and then reduce the quality and size to fit an FE accordingly.  One could even remove the sound to make the file size smaller.  This would be long and process intensive to create the movie, but you would only need to do it once for each game you want to have a movie for.

You're right that a full screen video is quite large, but a reduced size and quality would be significantly smaller.  Even a movie at 20 FPS would be something I would think is pretty cool looking in an FE.

[Silver]

This does sounds good.

The scripting would allow people to not only make there own, but choose there own quality too - and whether to include sound etc...  If 99% of people are using this for attract in an FE - would they want a full 3 minute attract? - Again, you could set the max length in script...

You could save all the PNG's, then call up an encoder, delete the raw pngs and move on to the next game. There are some capture codecs that can do real time compressed capture but thats probably a lot more fiddly and not necessary at all.

I think this would be a great app. I still think there a couple of issues - I still think skipping the recording of the bios checks is necessary (some are long) which is fine doing it manually but not for automated. Even is there is no way of working this out all it requires is a database to be created/hosted somewhere and people could submit......

[Trimoor]

It doesn't need to capture the frames the first time around.  Just set it loose to examine every frame and record a hash.  When it finds the repeat hash, it fires up the encoder, capturing exactly the frames it needs, not necessarily in real time.

Two problems though.

What if the attract contains two duplicate frames right next to each other?
What if the attract has a beginning that doesn't loop?

[Buddabing]

It doesn't need to capture the frames the first time around.

[Silver]

The loop algorithm is clearly the key....

although detecting start/to/start frames would actually avoid recording all the bios startup stuff on most games which is handy......

I think there would always be a few games that would slip though the net but getting most of them automated would still be a huge advantage - and the problems could be accounted for as they appeared.....

[Howard_Casto]

One question, why do the videos need to be full quality?

[Buddabing]

Hello,

I've done a few experiments with the ideas presented in this thread. Here are my findings.

It is trivial to generate the series of screen shots. It's a one line change to usrintrf.c. I also changed a few lines in common.c to do the checksum.

Frames are often repeated 20 or more in a row.

The MD5 checksums of the first frame of the demo and the first frame of the second demo match up. So, in theory, the loop detection algorithm can be done.

I ran MAME with these options to get the screen shots:

mame pacman -window -noafs -frameskip 0 -matchrefresh -resolution 224x288 -switchres 0 -skip_gameinfo 1 -skip_validitychecks 1 -intmakectrl 0 -extmakectrl 1

[Silver]

Buddabing - thats outstanding work, nice one for getting on this so quick.

Does the png creation happen in realtime? or fast-as-possible?

How large were all the png's?

I#m not sure why you convert PNG->PPM? I believe you can convert png to mpeg/avi direct... I will track down the software/plugins I've seen. There may also be an AVIsynth plugin that takes PNG's, allowing either direct playback or very easy integration to any video app/codec....

Skipping the ppm step would save lots of space and time.....

Seeing as speed/space will be an issue, I can't recommend mpeg.  Mpeg2 is fine at high bitrate or when real-time is needed (Digital TV/DVD) but there are much better results to be had. I believe Xvid is an open source project, although can check....

Dropping 1 frame in 2 would be a good start, getting a playback friendly 30fps, as well as halving the size right at the start.

I'm not interested in sound either, but out of curiosity whats the problem - I thought mame could write the sound output directly to WAV or something at emulated speed...? Apologies if this is naive....

[Silver]

Here it is:

http://www.avisynth.org/ImageSource

This avisynth (you may not know this tool, but its *unbelieveably* handy if you play around with video much) plugin can take a series of images, including pngs,  and feed them into almost any application, appearing as a standard video stream for compression.

You can also set the fps etc all in a script so it would be easy for adjusting for different fps games.....

EDIT: Getting my hands dirty.....

 OK This Imagesource() is actually now in built in to recent versions of AVISynth so it supports pngs natively.

As a quick and dirty test I decoded 19xx.mng from crashtests MNG collection - its 108 png files (I used advmng). I then made this 1 line script file:

http://www.silverfoxy.plus.com/19xx.avs

Which you can open in any media player (once you install AVisynth) and watch like any normal avi.

I then ran this through VirtualDub and compressed with Xvid. Resulting Avi here:



Did not mess with any settings, video is 250k looks high quality, 108 png files were 1.2meg. Compression took under 5 seconds. Whole above process manually took me less than 5 mins including ripping mngs and learning the syntax for imagesource().

I believe generating all the avs script files will be easy to automate (and thus quick) and I'm sure there are lots of batch encoders out there (in fact virtualdub supports scripts/batch processing I believe)

[Buddabing]

Buddabing - thats outstanding work, nice one for getting on this so quick.

Does the png creation happen in realtime? or fast-as-possible?

How large were all the png's?

I#m not sure why you convert PNG->PPM? I believe you can convert png to mpeg/avi direct... I will track down the software/plugins I've seen. There may also be an AVIsynth plugin that takes PNG's, allowing either direct playback or very easy integration to any video app/codec....

Skipping the ppm step would save lots of space and time.....

Seeing as speed/space will be an issue, I can't recommend mpeg.

[Silver]

The mpegdecoder requires either ppm or some other format image, that's why I used that.

Ah good - so we can skip that one.....

I am slightly familiar with avisynth from the work I've done on Daphne. I'll experiment with it. I had written a program to generate avs scripts to improve the image quality of the Space Ace video captures. Thanks for the lead, I had forgotten about it.

Excellent, its a extremely basic script.

The 4700 pngs from the pacman attract mode were only about 18 megabytes.

Good I was worryed it was going to be massive!

The problem with dropping every other frame is that it wouldn't work exactly. Pacman is 60.6060606 (2000/33) frames per second, not exactly 60. But if avisynth can take care of that issue, then we should be golden.

Check my previous post - you can set the fps exact in the script, and in the docs its happy with stuff like 29.97 etc..etc... floating fps. Will have to test this though.

I've played around with the loop detection algorithm, and it works for pacman, I'll try with some other games. Basically, I keep a file of the frame number and md5 checksum of each frame. Whenever the md5 changes that means the frame has changed. Then I check the file for an identical checksum back in the past. If an identical checksum has occurred relatively long ago, then we're at the end of the loop. Otherwise, the md5 is added to the file. The time has to be enough so that a single flashing light on then off again won't trigger the loop detection.

This is the clever bit, nice one. Out of curiosity, is it easy to keep a record of the 1st frame that you find a match to the last one? ie in pacman, if the lastone is 4700 I presume the first one is eg 150 or something after the bios checks. If you simply add the 150 to the script as the start frame, it will automatically only render the stuff AFTER all the bios stuff.....

Well whaddya know! -wavwrite <filename> (windows only apparently)

The question is how the sound will be affected given the video lag.

Well the good news here is that recording a wav and then speeding up the emulation by releasing the throttle (up to 450% realtime in test) it obviously sounds horrendous in play, but the WAV file is redorded in REALTIME (ie sounds perfect) so this should happen at slow speeds too - meaning I think we can record sound (in windows) easily! Cutting the bios might be an issue here though - although we could be talking about an easy time calculation: get fps of game, get # of start frame - multiply etc..etc... = exact time to cut off start of wav. I've used commandline tools in the past to cut wavs so that could be done.....


I'm liking this quite a lot....

[Buddabing]

This is the clever bit, nice one. Out of curiosity, is it easy to keep a record of the 1st frame that you find a match to the last one? ie in pacman, if the lastone is 4700 I presume the first one is eg 150 or something after the bios checks. If you simply add the 150 to the script as the start frame, it will automatically only render the stuff AFTER all the bios stuff.....

For the pacman loop I captured, frame 289 and frame 4697 are identical. So, we would take the 4409 frames, divided by 60.60606, gives 72.75 (roughly) seconds for the demo. So all we'd have to do for the audio is chop off the first 289/60.6060606 = 4.7685 seconds. That is, if the start of the audio matches the first png.

Here's an excerpt of the file containing the checksums:
E252A2D0BE0D3524F85CA1B211F2B6AB

[Silver]

That is, if the start of the audio matches the first png.

We will have to try it and see!

We may be able to get Avisynth to do this as it goes too... I've had a quick look and it can easily take the wav source and chop it to be the same length as the video , although it defaults to chopping off the end of the audio which is not what we want. Will probably need some experiemntation to iron out issues etc..etc.. but very doable....

Also, you will be automatically discovering the start frame for the end-of-bios-setup point for all the games. I was after this AGES ago when someone came up with a patch to skip video rendering of the first x frames (goes v fast) Catch was you had to know how many frames - this process tells us, so if that patch is still around, we could easily make a DB of all the games start screen frame points....

Obviously some games with strange/no attracts might need to be sorted....


EDIT: Buddabing, can you email me the pacman sample pngs? (including bios stuff) (zipped or somehting) Then I can generate the audio here and play around with avisynth to see what works. (try and match up the start of the audio....)  silver@silverfoxy.plus.com

one way of doing this is to create the video including bios stuff so that the audio is synced, and then chop the stream after x frames - this is easy and can be done in 1 script.

EDIT2: Hmmm Pacman attract is soundless, so maybe not best test option......  any others working?

[Buddabing]

Silver:

Zookeeper is one of my favorite games. It has a big, fat, obnoxious attract mode, so it will be a good test case. I'll email you the pngs as soon as I can.

I've integrated all the png generation and loop detection into a selectable MAME option. I'll put the code into a patch when it's finalized.

My initial loop detection algorithm was a bit slow, Zookeeper ran at about 8 frames per second. My new algorithm runs at 32 fps. I used a bucket sort. Instead of searching a whole file of the md5 checksums each time, I take the first two hex digits of the md5 and make an 8-bit index out of it, which points to one of 256 "buckets". Then the bucket is linearly searched for an exact match of the md5. A bucket sort is ideal for this kind of data, where each bucket will on the average have the same number of entries in it.

I would like to delegate the generating of the movie from the pngs and the integration of the sound to you. It's the hard part of this project, but you are more experienced at those kind of projects than I am, and I have a lot on my plate right now.

The project should generate the movies from a list of rom names the user provides. My ListGen utility can generate the rom names, or the user can hand-edit one. Then I can write something to convert the rom names into a batch file to call MAME to create the pngs and call your stuff to generate the movies.

I'll run a few more games to see if something needs to be tweaked.

Regards,
Buddabing

[Silver]

Just thought I'd surface for air, and ask if anyone had any recommendations or thoughts on compression formats for creating attract videos.

In my testing I've just been using Xvid and cbr MP3. The results look great to me but I've not been compressing to a low bitrate. Xvid's encoder also has a "cartoon" mode which is meant to be good for these kind of cartoon graphics from mame.

Someone pointed out to me that the modern compressors, like Xvid/DivX/wmv are good but much more cpu intensive than older codecs, like mpeg2 - and some people may be running cabs with slower pc's. Seeing as the most common use for these videos is attract screens, I don't think it will be a problem for most people running a windowed video in a FE, but I thought I'd check for feedback or suggestions for other codecs to try...

Obviously, it will probably end up being a matter of choice for each person, but thought I'd check anyway.

Also, this project has thrown up an easyish way of batch converting Crashtests 4gig MNG collection to standard avi's so they can be used in other FE's not just advance mame. Any interest in this?

[Trimoor]

Why not just leave them as PNG/MNG?  They use very good lossless compression, and disk space is becoming cheaper all the time.  MNG is perfect for still backgrounds with moving sprites.  It renders the background once, then puts the tiny sprites on top of it.

I've heard that Xvid is better than Dixv, but I think the cartoon mode refers to line art drawings (think classic warner brothers) rather than sprite based graphics.

MPEG codecs will destroy the video, as evident by the pacman video.

Please don't use WMV.  Micro$oft has enough of a monopoly already.  It's bad enough that they will get the standard for HD DVD when there are dozens of better free codecs available.

For audio, I highly recommend Ogg Vorbis.  It's just like mp3, but better quality, and freeware.  If you wanted to go lossless, use FLAC (Free Lossless Audio Codec).

BTW, there is no such thing as a "standard" avi.  Every avi must use a audio and video codec.  These can be anything, even mpeg. (For some stupid reason mpeg uses it's own extention.  Motion picture experts ---my bottom---.)

[Howard_Casto]

first off, I think that budda has done a great job with his tests.

[Silver]

Thanks all for your comments.

Why not just leave them as PNG/MNG?

Agreed - I've had to study up on it, and its great and well suited to this kind of video. Unfortunately, I have found it to be extremely badly supported in windows. There are numerous viewers, but several reject certain pngs (I believe the viewers are out of date) and most will only read frame 1 of a MNG. I have found no codecs to allow MNG playback though standard media players at all, meaning FE writers would have to support it themselves. If they did, I would not be on this thread...

I've heard that Xvid is better than Dixv, .....

Yep Xvid seems to be best of the bunch, and free.

For audio, I highly recommend Ogg Vorbis.

Great suggestion thanks. I've been using mp3 as I have the codec installed, but will check out Ogg.

first off, I think that budda has done a great job with his tests.  Unfortunately, he ran into the exact same problems I predicted he would.  The biggest problems being file size and audio syncing. 

Yes I'm very impressed with what Buddabing has managed to do. However, file size and audio sync do not appear to be an issue. Using PNG's Buddabing sent me and extracting WAVs usings mames -wavwrite option, you can create avi's in codecs of your choice. The PNG's are not converted to anything (so disk usage is 'tiny') and there are no audio sync issues so far. (more testing required).

I've written a crude VB6 program that automates the MNG/PNG -> AVI. At the moment it will convert Crashtest's MNG collection, but it can be adapted easily to take mames png/wav output.

In terms of speed, its possible to run mame at max speed (no throttling) and keep things synced, although I suspect saving all the PNG's will slow it down a bit. The encoding is also faster than realtime on my machine.

  The biggest difference you'll see on lower-end systems is the delay between when the video is called and when the video actually starts playing.  Even on the slowest of machines it is hardly noticable. 

Thanks thats what I suspected, but wanted to check!

[Buddabing]

I've done some tests on other games. The loop detection code finds a loop on almost all of them. I have run into a problem, however.

About half the games I tested, while running their attract mode, fade or transition to black while the attract mode is running. This can cause the loop detection to trigger. Gorf, for example, will hit the loop detection when the attract mode transitions from the space warp screen to the flagship screen.

One solution is to have a threshold value. If the red, green, or blue value of any pixel in the image is above the threshold, the loop detection is disabled for that frame. I would set the default threshold to 2 or 3.

Hopefully the threshold detection won't cause a horrible performance penalty.



 

[Silver]

One solution is to have a threshold value. If the red, green, or blue value of any pixel in the image is above the threshold, the loop detection is disabled for that frame. I would set the default threshold to 2 or 3.

Hmmm interesting. Does the loop detection trigger when the fade hits pure black? And if so does this create a MD5 checksum that is always identical for black screens across all/several games? If so you could just ignore that one checksum value, rather than checking for all pixel values?

[Buddabing]

One solution is to have a threshold value. If the red, green, or blue value of any pixel in the image is above the threshold, the loop detection is disabled for that frame. I would set the default threshold to 2 or 3.

Hmmm interesting. Does the loop detection trigger when the fade hits pure black? And if so does this create a MD5 checksum that is always identical for black screens across all/several games? If so you could just ignore that one checksum value, rather than checking for all pixel values?

Different sized black images will give different MD5s, as will different pixel depths. So that solution wouldn't work.

The performance hit isn't horrible. Zookeeper dropped from 32 fps to 28. If necessary it can be improved somewhat, I'm just using the canned MAME png handling routines.

[2600]

What about a double detection?  You also may need an option to detect for a certain amount of loops, some attract modes change after they have run a few times.

[Buddabing]

What about a double detection?