Re: Fwd: Re: Re[2]: [linux-audio-dev] peakfiles and EDL's

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

Subject: Re: Fwd: Re: Re[2]: [linux-audio-dev] peakfiles and EDL's
From: Richard C. Burnett (burnett_AT_tality.com)
Date: Thu Mar 01 2001 - 22:42:58 EET


Here is where I see a problem. I use the peak envelope for clipping, and
for a 'general' idea when mixing. My main problem right now has to do
with content. If you take the RMS value of the peak, I don't see that as
being overly more helpful. Are you concerned with the power of the
signal? If so, then a spectral power representation is what would
help, maybe even with phase data for mix prediction. When I get quite a
few tracks, I always have the fun of going through and tweaking the
volumne curves and eq to keep from getting clipped signals. What I am
actually working on from a conceptual point of view is a 'sound print'
function. I am trying to develop a way of a file that contains fft output
data that can be drawn behind the waveform as a thermal map. This can
help to identify hotspots in songs and apply filters for those hotspots
when they are causing clipping with other tracks. Also, with a phase
related information too, you could select some tracks and generate a
display of the 'mixing' potential, a rude prediction of the contents being
mixed.

What do you all think about this? I have been writing it in perl right
now (just because working with the canvas with Perl/Tk is so fast). Would
anyone benefit from the things I have described if I could come up with
some algorithms that were fast and have a good deal of correlation?

Rick

On Thu, 1 Mar 2001, Tom Pincince wrote:

> > true. and it has me thinking that computing the RMS value for the
> > window would actually be a lot nicer in many ways than using peak
> > values. the only problem i can see is that the peak values preserve DC
> > offsets, whereas a single RMS value does not, and this could be a
> > problem. but given that any sampled audio sound is really being stored
> > as a series of amplitudes, it somehow seems more fitting to actually
> > use something more like RMS than peak data ...
> >
> >
> > any comments ?
> >
> An RMS display would reduce the visual presence of transient peaks.
> Since one of the main uses of waveform overview display is to assist the
> user in knowing where he is in a song, and there is nothing better than
> transient peaks to identify location in a song (its called the beat), I
> would definitely want peak display when doing the cut and paste thing.
>
> There is another time when waveform overview displays come into use that
> would definitely benefit from RMS values, and that is mastering. In
> this case the individual songs are complete and there will not be any
> defining of regions which do benefit from peak display. Instead the
> timeline of the entire project is displayed and the songs are positioned
> relative to each other. In this mode the most valuable information is
> the relative loudness of adjacent songs, and peak displays are terrible
> at this. An RMS overview would give a clearer picture when setting gain
> and eq for the purpose of making one song flow nicely into the next.
> One possible feature for this mode of display is linking gain
> adjustments from the mixer to vertical zoom in the waveform overview
> display. What you see is what you hear. I have not seen this feature
> implemented anywhere.
>
> So I guess that I would like to see an overviewfile instead of a
> peakfile, where each N samples are represented by 3 pieces of info; the
> largest + peak, the largest - peak, and the RMS value.
>
> Are you computing this on the fly, creating the peakfile and the
> soundfile simultaneously, or are you computing the peakfile immediately
> after recording is stopped? Certainly you would need the ability to
> compute the peakfile for imported files, which would obviously not be
> done simultaneously with recording. Computing the peakfile after
> recording is stopped would allow you to include more statistical
> information about the soundfile since there would be no concern
> regarding rt performance. However, an immediately available waveform
> overview would also be nice, and creating a peakfile containing only
> peak info could probably be computed on the fly.
>
> Tom
>
>

+------------------------+-----------------------+
| T a l i t y | +------+ |
+------------------------+ +----+-+ | |
| Richard Burnett | +-+ | |
| Senior Design Engineer +---+ +----+ |
| burnett_AT_tality.com | | |
| | | |
| Phone: 919.380.3014 | |
| Fax: 919.380.3903 | | |
+------------------------------------------------+


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

This archive was generated by hypermail 2b28 : Thu Mar 01 2001 - 23:02:15 EET