Building Peak Files

in article 3ablk8F4lfq80U1@individual.net, Jon Harris at
goldentully@hotmail.com wrote on 03/22/2005 17:48:

> And keep in mind these types of "massively zoomed out" displays are
> usually just rough pictures of the envelope to help you identify major
> features.  You wouldn't typically be trying to select something as
> fine as 1 screen pixel when zoomed out like that.

yeah, you're probably right about that.  i just like consistent and
predictable user interface (and DSP algorithms) and it would be an annoyance
to me if there was a particular zoom setting where it goes from "chunky" to
"pristine".  i don't have Cool Edit (i don't think there is one for the Mac)
but Pro Tools, as i recall, had a set of zoom ratios and they were related
by powers of 2.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

"robert bristow-johnson" <rbj@audioimagination.com> wrote in message
news:BE661188.5802%rbj@audioimagination.com...
> in article 3ablk8F4lfq80U1@individual.net, Jon Harris at
> goldentully@hotmail.com wrote on 03/22/2005 17:48:
>
> > And keep in mind these types of "massively zoomed out" displays are
> > usually just rough pictures of the envelope to help you identify major
> > features.  You wouldn't typically be trying to select something as
> > fine as 1 screen pixel when zoomed out like that.
>
> yeah, you're probably right about that.  i just like consistent and
> predictable user interface (and DSP algorithms) and it would be an annoyance
> to me if there was a particular zoom setting where it goes from "chunky" to
> "pristine".  i don't have Cool Edit (i don't think there is one for the Mac)
> but Pro Tools, as i recall, had a set of zoom ratios and they were related
> by powers of 2.

With normal audio, the switch is not noticeable at all.  Only when I used
sub-audible sine waves so that the envelope looked like a sine waveform was the
switch detectable at all.  For me, being restricted to power of 2 zooming would
be a major limitation!

I've been working on this project and it's coming along rather nicely.
I've got it reading in samples and displaying the waveform.  I'm rather
pleased about it so far.

But here's what I'm doing - as an example I have a 24 minute audio file
(16 bit stereo) with a data section that is 276,456,960 bytes large.
Based on my current code of shrinking the file down to about 5mb in
memory that is roughly 111 samples per block.   Currently I'm
allocating 5,000,000 twice.  One of the 5mb is for storing a maximum
value for the block and the other is for storing a minimum.  Regardless
of the original bit rate, I'm storing the samples as LONGs.  Very
unoptimized but I wanted to see if I could get the wav graphed first.

So my question - is that the proper thing to do?  Do I need to store a
minimum and maximum value for each block?  And then when graphing I
determine the number of blocks per pixel and graph the determined
minimum/maximum for that block based off of the original block's
min/max values.

I feel like I'm doing something stupid here but I can't quite figure it
out.

Otherwise - it's working great ^_^  Simple yet good.  If storing
min/max values like I'm doing is the proper way, I won't mind it.  I
just didn't know if I should be storing something else.  Possibly a
single value of some kind.  Once I get the basics figured out, I'll
work on storing the samples based on the original bitrate and other
things.  Thanks for everything so far!

We discussed this in quite a bit of detail when this thread first started.  To
summarize, storing both minimum and maximum is the best way to do this as it
allows more accurate drawing of asymmetrical waveforms.  On the other hand,
storing a single value that is the maximum absolute value cuts your storage
requirements in half and still allows for drawing a decent envelope for most
typical audio waveforms.  The choice is up to you.

Based on your current implementation, you could of course cut your storage
requirement in half by truncating the data to 16-bit, which is more than enough
for display purposes.  Also, you might find it more efficient to store the
maximum and minimum values in adjacent locations rather than all the maximums
followed by all the minimums (i.e. interleave the maxs/mins).  That way, when
you go to draw a single block, you will be accessing 2 adjacent memory
locations, rather than 2 locations separated in memory by a large offset.  This
would be especially helpful if your data grew so large as to require virtual
memory.

-- 
Jon Harris
SPAM blocked e-mail address in use.  Replace the ANIMAL with 7 to reply.


<seijin@gmail.com> wrote in message
news:1112767024.512845.189000@o13g2000cwo.googlegroups.com...
> I've been working on this project and it's coming along rather nicely.
> I've got it reading in samples and displaying the waveform.  I'm rather
> pleased about it so far.
>
> But here's what I'm doing - as an example I have a 24 minute audio file
> (16 bit stereo) with a data section that is 276,456,960 bytes large.
> Based on my current code of shrinking the file down to about 5mb in
> memory that is roughly 111 samples per block.   Currently I'm
> allocating 5,000,000 twice.  One of the 5mb is for storing a maximum
> value for the block and the other is for storing a minimum.  Regardless
> of the original bit rate, I'm storing the samples as LONGs.  Very
> unoptimized but I wanted to see if I could get the wav graphed first.
>
> So my question - is that the proper thing to do?  Do I need to store a
> minimum and maximum value for each block?  And then when graphing I
> determine the number of blocks per pixel and graph the determined
> minimum/maximum for that block based off of the original block's
> min/max values.
>
> I feel like I'm doing something stupid here but I can't quite figure it
> out.
>
> Otherwise - it's working great ^_^  Simple yet good.  If storing
> min/max values like I'm doing is the proper way, I won't mind it.  I
> just didn't know if I should be storing something else.  Possibly a
> single value of some kind.  Once I get the basics figured out, I'll
> work on storing the samples based on the original bitrate and other
> things.  Thanks for everything so far!
>