forum

Audacity and offset

posted
Total Posts
17
Topic Starter
Dexus
So as some people saw I made a couple posts in the qualified section for beatmaps stating that maps were incorrect along with screenshots of audacity. This didn't go over well, so instead of directly telling people (some got offended or were confused) I will show and explain the reasons behind what I did so there is a better understanding.

What is audacity Download
Audacity is a sound editing/recording program that can be used to take direct samples of what the computer outputs in the form of waveforms that are visible, this is recorded as is so there is no way to say it's wrong or incorrect. The only problem is that there are discrepancies in latency and how things are actually played, plus what the player perceives as normal may not actually be so. Also there's no solid method to set a universal offset for everyone, so what you check may not work for someone else; this could explain why others found the offsets to be fine while I had to reduce the offset to be earlier (my computer is fine tuned so latency is extremely low, others haven't taken the time to do this). So essentially this is something each player would have to do themselves as it currently is.


So how can you detect what's right and what is wrong
Simply put you just set audacity to Windows WASAPI and this records the sound directly output by the computer without any inbetween, you can then go into the editor and do what mappers normally do of listening to the initial sound and offsetting it to that point. The metronome tick in the editor is pretty distinct and you can usually lower the game volume a bit to make it more so.

Here is what the metronome sound effect from the editor looks like, as you can see it starts abruptly, this is where the sounds from the music should be aligned

So to do this you simply go to the initial timing point and have it a bit before it

go to audacity and hit record, then go back to the editor and hit play so it can sample the timing point.

Next you simply zoom in and see where the metronome tick is at, sometimes you will have to lower the music volume and raise the sound effect volume so that it's more visible. [View > Volume] The way you have your windows volume can affect this as well, I would recommend having windows at 100 so everything is visible.

Next you just use the selection tool [Looks like the text selector in an editor] and select from the metronome tick to the start of the sound from the music [where it should be set to] You can also set the display down below to show in length [it outputs as ## h ## m ##.###s, the decimals in the seconds are milliseconds]

So you have the offset now. You simply test it by playing the map. You use [+] and [-] on the keyboard to adjust it; hold [alt] and press them to go in single units. You have to use a positive local offset (it adds to it) if the metronome is early, you use the negative offset (subtract to it) if the metronome is late.

Here are some other examples

Hey this isn't working, it doesn't sound right
You don't always have to use the initial offset. You can use other parts of the song that are clear where the timing should be set. What works best is finding those spots where there's empty sound before the metronome ticks.

It takes some practice using this because sometimes the sound waves you determine to be the offset point may actually be slightly off.

There are also possibilities that there's delay from your computer to your ears (This shouldn't be true as computers can get it precise to microseconds)

Another reason that a map may not seem right using this is that you're simply playing wrong and that you're predicting/anticipating the sounds.

Marathon maps are pretty much impossible to locally offset correctly since there are multiple timing points.

Okay you're crazy, we aren't "robots" we can just sense it
To human is to err. I personally would rather have something that is precisely timed than play something and have to fool myself into thinking it's correct. If you don't like this then again like the bevy of other stuff I do, don't do it. What you hear and what you're seeing in audacity are exactly the same. Honestly I only use this method if I feel a map is timed wrong for certain or I'm trying to rank on a map. It's kind of a pain to check every map before you play it just to find out there's a tiny bit of difference.

I hope this helps some people out there as that's all I'm trying to do here. If you have any questions or need help, please feel free to ask. Depending on how this is received I will possibly do a video in the future to make this easier to understand.
Ichi
Wow this looks really helpful, i don´t know anything about mapping but i can see where this goes.. thanks alot for the post, will probably have in mind if i start mapping!
Horo
every maps offset should be -5
you heard it here
Full Tablet
If you are going to use this method to set the offset, it's better to check the offset error with several metronome sounds instead of just 1 tick, and average them.
This is because the metronome sounds have a random variation (except when the bpm is a value where the time interval between each beat is divisible by 10ms); they can sound up to 10ms late (if the offset is set so the average variation is 0, the metronome sound can be between 5ms early and 5ms late, 2.88675ms of Standard Deviation).

Example: Assuming the BPM is set correctly.
The offset between the metronome and the first beat of the song is 48ms late, then the offset of the metronome and the next beat is 46ms late, then 50ms, and so on. You average those offsets to get the map offset.


Also, considering you can skin the metronome sound (metronomehigh and metronomelow), for the purposes of this method you can use a waveform that is easier to see and distinguish in the audio application. For example, a square pulse:

https://db.tt/4IPBrxKD
https://db.tt/HNXLyGKg
Topic Starter
Dexus
I've noticed that the metronome and the way it plays the bpm isn't perfect, it seems to drift and then reset itself every couple intervals.

Thanks for the sound files, those will be really useful.I can't seem to get them to work though.


I did some louder ones that also go into the negative range http://puu.sh/9fNEn.zip
RaneFire

Dexus wrote:

I've noticed that the metronome and the way it plays the bpm isn't perfect, it seems to drift and then reset itself every couple intervals.
This is exactly why I don't trust Audacity to find a local offset. It doesn't so much "drift" as it just jumps in 10ms steps due to the way Windows handles audio queues. The behaviour is rather random.

I only used Audacity to find my UO in conjunction with testing multiple local offset values (-20 to +20), measuring the deviation of the repeated hits vs the metronome tick over time. The UO value where the difference between map/hitsound ticks do not deviate at any local offset value (after a map restart) became my UO, even if it was +3 or -3 ms off the map's timing (better than being -13, then -3, then -13 again). Anything else appears to exhibit random behaviour and the flaw can occur when comparing the start of an mp3 file to the start of a hitsound.

There is also the issue with a small number of maps "lagging" when loading the mp3 file at the start. Then you also need to consider the possibility of a preceding note to the start of a bar (music), a kind of introductory note, which the mapper ignored.
Shohei Ohtani
god is dead and we killed him
Aqo
osu is weird and playbacks stuff on -20ms compared to literally everything else. Audacity is fine, it's osu's fault for being different. whenever you look for offsets with external programs, take into account that you'll need to use something different for osu anyway.
Natsu
Ears are the best way to get an offset here, IMO
Horo

Natsu wrote:

Ears are the best way to get an offset here, IMO
k
Full Tablet

Aqo wrote:

osu is weird and playbacks stuff on -20ms compared to literally everything else. Audacity is fine, it's osu's fault for being different. whenever you look for offsets with external programs, take into account that you'll need to use something different for osu anyway.
The method here doesn't load the mp3 directly, it records what the game outputs to the audio device, that way, the delay of the mp3 file doesn't have effect.
Aqo
are you sure about that?

I still think it's more reliable to just time by ear, assuming you have good accuracy :v
Lust
lets make things more overtly complicated than they need to be!
Topic Starter
Dexus
It's simple but your brains aren't comprehending it.
Shohei Ohtani
In this moment, I am euphoric. Not because of any phony ears timing, but because I am enlightened by my own audacity.
Topic Starter
Dexus

RaneFire wrote:

It doesn't so much "drift" as it just jumps in 10ms steps due to the way Windows handles audio queues. The behaviour is rather random.
I was checking the Universal offset and was wondering why it was jumping 10ms when I moved it to just -1ms

Using the Offset Wizard song https://osu.ppy.sh/s/4659 (Is this valid anymore?)
RaneFire
Yeah uhm... that thing about adjusting it by only 1ms and jumping 10ms occasionally confused me for a long time. That's why I spent about 5 hours finding the correct UO for my computer lol. Well at least I don't have to do that again... until I get a new one.

I don't time to the offset wizard beyond making sure the metronome ticks have the same deviation with the correct UO.

Example:
Always -3ms in audacity on 0 local offset / -13 on +10 local / +7 on -10 local etc etc. OR something along those lines, not any additional +10's or -10's in the same test. You must always restart the map after changing local offset too (Auto), no changing on-the-fly. However, do note, that it is not always the exact same value after each map restart (no changes to UO or local offset). Sometimes it's -2, -3, +2 +3 etc. But for each map test, the value must be the same. That's why I said it's random, because the mp3 start time is affected too, not just the hitsounds.

Values of +1 or -1 to the ideal UO value will usually produce at least 1 jump of an extra 10ms in either direction. As Full Tablet said, due to the standard deviation, you can assume that the value with the least 10ms jumps is the correct one, or in my case, I managed to find a value with no jumps at all. I don't know how that would fair for other people though. Every computer is different.

The human brain can easily compensate for a small consistent delay. It's when it is inconsistent that causes problems.

I hardly ever tamper with local offset tbh. I just test with it.
Please sign in to reply.

New reply