Fwd: [Audacity-users] Peculiar bug with stereo tracks and only one channel

[Al Dimond]

An interesting thread from the users list.  I just forwarded the original post
along because it got top-posty and confusing.  My comments down below.
----------  Forwarded Message  ----------

Subject: [Audacity-users] Peculiar bug with stereo tracks and only one channel
Date: Tuesday 06 October 2009
From: Ramekin <[hidden email]>
To: [hidden email]


I have an odd problem with my project. I have two tracks that are both
supposed to be stereo. One of them is only showing a single channel (not
marked left or right) and the other shows both channels. If I select the
track that only has one channel, the upper channel in the other track is
also selected. It seems the stereo track with only one channel is latching
onto the adjacent stereo track.

If I try to split the stereo track with only one channel Audacity crashes. I
have attached a screenshot for those that it will help. Any ideas?

I'm using Audacity 1.3.8 on Windows XP.

Thanks,

Mat
--
View this message in context: http://n2.nabble.com/Peculiar-bug-with-stereo-
tracks-and-only-one-channel-tp3777863p3777863.html
Sent from the audacity-users mailing list archive at Nabble.com.

----------------------- End of forwarded message ---------------------

Later in the thread (http://n2.nabble.com/Peculiar-bug-with-stereo-tracks-and-
only-one-channel-tp3777863p3777863.html; also check the screenshot there) he
commented that he could move different tracks underneath his broken stereo
track and the broken track would "attach" to them.  Which is exactly what
you'd expect if the second half of a stereo pair went away.

I asked him whether this started in the middle of editing or on a project load
and haven't heard back yet.  If it was during a project load, we probably
could use a sanity check for mismatched stereo pairs.

I advised him to export all his working tracks and start a new project.  If
there's a reasonable way to try to restore the missing second half of the
stereo pair that would probably be useful to this user.  If the structure of
project directories is documented somewhere I might be able to figure that out.

 - Al

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Richard Ash (audacity-help)]

On Wed, 2009-10-07 at 11:02 -0600, Al Dimond wrote:
> Later in the thread
> (http://n2.nabble.com/Peculiar-bug-with-stereo-tracks-and-
> only-one-channel-tp3777863p3777863.html; also check the screenshot
> there) he commented that he could move different tracks underneath his
> broken stereo track and the broken track would "attach" to them.
> Which is exactly what you'd expect if the second half of a stereo pair
> went away.

Stereo tracks are a monumental hack. I'd love someone to rewrite them
from scratch for n-channel tracks, and deal with this sort of issue
permanently. GSOC post 2.0?

> I asked him whether this started in the middle of editing or on a
> project load and haven't heard back yet.  If it was during a project
> load, we probably could use a sanity check for mismatched stereo
> pairs.

Seems sensible enough - although I'm not quite sure how you would
achieve this, because AFAIK there is only a single boolean flag to
achieve a linked pair of tracks (i.e. the linking is one-way).

> I advised him to export all his working tracks and start a new
> project.  If there's a reasonable way to try to restore the missing
> second half of the stereo pair that would probably be useful to this
> user.  If the structure of project directories is documented somewhere
> I might be able to figure that out.
I don't think you need to touch the project directory, just examine the
XML file, where all the tracks are defined, and see if you can locate
the offending tracks.

Richard


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Wednesday 07 October 2009 14:48:15 Richard Ash wrote:

> On Wed, 2009-10-07 at 11:02 -0600, Al Dimond wrote:
> > Later in the thread
> > (http://n2.nabble.com/Peculiar-bug-with-stereo-tracks-and-
> > only-one-channel-tp3777863p3777863.html; also check the screenshot
> > there) he commented that he could move different tracks underneath his
> > broken stereo track and the broken track would "attach" to them.
> > Which is exactly what you'd expect if the second half of a stereo pair
> > went away.
>
> Stereo tracks are a monumental hack. I'd love someone to rewrite them
> from scratch for n-channel tracks, and deal with this sort of issue
> permanently. GSOC post 2.0?
>

