Faster visual waveform preview creation

[ocmtime]

Hi , is it possible to make the visual waveform preview creation faster ?

For example for large audio recordings 24 hours or more it takes almost 60 seconds to create the visual preview.

So if instead of going through every sample of the file is it possible to
make a faster visual preview by jumping larger steps across the audio file ?

This would work as if it had lower time resolution like 4800hz instead of 48000hz would mean 10 times less resolution and ten times faster visual waveform preview creation.

But how to achieve that please ?

[Dstruct]

Search preferences for "cache resolution" and lower the value. Not sure if it helps tho.

[ocmtime]

Originally Posted by Dstruct

Search preferences for "cache resolution" and lower the value. Not sure if it helps tho.

That is the right setting but it has no effect ,
does it work at you ? I tried setting it to 1 sample per second and it still makes detailed peaks which takes a minute or so

[Dstruct]

Detailed peaks only should be visible when zoomed in.

[ocmtime]

Originally Posted by Dstruct

Detailed peaks only should be visible when zoomed in.

I think this feature was never tested with a large 24h audio file.
I zoomed out an empty project 3 samples per second and the waveform peaks are created at the same speed with 300 samples per second and zoomed in close.

[Pashkuli]

Originally Posted by ocmtime

Hi , is it possible to make the visual waveform preview creation faster?

For example for large audio recordings 24 hours or more it takes almost 60 seconds to create the visual preview.

DISCLAIMER
HAVE NOT TESTED THIS
For the change of "cache resolution" to have effect you might need to rebuild the peaks.
* simply delete the corresponding .reapeaks file and open the recorded file\session again with the new (lower) "cache resolution".

I am not quite convinced to have understood the question correctly... but 24+ hours of audio must have created a big file (in size, depending on samplerate, bit).

Maybe as a workaround you could have file size limit (gaplessly) before starting next file. This will break the high amount of hours into separate files, which should be more redraw friendly when opening the recorded session (also will depend on the "cached resolution").

In Reaper → Options → Preferences... → Recording:

· Start new files every (mine is 1024MB = 1GB)

Lower value might help as well in combination with the "cache resolution".


(44.1kHz of 16 bit audio for an hour is approximately 320MB) MONO source
(44.8Khz pf 24 bit audio for one hour is approximately 520MB) MONO source

So with my setting an hour of one mono track (microphone) recording will be one file. So lower that "Start new files every (mine is 1024MB = 1GB)" as well.

https://www.sounddevices.com/audio-r...ng-calculator/

[ocmtime]

After changing the setting to a value like 3 10 or 30 samples per second instead of the default 300 I always import another different recorded audio file that was never imported before also tried deleting .reapeaks files a few times .
The lower resolution cache setting is not taking effect.
Always the deatailed peaks are created with never before imported files no matter the cache resolution value.
It is not redraw related so file size limit and its resulted files would not be a solution to the problem.The speed problem relies in the thoroughness of file reading needed to create the reapeaks file.
Please yourself and anyone else here try setting the cache resolution to a low value like 3 or 10 samples per second instead of the default setting of 300 and tell me if it works when importing a 3 minute audio file all zoomed out the waveform representation should look more pixelated to say so like quantized blocks instead of smooth waves.
I think I might not work in any way for any given situation .
Please forum try it and post a screenshot showing it to work at 1 sample per second 3 minutes audio all zoomed out.

[schwa]

The cache resolution doesn't affect the speed of building the .reapeaks file. When building the peaks file, every sample in the file has to be looked at regardless of the resolution. If one screen pixel represents, say, 1000 audio samples, the peak drawn in that one pixel needs to represent the lowest and highest of those 1000 samples, otherwise the peak wouldn't represent any information at all.

Changing the cache resolution only affects the .reapeaks file size and the drawing performance at different zoom levels, not the time required to build the .reapeaks file, or the actual resolution of the peaks drawn. If you set the cache resolution too low, the peaks drawing will read the source file directly, which will be very inefficient if you are zoomed out enough that it could have read the peaks file instead.

[ocmtime]

Originally Posted by schwa

The cache resolution doesn't affect the speed of building the .reapeaks file. When building the peaks file, every sample in the file has to be looked at regardless of the resolution. If one screen pixel represents, say, 1000 audio samples, the peak drawn in that one pixel needs to represent the lowest and highest of those 1000 samples, otherwise the peak wouldn't represent any information at all.

Changing the cache resolution only affects the .reapeaks file size and the drawing performance at different zoom levels, not the time required to build the .reapeaks file, or the actual resolution of the peaks drawn. If you set the cache resolution too low, the peaks drawing will read the source file directly, which will be very inefficient if you are zoomed out enough that it could have read the peaks file instead.

Isn't there a way to read ready in large jumps with a direct disk access procedure probably with the need for contigous defragmented file verification check ?

[ocmtime]

schwa said "every sample in the file has to be looked at regardless of the resolution."
in media player classic you can set the skip size to 10 minutes and with the right keyboard arrow and a fast repeat key repeat rate setting you can preview 100 minutes per second . Of course it skips a lot of audio but you can understand a lot about the contents very fast.
Why can't reaper skip equally spaced segments of audio in order to create a really fast peaks preview ?

[schwa]

Because REAPER peaks are always accurate. The peak value during any time period is the maximum (absolute) sample value during that period. If you skip samples, you could skip the maximum sample value. For example imagine a 10 minute recording that is silent except for one gunshot every minute. If the peaks building skipped samples, the peaks display might show anywhere between zero and 10 gunshots.

[ocmtime]

Originally Posted by schwa

Because REAPER peaks are always accurate. The peak value during any time period is the maximum (absolute) sample value during that period. If you skip samples, you could skip the maximum sample value. For example imagine a 10 minute recording that is silent except for one gunshot every minute. If the peaks building skipped samples, the peaks display might show anywhere between zero and 10 gunshots.

I agree you are right for the higher frequency content of the audio events but that frequency domain would also get displayed in subsequent refining passes .

What I am proposing is getting a fast waveform display refining it from low frequency content to high frequency content as follows:

For a basic recording quality of 44100 hz one milisecond gets 44.1 samples

That means that physically skipping every other 1000 samples every milisecond gets a 44.1 samples of low frequency samples.

Even your audio event example lasts for 5 miliseconds (I searched the info) so even that would be displayed as a high amplitude low frequency (0hz-44hz domain) blob of 5 x 44.1 samples.

So skipping every 1000 samples at first and progresively refining would work in a useful way.

The first pass skipping every other 1000 samples would cover 0hz-44.1hz frequency domain.

The second pass would also skip every other 1000 samples but starting from the 500th sample counting from the begining of the recording and this second pass would cover 44.1hz-88.2hz domain.(and complement the 0hz-44.1hz domain)

The third pass starting from the 250th sample counting from the begining would cover
172.4hz-344.8hz domain ((and complement the 0hz-44.1hz domain + 44.1hz-88.2hz domain)

And so forth

The entire very long recording clip would quickly be filled with interpolated low frequency waveform graphical data obtained from skipping every other 1000 samples (or the user adjusted ammount) while continously refining it from the frequency ground up with each skipping but cumulative pass .

Being able to see high amplitute low frequency waveform data quickly all accross a 24 hours audio recording file is good .

One could see what is happening in the last 6 hours of the big file quickly not having to wait 4 minutes