GekiChuMai Timing Windows and Offsets

UPDATE 2023 JAN 6: Revised part about Chunithm's hold tick and added Ongeki's hold tick's timing windows

Happy holidays and happy new year to everyone! Before 2022 ends, I'd like to publish a short blog post regarding timing windows and offsets in 3 of Sega's rhythm games. Sorry I haven't posted anything this year. Don't worry, as I have a lot of write-ups in the making that I'll publish in 2023🤞

Timing Windows

All three Sega rhythm games are known for their creative twists on rhythm games. From MaiMai's circular arrangement of buttons with a touch screen in the middle, Chunithm's use of IR LED and sensors to detect vertical hand movement, to Ongeki's use of a one-dimensional joystick and wall buttons, they all utilize their control scheme to deliver a unique experience. Adding to this unique experience are note types that have different timing windows.

Before I start, I'll first clarify that all three games' timing is not frame-based1. Offsets in terms of frames may mislead you into believing that timing is frame-based, but they are all converted to milliseconds under the hood.


Starting off with the most set of complicated timing windows out of all the three. I used F for Fast and S for Slow for compactness in the table below. All numbers below are in terms of milliseconds (ms)

Note type F Good F Great Low F Great Mid F Great High F Perfect Low F Perfect High Critical Perfect S Perfect High S Perfect Low S Great High S Great Mid S Great Low S Good
Tap [-150, -100) [-100, -83.33) [-83.33, -66.67) [-66.67, -50) [-50, -33.33) [-33.33, -16.67) [-16.67, 16.67] (16.67, 33.33] (33.33, 50] (50, 66.67] (66.67, 83.33] (83.33, 100] (100, 150]
Ex and ExBreak [-150, 150]
Slide2 (-∞, -433.33) [-433.33, -366.67) [-366.67, -300) [-300, -233.33) [-233.33, 233.33] (233.33, 266.67] (266.67, 366.67] (366.67, 433.33] (433.33, 600]
Touch [-150, 150] (150, 175] (175, 200] (200, 216.67] (216.67, 233.33] (233.33, 250] (250, 300]

As you can see from the table above, MaiMai has 4 different timing windows. Some are asymmetric, and most have empty windows, meaning that that judgement can't be (usually) achieved. For example, you can't get a great ex tap note or a fast good touch tap note. As you may notice in slide's timing windows, there is no such thing as sliding too early that you'll miss.

You may wonder why there are 3 tiers in Great and 2 in Perfect. The answer to that is break notes and how they ultimately affect scoring. I will make a more comprehensive write-up on MaiMai mechanics and scoring soon, but the gist of it is that a note can be given a break modifier so that it's no longer scored like a tap or slide note but as a break note. So while a regular note's scoring disregards the different tiers, break notes have different scoring for each tier.

If you prefer a simpler table, then here's MaiMai's timing windows without the different tiers:

Note type Fast Good Fast Great Fast Perfect Critical Perfect Slow Perfect Slow Great Slow Good
Tap [-150, -100) [-100, -50) [-50, -16.67) [-16.67, 16.67] (16.67, 50] (50, 100] (100, 150]
Ex and ExBreak [-150, 150]
Slide2 (-∞, -433.33) [-433.33, -233.33) [-233.33, 233.33] (233.33, 433.33] (433.33, 600]
Touch [-150, 150] (150, 200] (200, 250] (250, 300]


Next is Sega's most popular arcade rhythm game in Japan. Not included in this table are mine notes which will be discussed in a future write-up about Chunithm.

Note type Fast Attack Fast Justice Fast Justice Critical Justice Heaven Slow Justice Critical Slow Justice Slow Attack
Tap [-83.33, -66.67) [-66.67, -33.33) [-33.33, -16.66) [-16.66, 16.66] (16.66, 33.33] (33.33, 66.67] (66.67, 83.33]
Tap Easy [-100, -66.67) [-66.67, -33.33) [-33.33, -16.66) [-16.66, 16.66] (16.66, 33.33] (33.33, 66.67] (66.67, 100]
Extap [-83.33, 83.33]
Extap Easy [-100, 100]
Hold/Slide Tick3 [-150, -100) [-100, -50) [-50, 0]
Flick Tap [-83.33, -33.33) [-33.33, 33.33] (33.33, 83.33]
Flick Slide [-166.67, -83.33) [-83.33, 83.33] (83.33, 166.67]
Air Flick Up [-166.67, -83.33) [-83.33, 0) [0, 200] (200, 283,33] (283.33, 366.67]
Air Flick Down [-266.67, -183.33) [-183.33, -100) [-100, 150] (150, 233.33] (233.33, 316.67]
Air Flick Up with Tap [-166.67, -83.33) [-83.33, 0) [0, 150] (150, 233.33] (233.33, 316.67]
Air Flick Down with Tap [-266.67, -183.33) [-183.33, -100) [-100, 100] (100, 183.33] (183.33, 266.67]
Air Action [-266.67, -183.33) [-183.33, -100) [-100, 100] (100, 183.33] (183.33, 266.67]
Air Crush [-266.67, 266.67]
Air Hold/Slide Tick3 [-600, -400) [-400, -200) [-200, 0]

Like MaiMai, Chunithm has its share of empty and asymmetric timing windows but no tiers. However, Chunithm is the only game in the three where lower difficulties have a wider timing window. (Ex)Tap Easy is used for Basic and Advanced difficulties.

