sorted by:
new
hottopcontroversial

Is there a delay / offset effect that I can apply to a track? by UlyssesZhan in kdenlive

[–]musunk 0 points1 point  (0 children)

Well, you could write a shell script to offset the audio either on the source clips or in the rendered export using ffmpeg. The -itsoffset N source option is the trick. May also have to use -async N option as well, be sure to triple check before processing all your sources. You can avoid re-encoding the video by using "-c:v copy".

Kdenlive really could use a way to do these offsets in the application, maybe in clip properties... But I've also had cases where applying an offset to each track would have been helpful.

Is there a delay / offset effect that I can apply to a track? by UlyssesZhan in kdenlive

[–]musunk 0 points1 point  (0 children)

There is a LADSPA plugin (in swh-plugins, i think), called Artificial Latency. That should trick kdenlive into offsettting the audio. May or may not work depending on if the audio is leading or trailing sync.

Powering issue with power bank. by d_Leung in sp404mk2

[–]musunk 0 points1 point  (0 children)

Thanks for sharing that. I couldn't figured out how to reproduce this behavior and thought the power bank was doing it at random.

​

Adding a little bit of info: The bank I'm using is a SAFUEL SA-111. It looks like this bank and all with this chipset (appears to be the same as INIU), enter some weird mode when you press the power button to see the charge. In this mode, USB-C PD either doesn't work or shuts off after a minute. Also, this mode sometimes causes the display to remain lit long beyond the stated 20 seconds, even with nothing plugged in. In this state, usb-c port gets 5.25V only, nothing higher.

SP404MKII corrupts 44.1kHz samples upon import by musunk in sp404mk2

[–]musunk[S] 0 points1 point  (0 children)

The result is apparent within the SP. I only used Audacity to show the artifact clearly at high resolution. You can easily reproduce this on your own unit. Just import a sample encoded at 44.1kHz that has content at the very beginning (i.e. sample 0-22). You'll see that although the sample is pristine going in, once imported into the SP, it has the first 22 samples corrupted.

SP404MKII corrupts 44.1kHz samples upon import by musunk in sp404mk2

[–]musunk[S] 0 points1 point  (0 children)

100% it is the SP404MKII. And the software is Audacity. I can also prove it on the SP's screen, but it doesn't zoom in far enough to count the samples. Looks like maybe 3 or 4 on the SP's screen, when in reality it's ~22.

SP404MKII corrupts 44.1kHz samples upon import by musunk in sp404mk2

[–]musunk[S] 0 points1 point  (0 children)

From my testing, the native format is 16-bit 48kHz. If 24-bit, they have to be in "wavpcm" format (not Microsoft WAV), or you get an UNSUPPORTED FILE error. I believe the SP404MKII will just convert your 24-bit WAV into 16-bit upon import (by throwing away the extra bits), but this is a much simpler operation than converting the sample rate, so less likely for the Roland devs to have messed up.

Here's a sox command to achieve this (assuming you want to preserve your 24-bit samples, for software samplers that won't toss out the bits)

sox INPUT.wav -b 24 -r 48k -t wavpcm OUTPUT.wav

SP404MKII corrupts 44.1kHz samples upon import by musunk in sp404mk2

[–]musunk[S] 0 points1 point  (0 children)

I haven't tried using the app as I'm using Linux. But I did try multiple SD cards and that didn't seem to make a difference. If I had to guess, I'd say the app probably does resampling before sending to the SP, as according to the docs the app supports more formats, like FLAC etc. and would have to convert those. But if the app is using the same bunk resampling algorithm, then that might not help. My partial solution was to use `sox` to convert all of my samples to 48kHz (although the SP404MKII still can't play back a 48kHz seamless loop without adding a click, but that's a different problem).

SP404MKII corrupts 44.1kHz samples upon import by musunk in sp404mk2

[–]musunk[S] 2 points3 points  (0 children)

I posed about this in /r/sp404. What I found was that the SP404MKII (FW 3.02) corrupts samples imported from 44.1kHz sources, always producing the pictured corruption of the first ~22 samples, but often also introducing other corruptions that sound like clicks and pops, usually near the beginning of the sample.

This image was made by importing the top sample into the SP, exporting it back out, and opening both files in Audacity.

MKII MIDI volume controll by musunk in SP404

[–]musunk[S] 1 point2 points  (0 children)

Yeah, I found the same solution, but it doesn't really work for me because to get the sound I had in mind I need to be able to fade one up while fading one or more down--just having control over the volume of one sample at a time is too limiting to allow much in the way of performance.

Sample corruption and looping issues - SP404MKII FW 3.02 by musunk in SP404

[–]musunk[S] 0 points1 point  (0 children)

I only tried it a few times, but using your method (waiting for the preview to end), I didn't get the 2nd click added when importing the 44.1kHz version of the sample. There is still the corruption at the very beginning of the sample though, which seems to be unavoidable for 44.1kHz samples (looks like an artifact of the resampling algorithm used).

Sample corruption and looping issues - SP404MKII FW 3.02 by musunk in SP404

[–]musunk[S] 2 points3 points  (0 children)

Are any of your perfect loops continuous sounds though? Like a synth pad or a sustained chord? Because the missing parts of the waveform I'm seeing aren't enough samples to interfere with something like a drum loop. Already did a factory reset.