Frame timing and playback

Playback speed is stored as a code, not as a duration beside every frame. A player uses that code to time frame changes and advance the playhead. The music track has its own speed field. Keeping those clocks distinct prevents the common error where a Flipnote runs at the right visual speed but its audio is pitched incorrectly. [1][2]

Playback cycle

1. Determine the current frame index and its deadline from the animation speed.
2. Decode the frame, reconstruct any translated difference against the prior frame, then present it using the frame palette and animation-header visibility.
3. Read that frame's sound-effect flags and trigger the corresponding tracks.
4. Advance or loop, resetting event state with the frame clock. [1][2]

Seek and pause are separate cases

Seeking to a frame should not automatically replay every skipped effect, while normal playback should not miss an effect when rendering is late. An implementation must define how it handles the clock under lag, pause and loop. The research identifies timing routines and effect handling, but does not yet reproduce every build's output pixel for pixel and sample for sample. [1]

Verification fixture

Use a note with effects on adjacent frames, another effect on the final frame, and unequal BGM and animation speed codes. Log the playhead and trigger indices over two loops; listening alone makes one-frame errors difficult to locate. [1][2]

V2 playback and frame updates

V2 handles playback separately from the drawing document and will not start it while recording is active. A populated music track prepares an ADPCM stream; an empty music track still starts the alarm that drives frame advancement. The frame clock handles countdown, cursor movement, frame rendering, effect triggers and end cleanup. It must therefore continue to run for a silent Flipnote. [2]

The documented callback order advances the countdown and frame cursor, presents the new frame and triggers its effects before terminal cleanup or a loop restart. JP and US V2 use framework counter +0x40 and countdown +0x1A; EU V2 uses +0x44 and +0x1C. These offsets refer to the examined in-memory objects, not positions in a file. A hard-coded US memory layout will read the wrong EU state. [2]

Navigation is a different frame path

Moving to the previous or next document frame decodes image state and updates the editor display without necessarily starting the playback clock. Previous at position zero returns before copying or rendering; moving to a present next frame selects difference or absolute decoding. A player that seeks by replaying a timer callback may accidentally fire sound effects that ordinary editing navigation would not. [1]

Comparing the eight playback settings

1. Speed 10.5 fps
2. Speed 21 fps
3. Speed 32 fps
4. Speed 44 fps
5. Speed 56 fps
6. Speed 612 fps
7. Speed 720 fps
8. Speed 830 fps

The bars use a linear scale from 0 to 30 frames per second. Speed settings run from 1–8. The byte stored in the file counts in the opposite direction: subtract it from 8 to find the setting. [3]