[invalid] [Proposal/Discussion] Discourage VBR MP3 use

Total Posts
Topic Starter
Ryu Sei
The usage of VBR MP3 should be discouraged because it introduces discrepancy between intended preview point and actual ones played in-game and web. This, however, doesn't happen on OGG because the format itself designed to maintain the sync between audio data and timing information. Both formats in VBR doesn't affect gameplay, though.

So far, I only see one in Ranked section, though I believe there are more.

I'm proposing to add a point to discourage the use of VBR in MP3 files on audio guidelines. It should looks like this:
  1. Avoid using MP3 file format with variable bitrate. Due to the nature of the format, a desync might occur between intended and played preview point. If you want to use variable bitrate, use OGG file format instead.
The preview point on that set is definitely broken, but I'd like to see more recent examples before I form an opinion about the issue, since VBR was apparently bugless in August 2019.

Ryu Sei wrote:

So far, I only see one in Ranked section, though I believe there are more.
okay! here are some more examples of vbr mp3s that randomly popped in my head

imo they should be fine if explorer/foobar2000/etc shows that the bitrate is equal to or lower than 192kbps
explorer isnt really accurate but eh just throwing it out there
Topic Starter
Ryu Sei
I've dumped almost ALL of osu! maps I have with VBR MP3. It might be inaccurate since it lists all MP3 files, regardless of it updated from server or not, and doesn't discern whether it's used as playable audio file or storyboarded hitsound. Below is the list of the files after automating it with script to detect whether the MP3 file is VBR or not; if it's VBR, it exist in that list.

The discrepancy of intended and played preview point can be quite big, though some are negligible, and I think it's a recurring issue with VBR MP3.
i recall to similar problem back then (im using stable release), and i did open issue in github

directly taken from there

peppy wrote:

This sounds like a stable issue. It is likely due to using a vbr track (which means the location may not be perfect). This isn't getting fixed in stable, but as you've noticed, works correctly in lazer, which will replace that version eventually.
so it might have something to do with stable encoder or something that behave weirdly, yet in lazer the issue almost nonexistent

tho i have no idea if in website it has similar behaviour with stable, but from what i know its not a problem (but then i didnt really up to date with how things developed so take this as massive grain of salt)
Topic Starter
Ryu Sei
I assume the problem on web is the outdated audio preview, then. I guess we shouldn't continue this topic and close it down for good. Thanks for the clarification!
Please sign in to reply.

New reply