This page documents the conversion process of .fcm to .fm2. It also documents known issues with conversion as well as known cases where conversion fails.
+FCEUX uses the file format .fm2. It does NOT play .fcm files (Older versions of FCEU). However any .fcm file can be converted to .fm2 by opening FCEUX and going to tools > Convert .fm2. You can mass convert files by highlighting them in the open dialog box. On the SDL build, you can run ./fceux --fcmconvert filename.fcm
+See also:
The old FCEUltra had a big problem with its movie recording. Every single movie was recorded with power-on, followed by a savestate. This means that WRAM (or save RAM) was being stored in its initialized state. As a consequence, many games that use save systems would go through an accelerated boot process since the save files were already initialized.
+Typically, a movie maker would load his game and let it sit at the title screen while he sipped his drink or adjusted his pants or steeled his nerves or whatever and then triggered the movie record. At that point the savefile was initialized, and the recording was already compromised. +
When preparing FCEUX for release, we decided that this was unacceptable. Therefore, every FCEUX movie is recorded from a fresh power-on with no WRAM or save RAM. Additionally, the "record from reset" was taken out because it is even worse. Now the game would be starting from initialized WRAM and initialized main ram. This can further confuse matters.
+So, your movies might desync because on FCEUX the game is taking longer to boot, while it is initializing its WRAM and/or main ram.
+Luckily, these are often easy to fix: since FM2 is a text format, it is trivial to insert additional empty frames into the correct locations during the game boot-up process. We have successfully used this approach to salvage a few movies. So, if you have trouble, let us know, and maybe since we have a bit of experience, we can help.
+Also, when a game is initializing, I bet it is uncommon for the RNG to be running so you might get lucky there also.
+Another trick is to add a boot-up time window to the beginning of your movie. Add empty frames to the very beginning, followed by the very first converted frame which should include a reset flag. This simulates what FCEUltra did, giving the game time to initialize its WRAM and possibly main RAM before your input events begin.
+We have been excruciatingly careful not to do anything else which would adversely affect synching. We take this seriously. We have only found few desynching movies so far that we aren't able to fix.
+Nearly all published .fcm files will convert without problem
+Exceptions are noted: +
Converting from FMV to FCM to FM2 may work, but it fails at least for these movies:
+Some movies will desync but can be fixed by adding frames to the beginning of the movie. Basically any movie that was recorded from soft reset and uses battery backed ram will probably desync. This is because the soft reset allowed the SRAM to be cleared ahead of time, so frames were not needed to clear it in the movie (This is arguably cheating anyway, and recording from soft reset was removed in FCEUX).
+Known desyncs that were fixed by adding frames:
+Movies that don't meet the above criteria but desync anyway
+FM2 is the movie capture format of FCEUX
+FCEUX uses a new movie file format - .fm2
+This differs from the previous FCE Ultra movie format (.fcm) in the following ways:
+FM2 is ASCII plain text. It consists of several key-value pairs followed by an inputlog section.
+The inputlog section can be identified by its starting with a | (pipe). The inputlog section terminates at eof. Newlines may be \r\n or \n
+Key-value pairs consist of a key identifier, followed by a space separator, followed by the value text. Value text is always terminated by a newline, which the value text will not include. The value text is parsed differently depending on the type of the key. The key-value pairs may be in any order, except that the first key must be version.
+Integer keys (also used for Booleans, with a 1 or 0) will have a value that is a simple integer not to exceed 32bits
+String keys have values that consist of the remainder of the key-value pair line. As a consequence, string values cannot contain newlines.
+Hex string keys (used for binary blobs) will have a value that is like 0x0123456789ABCDEF...
+GUID keys have a value which is in the standard GUID format: 452DE2C3-EF43-2FA9-77AC-0677FC51543B
+The inputlog section consists of lines beginning and ending with a | (pipe). The fields are as follows, except as noted in note C.
+| c | +port0 | +port1 | +port2 | +
Field c is a variable length decimal integer which is a bitfield corresponding to miscellaneous input states which are valid at the start of the frame. Current values for this are
+The format of port0, port1, port2 depends on which types of devices were attached.
+There is no key-value pair that indicates the length of the movie. This must be read by scanning the inputlog and counting the number of lines.
+All movies start from power-on, unless a savestate key-value is present
+If a fourscore is used, then port0 and port1 are irrelevant and ignored
+If fourscore, the input types must all be gamepads +
| c | +ABSTUDLR | +ABSTUDLR | +ABSTUDLR | +ABSTUDLR | +port2 | +
If fourscore is not used, then port0 and port1 are required
+FCEUX uses these framerate constants:
+