Why is bounce in place not sample accurate?

[Jac459]

https://www.youtube.com/live/sQochiMOzO ... xSs&t=1791

One of the Bounce - problems is described here, starting with minute 29.40

Quote "9 times out of 10, whenever i pull up some kind of kick and resample it, i end up losing the transient"

It's a known problem, and it sucks, and it hopefully will be patched out of Bitwig.

Isn't this one simply due to the autofade as described earlier?

It would have been a wonderfully simple solution, but no.

Recordings and Bouncings are not affected by autofade. They arent what Bitwig calls "Audio-Edits" in its Autofade settings. Audio Edits are a very limited category, like Splitting.

Actually, i was filing a feature request to Bitwig some weeks ago, to please include a second Autofade setting, which affects recordings. Which is really necessary for live performance, to get rid of harsh "blips/clicks" at the beginning of clips in the Launcher. (When recording long sustained notes which already play before hitting record!) Ableton has a "FADE" Button in each Clip for that purpose, which is turned on by default.

Thanks for the explanation mate!

[JHernandez]

Have you any of you noticed this issue with regular Bounce? (to a new track) Personally I haven't and that's what I use. Just curious.

Yea Alchemy Neuro is using regular bounce in his example (bouncing a phase plant kick sound into a fresh audio track)

Ah ok, now I remember. I actually commented on the video earlier in the thread. I totally forgot. My bad.

[Resonant- Serpent]

Has anyone checked if this bug is still present in 5.1?

[valankar]

Has anyone checked if this bug is still present in 5.1?

It is unfortunately. To followup, this was the response I received from support:

in certain cases, esp. when using audio files that are in stretch modes compared to audio files in raw or other stretch modes, or when using audio files with a different sample rate than then project sample rate or when cutting audio files and loop being active, it is possible that the playback position of a clip differs by exactly one sample due to rounding during the loop.
As it is not possible to play something with a higher accuracy than one sample, the app has to decide if it mathematically falls between the time frame of one sample. Practically it does not make any difference when mixing and can only be observed when trying to cancel out the start of exactly the same signal while looping.

And regarding why it sometimes cancels when looping:

the reason it sometimes cancels completely and sometimes not is due to the rounding, as explained, and because of the timing of the playback being shifted by one sample or not. We might be able to improve this in the future, but this can only be observed with trying to null the first sample click of two exactly bit-identical signals. A phase "shift" by one sample is practically not really affecting the phase of any other use cases, as you can see in your example, the rest also cancels out.

I personally don't agree with this explanation as the problem doesn't exist in other DAWs, but at least they responded. Even if you duplicate time and render master output (i.e. not using loop), the random cancellations still persist. I would say if it matters to you, to email support so they know.

[Resonant- Serpent]

Has anyone checked if this bug is still present in 5.1?

It is unfortunately. To followup, this was the response I received from support:

in certain cases, esp. when using audio files that are in stretch modes compared to audio files in raw or other stretch modes, or when using audio files with a different sample rate than then project sample rate or when cutting audio files and loop being active, it is possible that the playback position of a clip differs by exactly one sample due to rounding during the loop.
As it is not possible to play something with a higher accuracy than one sample, the app has to decide if it mathematically falls between the time frame of one sample. Practically it does not make any difference when mixing and can only be observed when trying to cancel out the start of exactly the same signal while looping.

And regarding why it sometimes cancels when looping:

the reason it sometimes cancels completely and sometimes not is due to the rounding, as explained, and because of the timing of the playback being shifted by one sample or not. We might be able to improve this in the future, but this can only be observed with trying to null the first sample click of two exactly bit-identical signals. A phase "shift" by one sample is practically not really affecting the phase of any other use cases, as you can see in your example, the rest also cancels out.

I personally don't agree with this explanation as the problem doesn't exist in other DAWs, but at least they responded. Even if you duplicate time and render master output (i.e. not using loop), the random cancellations still persist. I would say if it matters to you, to email support so they know.

Thank you for the information. At least now I have a better grasp of the issue. I'll continue to use Rolling Sampler to get around it.

[sjebrane]

