1. osu! forums
  2. osu!
  3. Gameplay & Rankings
show more
posted
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.
posted
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.
posted
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....
posted
Probably a bad soundcard or a bad audio driver. Having a different offset from 0 is not a bad thing if it's correct.
posted
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.
posted
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.
posted

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.
posted
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.
posted

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.
posted
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.
posted
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.
posted

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.
posted

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.
posted

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?
posted

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.
posted
sometimes -4 and sometimes +4, i'm not sure which is correct
posted

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.
posted

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. :P
posted
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.
posted
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?
show more
Please sign in to reply.