[linux-audio-user] Miscellaneous hardware/software questions

[Janina Sajka]

Regrets that I didn't jump into this thread earlier--it is an old thread
...

james at dis-dot-dat.net writes:
> On Wed, 02 Nov, 2005 at 09:25PM +1100, Jason White spake thus:
> > On Tue, Nov 01, 2005 at 02:10:29PM +0000, james at dis-dot-dat.net wrote:
> > > I don't think it needs to be *that* difficult.  At least for a basic
> > > editor for cutting, pasting, applying fades, etc.

I am myself blind, and I also need to do this. I do my best with two
apps and am considering a third.

Ecasound does the fades and mixing for me quite well. See below.

The less familiar app, which I think you would find useful, Jason, is
Chuck Hallenbeck's wave editor, wedit:

http://www.mhcable.com/~chuckh/

There are other apps there which will be of interest, notably a
more speech friendly gramofile.

The other app I find promissing is Kirk Reiser's bsound available via
cvs from linux-speakup.org (if it's up). 

> > I agree, but others have identified the challenging aspect - how to identify
> > with sufficient accuracy the point at which to apply an
> > insertion/deletion/block/cut/copy operation, and how to navigate through the
> > file with appropriate feedback. Audio feedback might be possible, but there
> > would have to be some provision for scaling the timing by different factors to
> > allow the desired moment to be pinpointed.

I would agree that vision is extremely useful for this, but my
observations suggest vision alone is not sufficient. I've been in
editing sessions where some will say: "This looks like a good spot," and
then we listen and find there was some audible reason why it wasn't a
good spot after all. Ultimately, it's all about our ears, though sight
might help one zoom in more quickly.

My experience with both wedit and awe (bsound) is that finding candidate
starting points isn't too hard. What's missing is a hard stop somewhere
further in the file. I wish cI could define one, so that I could ask
some portion to play again and again while I decide if the starting
location is good, or not so good. What I find with both of these apps is
that I have to struggle to hit Ctrl-C, and then work my way back to the
start point to listen again. That's too much emphasis on stopping, in my
experience.

Guess I'll send Kirk and Chuck my RFE.

The other missing feature is some way to scrub meaningfully. The 104
isn't a great tool for scrubbing. Again, vision helps, but it's
ultimately about ears, so I should not think it too difficult to
interface some kind of wheel control for scrubbing. What do people use
with apps like Ardour?

Another thing I miss when working with wedit or awe is very precise
"Where Am I?" info, precise time, precise sample, etc. For editing
that's more important than a quick and dirty tool like wedit, this inof
would be quite important.

Now, if I extrapolate from what I can already do, and what I have
outlined above as missing, I see no reason why I shouldn't be able to do
similar precise things in a multi-track environment (like Ardour). The
only additional control would seemingly be identify the particular
track, or group of tracks, on which to operate.

Janina


> > > 
> > > After reading this post, I quickly posted the idea to my final year
> > > students as a possible honours project for them.  Some haven't yet
> > > decided, and I thought this would be a good one.  I was thinking of a
> > > kind of "audio shell", with python-like slicing, but with
> > > understanding of audio.  This way, you could make the text very big
> > > for people with reduced sight, or pipe output to a speech engine for
> > > people with no sight.  Or both.
> > The latter part is handled by projects such as Speakup, Yasr and BRLTTY which
> > provide, respectively, speech and braille display access at the console level.
> > There are also several screen magnification projects on offer, including the
> > Gnopernicus magnifier.
> 
> Yes, this is exactly why I love unix.  All we need is to get something
> text based and the rest is taken care of.
> 
> > > 
> > > I hope someone takes the project, because even though I don't think it
> > > would necessarily be the big ground-breaking interface redesign you
> > > thought it would require, it will give us something to work from -
> > > usability data, and such.
> > If someone does take the project I'de be interested in discussing it further
> > and trying out whatever is developed.
> 
> No takers, I'm afraid.  Maybe next year.  I just don't have the time
> to do it myself, although I might have a little play when I can.
> 
> > 
> 
> -- 
> "I'd crawl over an acre of 'Visual This++' and 'Integrated Development
> That' to get to gcc, Emacs, and gdb.  Thank you."
> (By Vance Petree, Virginia Power)

-- 

Janina Sajka				Phone: +1.202.595.7777
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://ScreenlessPhone.Com to learn more.

Chair, Accessibility Workgroup		Free Standards Group (FSG)
janina at freestandards.org		http://a11y.org