One of the most important and fundamental parts of creating a simfile for any playstyle is ensuring that the chart is synced correctly. While learning how to properly sync a file, one may frequently hear about the importance of applying "the 9ms offset" to the file's sync data. This piece of content creation has existed in the community zeitgeist for many years, but the origin and purpose are often lost or miscommunicated due to a lack of easily-accessible documentation on the subject. The purpose of this page is to document what precisely the 9ms Bias is, how to properly apply it when necessary, and where it came from.
Note: The 9ms bias has, over the years, been variously referred to as "the 9ms Bias," "the 9ms offset," "the ITG offset," and many other terms. For the sake of internal consistency, this article will refer to it as "the 9ms Bias," or "the bias."
In simple terms, the 9ms bias is the addition of 9 milliseconds to a simfile's #OFFSET value, which Stepmania uses to determine when the file's chart data starts in relation to the file's audio data. This causes the chart, and, consequently, the step timing data, to begin 9 milliseconds earlier. Framed another way, this makes the song audio begin playing 9 milliseconds later.
As a brief example, let's say that we have a song with a known constant BPM song that has been cut and synced in such a way that the first beat of the music occurs precisely at the beginning of the audio file, at a timestamp of 0.000 seconds. In this case, assuming our BPM is correct (for this example, it is), syncing the file to "the 9ms Bias" requires that we set our #OFFSET value to 0.009, not 0.000 as one might expect.
As one might imagine, it can seem confusing, perhaps even illogical, that "correctly" syncing a simfile requires intentionally setting the file's sync to be 9 milliseconds off. Why would we do this? In order to understand that, it's important to understand the history and origins of this part of simfile creation.
Following the rollout of ITG 2's Revision 21, which enabled user-created custom simfiles to be more easily added to and played on arcade ITG 2 cabinets, many players noticed that their custom files were frequently offsync by substantial amounts, with the steps unusually late, even when the file's audio had been precisely cut and synced to millisecond-precision using digital audio workstations. One content creator and player, known as mute, investigated ITG 2's coding and data and found that the ITG developers had added a modification to the StepMania 3.95 engine which subtracted 12-milliseconds from all simfile #OFFSET values, making all audio files begin playing 12 milliseconds earlier than dictated by their individual #OFFSET values. Consequently, this made all of the step and timing data 12 milliseconds late. The reason given in the ITG 2 coding comments was that this was intended to "account for ITG's late arrows" - given that this change "accounted" for late steps by making them even later, it is widely assumed that this was a programming error.
Following this discovery, mute proposed that, to counteract the 12-millisecond delay, the easiest course of action would be to intentionally set the #OFFSET value in user-created files 12-milliseconds higher than it "should" be, per the audio waveform and sync. This would, in practice, cause the 12-millsecond delay (intrinsic to the ITG2 arcade program as a "Global Offset") and the 12-millisecond addition in the simfile itself to cancel each other out, resulting in the "proper" step time being precisely matched with the beat(s) of the song.
Before long, further refinement was made to the process. Another player and creator, winDEU, took mute's proposal a step further and calculated the time it takes sound waves to travel from the arcade cabinet's speakers to the player's ears, assuming reasonable averages for both cabinet distance and player height, and found this time to be, on average, 3 milliseconds. (Reminder - At this time, public arcade cabinets were the standard for ITG, therefore, these "assumptions" were largely a complete reality for the overwhelming majority of players.) In practical terms, this meant that the player typically heard a given sound or step "cue" 3 milliseconds after the simfile's step data "expected" that they heard it. To address this discrepancy, winDEU proposed that, rather than adding 12 milliseconds to a simfile's #OFFSET value, content creators should instead add 9 milliseconds, which would ensure that sound reached a player's ears at the precise moment they were intended to step on a given arrow (assuming correct chart sync otherwise).
Over time, this practice eventually became the standard for creating well-synced custom simfiles to be played on r21-enabled ITG2 arcade cabinets, largely adopted by most, if not all, content creators of the time. Put another way, for a substantial period of time in the history of "ITG" as we know it today, all custom content was intentionally created with a 9 millisecond sync discrepancy between the audio and the steps, because it was the only way to ensure that they would be synced "correctly" on the arcade hardware that was available at the time.
As custom StepMania builds for both arcade cabinets and (eventually) home setups became both more common and more varied in terms of hardware, players and operators began to explore and exercise greater control over several options and parameters in the StepMania engine that were previously inaccessible on standard ITG2 arcade cabinets. The most pertinent option for this discussion was the ability to change a machine or setup's Global Offset value, which, as discussed earlier, was originally set incorrectly in the ITG2 coding. Most players and machine operators found that the most practical method to set an accurate value for Global Offset was to compare to a file that was known to be "correctly" synced and set the value for Global Offset, commonly done via the Autosync Machine function, in such a way that the aforementioned file's steps lined up properly with the file's audio.
The necessary caveat to this process was that, for several years, all custom simfiles had been intentionally created with #OFFSET values that were intentionally "incorrect" by 9 milliseconds in order to account for shortcomings that had been intrinsic to the game since its infancy. As such, using the Autosync Machine function to adjust the Global Offset based on these simfiles resulted in an intrinsic "bias" in the machine's Global Offset that made simfiles that were "incorrect" by 9 milliseconds actually sound and play as if they were perfectly on-sync.
While this may seem improper, for practical purposes, it was the most reasonable course of action at the time. Though home cabinets and other custom systems were slowly becoming more common, for the most part, the vast majority of players still utilized arcade systems, either ITG2 dedicated cabinets or "upgrade" cabs, to play custom content. As such, the majority of the content base still needed to be designed in a way that accounted for the quirks and shortcomings of stock ITG2 systems, and the (at the time) minority of players using home systems found it easier and more practical to adopt the same standards for their own systems, since most of the content distributed and played was created with those standards in mind. For every simfile that was synced with exact accuracy to the audio's beat timestamps (commonly referred to as "being synced to null offset"), there were dozens upon dozens of existing files that assumed they were being played on a machine with a Global Offset that accommodated their intrinsic, intentional inaccuracy.
As such, even as arcade-based systems slowly fell to the wayside and home systems (either user-purchased arcade cabinets or custom-built StepMania setups) became more prevalent, due to the sheer mass of existing content that followed these (now theoretically unnecessary) standards, it was simply easier for the average end user or content creator to continue following the standard of the 9ms bias, even as the causes for its existence faded out of public eye or access.
In the modern "ITG" scene, the 9ms Bias is still utilized as a standard in simfile creation, despite being an unnecessary modification that largely only exists as a quirk of "legacy" systems. Given the current state of the game, one might wonder why the bias still exists as a standard, and why the community of players and content creators as a whole doesn't move away from it.
The answer, for better or for worse, is as simple as player convenience. While it is objectively "incorrect" to do, it is still practically convenient for a large portion of the "ITG" player base, as many players, regardless of their setup, still play content that was either created during the "legacy" era, or was created to the standards required by that era. As a result, machines and setups that might play any of this content have Global Offset values that accommodate them, and any newly-created content that is added to these machines ostensibly needs to be designed to fit that accommodation as well, even though the systems that it was originally crafted for have largely been phased into non-existence at this time.
While there have been discussions at times regarding a community-wide shift away from the use of a 9ms bias (which would be a great convenience for content creators), the execution of such a task would certainly be daunting, and rife with potential issues and mistakes, as the overwhelming mass of custom content distributed, shared, and re-shared for over more than a decade would either need to be completely re-synced to remove the 9 millisecond addition to all of their files (assuming no pre-existing syncing mistakes), and the onus would be on players and machine operators to both acquire this newly-resynced content and change the Global Offset value of their play location or setup, assuming it is possible and practical for them to do so. A more convenient and practical method, which many content creators have already begun adopting, is to provide multiple versions of their content to accommodate both types of setups, Null and 9ms. While this does not necessarily address the root cause, it is a vastly more practical and convenient method of allowing for community members who wish to move away from a long-irrelevant mechanic to do so, while still allowing for players who play and enjoy legacy content (or are otherwise unable to modify their setup's Global Offset) to still enjoy the fruits of a content creator's labors.
Ultimately, it is a problem that is difficult to solve. Perhaps the most reasonable and logical course of action for the time is to simply ensure that the community as a whole understands what the 9ms Bias is, why it exists, and, arguably, why it should continue to exist until a more elegant solution is determined.