That's what I thought when I first saw them.  I'm glad I'm not the only one.  
As it stands we pretty much have a max of 2 channels per track, which is lame
considering that surround sound has been around for a while.  After 2.0 if I'm
not too busy (I'm unemployed now but I'd like that to change ASAP) I could
take a look at it.

> > I asked him whether this started in the middle of editing or on a
> > project load and haven't heard back yet.  If it was during a project
> > load, we probably could use a sanity check for mismatched stereo
> > pairs.
>
> Seems sensible enough - although I'm not quite sure how you would
> achieve this, because AFAIK there is only a single boolean flag to
> achieve a linked pair of tracks (i.e. the linking is one-way).
>

We couldn't catch all cases.  But there are some clues.  For one thing, there
should never be two consecutive tracks with linked == 1.  In this user's case,
that test would have caught it.  And the channels should always be left
followed by right.  In most error cases you'd see left followed by left or
left followed by mono, so these two tests should catch stuff.  I'm looking at
adding checks for this now; it's not really too hard to write the tests, but
doing something sensible with recovery might be a little harder (I haven't
looked at how recovery works, so I could be totally wrong about that).

I generally assume (based on working closely with a group of users at a past
employer) that if one user reports a bug, a lot of others have experienced it
but not reported it.  So I bet this guy isn't the first person to have one of
his tracks fall off the cart.

 - Al

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Do these problems happen with HEAD?  It sounds very similar to a
problem that we had a little while ago, that was fixed. 1.3 8 is
ancient history to me.

TTFN
Martyn

Al Dimond wrote:

> On Wednesday 07 October 2009 14:48:15 Richard Ash wrote:
>> On Wed, 2009-10-07 at 11:02 -0600, Al Dimond wrote:
>>> Later in the thread
>>> (http://n2.nabble.com/Peculiar-bug-with-stereo-tracks-and-
>>> only-one-channel-tp3777863p3777863.html; also check the screenshot
>>> there) he commented that he could move different tracks underneath his
>>> broken stereo track and the broken track would "attach" to them.
>>> Which is exactly what you'd expect if the second half of a stereo pair
>>> went away.
>> Stereo tracks are a monumental hack. I'd love someone to rewrite them
>> from scratch for n-channel tracks, and deal with this sort of issue
>> permanently. GSOC post 2.0?
>>
>
> That's what I thought when I first saw them.  I'm glad I'm not the only one.  
> As it stands we pretty much have a max of 2 channels per track, which is lame
> considering that surround sound has been around for a while.  After 2.0 if I'm
> not too busy (I'm unemployed now but I'd like that to change ASAP) I could
> take a look at it.
>
>>> I asked him whether this started in the middle of editing or on a
>>> project load and haven't heard back yet.  If it was during a project
>>> load, we probably could use a sanity check for mismatched stereo
>>> pairs.
>> Seems sensible enough - although I'm not quite sure how you would
>> achieve this, because AFAIK there is only a single boolean flag to
>> achieve a linked pair of tracks (i.e. the linking is one-way).
>>
>
> We couldn't catch all cases.  But there are some clues.  For one thing, there
> should never be two consecutive tracks with linked == 1.  In this user's case,
> that test would have caught it.  And the channels should always be left
> followed by right.  In most error cases you'd see left followed by left or
> left followed by mono, so these two tests should catch stuff.  I'm looking at
> adding checks for this now; it's not really too hard to write the tests, but
> doing something sensible with recovery might be a little harder (I haven't
> looked at how recovery works, so I could be totally wrong about that).
>
> I generally assume (based on working closely with a group of users at a past
> employer) that if one user reports a bug, a lot of others have experienced it
> but not reported it.  So I bet this guy isn't the first person to have one of
> his tracks fall off the cart.
>
>  - Al
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Wednesday 07 October 2009 17:47:09 Martyn Shaw wrote:
> Do these problems happen with HEAD?  It sounds very similar to a
> problem that we had a little while ago, that was fixed. 1.3 8 is
> ancient history to me.
>
> TTFN
> Martyn
>

