Recent Changes to Uploaded Audio Compression/Processing Causing Timing Drift

Website/Engine(?) Bug: Recent Changes to Uploaded Audio Compression/Processing Causing Timing Drift

As of the time of the recent Audio Update (and possibly some time before), the compression/processing of audio on Roblox’s side after being uploaded to the library appears to have changed. This has caused the timing of audio files on the platform to not match their original file equivalents in an inconsistent manner, especially for longer audios.

A background:

Click to expand

Most pianos on Roblox based on the NickPatella implementation use a set of 6 audio files collectively referred to as a “soundfont” in order to play note sounds. Each audio is comprised of 8-second-long notes from a pair of keys. For instance, the first audio in this set contains 8-second-long C/C# notes, such that the audio begins with 8 seconds of a C2 note, followed by 8 seconds of a C#2 note, 8 seconds of a C3 note, so on and so forth until reaching the end of the range of a 61-key keyboard (C7).

This allows for the TimePosition of notes to be easily calculated: C2 is located at Sound.TimePosition = 0, C#2 at Sound.Timeposition = 8, C3 at Sound.Timeposition = 16, etc., and this format is likewise used for the rest of the note pairs in the soundfont (D/D#, E/F, F#/G, G#/A, and A#/B). This format is reliant, however, on the audio being in their assigned TimePositions – any deviation creates clicking, popping, a noticeable delay before any sound, or any combination of the three.

The errors caused by this deviation are referred to as “desync”, as the sound is no longer consistently “synced” with other notes in the same soundfont. Uploading soundfonts to the platform for use in production has always introduced a certain amount of desync due to (what is presumed to be) compression/processing of the audio before being stored on Roblox servers. This desync is definitely added by Roblox, as testing soundfonts in Studio using local files prior to uploading shows no desync whatsoever.

In prior years, desync was handled by adding an additional offset to the Sound.TimePosition, which was possible due to the amount/level of desync to the soundfont being mostly consistent. As of late, however, I and other developers have noticed a change in that desync added is now markedly inconsistent and makes the Sound.TimePosition method nearly impossible to use properly, even when trying to account for it. This has the effect of the sound of a note not matching up with the exact moment it is expected to be played, which becomes extremely obvious when playing chords or notes in consistent succession.