Chunithm has hold and slide ticks. In MaiMai, holds and slides only count as one note, but in Chunithm a hold/slide is judged continuously. These discrete checkpoints are referred to as ticks, and they are judged by the difference between the last time a button was pressed and the tick's time. For example, if a player let go 30ms before a touch hold tick then it is given a justice heaven judge. And if they let go 100ms before a touch hold tick, then it is given a justice judge.

I included two timing windows for flick notes. This is because a flick note has two phases: tap and slide. In the first phase, it acts as a tap note with a timing window stated in Flick Tap. Next is the actual flick where the player has to quickly slide their fingers and it has a timing window stated in Flick Slide. While the timing windows doesn't have an Attack timing window, you can still get an attack judgement for flicks if for example you failed to flick the note after tapping it.

Introduced in Chunithm New is a new tighter timing window called Justice Heaven or Heaven. It's visible as the middle bar in the "Justice Critical" group when you switch to the Late/Early detailed screen in the results screen.

Currently, as of the time of writing, Justice Heaven has no effect on scores, nor is there an equivalent to MaiMai's DX score or Ongeki's Platinum score that includes this tighter timing window in its computation.


Last but not least is Ongeki, which has the most straightforward and symmetrical timing windows out of all three games. The timing windows of the various bullets and beams are not included in this table. I'll cover them in a future write-up about Ongeki.

Note Type Fast Hit Fast Break Fast Critical Break Platinum Break Slow Critical Break Slow Break Slow Hit
Tap [-100, -66.67) [-66.67, -33.33) [-33.33, -16.66) [-16.66, 16.66] (16.66, 33.33] (33.33, 66.67] (66.67, 100]
Critical Tap [-100, -33.33) [-33.33, 33.33] (33.33, 100]
Side Tap [-150, -50) [-50, -25) [-25, 25] (25, 50] (50, 150]
Critical Side Tap [-150, -50) [-50, 50] (50, 150]
Flick [-166.67, -83.33] [-83.33, 83.33] (83.33, 166.67]
Critical Flick [-166.67, 166.67]
Hold Tick [-150, -100) [-100, -50) [-50, -25) [-25, 0]

Like Chunithm, Ongeki has hold ticks but with a separate timing window for critical breaks. Ongeki's Platinum Break was introduced in Ongeki RED. A platinum break has no effect on Technical Score; they are only counted in Platinum Score, which is only displayed at Expert difficulty and above (a feature introduced in Bright Memory, previously, was only in technical challenges.)


In all three games, 2 types of offset can be set by the user: Offset A and Offset B. Both of them are defined in terms of frame deltas at 60 fps (regardless whether the game is in 120 fps). In other words, it's in terms of 16.66... ms. So, for example, an offset of 0.1 is 0.1 * 16.66... ms = 1.66... ms. What's the difference between offset A and B? I'll use Tokaku's offset terminology on her video about timing and offsets.

Offset A is chart offset: It moves the time a note is active depending on what you set in offset A. Offset B is judge/input offset: it offsets all your inputs by the amount you set in offset B in the opposite direction. For example, you set offset A to -0.2. That would mean you offset the chart by -0.2 * 16.66.. ms = -3.33.. ms. So if a note is supposed to land at 203.33... ms, the game would add -3.33.. ms and will now land at 200 ms instead. If you set offset B to 0.3, your real offset B is 0.3 * 16.66... ms = 5 ms. That would mean that if a note is to land at 205 ms (assuming offset A is set to 0) and you press the button at 210 ms, the game would subtract 5 ms from your input, and it would treat as if you hit the button at 205 ms.

Which one should you change? Please don't take my recommendation as gospel; you may find that what works for you is the opposite of what I say. If you feel like the notes are off, adjust offset A. Specifically, if you feel like the notes are a bit too early, set offset A to positive, so you move all the notes later, and vice versa. Use offset B if you feel like you're hitting the notes completely on time, yet the game says otherwise. Take a look at your results screen and if you see that you hit more early than late, set offset B to negative, and vice versa..

"Which one should I change first?" If you're a beginner, find a comfortable scroll speed first and do not fiddle with the offsets until your accuracy is excellent and consistent. If your accuracy is over the place, you'll waste your time with offsets as they won't help you. If you're sure your accuracy is excellent and consistent, my recommendation is the following:

  • Check if you think the notes arrive on time with the music.

    • If you think the notes arrive early, slowly add offset A until the note timings are perfect.
    • If you think the notes arrive late, slowly subtract offset A until the note timings are perfect.
    • If you think the notes arrive on time, do not change offset A.
  • After modifying offset A, check the detailed results screen on multiple different songs.

    • If you're more early than late, slowly subtract offset B until late/early judgements are roughly equal across different songs.
    • If you're more late than early, slowly add offset B until late/early judgements are roughly equal across different songs.
    • If your late and early are roughly equal, do not change offset B.

I hope you learn something from this quick write-up I made. I'm sorry that this is my only blog post for this year. I was busy with many things this year, and I hope to share some of them with you next year. I wish everyone a happy new year and hope to see you in my next post. Cheers!

  1. Chunithm timing is partly affected by framerate/frametiming; when frame drops happen, inputs can be dropped too and may cause desync. My hypothesis is that Chunithm's game engine does not use multithreaded rendering, which means the pace of game logic updates is affected by long rendering times 

  2. Slide judgement does not depend solely on this timing window 

  3. Chunithm slide/hold ticks still needs more testing. I'll update the table when more info is available 

You'll only receive email when they publish something new.

More from donmai
All posts