I’m curious know whether a problem that was introduced in C4 and persisted through C5 may have been resolved in C6. In C4 or C5, if you cut an audio event in the project window at a “non-zero” point and then time stretch (with the MPEX algo) the event by any amount, you can zoom in to the cut point and see that a gap has been created in the waveform. This of course translates to an audible “pop”. I’m hoping that this may have been resolved, perhaps with the élastique algorithm. It’s a pretty quick and easy thing to test, would someone care to try this with élastique and MPEX?
Wow, disappointing, but thanks for checking. More that likely it would work ok with the “Standard” algo, at least it did with the “Realtime” algo in C5. It’s just unfortunate that the better sounding algos have this issue. Uwe said it had been added to the bug base back in early 2010 (a year after first reported), so I was really hoping it would be fixed in C6. Anyway, thanks again for checking.
I have to say I don’t really see an issue here … it’s certainly much better than the previously referenced pics. Think about it … I intentionally split an audio file at a non-zero crossing, so I have a piece on the left, and a piece on the right, which I then timestretch … I wouldn’t expect the ending of the piece on the left to change (in fact, no way should it change, as it wasn’t selected for editing), so therefore the abrupt cut to zero is expected as I intentionally split on a non-zero for the purposes of the experiment – something that would normally never be done intentionally.
Now, looking at the start of the time-stretched portion on the right, there’s no gap as in previous versions, at least not in the visual representation, however you have to remember we asked the software to take a piece of audio that starts at non-zero, therefore guaranteeing a glitch, and then time-stretch it … and expect no glitch?
From what I can see, the algorithm has intelligently added a fade-in to compensate for what might reasonably be interpreted as a lack of knowledge/skill/experience on the part of the user.
For what it’s worth, in this experiment the result from élastique, while still audible, was quite acceptable.
I agree that the event to the left would not be expected to change, however, the expectation for the waveform in the event to the right is that the amplitude and time position of the very first sample point should not change post-timestretch. Hence making the edit point absolutely inaudible. This correct behavior can be observed in the pic of MPEX2 in SX3 from the above thread link. I would also venture to say that the correct behavior may be observed using the “Standard” algorithm in C6, if it is basically the same algorithm as “Realtime” in C5. I can’t say for sure on that last one though since I don’t own C6.
As for amplitude, see my comments on fade-in above, but regarding time position … I see no evidence to suggest time position is altered, other than the obvious … by definition, every point in time in the right-hand audio event will appear “later” in the rendered (processed) portion. Could it be that it was just an issue with the graphical representation in C5/C4?
There’s certainly a small audible difference at the transition between the MPEX and the élastique rendered versions as per my graphic – the élastique version is a little easier on the ears. In the example, I chose a spoken piece and the transition is on the word “so”, just after the sibilance “s” and at the start of the vowel “o”. In reality however, I would never choose such an edit point, and would always cut on a zero-transition. I can categorically say that no average listener would ever notice the glitch, let alone be able to tell the difference between the algorithms.
Interesting as this experiment is, I am still puzzled as to why this might be an issue, and I cannot imagine a situation where this could cause a problem.
I don’t think so. The graphical discontinuance in the waveform and the audible “pop” have been in agreement thus far. If you “see” it, you’ll hear it and if you don’t see it, you won’t hear it. If you still have C5 loaded up, do this same experiment with the “Realtime” algo and then compare to MPEX4 and I think you see what I am talking about.
Most users would agree, and the obscurity of this issue is likely why is has survived through C4/C5 without ever becoming a very hot topic. Where this affects me is mainly when pocketing a stereo track. I want to make my slice just behind the transient, but it’s difficult to find a “zero” point in agreement between left/right. This is why I am not using “snap-to-zero” in this case.
I have to say it’s not an issue for me personally. I do think however that this has less to do with time-stretching and more to do with the difficulty of finding a suitable edit point in a multi-channel track. Taking a pragmatic approach, I would suggest either manually correcting (drawing) the waveform to reduce or eliminate the glitch, or, quite simply, if SX3 really was much better, use that instead? (I’m not being sarcastic … in the interest of getting results perhaps it’s just better suited to this particular job?)
In the longer term, this may be a discussion that needs to be had directly with Steinberg and referred back to the developers, as we can only guess what the logic is behind the behaviour of the various algorithms. I’m guessing that the newer variants automatically place a fade at the start of the time-stretched part, without regard to the preceding part. That’s probably fine for 99% of use cases and in inexperienced hands probably on average yields better results. Nevertheless, for deep editing and special cases such as this, If there were an option in Prefs to turn that short fade off, that would be the best solution.
IMO this is neither a hot topic nor is there a clear solution.
Hopefully you can help .
There are several things I’d like to say:
Fade: Yes, the first and last 100 frames are faded with some kind of sine curve in C6.
In C5 that were 80 frames. This is true for all warp algorithms.
It shouldn’t be a longer fade since this will create an audible volume level shrink in that place.
This preserves from hard clicks, but some weaker click may still occur.
I considered that less important than keeping volume.
It is absolutely correct that the left (= unprocessed) audio event is not touched at all.
To make sure that you hear what you see, you’ll have to bounce or flatten the warped or pitched audio file.
If you warp, you’ll see an approximation of the warp result.
That approximation is generated from the original audio file.
It was far too cpu consuming to display the exact waveform.
Remember that we do not develop all algorithms on our own.
So we have to be prepared to handle algorithms maybe don’t act as we/you like.
If elastique - for example - does not preserve the first sample to stay the same
as in the unwarped version, we have to live with that. Maybe it is for a good reason.
Algorithms cannot be perfect for arbitrary recordings usually and there are numerous tradeoffs.
Compared to e.g. elastique’s overall quality this is a minor issue IMO.
The workaround is to fade manually.
The preference idea is Ok. But if we’d make everything configurable via preferences instead of discussing
it to come to a final solution that omits preferences… - guess how many preferences we would have.
This is very special also.
I could change the standard algorithms so that the first samples are the same (and without a fade).
But keep in mind that the same problem will occur at the end of the warped file. And here it is not so easy
due to how the algorithm works.
Many thanks Onno for that detailed explanation. For me this the way it currently works is fine, and in the test I did for Stringpark, I do not hear a glitch as big as might be suggested by looking at the waveform. My solution in this case would be to render the file and manually repair if necessary, or arrange overlapping edits and crossfade … there are many ways to approach it. In my own case my audio is mostly mono and I would always easily find a zero-crossing anyway.
In Stringpark’s example, where he is working with stereo files with no common zero-crossing points, I can understand that such solutions are not practical – but perhaps there’s a different workflow that would yield better results in that specific case; I don’t know.
Thanks MrSoundman and Onno for the comments. It’s definitely very cool to be able to speak with a programmer concerning this issue. Onno, hopefully I can provide some helpful feedback to your comments below:
I’m not sure I’m seeing that in C5. Judging by the posted results of the experiment that MrSoundman was so kind to conduct, it apparently applies a fade-in in C6, but it doesn’t look anything like that in C5. Below is a pic of audio events in the project window. Both tracks are the same file and sliced in the same place. For the track on top, the event to the right was time stretched 105% with the MPEX algo. For the track on the bottom, the event to the right was time stretched 105% with the Realtime algo. Neither of these appear to have a fade-in applied. Ideally, I would expect all algorithms to behave such as the track on the bottom. I’m not sure how an automatically applied fade-in would be productive. Incidentally, MPEX in SX3 did not have the gap as shown in the top track.
This is what I have been doing to this point. When I make a slice and then time stretch out, I have to go back to the slice point, extend the event to the left slightly and then apply a cross fade. Unfortunately, this adds several steps that were not necessary before, and it can become quite cumbersome when doing the procedure repeatedly along the track.
If you were to remove the fade, would there be a gap in the first few samples as pictured above? I guess I’m still unsure as to whether this issue is a Cubase thing or an algorithm thing.
Are the “Standard” algorithms in C6 basically the same at the “Realtime” algorithms in C5? Again, I think that it makes the most sense to leave the very first sample intact, and not to move it in time or amplitude, as seen in events processed with the “realtime” algo in C5 or MPEX algo in SX3.
Hi Dreamix, I think this is a very legitimate question. When I say “realtime”, I am coming from a C5 perspective (I do not yet own C6). In C5, the MPEX algorithm sounds much better than the “realtime” algorithm, and I understand that the Elastique algorithm in C6 sounds even better than MPEX in C5. So, that is why I would prefer to use one of the higher quality algorithms.
I guess I’m not sure what you mean and perhaps there is a terminology difference between C5 and C6 that is confusing me. In C5, “realtime” and “MPEX” refer to different algorithms. From the manual, I understand that there is no longer an algorithm called “realtime” in C6, but one called “Standard” instead, which I assume may be basically the same as “realtime” in C5.
Yes there is some changes of how the timestretch works, and a bit confusing too heh… you can shoose which algo to use as realtime, Elastique time, tape… and as you say standard algo from which you also can choose plucked, drums, mix etc…