VSE - Improper audio on frame 1 when exporting to lossy-compressed audio #68945

New Issue

hudson barkley · 2019-08-21T00:41:27+02:00

hudson barkley commented

2019-08-21 00:41:27 +02:00

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)

**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. ![Clipboard02.png](https://archive.blender.org/developer/F7676188/Clipboard02.png) 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. ![Untitled.png](https://archive.blender.org/developer/F7676171/Untitled.png) **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)

hudson barkley commented

2019-08-21 00:41:27 +02:00

Added subscriber: @snuq

Paul McManus commented

2019-08-21 07:59:25 +02:00

Added subscriber: @PaulMcManus

Paul McManus commented

2019-08-21 07:59:25 +02:00

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.

hudson barkley commented

2019-08-21 18:54:06 +02:00

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.

Richard Antalik commented

2019-08-28 16:17:50 +02:00

Added subscriber: @iss

Richard Antalik commented

2019-08-28 16:17:50 +02:00

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.

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 commented

2019-10-01 21:10:27 +02:00

Added subscriber: @neXyon

Richard Antalik commented

2019-10-01 21:10:27 +02:00

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

here is reproducible sample:
aud.zip

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.

@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

This seemed like a headscratcher, until I realized, that this has nothing to do with animating the strip. here is reproducible sample: [aud.zip](https://archive.blender.org/developer/F7783912/aud.zip) 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. @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 ![aud.png](https://archive.blender.org/developer/F7783932/aud.png)

blender-admin commented

2019-10-03 10:24:33 +02:00

This issue was referenced by 514c9d14e4

This issue was referenced by 514c9d14e4ab4fb90237e63d8ec89e9bc2322810

Joerg Mueller commented

2019-10-03 10:27:16 +02:00

Changed status from 'Open' to: 'Resolved'

Joerg Mueller closed this issue

2019-10-03 10:27:16 +02:00

Joerg Mueller self-assigned this 2019-10-03 10:27:16 +02:00

Joerg Mueller commented

2019-10-03 10:30:14 +02:00

If I'm right this issue is the same as #52472 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.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

VSE - Improper audio on frame 1 when exporting to lossy-compressed audio #68945