Re: [linux-audio-dev] Dithering idiots

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Dithering idiots
From: rm (async_AT_cc.gatech.edu)
Date: Mon Jun 17 2002 - 17:01:26 EEST


On Mon, Jun 17, 2002 at 02:27:29PM +0100, Richard Bown wrote:

> And where does "peak data" come into things then? Are those peak files that
> an audio app produces the stored result of this interpolation or is that
> something different? And if so, again, why?

peak data is a precomputed representation of the min and max points of
blocks of the original audio. it alleviates the need for reading large
amounts of data where you are viewing for example 10 minutes of audio, etc.
and each pixel represents a large number of samples.

here's the conversation i had about it way back when on the music-dsp list:

> hi all,
> i was writing an app and i'd like to make it be able to display
> audio files in a window. initially i went for a naive implementation
> (reading blocks from disk finding the max and min for each x location to
> be displayed), and that doesn't seem to lead to smooth scrolling,
> especially as you zoom out and the amount of data becomes large.
> soundforge seems to allow only powers-of-two scales, and creates a
> peak file 1/128th the size of the original; it also has nice smooth zoom
> in/out, and scrolling.
> i guess the rationale for the powers-of-two is that in zooming out
> you take the max and min of every two current x points. the overview file
> would seem to be only a stop gap measure though especially once the audio
> files become tens of minutes in length.
> anyone know the standard way this is dealt with?
> thanks,

I don't know about a 'standard' way of doing things, but the peakfile
(whether hidden or public) is surely a good idea. I use an internal peak
array in the simple multi-channel viewer I made for CDP. It is used for
the low-resolution modes (ie above 32samples per pixel), and is
therefore especially useful when viewing large soundfiles. My approach
is indeed the 'power of two' zoom. This is mainly so that each pixel
represents an exact number of samples. The alternative is to draw an
arbitrary duration in an arbitrary window size, so that you may have
non-integral numbers of samples under each visible line, so there is a
further calculation overhead. The cursor may in these cases be pointing
between samples, not exactly on a sample. Of course, this will not
matter if you aren't using a cursor.

At fine resolutions (high zoom, I suppose), I calculate the image on the
fly, as by definition not many samples are being looked at, so the
calculation time is not critical. If you are drawing a MBytes worth of
sound in one window, however, having the peakfile already calculated
saves a lot of time - assuming you retain negative and positive peak
values, no file access is needed when displying this low-resolution
data.

Richard Dobson

-rob

----
Robert Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:     ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: async_AT_cc.gatech.edu


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jun 17 2002 - 17:13:50 EEST