Oh Yes! That is rather allegoric way to qualify Robin’s work with Spectralayers…
Until you dive deeper and find about his research with image/video reconstruction algorithms.
Not entirely unlike this week’s noticeable advancement at a parallel field of research, literally being applied at Space or subcellular technologies :
There is some chance such developments come later to affect what we do with these audio tools.
"the team developed a rapid joint space and frequency reconstruction (JSFR) SIM method, which provides improved image reconstruction speed and suppression of the out-of-focus background in thick cells.
How does JSFR-SIM work?
Most SIM reconstruction algorithms are based on the Wiener filter protocol, which essentially filters out noise from a corrupted signal to provide an estimate of the underlying signal of interest and optimizes contrast in the available signal-to-noise ratio. The complex workflow of Wiener-SIM makes super-resolution reconstruction extremely time-consuming, according to the researchers, which limits the utility of SR-SIM as a live-cell imaging modality.
JSFR-SIM is a concise reconstruction protocol to rapidly obtain optically sectioned, super-resolution images of thick specimens by combining spatial domain processing with the conventional workflow implemented in the frequency domain.
Most Fourier-domain operations are replaced with simple multiplication and summation calculations in real space.
“The main advantage of JSFR-SIM is its unrivaled reconstruction speed,” Lei says. The team found that the execution time of the reconstruction is reduced to millisecond level with the new algorithm, “which is measured to be 80x faster than the widely used Wiener-SIM. Critically, the speed increase does not come at the expense of image quality.”
///Spectralayers foundation comes from image research, has demonstrated is able to incorporate machine learning from others and own initiatives (Torch), and has navigated the business modelling + firm associations stormy waters while retaining its maneuvering ability.
Robin Lobel is at a very good position to keep delivering the best innovation with this software.
*And according to this specific news your speed optimization quest might be eased as well.
Dude… We know you are wise, brilliant, smart, eloquent poet, but really, this is a simple thread about SL disk performance. You litter it with your long unrelated comments and you make Robin’s job difficult. So again, please, create your own thread about Robin or beauty of SL and write there.
I know Robin and I appreciate his work very much, all we do.
Thanks. ffmpeg shouldn’t take that long to convert it. So there’s either something unusual with the file, or your system, or that version of ffmpeg running on your system.
1/ Would you be able to upload your wav file and send me a link to it in PM (or by email to contact [at] divideframe (dot) com) so I could check locally ?
2/ Can you download the latest version of ffmpeg (from here) and run the same command as in my previous post, but replacing the path to ffmpeg to the path where you downloaded the latest ffmpeg, and let me know how long it took (+log) ?
Wow, Robin, I think we found the source of the problem - here is log, but time is about 4-5s instead of 50s!
Do I need new ffmpeg.dll to improve SL9? I replaced “c:\Program Files\Steinberg\SpectraLayers 9\Plugins\Files\ffmpeg.exe” with the new one, but SL9 is still slow. From where can I dowload dll version?
I compared configuration of ffmpeg and here are new parameters set only in “fast version”:
disable-autodetect
disable-w32threads
enable-avisynth
enable-cuda-llvm
enable-gpl
enable-libfreetype
enable-libfribidi
enable-libgme
enable-libgsm
enable-librubberband
enable-libsrt
enable-libssh
enable-libvidstab
enable-libvmaf
enable-libx264
enable-libx265
enable-libxvid
enable-libzmq
enable-static
Here are parameters set only in “slow version”:
enable-libshine
enable-libsnappy
enable-libbluray
enable-libdav1d
enable-libfreetype
enable-libmysofa
enable-libsoxr
enable-libwavpack
enable-libtwolame
Thanks for the test and the audio file.
On my side, both old and new ffmpeg.exe perform equally well on your audio file (2sec for both).
Just to make sure, can you run the command line 3 times with each version of ffmpeg (if you lost the old ffmpeg, here’s a copy).
And for each run, please note the speed value - it’s near the end of the log:
Can you then copy here the 3 speed values you get with the old ffmpeg, and the 3 speed values you get with the new ffmpeg. This way we’ll be sure there’s a real difference and not just some random results.
Then if confirmed that the new ffmpeg is indeed way faster than the old one, in theory all that is required is to replace ffmpeg.exe like you did (ffmpeg.dll is just a bridge between SL and ffmpeg.exe). It seems to not be sufficient on your side, but first let’s confirm the difference between old and new ffmpeg for good.
sad news - times are completely random… For “old ffmpeg” always are about 70-100x, but for the new sometimes are above 1000x and decoding takes 3-4s, sometimes are 100-150x and takes 20-30s. I tried different disks (copy test wav to SSDs, HDDs, internal and external), same situation every time (I measured the conversion 20-30 times in summary).
It starts very fast but suddenly the speed is decreasing, look at the video clip. For the new ffmpeg the speed is increasing at the end (or always is fast), so it is much faster on average.
So, I see this is probably something in my system - but what? Why sometimes is sooo fast with “new ffmpeg” and after that is dramatically slow?
Anyway, thank you a lot, Robin, for your assistance and trying to help.
Strange indeed, and pointing to something in your system - but what, I’m not sure.
Have you tried SSD → SSD ? This scenario is supposed to provide constant high speed.
Yes, I tried every combination… Maybe I should try set/unset some parameters of ffmpeg, maybe something with cache or buffer size. I have to read about ffmpeg anyway.
I tried to set -max_alloc 100000000, but I worked only for a couple rounds so, in desperation I format one of my older SSD 128GB disk “from a drawer” and connect it to the PC, and after that set it as new SL9 cache location. And it works now perfectly! stable 800x-900x and 3-4 seconds to open file in “batch tryout” and 5-6s in SL9!
I also tried de-noising with iZotope Spectral De-noise VST3 plugin: 17 minutes instead of 20 - better, but still much worse than in other software (I suppose the new cache location is not so significant in that case). I accept that for the moment, I don’t need VST3 so badly.
sad news - times are completely random… For “old ffmpeg” always are about 70-100x, but for the new sometimes are above 1000x and decoding takes 3-4s, sometimes are 100-150x and takes 20-30s. I tried different disks (copy test wav to SSDs, HDDs, internal and external), same situation every time (I measured the conversion 20-30 times in summary).
I format one of my older SSD 128GB disk “from a drawer” and connect it to the PC, and after that set it as new SL9 cache location. And it works now perfectly!