Used the offset wizard after finding that I needed to change the local offset 80% of the time, and put it at -3ms. I still have to change local offset +5ms or -5ms for many maps, but it's not as bad as it used to be. (And I found that clicking the seek bar in the offset wizard will break the timing, which makes offset changes a bit more difficult)

And TBH, if you're having to set your offset that far from 0ms, I think there's something wrong with your setup. Keep in mind that offset moves your hitsounds, not just your timing windows, so putting it that far off will make cause your hitsounds to become unsynchronized with your music (They're supposed to be there to guide you, so I'd recommend finding a way to reduce latency rather than just disabling the sounds altogether).

Almost wrote:

RaneFire wrote:

[....]
How do you arrive at those values? They look pretty exact so I'm curious if you used a program to find them.

Also this is why I'm sitting at 0 too. I ran the offset wizard once and got -2, but I still couldn't be sure since I don't trust my own hearing and -2 isn't such a big deal... I think... but it's way too small for me to be certain.

I used the offset wizard map and played double tick in the offset wizard and adjusted my offset so that I couldn't tell the difference between the ticks.

^basically this + checking in editor on correctly timed(and easily SS'able by "you") map(easy and normals excluded).

YayMii wrote:

[..]so putting it that far off will make cause your hitsounds to become unsynchronized with your music [...].

I often have histounds set WAY louder than music itself and it's well synced for me.

0 because i have no idea how to set it up

Almost wrote:

I used the offset wizard map and played double tick in the offset wizard and adjusted my offset so that I couldn't tell the difference between the ticks.

Yeah this is what I did. Offset wizard/map, sorry for confusion. Except that I went into the editor instead and adjusted the offset before. Are you supposed to use the wizard or the editor? Anyway, I did both... both seemed to give me the same result.

I could hear distinctly that it's slightly out of time on 0 (can hear one before the other).

It took me a while to tell what was happening at greater negative values (UO), but I solved that by taking breaks in between listening. So for now it seems like my original estimate of -2 last year was on the right track. I re-listened to -2, -3 and -4 over and over, and it seems like -3 is where it's at.

I then went into the editor and "seeked around" in F3 timing panel as peppy recommended. With it being a default of -6, I changed it to -4 and seeked, heard many places very slightly out of time, very few perfectly in time. Same story for -2. But on -3 there seemed to be very few (1 out of 5) that ended up being out of time, as opposed to more than half being out of time on values either side of that. So since they work opposite directions apparently, adding 3 in the editor translates to -3 in the UO.

Hahaha! Just thought I should add as well... I had sudden memory loss that I changed my offset in the UO to "-3," and I went into the editor again and tried to find a setting again. I was like "WTF -6 sounds in time now? Am I going crazy?" - Went to the UO and was like omg... it's -3... So I think that served as my "blind" test lol.

Thanks for the help, I was just uncertain whether people used a program or not. Hopefully others can use this info to find their offset too.

Almost wrote:

I used the offset wizard map and played double tick in the offset wizard and adjusted my offset so that I couldn't tell the difference between the ticks.

I ran that and it did sound slightly out of sync and a bit better at -4. Thanks for posting that

This is surprisingly hard lol. I have mine at 0 since I have no clue if I'm doing it right or not. Isn't there an easier way to tell?

The way I personally ended up at my offset was the score meter (in graphics options) and watching my replays... left side if early and right side is late.
The following pictures show what the setting is and what it looks like in game







Taken from a random gameplay I made for the purpose of showing it

The problem with doing that, for me, is that I've been playing on 0 since forever. So test by playing will be inaccurate since I mentally compensate for it. I needed more technical method.

Since I set it to -3, my general hit error at the results screen has averaged 3ms earlier. I'm going to play some more before finalising, but at least when playing stream maps I am centering on the blue bar almost exactly now, since I listen to the music when streaming and not looking at approach circles. Used HD to make sure and I'm a lot more consistent on streams now. Always wondered why I lost my tempo on streams some times.

Edit:
Doing much better now in terms of consistency, although I'm still early a lot of the time. This beatmap is simple and has a really strong beat, but I still never SS anything on my first play. Tried playing it with HR but I found my reading letting me down as usual. Stuck on HD instead and SS'd it again on my first try... that's an accomplishment for me. Hit error rates still early though because I still read fade-in/out when playing HD. I'm also not that good at HD generally :/
The effects are quite amazing even with such small numbers so I'd recommend everyone find their offset xD

Okay so I have asked this before, but I really want to make sure it's correct. When I try to set my UO it sounds in sync from -4 to +4, if I used kriers' method from another thread I should be using +4, but is that really correct? Wouldn't it make sense for it to be at 0 since that is right in the middle of the audio sync range?

Mathsma wrote:

Okay so I have asked this before, but I really want to make sure it's correct. When I try to set my UO it sounds in sync from -4 to +4, if I used kriers' method from another thread I should be using +4, but is that really correct? Wouldn't it make sense for it to be at 0 since that is right in the middle of the audio sync range?

Use the seek function either in UO or in editor, some times it will be out of sync and you use this as a guide. Whichever offset value gives you the least amount of out of sync sounding ticks, after seeking like 10 times, is what you are looking for. I also couldn't tell the difference between values -1 to -9 before I did this. Apparently osu! has some random delay from 1-3ms when seeking and that's why it helps narrow it down a bit. Also take breaks between listening when you start narrowing down your offset to a final value. This also can take quite a bit of time, in my case, over an hour.

Mine is -1.
You'd ask "But why -1? How can one millisecond make any difference?"
On some maps like this one https://osu.ppy.sh/b/274276&m=0 the difference is from ~120 UR with 0 to ~95 UR with -1

I found -1 by the same way as Almost, using peppy's offset wizard in the Offset Wizard

On my old setup -70.
On my new setup 0.
On my laptop +6.

Get offset wizard map and increase/decrease your offset until you are almost correct, then make it higher (if negative make it less negative) and just reduce by 1 until the clicks align perfectly.

Also, I have noticed that until I changed my sound card, my offset would actually randomly change, probably related to how bad the sound card is (and its access to memory?)

Don't use regular maps to get your offset values, most of the maps have +-5 error, some much bigger. ;_;

Mathsma wrote:

Okay so I have asked this before, but I really want to make sure it's correct. When I try to set my UO it sounds in sync from -4 to +4, if I used kriers' method from another thread I should be using +4, but is that really correct? Wouldn't it make sense for it to be at 0 since that is right in the middle of the audio sync range?

That method is correct from my experience.

hitsounds should be in time with the music with 0


also no offset is perfect, if you cant play different offsets you cant play osu with any accuracy at all\\

lolcubes wrote:

then make it higher (if negative make it less negative)

lol "less negative"

going up is the same whether its negative or positive, as long as you can count

+15 since i got my new pc

edit: scratch that thought, doing my research and testing.

universal is 0 because fuck messing with that

1) Use the offset wizard song by peppy and the method below. (I got -3ms)
2) t/177770
3) Use the above method to locally offset the map.

