Page MenuHome

VSE - Improper audio on frame 1 when exporting to lossy-compressed audio
Closed, ResolvedPublicBUG


Blender Version
Broken: 2.80

Short description of error
When audio from the vse is exported to lossy-compressed formats (mp3, ac3, aac), blender is adding an odd fadein on it. (see channel 6 in the attached blender screenshot).
It actually appears somewhat like a fadein in blender, but when imported into audacity, there is a .005 second silence, then instantly full volume.

Whats worse, this false fadein seems to override any keyframes on the first frame: if the audio has a 6 frame fade in keyframed in, it will do that weirdness for the first frame, then return to the proper volume for frame 2 and continue the fade in. This creates a kind of 'hump' where there should be a smooth transition. (See channel 3 in the attached blender screenshot)

Oddly, this bug does not happen on non-lossy formats (wav, pcm, flac) (see channels 4 and 7 on the attached blender screenshot).

Note: all these tests were done with a basic sinewave test tone for maximum visibility of the waveform.

Exact steps for others to reproduce the error
Load an audio file with audio immediately at the beginning into the vse
Add a fadein
Render audio out to a lossy compressed format (either in a video, or as audio alone)

Revisions and Commits

Event Timeline

Can I add that the preview playback in the viewport doesn't exhibit this problem. It only manifests in the encoded output file. I'm not sure how far back this goes but I can confirm this has been a problem in 2.8 for several weeks now.

ok, this is weird... today im not getting the same issue with the 'bump' when exporting only audio, even compressed.... but I still see the issue every time when exporting to video/audio combined... but I now see it with ANY audio codec in video, not just lossy formats.

I do experience similar issues during preview, but not in rendered files, at least not "audibly"
This is quite contrary, to what's reported.

I never looked at cause of this issue, but I am pretty sure it's outside of scope of VSE code.

Richard Antalik (ISS) lowered the priority of this task from 90 to High.Sep 29 2019, 5:27 PM

This seemed like a headscratcher, until I realized, that this has nothing to do with animating the strip.

here is reproducible sample:

What happens is:
If sound strip has volume greater than 0, first few ms of rendered audio looks like fade-in from volume 0 to 1, then it fades to volume of the strip itself. This happens during first frame.

This is happens even with lossless format, unlike original report.

@Joerg Mueller (nexyon) can you please look into this? I have looked at what values we are setting, and that all seems to be correct.

When strip is animated, changes in volume in rendered audio looks highly irregular and not quite bound to frame boundaries. As if rendering and controlling threads weren't synced or what

If I'm right this issue is the same as T52472 and it was my mistake that I didn't correctly backport this to upstream audaspace and this caused a reintroduction of the bug. Please check if it's fixed for you now! There is some more explanation in the other bug report.