I think what you mention guys is far from being something that could alter or affect badly your mix its something that could happen with any DAW not just bounce but sometimes using stock plugins or third party plugins that how digital workstation works one thing to keep in mind as long as it sounds good nothing matters and these slight tiny things would never affect nor have big impact on the mix hope my idea make sense to you

[Danilo Villanova]

Is this fixed now?

EDIT: nope.

[nowiamone]

Is this fixed now?

EDIT: nope.

Hello, i'm trying to understand this bug, so i can report it too - could you please tell me:
- this only happens when bouncing in place Audio, correct?
- this only happens when using bounce in place, NOT with the normal "bounce" (which bounced into a second track) -> or am i wrong, and it also happens with normal bounce?

Also, i'd like to know if the beginning of the clip always has this "fade/being cut"-issue for you too, which you see in this video: https://www.youtube.com/watch?v=tQK3ziegX5Y

[Danilo Villanova]

Is this fixed now?

EDIT: nope.

Hello, i'm trying to understand this bug, so i can report it too - could you please tell me:
- this only happens when bouncing in place Audio, correct?
- this only happens when using bounce in place, NOT with the normal "bounce" (which bounced into a second track) -> or am i wrong, and it also happens with normal bounce?

Also, i'd like to know if the beginning of the clip always has this "fade/being cut"-issue for you too, which you see in this video: https://www.youtube.com/watch?v=tQK3ziegX5Y

I actually can't reproduce anymore. I'm only an occasional BW user, so I read about this bug and decided to test it on a fresh install of BW. I opened a new project this morning and tried bouncing a kick drum sample.

Both bounce in place and normal bounce would show the bug. Bounce in place seemed to be worse, but I could be wrong.

I closed BW and opened REAPER to compare. It's super tight (although, it does seem to move by 1 sample sometimes).

I read your post and decided to check back, so I opened BW again and tried bouncing a kick drum. It works perfect now. Could it be that the bug appears only when BW is 'indexing' my entire computer?

I will do more tests. Would appreciate if anyone else could do the same, it's just bouncing a file and zooming in.

[Danilo Villanova]

Ok, after some more tests:

Bounce if broken when you adjust the size of a clip. If you adjust the clip start time to make it shorter, then move back the clip to the start of the bar and then bounce, it will be bounced later than the original file. I tried consolidating the clip and doing a bounce in place, but the issue persists.

EDIT: I read through this thread again and OP seems to have had the issue with clips that had already been chopped or resized. So, if you import a wav file and bounce it without altering it, everything works fine. But do anything to the clip and the bounce will be out of place.

[pdxindy]

Ok, after some more tests:

Bounce if broken when you adjust the size of a clip. If you adjust the clip start time to make it shorter, then move back the clip to the start of the bar and then bounce, it will be bounced later than the original file. I tried consolidating the clip and doing a bounce in place, but the issue persists.

Good find! Please report it to Bitwig!

[Danilo Villanova]

Ok, after some more tests:

Bounce if broken when you adjust the size of a clip. If you adjust the clip start time to make it shorter, then move back the clip to the start of the bar and then bounce, it will be bounced later than the original file. I tried consolidating the clip and doing a bounce in place, but the issue persists.

Good find! Please report it to Bitwig!

I just did. Hope it gets taken care of. I bounce drum shots a lot and need them to be TIGHT!

[BobDog]

Yep very good find.

[nowiamone]

Ok, after some more tests:

Bounce if broken when you adjust the size of a clip. If you adjust the clip start time to make it shorter, then move back the clip to the start of the bar and then bounce, it will be bounced later than the original file. I tried consolidating the clip and doing a bounce in place, but the issue persists.

EDIT: I read through this thread again and OP seems to have had the issue with clips that had already been chopped or resized. So, if you import a wav file and bounce it without altering it, everything works fine. But do anything to the clip and the bounce will be out of place.

Very cool that you checked that out in depth

[Davedfx]

I have no problems here. I bounced and got no issues. No clipping or offsets. I tried inverting the stereo phase and it's perfect It must be a bug on certain systems
Macbook pro m1 Pro Sonoma.