The Universal Offset tool, as far as I am concerned, is basically useless unless you can already quote your input lag, at which point you don't actually need a tool.

I consider myself a decently intelligent person, and I still have trouble even figuring out what the calibration I am setting actually means, much less using the very odd system of visual calibration - extremely fast thick moving bar that connects with super thin bar and expands massively on every hit? lol wut?

Why not, instead, have some kind of calibration system like Rock Band or Guitar Hero, where you click some hitclircles or something and the game automatically measures your offset? The game already uses this exact kind of data measurement in the ranking graph (down to the hundredth of a millisecond), so it should be a snap to create. And while you're at it, properly label what the offset I have actually means. "-37" with no units, context, or frame of reference tells me basically nothing.

Universal offset is meant to adjust AUDIO sync, not input sync. Input offset isn't really supported by osu! due to the nature of the game (there is audible feedback from your actions). Therefore, just try and get your audio offset in sync, and reduce your input offset as low as you can using other means.

If the offset is just to calibrate for audio latency, why is there a visual system at all? Why not just have something where I click to a beat?

Clicking the beat would imply input offset.

The idea is that you listen to the beat and sync it to the music.

I'm still not sure I fully understand your argument (because this tool has left me feeling quite confused), but maybe I can help you understand mine a little bit better. Check this out:

https://www.youtube.com/watch?v=iXJAYXtWIKs

If all you had to do was click to a beat, like Rock Band's audio latency calibration tool, where does the input lag come in? I could close my eyes and do this thing, input lag is irrelevant in this scenario. And if you're saying that the tool would calibrate for input offset (for example, the delay between mouse click/keyboard tap to response), why is that a bad thing?

Regardless, I really appreciate the fact that you are willing to listen to my ideas and respond to me so promptly. Even if I might have no idea what I'm talking about.

No, you make a point. But the problem is, if you have bad input latency (and need to correct with an offset), you will have trouble playing osu! unless you turn off hitsounds, since they will be way out of sync with the actual music. Therefore, I have not felt the need to add a multi-tiered offset system into osu! yet (and the reason most people don't complain about it missing).

If you have bad input latency, I suggest you do the above and then use trial and error to adjust your UO. I may get to looking at the offset wizard at some point in the future, but it's not a high priority task for now.

The visual cue is kind of misleading since osu! doesn't have anything like a video offset at present.
You're supposed to listen to it and line up the beeps with the music.

Input lag is always best-effort since osu! can't predict your clicks and play its hitsounds a few milliseconds earlier. Playing the hitsounds late would render them useless. Guitar Hero can do input lag correction because it doesn't use hitsounds.

So, I take it that a multi-tiered lag calibrator isn't that necessary at this time since the relevant variables of osu! (AR/OD) aren't precise enough (AR11 being 300ms, and OD10 nomod being 18ms for 300) to really make a difference unless you're approaching ~20+ millisecond input lag, meaning you're playing on a TV or something stupid like that. At most it would only have benefit in low-tier setups and edge cases. That makes sense.

However, I'd still argue that the visual indicator of the Universal Offset is a very poor method of displaying what is actually going on in the Universal Offset tool, and also a very poor method of actually calibrating it once you see what it does. It's way too fast to see what's going on in detail (even on your custom-made Offset Wizard track), and the sizing modifications the game engine does to the options-offset-tick.png are annoying (especially the expansion of the mobile bar on click, which destroys any ability to read the timing in minute detail).

I'd imagine something like this to be better: Having the mobile bar move to the center bar, but once it clicks, it freezes exactly where it clicked and holds for maybe a second, so you can see exactly how much lag is going on. Having, say, the mobile bar have some sort of gradient (from red on the outsides and green in the center) and the immobile bar being both a higher layer than the mobile bar (I am not sure if this is the case in the current design, because I can't see anything clearly, even at 100fps backlight strobe), and white for contrast would be top notch, but that's only my personal design aesthetic - I'm just visualizing so maybe you understand my vision a bit more clearly.

That is, unless I am somehow still totally missing the point and the bar is irrelevant. It seems to be that the bar would be measuring the input lag, while the click is measuring audio latency, even though the input lag is irrelevant. In that case, wouldn't it make more sense to say, try to line up a matched kick drum and a snare drum, or two other such sounds, and remove the bar entirely? The Offset Wizard already more or less does this.

Sorry for all the text, but I just care a lot about this idea

You seem to be mixing up three different concepts: audio latency, video latency, and input latency.
The offset wizard only concerns itself with audio latency--the timing difference between the buffered playback of the mp3 and the (theoretically) immediate playback of sound effects.

Video offset refers to the timing discrepancy between the music and the video shown on your screen. Input offset refers to the discrepancy between the time in the song when you pressed a button on your input device and the time when osu! becomes aware of that press.

A multi-tiered latency adjustment isn't necessary not because osu!'s timing is generous, but because it is a lost cause. In essence, trying to correct the video and input lags requires seeing future events before they happen. Guitar Hero and other games fake it. The extent to which faking it is possible depends on the exact game mechanics used.

In osu!, there isn't much we can do to correct video lag. We could have approach circles shrink down a little bit early, but we clearly can't make hitbursts explode at the correct time without seeing the future. Similarly, we could correct for input lag by shifting the hit judgement window by a few milliseconds, but this would put it out of sync with the hitsounds themselves. (Playing hitsounds at the correct time anyway would also require seeing the future.)

Since players are expected to use their ear to judge timing, we consider it an unacceptable compromise to have accurate judgement of input at the cost of inaccurate hitsound timing. It's quite easy to build a muscle memory to click a few milliseconds early. Hitsound timing should make this mentally easier to get used to.

Plus, there's always the option of muting hitsounds and calibrating the existing Universal Offset to the input lag. (You won't want to hear the delayed hitsounds anyway in this case since they will fight for your attention for reasons I described earlier.)

Maybe we could replace the glowing bars in the offset wizard with a throbbing cookie or something that makes it obvious they aren't meant for timing.

I had to read that quite a few times to understand it (there's just something about it that made it unintuitive to me), but I think I get it now.

You can't time the hit bursts correctly if you shift early for video lag because you would have to assume the hit outcome x ms early in order to coincide the hitburst with the hit judgement, or the hitburst will also be delayed by x ms relative to the approach circle. This assumes that timing the hitburst with the hit judgement highly precisely is a priority over properly timing the approach circle, but that's your call. I personally disagree.

You can't shift for input lag because, similiar to video lag comp, shifting the hit judgement late by y ms also shifts the hitsounds late by y ms. I can see why you chose this route and I agree with your decision here, because this means your hitsounds are now y ms mistimed with the song, and this could easily throw you off your timing - even if your inputs are now properly timed with the approach circle, it sounds like you are hitting y ms late, instead of inputting y ms early on the approach circle and having your hitsounds be on time.

What I'm getting from this, overall, is that the graphical display of osu! on the screen can easily be wildly inaccurate when you put together input lag and video lag, and that the audio of the music is the only sensory input you can really depend on to time notes (assuming you don't have some kind of bizarre high-latency DAC solution).

I also agree that you should implement Operation osu! Cookie, because the current setup is hella confusing. What are those bars even intended to do?

In the meantime, I'm blanking options-offset-tick.png in my skin.