Start a new topic
Not Taken

Store spectrogram / waveform data into the database

!!! This is something for a future release !!!


What about storing the data calculated for each track into the database?

Simply create a new table with four fields (data_id, detail_id, data_type, data) and fill it, whenever new data is calculated.


Maybe you could even create these data in the background, when CPU is idle?


Pro: visualization shows up almost immediately

Contra: database size will increase (dramatically?)


I thought of this myself first, but I rate it as most likely not possible.

The calculated data for a file that's 5 minutes long is:


1619 fft blocks of each 4096 floats.

That makes the actual data about 25 Mb and that would totally crash the database size (yes, it sounds a bit odd, but since we are working with rawdata no compression is added).


The size is constant, no matter which FFT quality that's used.


Even the waveform data is quite large, about 301304 elements och each 8 bytes (4 bytes for the left channel and 4 bytes for the right channel) for a file of 5 minutes.

That makes it about ~2.3 Mb for the file.

Cut it down - even on a 4k display you don't need this much data. Remember that you'd only need to create 160px in height and 3840px (4k) in width. And since you don't need to zoom in...

The waveform does not need to be stored with full 4 bytes per channel and all elements...

For example, calculate 4000 elements with 1 byte per element, you'll get ~4kByte per track.


For spectrograms every block only needs 160 floats (I guess this means vertical resolution). And you could even cut this down to 80 (in Audacity, the vertical resolution is set lower than that).

Yes, it can surely be cut in certain ways, but it's unfortunatley a linear-scaling when it comes to spectrograms (for waveforms, it is)


For each block in a spectrogram, all values in the FFT array (4096) floats are used to interpolate the coloring of a line, since it is calculated with a special formula.

Further tests needs to be performed how much data (and which data) that can be cut.


Also, storing larger blobs is really an issue for a SQL Compact database,, but possibly this function can be discarded is using a Compact database.

Well, simply calculate a value per pixel...
You have a maximum of 3840x160px on a 4k display. How many colors does a palette have? 256? That makes a byte per pixel -> 600kByte. - And I guess there are less colors per palette.

Even if I only store 1920x80px (150kByte) and need to upscale for larger resolutions:


Remember, this is only a slider - it should look good, but does not need to be perfect... ;-)

Not really, there are about 1024*5+128 colors that can be used, althought not "all" are used because of a logarithmic scale. :)

This can be seen with palettes with more spread.


I think 600k is still quite much, impossible for a SQL Compact database with 30k+ tracks and a data consumer for other databases.


Is the preview calculation slow on your machine?

what your can do store the spectrogram / waveform data into Tags like "other"

if your want..

only a idea (I'm not a fan of this kind)

it not bring much.. so i'm not like it.


greets

Login or Signup to post a comment