I don't know.  I've never seen it happen with my own eyes, just have this
report.  1.3.8 is before I started working on Audacity, so I have no memory of
any such bug.  I've attached a patch that checks for this sort of thing when
opening projects.  It appears to do the right thing for all the cases I
checked (nothing for correct projects, and reports orphaned blockfiles for
projects I mangled by hand).  But if you think this bug has come and gone then
it might not be worth the trouble.

> Al Dimond wrote:
> > On Wednesday 07 October 2009 14:48:15 Richard Ash wrote:
> >> On Wed, 2009-10-07 at 11:02 -0600, Al Dimond wrote:
> >>> Later in the thread
> >>> (http://n2.nabble.com/Peculiar-bug-with-stereo-tracks-and-
> >>> only-one-channel-tp3777863p3777863.html; also check the screenshot
> >>> there) he commented that he could move different tracks underneath his
> >>> broken stereo track and the broken track would "attach" to them.
> >>> Which is exactly what you'd expect if the second half of a stereo pair
> >>> went away.
> >>
> >> Stereo tracks are a monumental hack. I'd love someone to rewrite them
> >> from scratch for n-channel tracks, and deal with this sort of issue
> >> permanently. GSOC post 2.0?
> >
> > That's what I thought when I first saw them.  I'm glad I'm not the only
> > one. As it stands we pretty much have a max of 2 channels per track,
> > which is lame considering that surround sound has been around for a
> > while.  After 2.0 if I'm not too busy (I'm unemployed now but I'd like
> > that to change ASAP) I could take a look at it.
> >
> >>> I asked him whether this started in the middle of editing or on a
> >>> project load and haven't heard back yet.  If it was during a project
> >>> load, we probably could use a sanity check for mismatched stereo
> >>> pairs.
> >>
> >> Seems sensible enough - although I'm not quite sure how you would
> >> achieve this, because AFAIK there is only a single boolean flag to
> >> achieve a linked pair of tracks (i.e. the linking is one-way).
> >
> > We couldn't catch all cases.  But there are some clues.  For one thing,
> > there should never be two consecutive tracks with linked == 1.  In this
> > user's case, that test would have caught it.  And the channels should
> > always be left followed by right.  In most error cases you'd see left
> > followed by left or left followed by mono, so these two tests should
> > catch stuff.  I'm looking at adding checks for this now; it's not really
> > too hard to write the tests, but doing something sensible with recovery
> > might be a little harder (I haven't looked at how recovery works, so I
> > could be totally wrong about that).
> >
> > I generally assume (based on working closely with a group of users at a
> > past employer) that if one user reports a bug, a lot of others have
> > experienced it but not reported it.  So I bet this guy isn't the first
> > person to have one of his tracks fall off the cart.
> >
> >  - Al
> >
> > -------------------------------------------------------------------------
> >----- Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ---------------------------------------------------------------------------
>--- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

[awd_linked_sanity.patch]

---

Index: src/Project.cpp
===================================================================
RCS file: /cvsroot/audacity/audacity-src/src/Project.cpp,v
retrieving revision 1.456
diff -u -r1.456 Project.cpp
--- src/Project.cpp 30 Sep 2009 19:31:44 -0000 1.456
+++ src/Project.cpp 8 Oct 2009 00:02:56 -0000
@@ -2299,6 +2299,39 @@
       while (t) {
          if (t->GetErrorOpening())
             err = true;
+
+         // Sanity checks for linked tracks; unsetting the linked property
+         // doesn't fix the problem, but it likely leaves us with orphaned
+         // blockfiles instead of much worse problems.
+         if (t->GetLinked())
+         {
+            Track *l = t->GetLink();
+            if (l)
+            {
+               // A linked track's partner should never itself be linked
+               if (l->GetLinked())
+               {
+                  err = true;
+                  t->SetLinked(false);
+               }
+              
+               // Channels should be left and right
+               if ( !(  (t->GetChannel() == Track::LeftChannel &&
+                           l->GetChannel() == Track::RightChannel) ||
+                        (t->GetChannel() == Track::RightChannel &&
+                           l->GetChannel() == Track::LeftChannel) ) )
+               {
+                  err = true;
+                  t->SetLinked(false);
+               }
+            }
+            else
+            {
+               err = true;
+               t->SetLinked(false);
+            }
+         }
+
          mLastSavedTracks->Add(t->Duplicate());
          t = iter.Next();
       }

