Sample-accurate splits?

[putoff]

So I messaged them and here's what I got back:

1. in reference to my test above using a file with a different sample rate than the one defined in settings:

yes, this is expected if you have cuts in a sample and a) are using a stretch mode and the sample is not played at its original speed (therefore not played neutral anymore but timestretching) and/or b) the sample has a different sample rate than the project and therefore has to be resampled on playback. In both cases those cuts technically can't be played completely sample-accurate and you get clicks for the amplitude immediately jumping to another and often different value compared to the previous sample.
In your case, point b) is the reason is the sample rate conversion on playback then playing a 96kHz file while the engine is running at 44,1kHz.
That's also why there is an option for automatic anti-click fades in the preferences.

If you play such cuts with a sample playing at neutral speed using "raw" or our "stretch" algo, for example (this algo is completely neutral when played back at original speed) and the engine is running at the same sample rate as the sample, so it does not have to be resampled on playback, there will be no clicks.

AND

B) yes, for sample accurate 1:1 playback, the files have to be in the same sample rate as the project. You can achieve these quickly by bouncing them in place, for example.

The default size for the automatic fades (which are also active by default) is 0.0.0.04 and should work fine in most cases.
In other hosts you'll get the same behavior in those cases if the host does not create automatic fades, but most of them do.

So it seems that if you plan to use the knife tool, your files must match the target sample rate for it to be TRULY accurate.

If you bounce your files in place in Bitwig, it seems to sound ok, but there will be additional spectral activity where you cut as shown below:


You need to have the automatic anti-fades enabled.

I'd rather not fight with this over email, however if you guys DO care, you need to email them. Simply posting stuff here will not get anything done. I did most a link to this topic but I think they're more focused on what they have on their plate internally, they may not have the time to browse forums for problems. Perhaps mention that this was never an issue with version 1.

[shadiradio]

Thanks for following up! I'll send this over too:

I understand their reasoning, but this doesn't seem like an elegant way to handle the cut situation. In my opinion, if you cut a clip but don't move anything, that is just a visual abstraction - behind the scenes it should just be a list of samples from left to right, with both "sides" of the cut at the sample rate of the original file. If Bitwig can play that list of samples correctly before you cut, why can't it play that same list after you cut?

BEFORE:
[sample1, sample2, sample3, sample4]

AFTER:
[sample1, sample2][sample3, sample4]

My guess is that the engine handles these cuts as separate entities no matter what, so without short fades it "stops" the first clip before "starting" the second, maybe interpolating from sample2 to zero-crossing (pop) and then zero-crossing to sample3 (pop). This could be alleviated if any adjacent clips that have the same sample rate are played back as "one" clip, and interpolated as if the cut wasn't there.

[Hez]

@shadiradio, I see where you're coming from but I don't think it's a trivial thing to fix. The last suggestion in your post would be the only way that it could really work, but I think it could get ugly in some situations:

Say you've got two clips back to back, they are the same sample rate, but not actually related pieces of audio. Bitwig would have to be checking the audio source for each clip in the project to test whether the clips either side of it are related and if so, treat as a continuous audio stream. I don't know a whole lot about how DAWs are coded behind the scenes but I imagine this would be quite a deviation from the current organisation of the software where audio clips are discrete and probably individual objects. Still solvable technically, but pretty awkward.

What if the two clips ARE from the same piece of audio, but the second clip has been offset, so it's not actually playing continuously any more. E.g. if you sliced a clip in two, then offset the audio within the second clip. To avoid this situation, Bitwig would now have to be checking for every clip whether a.) the source audio file in the clips adjacent to it are the same and b.) whether the first sample in the next clip is found immediately after the last sample in the current clip.

How about using the clip launcher, or dragging audio around during live playback. Would Bitwig be checking these conditions live, or would it be something that is done once before playback starts?


Out of interest, in what situations do you guys typically end up slicing a clip but not actually moving the separate pieces? I don't think I've ever done this, but of course everybody has different workflows and uses the software to achieve different goals.

[wavedigit]

In this demonstration, I've bounced to 32bit pre-fader in Raw mode, so there shouldn't be any clicks, yet... https://youtu.be/tzwzcu_ICD4

[Ou_Tis]

Is this still an unsolvable issue in Bitwig 4, or is there a way around it now? Should I just give up on this garbage excuse for a DAW and get back to learning Cubase? The clicks at the end of chopped samples are infuriating. And they waste their time on developing the "the grid" which I have no interest in. What, they think actually making Bitwig into a viable primary DAW would be too boring for them?

[carlca]

Should I just give up on this garbage excuse for a DAW and get back to learning Cubase?

Yeah! That's probably best. See ya

[JHernandez]

Is this still an unsolvable issue in Bitwig 4, or is there a way around it now? Should I just give up on this garbage excuse for a DAW and get back to learning Cubase? The clicks at the end of chopped samples are infuriating. And they waste their time on developing the "the grid" which I have no interest in. What, they think actually making Bitwig into a viable primary DAW would be too boring for them?

Bye, Felicia

[Ou_Tis]

As I explained in the thread I started, the micro-fades that Bitwig automatically adds aren't sufficient to avoid very audible clicks with some audio. Even doubling the fade time doesn't solve it. I have to lengthen the fade to the point where it's diminishing the intelligibility of the word I'm trying to isolate---and it's also a very audible fade-out. If you accept this crap from Bitwig, and have no desire for a solution or even a work-around... what does that say about you?

[JHernandez]

It says absolutely nothing about me. I do not encounter this at all. Maybe it's the way I work, IDK.

When this thread started I had to purposely drag in audio that didn't match the project's SR to get a click. I haven't tested it since then because as a matter of habit I make sure that absolutely all audio that comes into my DAW matches the projects SR. I prefer using my own choice of conversion in general, if possible.

[pdxindy]

If you accept this crap from Bitwig, and have no desire for a solution or even a work-around... what does that say about you?

It says I don't often cut up audio having sample rates different than the project.

[Ou_Tis]

If you accept this crap from Bitwig, and have no desire for a solution or even a work-around... what does that say about you?

It says I don't often cut up audio having sample rates different than the project.

Well, I confirmed that the Kontakt samples were recorded at 48 khz and 24 bits. Since I'm bouncing the Kontakt instrument from midi it shouldn't matter anyway, but I tried setting my project to 48 khz and bounced from midi at 24 bits. Still a very loud click artifact even with > 100 ms fade; I have to put it around 200 ms for it to be quiet enough *in the mix*, and even then it's still audible. My Bitwig update plan's expired so I can't ask support; I do have an update plan license I could register, but I'd rather wait until they add something I care about... or fix this shit.

[pdxindy]

If you accept this crap from Bitwig, and have no desire for a solution or even a work-around... what does that say about you?

It says I don't often cut up audio having sample rates different than the project.

Well, I confirmed that the Kontakt samples were recorded at 48 khz and 24 bits. Since I'm bouncing the Kontakt instrument from midi it shouldn't matter anyway, but I tried setting my project to 48 khz and bounced from midi at 24 bits. Still a very loud click artifact even with > 100 ms fade; I have to put it around 200 ms for it to be quiet enough *in the mix*, and even then it's still audible. My Bitwig update plan's expired so I can't ask support; I do have an update plan license I could register, but I'd rather wait until they add something I care about... or fix this shit.

I have not seen an issue like that. I can get clicks with samples that are different sample rates and with time-stretched audio (same thing). I've not had to put such big fades either when I do need fades. Do you have some weird DC offset going on?