Hello !! ( && Audio Diff Interface Brainstorming )

>
>> In terms of an interface, I'm a big fan of allowing
users to have as
>> much control over the alignment process as
possible.
>> Allowing users to specify "sticky"
regions with relative weights is
>> important (at least until we come up with a 100%
perfect  
>> algorithm 
>
> User control is good - particularly valuable to someone
refining the
> underlying algorithm to get it as good as possible. 
How useful to the
> end user?  Depends on how the user control of alignment
is  
> presented. A
> modified envelope could be used to set the
'stickiness'.  We're
> already using our envelope code for envelopes, for
filters and for  
> audio
> time stretching, so it's a natural for further
adaptation.  I think  
> it's
> less likely to be used for 'stickiness' as a way to
mark 'this part of
> the sequence is VERY important to align, this part is
less so.'
>

Yes indeed.  Another random thought.  On your 'audio-diff'
page, you  
mention
the following functionality:

"If we were to line up two audio tracks in this way, we
could mix-and- 
match between the two tracks.
This would be extraordinarily cool. I don't know of any
commercial  
audio software that can do this - perhaps someone else can
look."

I agree... this would be extremely cool.  It seems to me
that almost  
a "search-and-replace" type of functionality is
implied ?!
For instance, I have 2 takes of a track, and I want to use
one  
particular instance of the chorus from Track A to replace
every
instance of the chorus in track B.

This is not alignment, because we're searching for every
instance.  I  
was thinking how it might be possible to incorporate
both functionalities.  The default visualization could be a
straight  
alignment of 2 tracks.  In this case, each segment of Track
A
would be visually matched to only the best matching region
on Track  
B.  Next, the user could then use the mouse to select a
portion of Track A (e.g. one instance of the chorus of a
song), and  
then (possibly multiple) regions on Track B would
highlight if they are good matches.  Perhaps a colour
mapping could  
be used for the highlighted regions to indicate
the strength of similarity of the regions.  Comments welcome
as I  
brainstorm interface ideas.

My intuition says we can compute multiple similar regions on
Track B  
using the same dotplot.  Yes?

<< more below >>


>> ----------------------------
>
>> Naturally, in thinking of my own selfish needs, I
thought about  
>> the fact
>> that I also need to create at some point an
interface for
>> sound source separation (potentially interactive)
for my thesis,  
>> hence:
>
>> (3) Interface for audio source separation  :-D   I
don't pretend  
>> to have
>> the answer to mono or polyphonic sound source
separation,
>> so an interface that allows for different Vamps
would be great.  I  
>> could
>> write an essay here about features, but will
>> refrain until I see how interested others on the
list are about  
>> this idea.
>
> My view: It's crucial to find use cases for the
interface which hit  
> real
> user needs.  And that are achievable in the time! 
Consider for  
> example
> taking a radio-phone-in interview and separating the
host (full
> spectrum) from the telephone caller (8K bandwidth) onto
two  
> tracks.  For
> this application it isn't a big deal if we don't
separate the speakers
> when they're talking at the same time   So I'm
talking more about a
> classifier than source separation.  As I see it a
classifier is 'just'
> source separation that behaves rather poorly when both
sources are  
> there
> at once.. 
>
> Doing this, you could focus on the interface, because
the 'separation'
> is not (?) that demanding.
>
> focus on what benefit the user will see from it.
> What use cases for the end user (who is not also a
researcher) will be
> achieved in the time?

Hmm, this sounds much more like segmentation than
separation, which
is an entirely different beast.  I am in complete agreement
that use  
cases
are important, and practicality for users is the key issue. 
I also  
think
with the current state and constraints of separation
algorithms  
(thinking
beyond denoising), perhaps a tie-in with my own research
might in fact
not be of greatest practical benefit to the Audacity
project...  
absolutely
not a problem.

Cheers,
Jen






-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Audacity-devel mailing list
Audacity-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/audacity
-devel