This RFE was reported in a message to the javasound-comments mail alias:

From: "Tim Boudreau" <###@###.###>
To: "###@###.###" <###@###.###>
Date: Sun, 14 Nov 1999 02:32:47 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: JavaSound - Visible rendering of audio data

I've been looking over the specs for JavaSound (I work for a company
recently acquired by Sun Microsystems, NetBeans, and have a background
in digital audio).

One thing I did not see that would be extremely useful for digital
audio applications, and both deserves standardization (there are an
assortment of formats for it now in use) is the visual rendering of
audio data, and caching and storing of that information for fast access
later. That is to say, if I want to display a visual representation of
audio data, that involves some rather extensive processing and
averaging, and potentially reprocessing that data when the display
resolution changes.

The solution to this issue in a number of digital audio applications
(SAW32, Cool Edit Pro, etc) is to build a "peak file" or to cache the
visual representation of audio data, so that it does not need to be
reprocessed.

Two things that I think would be very useful addendums to the JavaSound
spec would be reader/writer classes that can build such data from an
object containing audio data, and an "audioPainter" class, or even an
"audioView" class that allows for the display and possibly visual
editing of audio data. For performance, caching display data is a
necessity, hence the desire for a standard for storing that data.

No doubt the JavaSound folks are familiar with it, but one company that
has done some very good work with this sort of thing is Syntrillium
(they make CoolEdit). The approach they use for caching visual
representations of audio data is fast and very effective and worth a
look.

These are difficult tasks, which are exactly the sort of thing a lot of
Java APIs provide for. What do you think?

Tim Boudreau
NetBeans - Sun Microsystems