![]() Melodyne, Serato, Dirac, Radius, Elastique. Recent algorithms using more modern approaches like TDHS, Wavelets and the stuff done by Prosoniq/Zynaptiq are better at finding a dynamic adjustment and other tricks to get the best of the possible algorithm settings automatically, but even in 2018, we're still "not there" in the sense of perfect results. Developers can choose to stretch using very short audio buffers to stay very tight in timing, but that will introduce a very "grainy" sound.Ĭhoosing a longer buffer and crossfading between time-stretched or time-compressed audio buffers will sound much smoother but will also smear transients, making a drum loop sound like it's dropped into honey. OK, we're talking about tiny offsets of a few milliseconds that I would guess are introduced by Blocs Wave's time stretching algorithm, that would also explain why the offsets are not uniform for the different attack transients you've shown. Wow if this really is the case as it seems, it will be very interesting to hear what amplify say, as this is obviously centre to their whole app and IAP model. Note that this is audible or you certainly can feel it, I’ve realized that because after import in Gadget there was something wrong in rythmic timing, no impact with other tracks. Also offset is not only in Gadget but also BW after importing the initial loop (exported from BW, not Gadget).Ĭreate a blank BW project, change bpm (example 95 to 110), export your loop, import it again in BW and check waves. Offsets are not regular and occurs after first beat. On screenshots this is beat 1.3 so third beat of first bar. Yes of course bpm is the same in both apps. Have you set the same bpm in Gadget? There is silence at the beginning of your audio and Gadget won't touch the imported audio file in contrast to blocs wave which will do proper time stretching/compressing. Same 129 bpm exported loop imported again in Blocswave same offsetĮxported loop imported again in BW at initial 95 bpm, correct said: This is loop exported imported at 129 bpm in Gadget, there is an offset Here is initial waveform timestretched at 129 bpm Spent 50 € during sales, 100 € value on BW features and packs iaps It’s an important info for Blocswave users IMO, wanted to share it. On iOS, when recording BW IAA output in AUM or GarageBand with midi link sync in real-time it’s a bit better but still not as tight as it should. With Ableton Live you can use markers to fix offset, but that’s a huge work on a full set. I don’t know if can fix that, but that’s a huge issue, and will kill any precise timing and will give floaty groove. ![]() ![]() I don’t know their algo, but I’ve read even Pro Tools Elastique algo gives similar issues, when Ableton Live’s one is spot on. This is not a midi timestamps issue, but gives certainly similar issues. With iaps packs it’s just not possible to know loops initial bpm, that doesn’t help. For example a 95 bpm drum loop played at 129 bpm will not export correctly: first beat is spot on, but all other beats are all other the place when you zoom in. There is an issue with Blocswave and exported loops when time stretch is involved.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |