Start a new topic
Implemented

Spectrogram seekbar

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.


Mikael

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.


greets

It is a bit hard to say what the difference is without having compared you version with Neons version. Please open a bug report with comparison data so that I can see in detail what you refer to. I have not found any problems seeing/hearing sweeps/faded/freqs etc.

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)


greets

i can nothing see in your spectrogram that is what i mean ;)

here test this


so you can compare (See what i mean)

http://home.arcor.de/weiss.em/Spectrogram.rar

that is not optimized for fast reading yet only for testing.


greets

I will download and test this tomorrow. I'm still not sure what you refer to :)

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.


Example:

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.

>>@Emil: I use 1024 already, my first test was using 2048 FFT but that was overkill :)

Okidoki


greets

>>That's the reason why data looks diferent.

yes :)

and that is i can see what i hear.


greets

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.

>>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


greets

http://www.bass.radio42.com/help/html/4f7e21aa-2c6d-bc83-56ef-bf171d6a6946.htm


But I guess, you can't use this, since it does not fulfill your needs?!

>>But I guess, you can't use this, since it does not fulfill your needs?!


correctly.. :)


greets

That one works perfect, but ONLY when rendered in realtime. 

This method requires that you feed the function with data for each new position (=realtime playback) which fails completely in two major cases:

1) I need to pre-render the spectogram just as the waveform whilst playing

2) If you skip during rendering, there will be gaps in the spectogram


Therefore it's a must to first render the wavpeaks to a buffer (as for the waveform) and the apply FFT transformations to get the magnitute for each line.

I did some speedtests as well and that's a bit worrying since in a spectorgram each pixel needs to be plotted, lines are simply not allowed.

I checked your code Emil, but it is still using reltime rendering with "BASS_ChannelGetData", since I have a pre-filled buffer I must do the FFT myself on the buffer. Quite complex ;)

yes is not to simple..

do it if you has time for it. :)


greets

Login or Signup to post a comment