Audio animation bug (fcurves) #43853

New Issue

Campbell Barton · 2015-03-02T00:23:36+01:00

Campbell Barton commented

2015-03-02 00:23:36 +01:00

FCurves fail on mixdown sequencer audio.

The attached file has 2 sequencer channels alternating

[noise/tone/noise/tone/noise] - each ~40 frames.
Where the tone is a single strip using an fcurve to fade out during the second noise strip.

Currently there is a bug. Open this file and play the sound, it works as expected.

But when the audio is mixed down, frames (41 -> 78) contain silence (out.wav in attached file)
Strangely however the second half of TONE strip does play.

This bug happens even when the accuracy value is set to 1.

Note that the first NOISE strip also has an FCurve, and this works correctly (without initial silence).

mixdown_bug.zip

FCurves fail on mixdown sequencer audio. The attached file has 2 sequencer channels alternating `[noise/tone/noise/tone/noise]` - each ~40 frames. Where the **tone** is a single strip using an fcurve to fade out during the second noise strip. Currently there is a bug. Open this file and play the sound, it works as expected. But when the audio is mixed down, frames (41 -> 78) contain silence (`out.wav` in attached file) Strangely however the second half of `TONE` strip does play. This bug happens even when the *accuracy* value is set to `1`. Note that the first `NOISE` strip also has an FCurve, and this works correctly (without initial silence). [mixdown_bug.zip](https://archive.blender.org/developer/F146615/mixdown_bug.zip)

Campbell Barton commented

2015-03-02 00:23:36 +01:00

Changed status to: 'Open'

Joerg Mueller was assigned by Campbell Barton

2015-03-02 00:23:36 +01:00

Campbell Barton commented

2015-03-02 00:23:36 +01:00

Added subscriber: @ideasman42

blender-admin commented

2015-03-02 00:23:36 +01:00

#44902 was marked as duplicate of this issue

Julian Eisel commented

2015-03-02 18:47:04 +01:00

Added subscriber: @JulianEisel

Joerg Mueller changed title from ~~Audio mixdown bug (fcurves)~~ to Audio animation bug (fcurves)

2015-03-08 06:04:11 +01:00

Joerg Mueller commented

2015-03-08 06:36:21 +01:00

Hi,

I had a look at the file and started debugging. The bug is not related to mixdown. When you open the test file and playback playback sounds fine the very first time, but if you keep it running it will have the same bug in following runs.

Debugging I found the problem is specific to this case in the way that in anim_sys.c:1551 properties are updated only when the value changes. The audio system has a cache of the animation values that is empty at the beginning. As it is empty, the sound has a default volume of 1.0 in the beginning, so during first playback it is fine.

Now when the animation is played back the first time it never sets the volume property of the animated sound until it reaches the frame where it jumps to 0. Here the if in anim_sys.c:1551 passes and as a result the audio animation system cache gets the info that on frame 80, the volume is now 0. As the buffer was empty before it creates a new one with 81 frames (starting at 0), filling all of them with 0, as it didn't know the value before, but marks the first 80 as unknown, so it looks like this:

000...0000
UUU...UUUK

(U is unkown, K is known)

Now it stays 0 until frame 111 when it jumps back to 1 and the anim_sys.c:1551 line triggers a write to the cache again. The frames 81 to 110 are unkown again and as the previous value has been 0, this 0 gets copied up to 110.

000...0000000...0001
UUU...UUUKUUU...UUUK

Until frame 181 it stays at 1 and thus the cache never gets updated again. Now when it jumps back to frame 1, there is again no difference according to anim_sys.c:1551 and we get only the same two updates we had during the first playback. As the buffer exists now and has been initialized with 0, the strip doesn't play in the beginning though.

Now if the playback is between frame 80 and 110, so while the value is 0 and you now seek to X, which is somewhere between the 0 and 79, you get an update through anim_sys.c:1551 as 0 and 1 are different and it writes a 1 to X and updates the unknown values behind that, making it look like this:

000...0001111...1110000...0001
UUU...UUUKUUU...UUUKUUU...UUUK

If you play back then, you'll hear that from that frame X you seeked to on it will be correct.

It all comes from the policy how unknown animation cache is initialized. The attached patch.diff changes the policy to use the default value for the beginning of the buffer instead of the first written value and thus fixes the bug. I hope that it doesn't introduce any other bug though.

Can you test this Campbell and maybe add your comments. If it's ok I'll commit the bug fix after release or if you think it's ok during bcon 4 still.

Hi, I had a look at the file and started debugging. The bug is not related to mixdown. When you open the test file and playback playback sounds fine the very first time, but if you keep it running it will have the same bug in following runs. Debugging I found the problem is specific to this case in the way that in anim_sys.c:1551 properties are updated only when the value changes. The audio system has a cache of the animation values that is empty at the beginning. As it is empty, the sound has a default volume of 1.0 in the beginning, so during first playback it is fine. Now when the animation is played back the first time it never sets the volume property of the animated sound until it reaches the frame where it jumps to 0. Here the if in anim_sys.c:1551 passes and as a result the audio animation system cache gets the info that on frame 80, the volume is now 0. As the buffer was empty before it creates a new one with 81 frames (starting at 0), filling all of them with 0, as it didn't know the value before, but marks the first 80 as unknown, so it looks like this: ``` 000...0000 UUU...UUUK ``` (U is unkown, K is known) Now it stays 0 until frame 111 when it jumps back to 1 and the anim_sys.c:1551 line triggers a write to the cache again. The frames 81 to 110 are unkown again and as the previous value has been 0, this 0 gets copied up to 110. ``` 000...0000000...0001 UUU...UUUKUUU...UUUK ``` Until frame 181 it stays at 1 and thus the cache never gets updated again. Now when it jumps back to frame 1, there is again no difference according to anim_sys.c:1551 and we get only the same two updates we had during the first playback. As the buffer exists now and has been initialized with 0, the strip doesn't play in the beginning though. Now if the playback is between frame 80 and 110, so while the value is 0 and you now seek to X, which is somewhere between the 0 and 79, you get an update through anim_sys.c:1551 as 0 and 1 are different and it writes a 1 to X and updates the unknown values behind that, making it look like this: ``` 000...0001111...1110000...0001 UUU...UUUKUUU...UUUKUUU...UUUK ``` If you play back then, you'll hear that from that frame X you seeked to on it will be correct. It all comes from the policy how unknown animation cache is initialized. The attached [patch.diff](https://archive.blender.org/developer/F147979/patch.diff) changes the policy to use the default value for the beginning of the buffer instead of the first written value and thus fixes the bug. I hope that it doesn't introduce any other bug though. Can you test this Campbell and maybe add your comments. If it's ok I'll commit the bug fix after release or if you think it's ok during bcon 4 still.

blender-admin commented

2015-03-16 11:02:04 +01:00

This issue was referenced by 2fa593a6f7

This issue was referenced by 2fa593a6f7d0dcf4a638180da1afd6d10afc3ac5

Joerg Mueller commented

2015-03-16 11:02:59 +01:00

Changed status from 'Open' to: 'Resolved'

Joerg Mueller closed this issue

2015-03-16 11:02:59 +01:00

Joerg Mueller commented

2015-03-16 11:02:59 +01:00

Closed by commit 2fa593a6f7.

Closed by commit 2fa593a6f7.

blender-admin commented

2015-03-24 15:47:46 +01:00

This issue was referenced by 1ad57f287b

This issue was referenced by 1ad57f287b13f60c22b621179f9e6f22d0b191e5

Joerg Mueller commented

2015-06-01 09:35:39 +02:00

Added subscriber: @pocock

Daniel Pocock commented

2015-06-01 11:51:09 +02:00

I tried applying the patch to the Debian package 2.72.b+dfsg0-3 and it didn't resolve the issue. It still has all of the symptoms, e.g. mixdown generates a file without respecting the curves, playback in the Blender UI sometimes has no audio and sometimes ignores the curves for audio and just plays all the audio at full volume.

Then I tried the newer code, 2.74+dfsg0-2 from the Debian Git repository, I was able to use the mixdown successfully and save the audio to an Ogg Vorbis file.

I tried applying the patch to the Debian package 2.72.b+dfsg0-3 and it didn't resolve the issue. It still has all of the symptoms, e.g. mixdown generates a file without respecting the curves, playback in the Blender UI sometimes has no audio and sometimes ignores the curves for audio and just plays all the audio at full volume. Then I tried the newer code, 2.74+dfsg0-2 from the Debian Git repository, I was able to use the mixdown successfully and save the audio to an Ogg Vorbis file.

Daniel Pocock commented

2015-06-01 13:54:02 +02:00

I think there was something wrong with my build of 2.72.b+dfsg0-3, after making a fresh build with the patch it does also appear to be resolved for that version so hopefully the patch can be backported for the stable Debian package. Thanks for fixing this and providing prompt feedback about the issue.

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

Audio animation bug (fcurves) #43853