I mean this could be enum for placement and pan field of -1 to 1 range.

Is this report really for version v2.76b?
That version is almost 4years old. We are not able to make fix for such old release. Please consider upgrading.

I wonder if it would be possible to show which speaker the pan is directed towards, by putting a Letter, representing the speaker, next to the number?

I would say, that this panning range seems a bit hacky, but it is also described in manual:
https://docs.blender.org/manual/en/latest/video_editing/sequencer/properties/strip.html#sound

Yet the default settings allow you to set it out of range -2 and 2. If it is set out of range, it won't pan at all.

In tomorrows build (with the fix above), having the soundstip in there should also not crash anymore...

Hi. Yes, deleting the audio track takes care of the crash issue on 2.81 alpha. Thank you.

Exact Steps:

• Open provided file
• Window -> New Window
• Play Animation (spacebar)
• Close Window

Audio is still still playing until end

I have a strong feeling, that this, T68945: VSE - Improper audio on frame 1 when exporting to lossy-compressed audio and T69167: VSE - "Render Audio" exports only one audio strip in some cases are caused by the same issue, or at least an issue in depsgraph.

Possibly Depsgraph issue.

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

Archiving, cannot reproduce that anymore with current own builds… Probably a mysterious glitch in libs/compiler/linker magic.

Blender 2.8 uses the latest version of audaspace where the aud API has changed considerably, please refer to the audaspace bindings API documentation.

On windows you can just download and run Blender, no need to install.
Not sure about other platforms.

Right now I am focusing on bugs.
If there is VSE bug not tagged, I guess other devs will relay this to me If I don't catch it.

Okay, maybe the bug has been fixed as a side effect of something else then?
I will test on 2.80 as soon as it's officially released. I hesitate to remove my current installation in case something breaks, and I'll need to deal with reinstalling an old version...

Yes, this is still an issue. It's a minor inconvenience for me, but others may find it a blocker in their work flow.

Is this still an issue?
If yes, Should I keep VSE tag?
I am trying to cleanup workboard a bit..

Since last asking for information it has been 7 or more days, due to the policy of our bug tracker we will have to archive the report until the requested information is given.

@Hossein Shah (hk1ll3r), you're right the strip length stays the same, but that doesn't mean that the speed doesn't change. If you have a strip of full length (not cut on any side) and you change the pitch to 2, you'll end up with double pitch and double speed, but the strip will stay the same length, meaning that it's silent in the second half. We intentionally don't change the strip length when the pitch is changed, since this can cause many problems, especially when you animate the pitch. I hope this clarifies the issue. If not, please ask further questions on devtalk.blender.org as @Sergey Sharybin (sergey) suggested.

@Hossein Shah (hk1ll3r), instead of re-opening old reports, make a new one. With all the information requested there.
Please note that this is not really a place for discussion, but for a bug tracking, where artists report reproducible bugs and developers fix them. For discussions there are other channels like devtalk.blender.org, or blender artists.

I'm new to blender, not sure if this is the right place but here I try...

Only now I realized, that this is 2.79 bug report
Can not reproduce this in 2.79 f4dc9f9d68b or in 2.8

Unfortunately gcc9 is not actually installable in debian testing currently (there are some unstable packages, but broken).

See attached screenshot for the codec settings.

In T61043#611875, @Joerg Mueller (nexyon) wrote:

The bug was introduced in rBdbe23c545649, so it only exists in 2.8, not 2.7. And yes @Richard Antalik (ISS) I can confirm that, but it has nothing to do with this bug.

The bug was introduced in rBdbe23c545649, so it only exists in 2.8, not 2.7. And yes @Richard Antalik (ISS) I can confirm that, but it has nothing to do with this bug.

@Joerg Mueller (nexyon), not sure if you are involved in audio codec stuff, can you confirm my claim: "especially mp3 can report longer length of data stream then actual length." This is just a general observation from number of mp3 files, that behave this way.

Just tried with setting it in C/CXX FLAGS but same result as with WITH_COMPILER_ASAN. Please let me know what you get with gcc9. If you still have it there, I fear you'll have to help me debugging this. ;)

Hrrrmmm… Well, I do not use WITH_COMPILER_ASAN either, it does not work very well for me… So I rather just edit the CMAKE_C/CXX_FLAGS_DEBUG flags in cmake, and add -fsanitize=address to both.

I tried reproducing - I enabled WITH_COMPILER_ASAN (and disabled cycles and libmv in order to get it compile on my machine) but I only get memory leaks when I run blender then, not the error you reported. Do you have any hints on how to reproduce it?

@Joerg Mueller (nexyon) Assigning to you for now, guess you'll be more familiar than me with c++/templates/std weirdness. ;)