Let the select to see a spectrogram seekbar instead of the waveform seekbar.
A spectrogram looks like this:
A spectrogram shows the use of frequencies for each point of a track (x-axis = time, y-axis = frequency, coloring = loudness).
This way you can recognize low quality audio files, since they have a large black border at the top, because high frequencies have been cut.
>>No, sorry, that's not the perfered behaviour.
>>The end user needs to see the entire position slider at once to easily be able to skip within the whole file >>without any paging.
i understand you.. :)
Neon is your baby and you can do with it what you want.
If you use Neon with a huge display you will get more or less the same look as in your small application.
Here's the interpolation steps smaller than with a 1920*1080 resolution.
See the attached picture:
>>only flip to the next Page after the marker (Scrolling line end in Bitmap is reached)
No, sorry, that's not the perfered behaviour.
The end user needs to see the entire position slider at once to easily be able to skip within the whole file without any paging.
>>A scrolling spectogram in Neon is not relevant at the moment.
I have no scrolling spectrogram :)
only flip to the next Page after the marker (Scrolling line end in Bitmap is reached)
>>So, it is not a bug
have always said that there is no error
only a design technical
Picasso is not Michelangelo
When Michelangelo you immediately recognize what it says with his pictures
When Picasso probably less
So, it is not a bug, it just relates to how data is displayed. I can easily both see and hear for example a fading (loud > silent) part in Neon.
A scrolling spectogram in Neon is not relevant at the moment.
>>That's the reason why data looks diferent.
and that is i can see what i hear.
You are rendering your spectrogram "unshrinked", e.g. a full-width spectrogram with scrolling.
This makes every chunk larger in your view, because I shrink the width and interpolated the values.
1) You have a picture A which is 2408px width
2) In Neon we can say that this picture is displayed at 1024px, shrinked and interpolated
3) In your app you display 1024px at a time, with scrolling instead of shrinking and interpolating
That's the reason why data looks diferent.
i have upload a sample for testing Take a while ;)
is not a bug in Neon so is not needed create a bug Report..
only what i say is i can not see what i hear.. (Hmm ... my bad english)
by the way
I did not say that your work is wrong.
I can not see only what I hear
In my Spectrogram I can.
i can nothing see in your spectrogram that is what i mean ;)
here test this
so you can compare (See what i mean)
that is not optimized for fast reading yet only for testing.
I use the interpolation technique in Neon to take use of the full FFT buffer no matter which height the data will be rendered on.
So, if the FFT buffer is 8192 floats, I process ALL with a logarithmic formula to not skip any data and the resulting data will be shrinked.
I the code example I saw from you, you seemed to process only the 512 first blocks, which will not give the full frequency spectrum.
For 44100Hz, the range will display 22.5 kHz to 0 (Nyquist transformation).
Possibly that's the reason.
Also, when presenting the data, you need to use a logarithmic scale (avoid linear scales!) to enhance occurances of lower frequencies, otherwise they may be not displayed.
ok is implemented
but I see a big difference between my spectrogram and the Neon.
i think to do with the blocks.
Can this be?
i read Pixel by Pixel
Sweep right without playing..