forum

Offset; what is your and why?

posted
Total Posts
91
show more
Synchrostar
+15 since i got my new pc
Dexus
edit: scratch that thought, doing my research and testing.
Soulg
universal is 0 because fuck messing with that
Dexus
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.
brendanuhs
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.
RaneFire
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.
yoyomster
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.
Topic Starter
laeamminlakana
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....
lolcubes
Probably a bad soundcard or a bad audio driver. Having a different offset from 0 is not a bad thing if it's correct.
Rickput
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.
Dexus
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.
RaneFire

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.
Dexus
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.
RaneFire

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.
Dexus
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.
Salvage
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.
lolcubes

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.
Topic Starter
laeamminlakana

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

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

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

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

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
Dexus
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.
Mathsma
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?
peppy
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.
RaneFire

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 :| ).
Dexus
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.
A random +50ms record
This shows it should be roughly +3ms

Looking at kriers method
+2ms (first track) this is 1ms before the audio syncs up
+1ms (second track) is where it first syncs
-5ms (third track) still the same as the previous track
-8ms (Fourth track) is the very last one before it gets out of sync.
-9ms (last) track which is only a 1ms difference. From what you can see it just jumps a huge amount.


From +1ms all the way to -8ms it's all in sync the same way. Also notice that it's not close to the +3ms offset that I have determined from above. When you measure the difference in the -9ms track however it shows that the offset should still be +3ms. I'm assuming the wav files being used have low sound gaps at the start of them which isn't helpful to the human ear to measure it. The wav files I use for my hitsounds have no low sound gap at the start and wav doesn't require decoding, so it makes for a pretty precise hit.

Spec_old_1
0
RaneFire

Dexus wrote:

-8ms (Fourth track) is the very last one before it gets out of sync.
-9ms (last) track which is only a 1ms difference. From what you can see it just jumps a huge amount.[/b]
Thank you for proving Law of Kriers! (i.e. stop adjusting as soon as it sounds in sync from + offset)

Btw, do you think this "jump" is a hardware problem or osu!?
It could be different for everyone else, but it sounds like the problem Mathsma is experiencing. I also noticed it in my first test where I couldn't tell the difference between -1 and -9, but it doesn't happen all the time. Re-tests allowed me to tell values -4 to -9 were out of sync.

If it jumps by that amount, I don't think measuring the offset from it is reliable. It could still be off/random.

I wish I could set my offset to -2.5ms, because that's what I think it actually is. (-2 and -3 indistinguishable)
Full Tablet
By using a similar method to the one Dexus used (recording the audio output with +50 UO). I used auto mod instead of using the ticks of the offset wizard. I got an UO of +15ms (with my other method I got +16 ± 2.63 ms).

Then, when I adjusted the UO accordingly, the pulses were still constantly off by ~2ms. Changing the UO slightly didn't have any effect on that, until it jumped by about 10ms when I set the UO to 20 (and the jump was noticeable while hearing). It seems that the music or hit-sounds timings are snapped to certain time points.

Increasing the fps seems to not have an effect on this (tried changing from 500fps limiter to Unlimited that runs at about 800fps. It was the same). With 60fps v-sync the alignment was unstable (for some ticks they were off by 2ms, while in others they could be off by about 50ms)
Dexus
Well, I wish I had access to the WAV files that the pings in the offset wizard in the options so I could tell really what the waveform looks like, but my theory is that it has a slight gap at the start of it making the measurements incorrect. As for the way I tested it, I stopped every time and started the song from the beginning to measure each millisecond change.


I'm going to test and see if I can cut out these gaps and match to the same way peppy has his mp3 and see what results I get

I wouldn't trust the auto mod because from time to time I can see in the hit error bar it's wrong; same thing can be said about the relax mod. I'm guessing it's an anti-cheat method or the bot itself gets offset due to the community offset.

From what I saw, yeah the v-sync/low frame rate method made for unstable tick rates so I figured unlimited would suffice to be the most accurate reading.

I asked peppy if it was possible to get float value offsets, but I don't think it's even possible (or really needed for that matter)
Lach

Dexus wrote:

I wish I had access to the WAV files that the pings in the offset wizard in the o...
now you do
Dexus
Thank you very much Lach. Is it skinnable?
Lach

Dexus wrote:

Thank you very much Lach. Is it skinnable?
No, I decompiled things that I probably shouldn't have.
Dexus
Welp, it'd be amazing if it was skinnable. I quickly checked and there is a gap at the start (it's small though). It would be better if I could cut it short at a high point to make it easier to offset.


You can see the waveforms merge together to the right, that's about at 8ms it happens which I recorded this with a +3 UO.
Full Tablet

Dexus wrote:

Welp, it'd be amazing if it was skinnable. I quickly checked and there is a gap at the start (it's small though). It would be better if I could cut it short at a high point to make it easier to offset.


You can see the waveforms merge together to the right, that's about at 8ms it happens which I recorded this with a +3 UO.
The metronome sound is skinnable (just add those files to your skin folder).

While testing with the offset wizard in the options menu (and using my hitsounds instead of the metronome sound). The situation was similar to the last case, (though the UO range where the sounds matched was different). In detail:
- UO 50: The recording suggested the UO should be -7 (the time difference was very audible).
- UO -7: The recording suggested the UO should be -5 (the time difference between the pulses was just a bit audible).
- UO -5: The recording suggested -3.
- UO -3: The recording suggested -1.
...
- UO 3: The recording suggested +5
- UO 5: The recording suggested -2 (the time difference was very audible).
- UO -2: The recording suggested 0.

There seems to be something wrong with either my PC, the method of testing, or the game that makes it so UO only affects the offset in large ms intervals. I will keep +16UO offset since that is the offset that statistically gives me the most accuracy while playing the game (and also the previous recording test gave me a value in an interval that included +16).
Dexus
Another test with -50ms UO
The first two are the WAV files, the third is the actual mp3 file for the song, and the last one is my recording.


Great to see the metronome files are skinnable, now to get more precise results. The above was done with the default.

Edit:
Interesting to say the least; I cut the wav file shorter and did another test at +50ms, here is the resultant


So my offset is really +3, assuming peppy's offset song is correctly offset.

Here are the mono metronome sounds that I used which were cut short if anyone else is interested in using them http://puu.sh/6vcUM.zip

Be sure to check your wav files that you're using to play with though, some of them have gaps at the start which can be a couple milliseconds off. I'll eventually write a post if anyone needs assistance in doing this.

Edit:
So I did more testing, here I used +18 UO; The labels for what I did are on the left. The last line the reference is the blip on the right. The community offset isn't applied in the options offset wizard I guess... Peppy please do something about this community offset, either apply it everywhere or nowhere.
Lach
The metronome sounds are not skinnable.
Full Tablet

Lach wrote:

The metronome sounds are not skinnable.
I just skinned them...
show more
Please sign in to reply.

New reply