meh. most of the time what you perceive as "off time" is just some made up rhythm you're following. Most maps are "good enough" timing wise.

Use krier's method.

Seeking/my method is wrong. Typically a song is not going to have the random delay from seeking. I redid the peppy offset wizard map again today, but this time I stopped and started it repeatedly and it was perfectly in sync on -2 every time, and same in the editor.

So I'm using -2 now instead of -3. Why?... Because this placebo is better than my last one.

I used https://osu.ppy.sh/forum/p/2741485. It's the method Full Tablet posted.

Problem is the UO value you end up with using this method is only an estimation unless your unstable rate is pratically zero.

My UO is now -4.

Seeing as I am the weird one in the bunch (I don't see anyone else with a positive offset value and especially not one with 100+ [just went on to 101]) I wonder what on earth have I done to end up needing this....

Probably a bad soundcard or a bad audio driver. Having a different offset from 0 is not a bad thing if it's correct.

I use -7. Configured it with the offset wizard map and synced the metronome. Only for maps that haven't adjusted for the community offset of 22 or 23 (forgot which one) do i have to add an additional -20 to -23, in some cases around -30 or -15. Never do I have to add a positive offset.

Universal Offset is reverse of local offset (Which makes no sense). Local offset subtracts or adds to the map's offset. So if your map is timed correctly in the editor, when you go to play a +22 offset is applied locally (which shifts the map's offset to being later). This is wrong so when you use a negative offset around 20 it really shows the map is timed right but GG peppy and community offset. The reason why there is a community offset of 22ms is because the mp3 file peppy used for the offset wizard song has a 22ms gap in it from the start of the song to the beginning of the first blip. The offset in the editor for the song really should be +6ms not -6ms because the spike of the blip that will be most audible is 6ms after 22ms into the mp3 file.