---

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

Another thing: while figuring out how project loading worked I came across what
is probably a bug in the XMLFileReader class.  It is unlikely to ever affect us
in practice, because the code would only run when updating mMaxDepth, which is
initialized to 128.  When that depth is exceeded (in startElement()), a new
array is allocated, but it would never have actually replaced the old one.  
This very short patch fixes that.

 - Al

[awd_xml_reader_depth.patch]

---

Index: src/xml/XMLFileReader.cpp
===================================================================
RCS file: /cvsroot/audacity/audacity-src/src/xml/XMLFileReader.cpp,v
retrieving revision 1.14
diff -u -r1.14 XMLFileReader.cpp
--- src/xml/XMLFileReader.cpp 24 May 2009 11:31:06 -0000 1.14
+++ src/xml/XMLFileReader.cpp 8 Oct 2009 00:29:53 -0000
@@ -98,6 +98,8 @@
       XMLTagHandler  **newHandler = new XMLTagHandler*[This->mMaxDepth*2];
       for(int i=0; i<This->mMaxDepth; i++)
          newHandler[i] = This->mHandler[i];
+      delete[] This->mHandler;
+      This->mHandler = newHandler;
       This->mMaxDepth *= 2;
    }
 

---

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From Al Dimond <[hidden email]>
| Wed, 7 Oct 2009 18:20:27 -0600
| Subject: [Audacity-devel] Fwd: [Audacity-users] Peculiar bug with stereo tracks and only one channel

> On Wednesday 07 October 2009 17:47:09 Martyn Shaw wrote:
> > Do these problems happen with HEAD?  It sounds very similar to a
> > problem that we had a little while ago, that was fixed. 1.3 8 is
> > ancient history to me.
> >
> > TTFN
> > Martyn
> >
>
> I don't know.  I've never seen it happen with my own eyes, just have this
> report.  1.3.8 is before I started working on Audacity, so I have no memory of
> any such bug.  I've attached a patch that checks for this sort of thing when
> opening projects.  It appears to do the right thing for all the cases I
> checked (nothing for correct projects, and reports orphaned blockfiles for
> projects I mangled by hand).  But if you think this bug has come and gone then
> it might not be worth the trouble.

Martyn, were you thinking of the bug where a larger DPI or
downsizing the project window caused a stereo track to split,
so making it appear the left-hand channel had disappeared?
http://www.gaclrecords.org.uk/dp12.png 

That isn't what the user sees. What he gets is a track that looks
"Right" in my image, but says "Stereo" (only has one channel).  
I can't recall anything like that before.

Orphaned blockfile warnings are obviously a cause for user concern
where they occur. Once again I question whether the dialogue
defaults of deleting orphans and replacing missing blockfiles really
are "safe" while we have an outstanding P3 for these errors occurring
for unknown reasons, and known cases where deleting orphans
silences the project.

I'm all for the new checks, but do I assume the user will actually
need to "continue without deleting" in order not to be in a worse
state than having delinked (but probably recoverable) tracks?




Gale