Reproduction steps (see @lexandstuff’s post below for a simpler repro):

  • Download and extract the original audio files from the .zip below: (7.0 MB)

  • Place the extracted files (1.mp3 through 6.mp3) into the /content/sounds folder of the Studio version being used. These are the original asset files prior to being uploaded to the platform.

  • Download and open the following reproduction place:
    compressionreport.rbxl (42.9 KB)

  • Start a Play Here session and open Output. Using the gui, you can toggle what keys to play simultaneously and see their set TimePosition in the output. Clicking the “Asset:” button will toggle which sound assets to play (between Uploaded and Local). Clicking the “Play Selected” button will play all selected notes simultaneously.

  • As an example, select C2 and E2 and hit “Play Selected”. The sounds should play simultaneously for both Uploaded and Local assets. The Output should show that the TimePosition of both notes are 0.

  • Next, select C2 and F2 and hit “Play Selected”. The sounds should play simultaneously for Local assets, but a delay (desync) should be noticeably present for Uploaded assets. The Output should show that the TimePosition of F2 is being set to 8 as expected.

  • Testing various combinations should show that Uploaded assets contain varying and inconsistent amounts of timing drift at all nonzero TimePosition values, even for sounds at the same TimePosition (e.g. C#3 & G3, which are both TimePosition = 16).

A video demonstration of the steps above can be viewed below (sans Output):
robloxapp-20220329-0124393.wmv (654.0 KB)

Expected Behavior:

No significant delay/desync should occur when settings the TimePosition of sounds to specific values where they are expected to be synced, as with the playing of Local assets in the reproduction place.

Actual Behavior:

Delay/desync is present for all recently uploaded sound assets in varying, inconsistent amounts in both Studio and production games.

Issue Area: Roblox Website(?)
Issue Type: Other
Impact: Medium
Frequency: Constantly
Date First Experienced: 2022-03-23

Possible workarounds:

  • Reuploading files in different bitrates and file formats
    • Did not work, desync was still present
  • Attempting to account for desync by calculating & adding additional offset
    • Desync is present in inconsistent amounts all throughout, making this virtually impossible
  • Uploading 61/88 individual audio files to avoid setting TimePosition entirely
    • Currently untenable: common audio upload limits are 10/100, a disproportionate amount of work is required, and easily affected by wrongful moderation

cc: @Extragold, @Seenall, @angelkireina, & @Disformed_Potato on Roblox for additional info regarding this issue.


Thanks for the report! We’ve filed a ticket to our internal database, and we’ll follow up when we have an update for you.


Looks like this is affecting us too :sob:

Here’s a really simple repro for you. I have a clip of almost silence where the source is 0.6857142857142857 seconds long.

Here’s the source OGG file:

After uploading to Roblox, then downloading it using Chrome Web Tools in the asset page the duration of it changes to 0.687891156462585 seconds.

You can see the difference in audio lengths in Audacity. It looks like Roblox is appending some kind of fade to the audio maybe.

Even weirder, the same audio we uploaded earlier when downloaded is 0.6980498866213152 seconds. So the amount of fade appears random.

Having correct audio lengths is really important for us. We utilise a beat length of silence to allow us to sync multiple audio loops allowing players to make original compositions of loops. Without accurate sound lengths, we aren’t able to continue doing this.

Thank you!


I have been experiencing this since 20/11/2021(dd/mm/yyyy) and it has affected every audio I have uploaded since.

AssetID of audio where issue was first experienced: concert wrong volume level - Roblox

Any audio upload I have done prior to that did not have this issue.


1 Like

In the last 2 days, we suddenly have a lot of users complaining about loops being out of sync… It seems this bug went from only affecting newly uploaded audio to affected ~50% of all our uploaded audio.

Is there any chance that Roblox are running a processing job to reprocess previously uploaded audio with this new bug?

This audio sample is 6.735 seconds long: rbxassetid://6842458063
This audio sample is 6.713 seconds long: rbxassetid://6842460245

At the time of upload, I’m confident they were the exact same length.

Looking at the audio page for loop 6842458063, it looks like the audio was modified 2 days ago. That would coincide with exactly when this particular loop set (and many others like it) was reported as broken:


Here’s another waveform comparison for ya’ll with something that’s not silence. The top one is the Roblox uploaded track, the bottom one is the source. You can see that Roblox is appending silence to the track for some reason. The length of the silence appended appears to be somewhat random across audio.

We are going to see if we can write our own looping engine in Roblox in the meantime.

Thank you for the detailed reports all; we are investigating


Hello All,
Many thanks for the report and the test case.
We just fixed this bug and updated our servers.
Please re-upload the audio and give it a test.
Thanks - and keep the reports coming!


I apologize if this counts as off topic, I am unable to post directly in #bug-reports and I noticed this may be related to my issue; today’s Roblox update has messed up some of my audio by producing weird blips usually at the beginning of the audio’s playback (only in Studio and in-game, does not happen on the site). This did not happen before now and does not happen in any of the audio files I uploaded to Roblox with. Would this issue happen to have stemmed from this bug fix?

(Found this in logs, the ID is the audio that is most notably blipping in studio. Content failed to parse for rbxassetid://9611717818 because SerializerPugi::deserializeImpl ill-formed XML.)

This update may have also caused SoundService’s AmbientReverb to play audio differently as my game uses the “Forest” setting and after this update suddenly all audio is echoing much more than it usually did before.

Edit: Should also note that reuploading the same audio or attempting to trim the beginning and then reuploading it did not fix my issue.

In addition to @texticks issue, I am also noticing bizarre audio behaviour as of recently today. Sounds that are extremely far away are still audible, when they previously weren’t. I’m also hearing some sounds as if they’re playing locally in addition to playing in the world. The sounds in question are playing in-world from the server.

I’m only noticing this on in-world sounds (not 2d sounds) and in live games. It does not appear to be happening in Studio.

You can notice this issue right away by joining any server on this game: [Carriages+] Wild Horse Islands - Roblox - You will hear “clicking” or “fireworks” in the distance. These are horse hoof sounds thousands of studs away.

I made a new thread to bring the issues created by today’s changes to the top.


Seconding this, just noticed this started happening a few minutes ago in my game Attrition. It seems that audio equalizing is messed up. Distant sounds are very loud and muffled, and louder sharper sounds are quiet and crackly.

Sounds also play when audio is muted

This only affects 3D sounds, 2D sounds seem to be alright.


Just following up.
The post is marked as solved by the author!
Therefore, we are closing this post. For any other issues, please make a new bug report, so we can look into!

Thank you!

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.