Red - is the 22ms community offset that is applied
Orange - Where the offset should be which is at 28ms
Yellow - The offset should be 6ms in the editor because the +22ms (Red) is applied when you start the map.
Blue - Negative 6ms offset peppy has used in the editor for the song
Purple - What the offset is you are timing to in the options menu
Brown - Usually what the offset people think is correct (-3ms, -4ms, 5ms, etc). which means your offset really should be -9ms universally or more.
Maroon - What peppy was at and offset the map to, which he collected data and used to just set everyone 22ms off roughly.

What would work is correcting it in the editor to +6 and THEN using the options offset wizard and the song to check the offset. The offset wizard in the options has the community offset applied while using it (from what I've seen).

(I probably should have put arrows showing which way it's offsetting but you get the general idea.)

If I'm totally wrong, peppy please do explain. The offset is really giving me a headache.

Dexus wrote:

Universal Offset is reverse of local offset (Which makes no sense). Local offset subtracts or adds to the map's offset. So if your map is timed correctly in the editor, when you go to play a +22 offset is applied locally (which shifts the map's offset to being later). This is wrong so when you use a negative offset around 20 it really shows the map is timed right but GG peppy and community offset. The reason why there is a community offset of 22ms is because the mp3 file peppy used for the offset wizard song has a 22ms gap in it from the start of the song to the beginning of the first blip. The offset in the editor for the song really should be +6ms not -6ms because the spike of the blip that will be most audible is 6ms after 22ms into the mp3 file.

Why are you trying to science it when it's really just about syncing the sound of the ticks? ...which can actually be done by human ear to the nearest 1ms using krier's method. If you're looking at a graph, it's not a true representation of how the human ear discerns the exact timing of a beat, which is why your "audacity method" is all but useless except in the start of a song where silence precedes.

Universal Audio Offset moves the audio track earlier(-) or later(+) for every map.
Local offset moves the beatmap earlier(-) or later(+) on a per map basis, i.e. the hit objects/sounds, just like in the editor. If you want to look at it inversely, it does the opposite to the audio track.

If you think of it this way, it makes much more sense.

Dealing with audio waves is what I do in the military for a living. I'm a RF transmissions technician and timing is very important with what I do because the satellites I deal with have to have correct timing in order to send and receive data in sync with the distant end. If the waves are out of sync then information becomes garbage. I just know how data signals and audio signals look like and how they're supposed to be synced up. I'm not pulling this out of my ass; there are just too many unknown variables that are being thrown in for me to discern a perfect solution. When I see this waveform and see that it's 6ms off and I move the game's offset to be 6ms it doesn't move it 6ms. It puts it a displaced point due to uncontrollable variables. By the time it reaches your ears it's way off. Sometimes though it does the exact opposite and even though it's wrong initially it eventually comes out to be correct. So your offset could be super early but there's so much latency that it just comes out right. The human variable shouldn't be relied upon due to the placebo effect.

If you actually read what I wrote and looked at the graph and understood what I was saying it would make sense to you, but I guess not. Peppy initially had that beatmap made BEFORE the community offset was applied to everyone so his audio was 34ms off and when he set the map to -6ms in the editor it got to the 28ms (which is where the human ear hears the sound; I know for a fact).

Again; peppy collected the data he received from everyone's feed back and had a +22ms Local / -22 Universal offset applied to everyone. This 22ms is just the blank empty space at the start of the mp3 due to the way it's encoded (which is the whole reason the community offset is there). You should be using +6 in the editor for the map, not -6 because -6ms is wrong. You can use Krier's method but the human ear can only go so far in certain situations. When you play EVERY other map they are not timed correctly because the people who made them didn't have a correct UO; and at that they most likely are several milliseconds off. The combination of an incorrect offset and not even timing it right can make a map really timed wrong when played by someone with the correct settings.

I should be able to look at an mp3 with an offset put to the very start of the song at the initial sound the same as it is read in audacity; but I can't because the timing in everything is just nuts. There's too many repeated delays from everything being sent back and forth inside the computer and to the human ear for it to figured out the same way for everyone. I just use audacity because I can visually see if something is off or not and it's pretty much the final output from the game. Only problem in doing it is there's still latency from the computer to your ears, but if you sync your hits up to the song it wouldn't matter. Only thing that matters is getting the sound aligned to the music, which is again why I use audacity.

I still would say the Offsets locally and universally should be the same because it would make for uniformity. My only beef is the community offset and the way it's applied, it makes it very difficult to provide correct timing. Oh yeah and even the BPM speeds are timed wrong, there's always several ticks that are either too fast or too slow and then one that is displaced to correct it to be consistent to the end. It's literally impossible to get perfect timing with this game, but you can get a lot closer than it is right now.

Dexus wrote:

Again; peppy collected the data he received from everyone's feed back and had a +22ms Local / -22 Universal offset applied to everyone. This 22ms is just the blank empty space at the start of the mp3 due to the way it's encoded (which is the whole reason the community offset is there). You should be using +6 in the editor for the map, not -6 because -6ms is wrong. You can use Krier's method but the human ear can only go so far in certain situations. When you play EVERY other map they are not timed correctly because the people who made them didn't have a correct UO; and at that they most likely are several milliseconds off. The combination of an incorrect offset and not even timing it right can make a map really timed wrong when played by someone with the correct settings.

...

It's literally impossible to get perfect timing with this game, but you can get a lot closer than it is right now.

On what basis should it be +6 and not -6? That's a 12ms difference, nothing you mentioned refers to the number 12. I re-read both your posts and still don't understand. My UO is definitely not out by that much, there is no way that's possible. It's what you hear that counts. Having the correct offset in UO and local makes playing HR at AR10/OD10 a lot easier.

Also yes, it's impossible to get perfect timing. But that's also why it's important to set your offset to a map made by the game's creator. There are rules regarding ranked maps that you need to get a certain number of mods. This is to reduce the chance of the mapper using an incorrect offset. When you have 10+ people checking that it is correct, that chance that a few of them are experienced in setting their offset is reasonably good. Most maps are well-timed.

Tbh, your example in another thread of Scarlet Rose being off by 47ms actually made me laugh. Did you know that 47ms is the time-frame between 1/4 beats at 320 bpm? (talking about the audio here) All that means is the beat is discerned by the human ear as being on blue ticks, because it's really not that badly timed.

UO isn't off, it's the map timings due to the community offset. To be honest you can leave it at 0 UO and just locally offset to correct timings.

47ms is 47ms. regardless of the bpm or the ticks you're talking about. The sounds that are being played aren't in sync with the map, it's literally a note off. It's so fast that your ears aren't picking up on it really. But your eyes and your memorization just kick in and the rest happens. Again, the human variable is gullible to the placebo affect.

Well i never had problems with accuracy at all, but i tried kriers method on the other thread and i felt i was ages offbeat with the change so well i had to come back to default .. i guess i just got used to this, i still change offset depending on the map if necessary so it's just the same.

Dexus wrote:

UO isn't off, it's the map timings due to the community offset. To be honest you can leave it at 0 UO and just locally offset to correct timings.

You are wrong. This heavily depends on your hardware (and software - drivers).
Please stop assuming UO at 0 is correct, because it is not. The correct value is where the ticks sync. (else it would be pointless to even exist)

Also, for what it's worth, depending on the mp3 type, you will get different results in audacity/game. VBR especially.

lolcubes wrote:

Probably a bad soundcard or a bad audio driver. Having a different offset from 0 is not a bad thing if it's correct.

a bad soundcard won't give me the sounds ~100 ms early, since it won't know the sounds are coming, it might give the sounds 100 ms late though, which my offset clearly doesn't imply.

lolcubes wrote:

Dexus wrote:

UO isn't off, it's the map timings due to the community offset. To be honest you can leave it at 0 UO and just locally offset to correct timings.

You are wrong. This heavily depends on your hardware (and software - drivers).
Please stop assuming UO at 0 is correct, because it is not. The correct value is where the ticks sync. (else it would be pointless to even exist)

Also, for what it's worth, depending on the mp3 type, you will get different results in audacity/game. VBR especially.

I'm aware that UO isn't 0. Just saying you could just use LO. You didn't read anything but that post, right?

Dexus wrote:

I'm aware that UO isn't 0. Just saying you could just use LO. You didn't read anything but that post, right?

So you'd rather use a local offset on every single map ever than use a UO and just fix the maps that are still off by a bit then? You make no sense.

sometimes -4 and sometimes +4, i'm not sure which is correct

marcostudios wrote:

sometimes -4 and sometimes +4, i'm not sure which is correct

I get the exact same thing so I decided to just go with the middle and put 0. I still don't know if that is right or not because everyone is saying different things.

Brimroth wrote:

lolcubes wrote:

Probably a bad soundcard or a bad audio driver. Having a different offset from 0 is not a bad thing if it's correct.

a bad soundcard won't give me the sounds ~100 ms early, since it won't know the sounds are coming, it might give the sounds 100 ms late though, which my offset clearly doesn't imply.

Its possible. My asus xonar ds had a UO of -70. Yes, sounds were very early compared to the music.

Edit: What I said was uncalled for.

Still though, I was saying using a 0 UO is a possible option since I check every map for it's timing when I go to play anyways. Personally though I use a universal offset timed to peppy's original offset map and check by using the hit error bar for quick reference. If I feel the timing is really wrong I then use audacity to make sure I get a correct one.

Is peppy's offset map supposed to be on -6 and then we check for timing in the offset wizard or are you supposed to change it to 0 and then use the offset wizard to check for timing?

Using audacity does NOT WORK, because mp3 decoders all add arbitrary offset to the beginning of tracks. Using 0 is fine if 0 sounds right to you. On most sound hardware it will not.

Mathsma wrote:

Is peppy's offset map supposed to be on -6 and then we check for timing in the offset wizard or are you supposed to change it to 0 and then use the offset wizard to check for timing?

Leave it on it's default "-6." Think of it like it's actually a "0" (but it's not). UO works in opposite directions to editor/local/online offset, so work backwards. It's the same thing imo.

Krier's method! Krier's method! Krier's method! Krier's method! Krier's method!

Remember hitsounds are a sound file. They have a start and end, and the punchline is longer than 1ms, which is why you want to sync it in UO starting from a large positive offset and work your way down until it synchronizes. IMO (and other's O's) this is the best way to do it. If you keep decreasing your UO it may still sound in sync for another few ms, but that's wrong (apparently ).

Peppy is talking about opening the mp3 file to check for the offset. It's not what I have been doing because of what he just said. Yeah though, that 6ms switch is proved wrong though; thanks peppy for confirming it. Recording and checking songs in audacity however can still work.

Here are some tests I have done using audacity, peppy's default offset wizard song, and the options offset wizard with the game focused at unlimited fps.