> > Al Dimond wrote:
> > > On Wednesday 07 October 2009 14:48:15 Richard Ash wrote:
> > >> On Wed, 2009-10-07 at 11:02 -0600, Al Dimond wrote:
> > >>> Later in the thread
> > >>> (http://n2.nabble.com/Peculiar-bug-with-stereo-tracks-and-
> > >>> only-one-channel-tp3777863p3777863.html; also check the screenshot
> > >>> there) he commented that he could move different tracks underneath his
> > >>> broken stereo track and the broken track would "attach" to them.
> > >>> Which is exactly what you'd expect if the second half of a stereo pair
> > >>> went away.
> > >>
> > >> Stereo tracks are a monumental hack. I'd love someone to rewrite them
> > >> from scratch for n-channel tracks, and deal with this sort of issue
> > >> permanently. GSOC post 2.0?
> > >
> > > That's what I thought when I first saw them.  I'm glad I'm not the only
> > > one. As it stands we pretty much have a max of 2 channels per track,
> > > which is lame considering that surround sound has been around for a
> > > while.  After 2.0 if I'm not too busy (I'm unemployed now but I'd like
> > > that to change ASAP) I could take a look at it.
> > >
> > >>> I asked him whether this started in the middle of editing or on a
> > >>> project load and haven't heard back yet.  If it was during a project
> > >>> load, we probably could use a sanity check for mismatched stereo
> > >>> pairs.
> > >>
> > >> Seems sensible enough - although I'm not quite sure how you would
> > >> achieve this, because AFAIK there is only a single boolean flag to
> > >> achieve a linked pair of tracks (i.e. the linking is one-way).
> > >
> > > We couldn't catch all cases.  But there are some clues.  For one thing,
> > > there should never be two consecutive tracks with linked == 1.  In this
> > > user's case, that test would have caught it.  And the channels should
> > > always be left followed by right.  In most error cases you'd see left
> > > followed by left or left followed by mono, so these two tests should
> > > catch stuff.  I'm looking at adding checks for this now; it's not really
> > > too hard to write the tests, but doing something sensible with recovery
> > > might be a little harder (I haven't looked at how recovery works, so I
> > > could be totally wrong about that).
> > >
> > > I generally assume (based on working closely with a group of users at a
> > > past employer) that if one user reports a bug, a lot of others have
> > > experienced it but not reported it.  So I bet this guy isn't the first
> > > person to have one of his tracks fall off the cart.
> > >
> > >  - Al
> > >
> > > -------------------------------------------------------------------------
> > >----- Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > > is the only developer event you need to attend this year. Jumpstart your
> > > developing skills, take BlackBerry mobile applications to market and stay
> > > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > > http://p.sf.net/sfu/devconference
> > > _______________________________________________
> > > audacity-devel mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
> > ---------------------------------------------------------------------------
> >--- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> > the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Wednesday 07 October 2009 20:45:29 Gale Andrews wrote:

> | From Al Dimond <[hidden email]>
> | Wed, 7 Oct 2009 18:20:27 -0600
> | Subject: [Audacity-devel] Fwd: [Audacity-users] Peculiar bug with stereo
> | tracks and only one channel
> |
> > On Wednesday 07 October 2009 17:47:09 Martyn Shaw wrote:
> > > Do these problems happen with HEAD?  It sounds very similar to a
> > > problem that we had a little while ago, that was fixed. 1.3 8 is
> > > ancient history to me.
> > >
> > > TTFN
> > > Martyn
> >
> > I don't know.  I've never seen it happen with my own eyes, just have this
> > report.  1.3.8 is before I started working on Audacity, so I have no
> > memory of any such bug.  I've attached a patch that checks for this sort
> > of thing when opening projects.  It appears to do the right thing for all
> > the cases I checked (nothing for correct projects, and reports orphaned
> > blockfiles for projects I mangled by hand).  But if you think this bug
> > has come and gone then it might not be worth the trouble.
>
> Martyn, were you thinking of the bug where a larger DPI or
> downsizing the project window caused a stereo track to split,
> so making it appear the left-hand channel had disappeared?
> http://www.gaclrecords.org.uk/dp12.png
>
> That isn't what the user sees. What he gets is a track that looks
> "Right" in my image, but says "Stereo" (only has one channel).
> I can't recall anything like that before.
>
> Orphaned blockfile warnings are obviously a cause for user concern
> where they occur. Once again I question whether the dialogue
> defaults of deleting orphans and replacing missing blockfiles really
> are "safe" while we have an outstanding P3 for these errors occurring
> for unknown reasons, and known cases where deleting orphans
> silences the project.
>
> I'm all for the new checks, but do I assume the user will actually
> need to "continue without deleting" in order not to be in a worse
> state than having delinked (but probably recoverable) tracks?
>
>

