1. An algorithm to detect where the downbeat lies. It currently sets the offset on an arbitrary beat.
2. A proper and accurate way to determine if BPM, say ***.002 or ***.999, is actually an integer or is it really a bit off, and round the result if desirable.
3. Since osu! and osu!sdk are written in C#, while dsp is floating point operation heavy, I'm concerned that it might become several times slower than the current C++ implementation if it is to be ported to C#.
4. Where to set the "offset offset", i.e. how much is the offset used in mapping off the actual beats in audio waveform. Afaik a universally agreed reference point doesn't exist (even tutorial is considered off timing by BATs), and the de facto standard is how the community sets it, which is prone to drift over time, especially so during 2007-2009. I set the "offset offset" in my program to -22.5ms in late 2010, matching the average of some dozen newest ranked maps at that time.
5. It doesn't work on songs with multiple timing sections. Anyway I would probably never try to do this

mm201 wrote:

The community offset ("offset offset") is around -15ms in my experience. osustream maps are synced to the waveform and I've noticed I need to adjust my offset by 15ms for them to sound right. Mind that osu!'s audio decoder also adds 30ms of leading silence to CBR mp3s.
Some statistics (54 late 2010 ranked maps I analyzed):
Multiple sections: 2%
BPM off: 11%
From the remaining 47 ranked maps:
Mean: -23ms
Std dev: 5ms
Median: -23ms
Quartiles: -26ms, -20ms
Cf. tutorial -35ms from waveform
I use bass.dll included in osu! install to decode mp3s.

You said yourself that finding the timing when there are multiple sections is really hard. Unfortunately, this is the only really useful function needed. It takes me all of 10 seconds to find the timing for a song with a single section and integer BPM.
Unfortunately, not all mappers are good at timing. I know some mappers that just often fail to get the offset within even, say ±10ms, so that a timing detection program would offer a much better starting point to get with.
As for fractional BPMs (which actually are not rare), it would take mappers longer to figure that out. Lots of mappers are also not accurate enough on bpm (bpm error of 0.01 is large: it would cause 16ms drift of timing on an 150-bpm 4-minute song), or sometimes fails to notice that a song's bpm is 0.01/0.02 apart from integer.
At the very least, it works as a recheck method in case there's a mistake or mistiming is overlooked (that's how Alace used it lol)
Btw, some ranked maps really need online bpm adjustment (+120ppm -10ms, etc.)


C#'s performance is pretty good, especially when using unmanaged arrays. It also makes interop with C(++) very easy if you want to go that route.