Re: Peak and averagePowerForChannel are nice, but what about the actual current power?
Re: Peak and averagePowerForChannel are nice, but what about the actual current power?
- Subject: Re: Peak and averagePowerForChannel are nice, but what about the actual current power?
- From: Ochen Kaylan <email@hidden>
- Date: Sat, 16 May 2009 10:40:07 -0500
On May 16, 2009, at 8:00 AM, Hamish Allan wrote:
On Sat, May 16, 2009 at 5:39 AM, Ochen Kaylan <email@hidden> wrote:
The way most audio editors draw waveforms is to determine the maximum
and minimum peaks of the waveform for the time period covered by each
pixel, something like:
Thanks. That makes sense to me. One thing I haven't figured out yet is
how I want to redraw the waveform when the pixel width is arbitrary.
So in your example of an audio editor, when the user zooms in, I'm
assuming the program doesn't go back to the source PCM data, extract,
and re-interpolate the waveform each step of the zoom. (Worst case
example: I have an audio editor where I can drag the visible bounds,
so it's not a quick jump from 100% to 200%, but a slow zooming in. If
I have 20 tracks each with 20 blocks of audio, it's not recalculating
for each block, is it?) This is more of a theoretical, as I don't have
to deal with that, at least not on this project. But I don't know how
I'd go about doing it if I did need it.
By the way, your code raises another question. Is PCM data itself the
array of values -1 to 1 plus data headers and tails, or do you have to
loop through each frame of a PCM file and extract the
kAudioQueueProperty_CurrentLevelMeter property into a new array?
(By the way, you folks are awesome to help me with this!)
If the audio is 10 minutes long, but the
waveform is only going to be 100 pixels wide, there's no need to
have the
instantaneous power of every sample. A few a second is plenty for
that
scenario.
You wrote previously: "Right, but the problem is the falloff period.
If the first sample is -10db and the second sample is 0db, the average
called on sample one will be -10db, but the average called on sample
two will be something shy of -5db (the average minus the falloff
increment.) Unless the falloff period is less than the frequency of
the calls, the average will always be different than the
instantaneous, whatever the granularity is."
But now you're proposing to arbitrarily choose either the 0db or the
-10db. How can that possibly be an improvement?
Sure, and even beyond that, if I was only hitting the file once or
twice a second, that frequency might actually be larger than falloff
period. However, that file of 100 pixels might not be 10 minutes. If
it's one second, then I'll need to access it 100 times per second, far
less than the falloff period.
To look at it another way: think of the number of zero crossings there
are in any given wave. If every thousandth sample happens to be on a
zero crossing, would you consider those samples representative of the
waveform?
You're totally right. That was a compromise I was willing to make. Far
from ideal, but if it saved me from something far more time/processor
intensive, I was willing to at least try it out.
If you think digging into the PCM data isn't quick, think again about
what you're trying to do. If the audio is 10 minutes long, it'll take
you 10 minutes to draw the waveform.
Not at all. I can draw the graph of average and peak powers of a 10
minutes wave in milliseconds. Similar to your code, but I'd play and
seek through the file at intervals totalNumberOfSeconds/numberOfPixels
and get the average and peak powers of that millisecond. A quick loop
of 100 calls for a 100-pixel-wide graph, however long the audio file is.
Thanks again!
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Ochen Kaylan <email@hidden>) |
| | >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Ochen Kaylan <email@hidden>) |
| | >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Hamish Allan <email@hidden>) |
| | >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: email@hidden) |
| | >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Hamish Allan <email@hidden>) |
| | >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: email@hidden) |
| | >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Hamish Allan <email@hidden>) |
| | >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: email@hidden) |
| | >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Brian Willoughby <email@hidden>) |
| | >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Ochen Kaylan <email@hidden>) |
| | >Re: Peak and averagePowerForChannel are nice, but what about the actual current power? (From: Hamish Allan <email@hidden>) |