Yes, that's true.  That's probably true in many cases where there are orphaned
blockfiles (I think a crash between new track creation and a save would be such
a case).  Unless there's a good way to automatically recover tracks from
orphaned blockfiles the user is probably stuck re-creating the audio whether
the blockfiles are there or not.  I think Audacity checks for extra blockfiles
every time it loads a project, so he'll continue to be nagged about it until
he does something.

There may be a class of user that knows things can be recovered from blockfiles
but at the time he sees the dialog doesn't realize that he's actually losing
something.  The dialog does make it seem unlikely that you're actually losing
data.  So maybe we'll have to write up some new text for this case.

>
>
> Gale
>
> > > Al Dimond wrote:
> > > > On Wednesday 07 October 2009 14:48:15 Richard Ash wrote:
> > > >> On Wed, 2009-10-07 at 11:02 -0600, Al Dimond wrote:
> > > >>> Later in the thread
> > > >>> (http://n2.nabble.com/Peculiar-bug-with-stereo-tracks-and-
> > > >>> only-one-channel-tp3777863p3777863.html; also check the screenshot
> > > >>> there) he commented that he could move different tracks underneath
> > > >>> his broken stereo track and the broken track would "attach" to
> > > >>> them. Which is exactly what you'd expect if the second half of a
> > > >>> stereo pair went away.
> > > >>
> > > >> Stereo tracks are a monumental hack. I'd love someone to rewrite
> > > >> them from scratch for n-channel tracks, and deal with this sort of
> > > >> issue permanently. GSOC post 2.0?
> > > >
> > > > That's what I thought when I first saw them.  I'm glad I'm not the
> > > > only one. As it stands we pretty much have a max of 2 channels per
> > > > track, which is lame considering that surround sound has been around
> > > > for a while.  After 2.0 if I'm not too busy (I'm unemployed now but
> > > > I'd like that to change ASAP) I could take a look at it.
> > > >
> > > >>> I asked him whether this started in the middle of editing or on a
> > > >>> project load and haven't heard back yet.  If it was during a
> > > >>> project load, we probably could use a sanity check for mismatched
> > > >>> stereo pairs.
> > > >>
> > > >> Seems sensible enough - although I'm not quite sure how you would
> > > >> achieve this, because AFAIK there is only a single boolean flag to
> > > >> achieve a linked pair of tracks (i.e. the linking is one-way).
> > > >
> > > > We couldn't catch all cases.  But there are some clues.  For one
> > > > thing, there should never be two consecutive tracks with linked == 1.
> > > >  In this user's case, that test would have caught it.  And the
> > > > channels should always be left followed by right.  In most error
> > > > cases you'd see left followed by left or left followed by mono, so
> > > > these two tests should catch stuff.  I'm looking at adding checks for
> > > > this now; it's not really too hard to write the tests, but doing
> > > > something sensible with recovery might be a little harder (I haven't
> > > > looked at how recovery works, so I could be totally wrong about
> > > > that).
> > > >
> > > > I generally assume (based on working closely with a group of users at
> > > > a past employer) that if one user reports a bug, a lot of others have
> > > > experienced it but not reported it.  So I bet this guy isn't the
> > > > first person to have one of his tracks fall off the cart.
> > > >
> > > >  - Al
> > > >
> > > > ---------------------------------------------------------------------
> > > >---- ----- Come build with us! The BlackBerry(R) Developer Conference
> > > > in SF, CA is the only developer event you need to attend this year.
> > > > Jumpstart your developing skills, take BlackBerry mobile applications
> > > > to market and stay ahead of the curve. Join us from November 9 - 12,
> > > > 2009. Register now! http://p.sf.net/sfu/devconference
> > > > _______________________________________________
> > > > audacity-devel mailing list
> > > > [hidden email]
> > > > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> > >
> > > -----------------------------------------------------------------------
> > >---- --- Come build with us! The BlackBerry(R) Developer Conference in
> > > SF, CA is the only developer event you need to attend this year.
> > > Jumpstart your developing skills, take BlackBerry mobile applications
> > > to market and stay ahead of the curve. Join us from November 9 - 12,
> > > 2009. Register now! http://p.sf.net/sfu/devconference
> > > _______________________________________________
> > > audacity-devel mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ---------------------------------------------------------------------------
>--- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel