In what stage of the decoding process can i find the information I would need to create an equaliser (a frequencies bar graph) visualisation? Do I just look at the subband levels or is that totally wrong? Has anybody done this?
Much thanks.
Tom.
On Thursday, May 2, 2002, at 07:56 AM, Thomas Rathbone wrote:
In what stage of the decoding process can i find the information I would need to create an equaliser (a frequencies bar graph) visualisation? Do I just look at the subband levels or is that totally wrong? Has anybody done this?
You could look at the subbands after decoding a frame, yes, before synthesis (or actually whether or not you perform synthesis.) The subbands are somewhat coarse, and there is some overlap between them, so implementing an equalizer *control* with them is tricky, but they should be sufficient for a simple *visualization*.
The subband samples are found in:
frame->sbsample[channel][timeslice][subband]
where `channel' is less than MAD_NCHANNELS(&frame->header), `timeslice' represents an output unit of 32 PCM samples and is less than MAD_NSBSAMPLES(&frame->header), and `subband' is 0-31 covering the frequency spectrum in equal-width bands up to the Nyquist frequency.
One thing to keep in mind is that the subband values are both positive and negative. The general range is +/- MAD_F_ONE, but actually any value is possible.
-- Rob Leslie rob@mars.org
I'm using the high level API. Could I implement the bar drawing code in the filter callback or would this cause problems/delays with the decoding process? Otherwise how do I get at the frame structure?
Thanks.
Rob Leslie wrote:
On Thursday, May 2, 2002, at 07:56 AM, Thomas Rathbone wrote:
In what stage of the decoding process can i find the information I would need to create an equaliser (a frequencies bar graph) visualisation? Do I just look at the subband levels or is that totally wrong? Has anybody done this?
You could look at the subbands after decoding a frame, yes, before synthesis (or actually whether or not you perform synthesis.) The subbands are somewhat coarse, and there is some overlap between them, so implementing an equalizer *control* with them is tricky, but they should be sufficient for a simple *visualization*.
The subband samples are found in:
frame->sbsample[channel][timeslice][subband]where `channel' is less than MAD_NCHANNELS(&frame->header), `timeslice' represents an output unit of 32 PCM samples and is less than MAD_NSBSAMPLES(&frame->header), and `subband' is 0-31 covering the frequency spectrum in equal-width bands up to the Nyquist frequency.
One thing to keep in mind is that the subband values are both positive and negative. The general range is +/- MAD_F_ONE, but actually any value is possible.
-- Rob Leslie rob@mars.org
On Monday, May 13, 2002, at 03:49 AM, Thomas Rathbone wrote:
I'm using the high level API. Could I implement the bar drawing code in the filter callback or would this cause problems/delays with the decoding process? Otherwise how do I get at the frame structure?
Yes, you could draw during the filter callback. Whether this causes an unacceptable delay depends on how much time you take and how soon you need the decoded PCM in your output callback. In the case of 44100 Hz Layer III, each frame contains about 26 ms of audio (1152 samples), so as long as the total processing time per frame (including decoding/synthesis) is less than this, you should have no problem maintaining real time.
You may however want to think about synchronization issues. The data you get from the filter callback corresponds to samples which will not be heard until after they are passed to the audio subsystem in the output callback, and after they subsequently wait in the operating system's buffer before being played. You could probably devise a simple method to synchronize with the output callback, but further synchronizing with the audio subsystem depends a lot on your operating system and the available audio API.
You may also want to consider your visual frame rate. 26 ms per frame yields around 38 frames per second. If that's acceptable, you can proceed without complicating matters much further. If you want a higher frame rate, you may want to draw in a separate thread so you can smooth the data between audio frames.
-rob
Hi,
I've implemented visualization using the subband samples as you mentioned. I'm currently averaging the subbands from all the timeslices in a frame and then displaying the subbands as a bargraph. The output is quite disappointing delivering an effect that seems far too frantic and of little relation to the sound. (I accounted for the delay before play by the sound subsystem.) Even by only displaying every other frame the output remians frantic. Many bars seem to be continually active even with no noticable sounds. I was wondering whether you perhaps had any advice on how I could improve the effect... I was hoping for something a little more like winamp's equalizer effect. How does winamp breakdown the frequency spectrum?
Thanks. Tom.
Rob Leslie wrote:
On Monday, May 13, 2002, at 03:49 AM, Thomas Rathbone wrote:
I'm using the high level API. Could I implement the bar drawing code in the filter callback or would this cause problems/delays with the decoding process? Otherwise how do I get at the frame structure?
Yes, you could draw during the filter callback. Whether this causes an unacceptable delay depends on how much time you take and how soon you need the decoded PCM in your output callback. In the case of 44100 Hz Layer III, each frame contains about 26 ms of audio (1152 samples), so as long as the total processing time per frame (including decoding/synthesis) is less than this, you should have no problem maintaining real time.
You may however want to think about synchronization issues. The data you get from the filter callback corresponds to samples which will not be heard until after they are passed to the audio subsystem in the output callback, and after they subsequently wait in the operating system's buffer before being played. You could probably devise a simple method to synchronize with the output callback, but further synchronizing with the audio subsystem depends a lot on your operating system and the available audio API.
You may also want to consider your visual frame rate. 26 ms per frame yields around 38 frames per second. If that's acceptable, you can proceed without complicating matters much further. If you want a higher frame rate, you may want to draw in a separate thread so you can smooth the data between audio frames.
-rob
-
Rob Leslie -
Thomas Rathbone