Bugzilla – Bug 1784
Silencing an audio selection that crosses a split causes an "Internal error ..."
Last modified: 2018-08-20 11:46:00 UTC
Created attachment 739 [details] screenshot of MaxFlight's error message User MaxFlight reported this on the Forum: http://forum.audacityteam.org/viewtopic.php?f=46&t=97773 reconstructing a similar project on my W10 laptop I could not reproduce this on 2.2.0 or 2.2.1 alpha. MaxFlight posted a zip hile with a project that failed for hi - I used that project and also then got the "Internal error ..." Set as P2 as users should not see such messages. Marked moonphase as I can't reproduce this from scratch
Created attachment 740 [details] zip file of project that creates the error
In the unzipped project that MaxFlight sent I do get the error with the track/splits/selection you sent there (btw I get orphan blockfiles when I open the project) But if I: 1) Keep the project open 2) delete the track 3) Add a new mono track 4) generate 30 seconds of "silence" 5) set clip lines at 10 1nd 20 seconds 6) select from 5 to 25 seconds 7) Press Ctrl+L => no error message.
Interesting observations: Take the file and shift the selection area to the left so only the lefthand split line is in the selected area. Cmd/Ctrl+L does not cause the error. Shift the selection to the right so the lefthand split line is not in the selected area and Cmd/Ctrl+L still gives the error. Delete the righthand split line in the original file and no error on Cmd/Ctrl+L. Restore the righthand line and delete the lefthand one and the error returns. Delete the righthand line and create a new line and there is also no error. Question - What is special with that particular righthand line? To me it seems as there may be something corrupted in the file related to that line. Could there be a relation with the orhpan files? I wouldn't put this as a bug unless it appears again or else put it as a P5 Moonphase. Suggestion: Ask the reporter, MaxFlight, to try to repeat the error in another file. I suspect he will not be able to do so. If I am correct then close the bug as not a bug.
I believe the AUP is damaged. Open it in a text editor and you'll see that there is a zero-length sequence. <waveclip offset="7.50004847"> <sequence maxsamples="262144" sampleformat="262159" numsamples="0"/> <envelope numpoints="0"/> </waveclip> Then there appears to be a gap (of 0.00000553 seconds) since the next waveclip should (?) begin at the same time as the previous one since it is zero length? <waveclip offset="7.50005400"> That gap is less than one sample at 44100 Hz sample rate. You can zoom in to the sample level at the clip line near 7.50 seconds and see the "phantom" clip. It's been ages since we've seen a zero-length clip. Was code added to deal with them? If so, should we add that code to the Silence command?
The zero-length clip is certainly involved in this, but should be harmless. The problem was that the code was unnecessarily treating it as an error. Fix is at https://github.com/audacity/audacity/commit/92691d84853875ee9bc8296309e5172210044c61
(In reply to Paul L from comment #5) Testing on macOS 10.13.1 High Sierra on audacity-macos-nightly-2.2.1-92691d8.dmg 21Nov17 Using MaxFlight's project no longer caused this "internal error"/assert. Nor does it occur with multi-track projects of my own that I created. It did still occur on the previous alpha of 20Nov17. Looks to be fixed on Mac Cannot test yet on Windows as we have no nightlies or RC
(In reply to Paul L from comment #5) Testing on W10-CE 2,2,1 RC1 Using MaxFlight's project no longer caused this "internal error"/assert. Nor does it occur with multi-track projects of my own that I created. It did still occur on the previous alpha of 20Nov17. Looks to be fixed on Mac
