Thread: [Audacity-devel] Repeatable crash set format to 16-bit on read directly 32-bit float WAV
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: <ga...@au...> - 2012-02-28 21:46:31
|
Using audacity-win-2.0rc4 on Win 7 x64 but occurs in 1.3.14 too. 1. Import a 32-bit float, 22050 Hz mono WAV choosing "Read Directly". 2. From Track Drop-Down menu, choose "Set Sample Format" > 16-bit PCM. 3 Crash. To create the WAV I generated 11 seconds of white noise but probably anything would do. No crash if you copy in the WAV. Seen one other report of similar but could not get details from user. P1? Gale |
From: Bill W. <bi...@go...> - 2012-02-28 22:16:07
|
This does not appear to be dependent on the format of the imported file. Tested 2.0.0-rc3 Mac on OS X 10.7.2. 1. Set Quality to 32-bit float 44100 Hz 2. Import any AIF or WAV with Read Directly - the track reads "32-bit float" 3. From Track Drop-Down menu, choose "Set Sample Format" > 16-bit PCM 4. Crash The crash is always in the same place. Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 Audacity 0x001a7a3c Sequence::ConsistencyCheck(wchar_t const*) + 108 1 Audacity 0x001a8e33 Sequence::ConvertToSampleFormat(sampleFormat, bool*) + 403 2 Audacity 0x001fe2e3 WaveClip::ConvertToSampleFormat(sampleFormat) + 35 3 Audacity 0x0020763f WaveTrack::ConvertToSampleFormat(sampleFormat) + 47 4 Audacity 0x001e5453 TrackPanel::OnFormatChange(wxCommandEvent&) + 83 -- Bill On 28/02/2012, at 4:46 PM, ga...@au... wrote: > > Using audacity-win-2.0rc4 on Win 7 x64 but occurs in 1.3.14 too. > > 1. Import a 32-bit float, 22050 Hz mono WAV choosing "Read Directly". > 2. From Track Drop-Down menu, choose "Set Sample Format" > > 16-bit PCM. > 3 Crash. > > To create the WAV I generated 11 seconds of white noise but > probably anything would do. > > No crash if you copy in the WAV. > > Seen one other report of similar but could not get details from > user. > > P1? > > > > Gale > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Vaughan J. <va...@au...> - 2012-02-28 23:29:19
|
On 2/28/2012 1:46 PM, ga...@au... wrote: > > Using audacity-win-2.0rc4 on Win 7 x64 but occurs in 1.3.14 too. > > 1. Import a 32-bit float, 22050 Hz mono WAV choosing "Read Directly". > 2. From Track Drop-Down menu, choose "Set Sample Format" > > 16-bit PCM. > 3 Crash. > > To create the WAV I generated 11 seconds of white noise but > probably anything would do. > > No crash if you copy in the WAV. > > Seen one other report of similar but could not get details from > user. > > P1? That's the law. Glad you found it. Infrequent as it might be, it's definitely a bug in Audacity code. I'm looking at the bug. Thanks, Bill, for confirming it and for your stack info. Happens at the same place on Windows. The first block in that loop has a null file pointer, that gets dereferenced, ergo crash. It's easy enough to trap that and prevent the crash, and I'll do that, because Sequence::ConsistencyCheck() should not crash, it should report the problem. I think the real problem is in Sequence::ConvertToSampleFormat(), before it calls Sequence::ConsistencyCheck(). It's unfortunate this code has been so problematic. It's in the same area as bug 451. I think we *could* apply the same reasoning as there when I've trapped the crash(es), i.e., it could at least be demoted from P1. But I'll let you know what happens to the audio when I've made it crash-safe. Unnerving that a P1 comes up a day before planned release. We now need another round of RC's, so we are definitely postponing release, even if I can get the bug fixed before nightly build for Mac. Plus, I'm behind on preparing the website changes. Sorry I messed up the Download page. Gale, if you want to revert that and push it to the site, that's fine. As RM, I say we go on the 48-hour cycle, as in http://wiki.audacityteam.org/wiki/Release_Process#Process step 7, until we have a 48-hour cycle with no P1 or P2. We don't want to have daily RC's -- too much overhead. Do the manual editors want to fix those link issues? I think they were agreed as P1, but obscure, and not worth holding up release. I'm certain I can get the crashes trapped and that code committed in time for the Mac nightly. Then we can test like crazy (continuing that today, too!), discuss, and if okay, set the next RC's for 21:00 GMT Feb 29, to start the 48-hour cycle. - V |
From: Bill W. <bi...@go...> - 2012-02-29 00:27:37
|
On 28/02/2012, at 6:33 PM, Vaughan Johnson wrote: > > [snip] > Do the manual editors want to fix those link issues? I think they were > agreed as P1, but obscure, and not worth holding up release. We're going to try. -- Bill |
From: Vaughan J. <va...@au...> - 2012-02-29 04:58:32
|
On 2/28/2012 4:27 PM, Bill Wharrie wrote: > > On 28/02/2012, at 6:33 PM, Vaughan Johnson wrote: >> >> > [snip] > >> Do the manual editors want to fix those link issues? I think they were >> agreed as P1, but obscure, and not worth holding up release. > > We're going to try. > > -- Bill All right, good. My fix for the Sequence::ConsistencyCheck() P1 bug, just committed, will not be in the Feb 29 Mac nightly build, so please keep me posted on that. The next 48-hour cycle should start when those are both approved. - V |
From: Martyn S. <mar...@gm...> - 2012-02-29 00:37:18
|
On 28/02/2012 23:33, Vaughan Johnson wrote: > On 2/28/2012 1:46 PM, ga...@au... wrote: >> >> Using audacity-win-2.0rc4 on Win 7 x64 but occurs in 1.3.14 too. >> >> 1. Import a 32-bit float, 22050 Hz mono WAV choosing "Read Directly". >> 2. From Track Drop-Down menu, choose "Set Sample Format"> >> 16-bit PCM. >> 3 Crash. >> >> To create the WAV I generated 11 seconds of white noise but >> probably anything would do. >> >> No crash if you copy in the WAV. >> >> Seen one other report of similar but could not get details from >> user. >> >> P1? > > That's the law. Glad you found it. Infrequent as it might be, it's > definitely a bug in Audacity code. ****, ******, **** ******, **** ****** ****** (expletives deleted). > I'm looking at the bug. Thanks, Bill, for confirming it and for your > stack info. Happens at the same place on Windows. The first block in > that loop has a null file pointer, that gets dereferenced, ergo crash. > It's easy enough to trap that and prevent the crash, and I'll do that, > because Sequence::ConsistencyCheck() should not crash, it should report > the problem. I think the real problem is in > Sequence::ConvertToSampleFormat(), before it calls I see that you have a number of comments in there already. I'm afraid that I can't help with that today. > Sequence::ConsistencyCheck(). It's unfortunate this code has been so > problematic. It's in the same area as bug 451. I think we *could* apply > the same reasoning as there when I've trapped the crash(es), i.e., it > could at least be demoted from P1. But I'll let you know what happens to > the audio when I've made it crash-safe. > > > Unnerving that a P1 comes up a day before planned release. We now need > another round of RC's, so we are definitely postponing release, even if > I can get the bug fixed before nightly build for Mac. OK with me. > Plus, I'm behind on preparing the website changes. Sorry I messed up the > Download page. Gale, if you want to revert that and push it to the site, > that's fine. We are in a unique situation here - a 2.0 release. Things were almost bound to take more time. > As RM, I say we go on the 48-hour cycle, as in > http://wiki.audacityteam.org/wiki/Release_Process#Process step 7, until > we have a 48-hour cycle with no P1 or P2. We don't want to have daily > RC's -- too much overhead. OK. > Do the manual editors want to fix those link issues? I think they were > agreed as P1, but obscure, and not worth holding up release. > > I'm certain I can get the crashes trapped and that code committed in > time for the Mac nightly. Then we can test like crazy (continuing that > today, too!), discuss, and if okay, set the next RC's for 21:00 GMT Feb > 29, to start the 48-hour cycle. But not at the expense of your (or anybody else's) health! TTFN Martyn > > > - V > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Vaughan J. <va...@au...> - 2012-02-29 04:37:33
|
On 2/28/2012 4:37 PM, Martyn Shaw wrote: > > > On 28/02/2012 23:33, Vaughan Johnson wrote: >> On 2/28/2012 1:46 PM, ga...@au... wrote: >>> >>> Using audacity-win-2.0rc4 on Win 7 x64 but occurs in 1.3.14 too. >>> >>> 1. Import a 32-bit float, 22050 Hz mono WAV choosing "Read Directly". >>> 2. From Track Drop-Down menu, choose "Set Sample Format"> >>> 16-bit PCM. >>> 3 Crash. >>> >>> To create the WAV I generated 11 seconds of white noise but >>> probably anything would do. >>> >>> No crash if you copy in the WAV. >>> >>> Seen one other report of similar but could not get details from >>> user. >>> >>> P1? >> >> That's the law. Glad you found it. Infrequent as it might be, it's >> definitely a bug in Audacity code. > > ****, ******, **** ******, **** ****** ****** (expletives deleted). For sure. > >> I'm looking at the bug. Thanks, Bill, for confirming it and for your >> stack info. Happens at the same place on Windows. The first block in >> that loop has a null file pointer, that gets dereferenced, ergo crash. >> It's easy enough to trap that and prevent the crash, and I'll do that, >> because Sequence::ConsistencyCheck() should not crash, it should report >> the problem. I think the real problem is in >> Sequence::ConvertToSampleFormat(), before it calls > > I see that you have a number of comments in there already. Indeed. Some of that code is from 2002-2005! :-) >I'm afraid > that I can't help with that today. ...but you have! > >> Sequence::ConsistencyCheck(). It's unfortunate this code has been so >> problematic. It's in the same area as bug 451. I think we *could* apply >> the same reasoning as there when I've trapped the crash(es), i.e., it >> could at least be demoted from P1. But I'll let you know what happens to >> the audio when I've made it crash-safe. Following from my other message on this thread, I think I've fixed the main bug in Sequence::ConvertToSampleFormat() (which was not checking whether the blockfile is aliased), and committed the fix. It's past the mac nightly build time, but it's a cross-platform bug, so please go ahead and test win and *nix. >> >> >> Unnerving that a P1 comes up a day before planned release. We now need >> another round of RC's, so we are definitely postponing release, even if >> I can get the bug fixed before nightly build for Mac. > > OK with me. > >> Plus, I'm behind on preparing the website changes. Sorry I messed up the >> Download page. Gale, if you want to revert that and push it to the site, >> that's fine. > > We are in a unique situation here - a 2.0 release. Things were almost > bound to take more time. Thanks. Focusing on the app! > >> As RM, I say we go on the 48-hour cycle, as in >> http://wiki.audacityteam.org/wiki/Release_Process#Process step 7, until >> we have a 48-hour cycle with no P1 or P2. We don't want to have daily >> RC's -- too much overhead. > > OK. > >>[...] >> I'm certain I can get the crashes trapped and that code committed in >> time for the Mac nightly. Then we can test like crazy (continuing that >> today, too!), discuss, and if okay, set the next RC's for 21:00 GMT Feb >> 29, to start the 48-hour cycle. > > But not at the expense of your (or anybody else's) health! Definitely! - V |
From: Vaughan J. <va...@au...> - 2012-02-29 00:43:21
|
On 2/28/2012 3:33 PM, Vaughan Johnson wrote: > On 2/28/2012 1:46 PM, ga...@au... wrote: >> >> Using audacity-win-2.0rc4 on Win 7 x64 but occurs in 1.3.14 too. >> >> 1. Import a 32-bit float, 22050 Hz mono WAV choosing "Read Directly". >> 2. From Track Drop-Down menu, choose "Set Sample Format" > >> 16-bit PCM. >> 3 Crash. >> >> To create the WAV I generated 11 seconds of white noise but >> probably anything would do. >> >> No crash if you copy in the WAV. >> >> Seen one other report of similar but could not get details from >> user. >> >> P1? > > That's the law. Glad you found it. Infrequent as it might be, it's > definitely a bug in Audacity code. > > I'm looking at the bug. Thanks, Bill, for confirming it and for your > stack info. Happens at the same place on Windows. The first block in > that loop has a null file pointer, that gets dereferenced, ergo crash. > It's easy enough to trap that and prevent the crash, and I'll do that, > because Sequence::ConsistencyCheck() should not crash, it should report > the problem. I think the real problem is in > Sequence::ConvertToSampleFormat(), before it calls > Sequence::ConsistencyCheck(). It's unfortunate this code has been so > problematic. It's in the same area as bug 451. I think we *could* apply > the same reasoning as there when I've trapped the crash(es), i.e., it > could at least be demoted from P1. But I'll let you know what happens to > the audio when I've made it crash-safe. BAD things! I trapped the places where it was doing null derefs (and will commit those because they do at least failsafe Sequence::ConsistencyCheck() and Sequence::DebugPrintf()). In the debug build, when it has this error, it fails on a wxASSERT in WaveClip::ConvertToSampleFormat() that checks the result of Sequence::ConvertToSampleFormat(). That wxASSERT doesn't do anything in release build, but Audacity still crashes. So I'll get to work on debugging Sequence::ConvertToSampleFormat(). :-( - V > > > Unnerving that a P1 comes up a day before planned release. We now need > another round of RC's, so we are definitely postponing release, even if > I can get the bug fixed before nightly build for Mac. > > Plus, I'm behind on preparing the website changes. Sorry I messed up the > Download page. Gale, if you want to revert that and push it to the site, > that's fine. > > > As RM, I say we go on the 48-hour cycle, as in > http://wiki.audacityteam.org/wiki/Release_Process#Process step 7, until > we have a 48-hour cycle with no P1 or P2. We don't want to have daily > RC's -- too much overhead. > > Do the manual editors want to fix those link issues? I think they were > agreed as P1, but obscure, and not worth holding up release. > > I'm certain I can get the crashes trapped and that code committed in > time for the Mac nightly. Then we can test like crazy (continuing that > today, too!), discuss, and if okay, set the next RC's for 21:00 GMT Feb > 29, to start the 48-hour cycle. > > > - V > |
From: Bill W. <bi...@go...> - 2012-02-29 04:22:04
|
On 28/02/2012, at 7:34 PM, Vaughan Johnson wrote: > > [snip] > BAD things! > > I trapped the places where it was doing null derefs (and will commit > those because they do at least failsafe Sequence::ConsistencyCheck() and > Sequence::DebugPrintf()). > > In the debug build, when it has this error, it fails on a wxASSERT in > WaveClip::ConvertToSampleFormat() that checks the result of > Sequence::ConvertToSampleFormat(). > > That wxASSERT doesn't do anything in release build, but Audacity still > crashes. So I'll get to work on debugging > Sequence::ConvertToSampleFormat(). :-( > > - V My steps still crash, but in a different place. Mac nightly 03:15 Feb 29. 1. Set Quality to 32-bit float 44100 Hz 2. Import any AIF or WAV with Read Directly - the track reads "32-bit float" 3. From Track Drop-Down menu, choose "Set Sample Format" > 16-bit PCM 4. Crash Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 Audacity 0x001a6f8d Sequence::AppendBlock(SeqBlock*) + 77 1 Audacity 0x001ac1ec Sequence::Paste(long long, Sequence const*) + 3660 2 Audacity 0x001acd83 Sequence::Sequence(Sequence const&, DirManager*) + 211 3 Audacity 0x00202522 WaveClip::WaveClip(WaveClip&, DirManager*) + 258 4 Audacity 0x002099af WaveTrack::WaveTrack(WaveTrack&) + 367 5 Audacity 0x00209aa9 WaveTrack::Duplicate() + 41 6 Audacity 0x001ebfe8 UndoManager::PushState(TrackList*, double, double, wxString, wxString, int) + 168 7 Audacity 0x0019b411 AudacityProject::PushState(wxString, wxString, int) + 145 8 Audacity 0x0019b5f0 AudacityProject::TP_PushState(wxString, wxString, int) + 96 9 Audacity 0x001d321e TrackPanel::MakeParentPushState(wxString, wxString, int) + 110 10 Audacity 0x001e550b TrackPanel::OnFormatChange(wxCommandEvent&) + 363 -- Bill |
From: Bill W. <bi...@go...> - 2012-02-29 04:24:18
|
Oops. While I was writing this Vaughan made another commit addressing this bug. -- Bill On 28/02/2012, at 11:21 PM, Bill Wharrie wrote: > > On 28/02/2012, at 7:34 PM, Vaughan Johnson wrote: >> >> > [snip] > >> BAD things! >> >> I trapped the places where it was doing null derefs (and will commit >> those because they do at least failsafe Sequence::ConsistencyCheck() and >> Sequence::DebugPrintf()). >> >> In the debug build, when it has this error, it fails on a wxASSERT in >> WaveClip::ConvertToSampleFormat() that checks the result of >> Sequence::ConvertToSampleFormat(). >> >> That wxASSERT doesn't do anything in release build, but Audacity still >> crashes. So I'll get to work on debugging >> Sequence::ConvertToSampleFormat(). :-( >> >> - V > > My steps still crash, but in a different place. Mac nightly 03:15 Feb 29. > > 1. Set Quality to 32-bit float 44100 Hz > 2. Import any AIF or WAV with Read Directly > - the track reads "32-bit float" > 3. From Track Drop-Down menu, choose "Set Sample Format" > 16-bit PCM > 4. Crash > > Crashed Thread: 0 Dispatch queue: com.apple.main-thread > > Exception Type: EXC_BAD_ACCESS (SIGBUS) > Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 Audacity 0x001a6f8d Sequence::AppendBlock(SeqBlock*) + 77 > 1 Audacity 0x001ac1ec Sequence::Paste(long long, Sequence const*) + 3660 > 2 Audacity 0x001acd83 Sequence::Sequence(Sequence const&, DirManager*) + 211 > 3 Audacity 0x00202522 WaveClip::WaveClip(WaveClip&, DirManager*) + 258 > 4 Audacity 0x002099af WaveTrack::WaveTrack(WaveTrack&) + 367 > 5 Audacity 0x00209aa9 WaveTrack::Duplicate() + 41 > 6 Audacity 0x001ebfe8 UndoManager::PushState(TrackList*, double, double, wxString, wxString, int) + 168 > 7 Audacity 0x0019b411 AudacityProject::PushState(wxString, wxString, int) + 145 > 8 Audacity 0x0019b5f0 AudacityProject::TP_PushState(wxString, wxString, int) + 96 > 9 Audacity 0x001d321e TrackPanel::MakeParentPushState(wxString, wxString, int) + 110 > 10 Audacity 0x001e550b TrackPanel::OnFormatChange(wxCommandEvent&) + 363 > > -- Bill > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Vaughan J. <va...@au...> - 2012-02-29 06:57:24
|
On 2/28/2012 9:40 PM, Michael Chinen wrote: > On Tue, Feb 28, 2012 at 6:48 PM, Vaughan Johnson > <va...@au...> wrote: >> On 2/28/2012 4:27 PM, Bill Wharrie wrote: >>> >>> On 28/02/2012, at 6:33 PM, Vaughan Johnson wrote: >>>> >>>> >>> [snip] >>> >>>> Do the manual editors want to fix those link issues? I think they were >>>> agreed as P1, but obscure, and not worth holding up release. >>> >>> We're going to try. >>> >>> -- Bill >> >> All right, good. My fix for the Sequence::ConsistencyCheck() P1 bug, >> just committed, will not be in the Feb 29 Mac nightly build, so please >> keep me posted on that. >> >> The next 48-hour cycle should start when those are both approved. > > Nice fix, Vaughan! > I tried to look at the crash too but it wasn't so simple and I didn't > figure it out before you did. Thanks, Michael! To be complete, and I should have been more specific: * These P1 bug crashes were in Sequence::ConsistencyCheck() and its calls. * This fix was in Sequence::ConvertToSampleFormat(), back-traced from its calls to Sequence::ConsistencyCheck(). That's a higher level so I hope it may clear remaining bug 451 issues, too... Optimist. :-) > > I tested on mac and it works. Building linux rcs now and will put > them up once I verify them. > > Michael > Thanks! - V |
From: James C. <cr...@in...> - 2012-02-29 19:12:49
|
On 29/02/2012 07:01, Vaughan Johnson wrote: > * This fix was in Sequence::ConvertToSampleFormat(), back-traced from > its calls to Sequence::ConsistencyCheck(). That's a higher level so I > hope it may clear remaining bug 451 issues, too... Optimist. :-) Excellent. And the possibility it might have fixed 451 also doubly validates your/our strategy of treating it as repeatable-crash=P1 - and not trying to demote it because we are so close to deadline. After release we should look into what damage the faulty code could have done in the past in more detail. --James. |
From: Vaughan J. <va...@au...> - 2012-02-29 19:35:33
|
+1. :=) Has this fix been tested and confirmed on all platforms, at least for the new bug? That is, are we ready for the next round of RC's? (Should be started in about a half hour, after 21:00 GMT.) - Vaughan On 2/29/2012 11:12 AM, James Crook wrote: > On 29/02/2012 07:01, Vaughan Johnson wrote: >> * This fix was in Sequence::ConvertToSampleFormat(), back-traced from >> its calls to Sequence::ConsistencyCheck(). That's a higher level so I >> hope it may clear remaining bug 451 issues, too... Optimist. :-) > Excellent. And the possibility it might have fixed 451 also doubly > validates your/our strategy of treating it as repeatable-crash=P1 - and > not trying to demote it because we are so close to deadline. > > After release we should look into what damage the faulty code could have > done in the past in more detail. > > --James. > |
From: Gale A. <ga...@au...> - 2012-02-29 21:44:08
Attachments:
writing_length.png
|
Vaughan wrote: > Has this fix been tested and confirmed on all platforms, at least > for the new bug? As I understand it, it can't be QA-tested on Mac yet because the fix was made after the 03:15 GMT Mac Nightly today. I understand Michael thought the fix was OK on Mac? Anyway sadly I've found a repeatable issue on Windows 7 x64. 1 Set Quality Prefs to 16-bit 2 Import any 16-bit WAV, choose "Read Directly" 3 From Track Drop-Down menu, choose "Set Sample Format" > 32-bit float 4 Many dozens of "Length in Writing Sequence" messages appear (see attached) 5 When all messages dismissed, Play then crash. Does not happen if you copy in the WAV. Sorry, not tested on Linux yet. Gale | From Vaughan Johnson <va...@au...> | Tue, 28 Feb 2012 15:33:19 -0800 | Subject: [Audacity-quality] Repeatable crash set format to 16-bit on read directly 32-bit float WAV > On 2/28/2012 1:46 PM, ga...@au... wrote: > > > > Using audacity-win-2.0rc4 on Win 7 x64 but occurs in 1.3.14 too. > > > > 1. Import a 32-bit float, 22050 Hz mono WAV choosing "Read Directly". > > 2. From Track Drop-Down menu, choose "Set Sample Format" > > > 16-bit PCM. > > 3 Crash. > > > > To create the WAV I generated 11 seconds of white noise but > > probably anything would do. > > > > No crash if you copy in the WAV. > > > > Seen one other report of similar but could not get details from > > user. > > > > P1? > > That's the law. Glad you found it. Infrequent as it might be, it's > definitely a bug in Audacity code. > > I'm looking at the bug. Thanks, Bill, for confirming it and for your > stack info. Happens at the same place on Windows. The first block in > that loop has a null file pointer, that gets dereferenced, ergo crash. > It's easy enough to trap that and prevent the crash, and I'll do that, > because Sequence::ConsistencyCheck() should not crash, it should report > the problem. I think the real problem is in > Sequence::ConvertToSampleFormat(), before it calls > Sequence::ConsistencyCheck(). It's unfortunate this code has been so > problematic. It's in the same area as bug 451. I think we *could* apply > the same reasoning as there when I've trapped the crash(es), i.e., it > could at least be demoted from P1. But I'll let you know what happens to > the audio when I've made it crash-safe. > > > Unnerving that a P1 comes up a day before planned release. We now need > another round of RC's, so we are definitely postponing release, even if > I can get the bug fixed before nightly build for Mac. > > Plus, I'm behind on preparing the website changes. Sorry I messed up the > Download page. Gale, if you want to revert that and push it to the site, > that's fine. > > > As RM, I say we go on the 48-hour cycle, as in > http://wiki.audacityteam.org/wiki/Release_Process#Process step 7, until > we have a 48-hour cycle with no P1 or P2. We don't want to have daily > RC's -- too much overhead. > > Do the manual editors want to fix those link issues? I think they were > agreed as P1, but obscure, and not worth holding up release. > > I'm certain I can get the crashes trapped and that code committed in > time for the Mac nightly. Then we can test like crazy (continuing that > today, too!), discuss, and if okay, set the next RC's for 21:00 GMT Feb > 29, to start the 48-hour cycle. > > > - V |
From: Vaughan J. <va...@au...> - 2012-02-29 22:46:14
|
On 2/29/2012 1:43 PM, Gale Andrews wrote: > > Vaughan wrote: > >> Has this fix been tested and confirmed on all platforms, at least >> for the new bug? > > As I understand it, it can't be QA-tested on Mac yet because the fix > was made after the 03:15 GMT Mac Nightly today. I understand > Michael thought the fix was OK on Mac? > > Anyway sadly I've found a repeatable issue on Windows 7 x64. > > 1 Set Quality Prefs to 16-bit > 2 Import any 16-bit WAV, choose "Read Directly" > 3 From Track Drop-Down menu, choose "Set Sample Format" > > 32-bit float > 4 Many dozens of "Length in Writing Sequence" messages appear > (see attached) > 5 When all messages dismissed, Play then crash. > > Does not happen if you copy in the WAV. > > Sorry, not tested on Linux yet. > Darn. I'll look into it and try to fix it before the March 1 nightly. - V |
From: Vaughan J. <va...@au...> - 2012-03-01 00:52:46
|
On 2/29/2012 2:37 PM, Vaughan Johnson wrote: > On 2/29/2012 1:43 PM, Gale Andrews wrote: >> >> Vaughan wrote: >>[...] >> >> Anyway sadly I've found a repeatable issue on Windows 7 x64. >> >> 1 Set Quality Prefs to 16-bit >> 2 Import any 16-bit WAV, choose "Read Directly" >> 3 From Track Drop-Down menu, choose "Set Sample Format" > >> 32-bit float >> 4 Many dozens of "Length in Writing Sequence" messages appear >> (see attached) >> 5 When all messages dismissed, Play then crash. >> >> Does not happen if you copy in the WAV. >> >> Sorry, not tested on Linux yet. >> > > Darn. I'll look into it and try to fix it before the March 1 nightly. > Okay, I fixed it with commit r11554. In time for the nightly! And now I see that as I was working on it, several messages came in on this thread... but I want to get the news out first. Please test on other platforms. We'll shoot for next round of RC's at 21:00 GMT on March 1. - V |
From: Martyn S. <mar...@gm...> - 2012-03-01 00:12:27
|
(Note change of distribution list) On 29/02/2012 23:45, Michael Chinen wrote: > On Wed, Feb 29, 2012 at 12:37 PM, Vaughan Johnson > <va...@au...> wrote: >> On 2/29/2012 1:43 PM, Gale Andrews wrote: >>> >>> Vaughan wrote: >>> >>>> Has this fix been tested and confirmed on all platforms, at least >>>> for the new bug? >>> >>> As I understand it, it can't be QA-tested on Mac yet because the fix >>> was made after the 03:15 GMT Mac Nightly today. I understand >>> Michael thought the fix was OK on Mac? >>> >>> Anyway sadly I've found a repeatable issue on Windows 7 x64. >>> >>> 1 Set Quality Prefs to 16-bit >>> 2 Import any 16-bit WAV, choose "Read Directly" >>> 3 From Track Drop-Down menu, choose "Set Sample Format"> >>> 32-bit float >>> 4 Many dozens of "Length in Writing Sequence" messages appear >>> (see attached) >>> 5 When all messages dismissed, Play then crash. >>> >>> Does not happen if you copy in the WAV. >>> >>> Sorry, not tested on Linux yet. >>> >> >> Darn. I'll look into it and try to fix it before the March 1 nightly. > > I attempted a fix that forces the sequence to do nothing and return > before affecting the member vars in ConvertToSampleFormat (patch > attached). I thought of that but it's not a good plan. Sequences can have aliased (non-converted) and non-aliased blockfiles in them quite easily. > This fixes the crash, but there is an assert when you generate some > sound in the 32 bit track paste from the 16 bit alias to the 32 bit > track. > However, this assert is also there for other tracks of different > sample format (not just aliased), so this probably should be removed > (2nd patch). I agree with you, and have discussed this with Vaughan (but this is a bit OT). From what I recall, he doesn't think we should have clips with different properties in the same track, but I think it's OK and that the rest of the code is set up to handle that. > The code seems to work, but looking deeper it seems something could > still be wrong. > The idea to not convert aliases in ConvertToSampleFormat may be > tripping us up. I don't think so. Not remembering later that we did that is causing the problem. More before I turn in Martyn In fact, since the conversion that happens when we > copy and paste a 16 bit alias into a 32 bit clip should be done by > ConvertToSampleFormat(), I would expect the resultant behavior to be > bad, but so far it runs okay. I tried various other things - copy and > paste a 32 bit clip into a 16 bit alias and converting that to > different sample formats, and this seems to be okay. > > Since I'm not sure about it, I'll keep looking at it until I can prove > this is correct or someone comes up with a more convincing fix. In > the meantime I post the patch for review. > > Michael > > > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > > > > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Vaughan J. <va...@au...> - 2012-03-01 01:24:46
|
Hi, Martyn. Thanks for looking into this. I find I focus and debug much better without distraction, so I usually don't read email while doing so. But good to have your eyes on this, too. On 2/29/2012 4:12 PM, Martyn Shaw wrote: > (Note change of distribution list) Yes, this one is better. I started it on both, and Michael responded on -quality, but I brought those back to both. But -quality probably doesn't want to read all this. > > On 29/02/2012 23:45, Michael Chinen wrote: >> On Wed, Feb 29, 2012 at 12:37 PM, Vaughan Johnson >> <va...@au...> wrote: >>> On 2/29/2012 1:43 PM, Gale Andrews wrote: >>>>[...] >>>> Vaughan wrote: >>>> >>>>> Has this fix been tested and confirmed on all platforms, at least >>>>> for the new bug? >>>> >>>> As I understand it, it can't be QA-tested on Mac yet because the fix >>>> was made after the 03:15 GMT Mac Nightly today. I understand >>>> Michael thought the fix was OK on Mac? >>>> >>>> Anyway sadly I've found a repeatable issue on Windows 7 x64. >>>> >>>> 1 Set Quality Prefs to 16-bit >>>> 2 Import any 16-bit WAV, choose "Read Directly" >>>> 3 From Track Drop-Down menu, choose "Set Sample Format"> >>>> 32-bit float >>>> 4 Many dozens of "Length in Writing Sequence" messages appear >>>> (see attached) >>>> 5 When all messages dismissed, Play then crash. >>>> >>>> Does not happen if you copy in the WAV. >>>> >>>> Sorry, not tested on Linux yet. >>>> >>> >>> Darn. I'll look into it and try to fix it before the March 1 nightly. >> >> I attempted a fix that forces the sequence to do nothing and return >> before affecting the member vars in ConvertToSampleFormat (patch >> attached). > > I thought of that but it's not a good plan. Sequences can have > aliased (non-converted) and non-aliased blockfiles in them quite easily. > >> This fixes the crash, but there is an assert when you generate some >> sound in the 32 bit track paste from the 16 bit alias to the 32 bit >> track. >> However, this assert is also there for other tracks of different >> sample format (not just aliased), so this probably should be removed >> (2nd patch). > > I agree with you, and have discussed this with Vaughan (but this is a > bit OT). From what I recall, he doesn't think we should have clips > with different properties in the same track, but I think it's OK and > that the rest of the code is set up to handle that. I'm okay with it now, i.e., now it's mostly working. My concern was that there were a lot of glossed-over or ignored issues in the original implementation. > >> The code seems to work, but looking deeper it seems something could >> still be wrong. >> The idea to not convert aliases in ConvertToSampleFormat may be >> tripping us up. > > I don't think so. Not remembering later that we did that is causing > the problem. > > More before I turn in > Martyn Thanks! Please review my commit if you're still up. - V |
From: Martyn S. <mar...@gm...> - 2012-03-01 00:15:18
|
Saw this after my last post... On 01/03/2012 00:06, Michael Chinen wrote: > On Wed, Feb 29, 2012 at 1:45 PM, Michael Chinen<mc...@gm...> wrote: >> On Wed, Feb 29, 2012 at 12:37 PM, Vaughan Johnson >> <va...@au...> wrote: >>> On 2/29/2012 1:43 PM, Gale Andrews wrote: >>>> >>>> Vaughan wrote: >>>> >>>>> Has this fix been tested and confirmed on all platforms, at least >>>>> for the new bug? >>>> >>>> As I understand it, it can't be QA-tested on Mac yet because the fix >>>> was made after the 03:15 GMT Mac Nightly today. I understand >>>> Michael thought the fix was OK on Mac? >>>> >>>> Anyway sadly I've found a repeatable issue on Windows 7 x64. >>>> >>>> 1 Set Quality Prefs to 16-bit >>>> 2 Import any 16-bit WAV, choose "Read Directly" >>>> 3 From Track Drop-Down menu, choose "Set Sample Format"> >>>> 32-bit float >>>> 4 Many dozens of "Length in Writing Sequence" messages appear >>>> (see attached) >>>> 5 When all messages dismissed, Play then crash. >>>> >>>> Does not happen if you copy in the WAV. >>>> >>>> Sorry, not tested on Linux yet. >>>> >>> >>> Darn. I'll look into it and try to fix it before the March 1 nightly. >> >> I attempted a fix that forces the sequence to do nothing and return >> before affecting the member vars in ConvertToSampleFormat (patch >> attached). >> This fixes the crash, but there is an assert when you generate some >> sound in the 32 bit track paste from the 16 bit alias to the 32 bit >> track. >> However, this assert is also there for other tracks of different >> sample format (not just aliased), so this probably should be removed >> (2nd patch). >> >> The code seems to work, but looking deeper it seems something could >> still be wrong. >> The idea to not convert aliases in ConvertToSampleFormat may be >> tripping us up. In fact, since the conversion that happens when we >> copy and paste a 16 bit alias into a 32 bit clip should be done by >> ConvertToSampleFormat(), I would expect the resultant behavior to be >> bad, but so far it runs okay. I tried various other things - copy and >> paste a 32 bit clip into a 16 bit alias and converting that to >> different sample formats, and this seems to be okay. >> >> Since I'm not sure about it, I'll keep looking at it until I can prove >> this is correct or someone comes up with a more convincing fix. In >> the meantime I post the patch for review. > > FYI I looked more into it and these patches are certainly wrong > because sequences are not homogeneous. Indeed. > However, it doesn't crash or create bad behavior because we convert > the aliases to normal block files. But why should we do that? > I was testing with copying and pasting small blocks, so I wasn't > hitting the required blocksize for a full block needed to insert an alias. I had a similar problem to start with :-). TTFN Martyn > I'm now thinking to try a solution that just converts all the aliases > and will get back on that. > > Michael > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Michael C. <mc...@gm...> - 2012-03-01 00:34:23
|
Attached is a proposed fix that works by converting all aliases on sampleformat conversion to maintian track stability. The waveclip patch just quiets an assertion that shouldn't be there since we can paste between different formats (and this is not checked at an earlier point in the paste code). Discussion below: On Wed, Feb 29, 2012 at 2:15 PM, Martyn Shaw <mar...@gm...> wrote: > Saw this after my last post... > > [...] >> FYI I looked more into it and these patches are certainly wrong >> because sequences are not homogeneous. > > > Indeed. > > >> However, it doesn't crash or create bad behavior because we convert >> the aliases to normal block files. > > > But why should we do that? When we copy and paste from a 16 bit alias into a 32 bit track, in most cases some of the blocks need to be converted to 32 bit (at least the edges). This is done in ConvertToSampleFormat in WaveClip::Paste. If we make ConvertToSampleFormat ignore this, it won't be able to resolve the paste since Sequence::Paste expects the format to be the same (error and assert on otherwise). Also, the min/maxSamples need to be tracked differently if we allow multiple format types per sequence. There is probably a better solution, but resolving both of the above issues may be difficult given the time constraints and involve more structural changes that can destabilize. This solution should fix both cases and not have bad behavior at the cost of converting aliased files. I'm just posting it as a stop-the-bleeding fix for now, please do explore other solutions. > > >> I was testing with copying and pasting small blocks, so I wasn't >> hitting the required blocksize for a full block needed to insert an alias. > > I had a similar problem to start with :-). Yeah, I realized you guys have been working on this code so I'm probably repeating some common mistakes :). Michael |
From: Vaughan J. <va...@au...> - 2012-03-01 01:35:46
|
On 2/29/2012 4:33 PM, Michael Chinen wrote: > Attached is a proposed fix that works by converting all aliases on > sampleformat conversion to maintian track stability. > The waveclip patch just quiets an assertion that shouldn't be there > since we can paste between different formats (and this is not checked > at an earlier point in the paste code). I'm pretty sure we had a case when that caused problems. That's why the assert should remain there. > Discussion below: > > On Wed, Feb 29, 2012 at 2:15 PM, Martyn Shaw <mar...@gm...> wrote: >> Saw this after my last post... >> >> [...] >>> FYI I looked more into it and these patches are certainly wrong >>> because sequences are not homogeneous. >> >> >> Indeed. >> >> >>> However, it doesn't crash or create bad behavior because we convert >>> the aliases to normal block files. >> >> >> But why should we do that? > > When we copy and paste from a 16 bit alias into a 32 bit track, in > most cases some of the blocks need to be converted to 32 bit (at least > the edges). > This is done in ConvertToSampleFormat in WaveClip::Paste. If we make > ConvertToSampleFormat ignore this, it won't be able to resolve the > paste since Sequence::Paste expects the format to be the same (error > and assert on otherwise). > > Also, the min/maxSamples need to be tracked differently if we allow > multiple format types per sequence. I think these have been addressed in emails I just sent, and in the comment I added to Sequence::WriteXML about why we shouldn't check against mMaxSamples for AliasBlockFiles (because conversion can change mMaxSamples, but doesn't change the number of samples actually in the file). > > There is probably a better solution, but resolving both of the above > issues may be difficult given the time constraints and involve more > structural changes that can destabilize. > This solution should fix both cases and not have bad behavior at the > cost of converting aliased files. > I'm just posting it as a stop-the-bleeding fix for now, please do > explore other solutions. Thanks for your work on this! > >> >> >>> I was testing with copying and pasting small blocks, so I wasn't >>> hitting the required blocksize for a full block needed to insert an alias. >> >> I had a similar problem to start with :-). > > Yeah, I realized you guys have been working on this code so I'm > probably repeating some common mistakes :). > Hey, we're building our base of expertise, and reviewing decisions. Good stuff. - V |
From: Martyn S. <mar...@gm...> - 2012-03-01 00:59:12
|
Hi there Clearly we decided not to 'actually' convert aliased files: Sequence::ConvertToSampleFormat has // No conversion of aliased data. //v Should the user be alerted, as we're not actually converting the aliased file? // James (2011-12-01, offlist) believes this is okay because we are assuring // the user we'll do the format conversion if we turn this into a non-aliased block. // TODO: Confirm that. but we change mSampleFormat to floatSample, and then mMaxSamples as well (lines 164-169), for this Sequence. Any aliased blockfiles in the Sequence remain at the different format, and that's ok. The rest of the code is all set up to handle that, including playing, I believe. So the problem is with Sequence::WriteXML if (bb->f->GetLength() > mMaxSamples) which does not take into account there may be (possibly longer) aliased blocks around and so truncates them which later causes the crash on 'play'. This is relatively recent code, trying to to flag up the ('moon-phase') errors that some were encountering, but not considering aliased blockfiles (they weren't under discussion at the time) So I propose: Index: Sequence.cpp =================================================================== --- Sequence.cpp (revision 11553) +++ Sequence.cpp (working copy) @@ -1034,7 +1034,7 @@ SeqBlock *bb = mBlock->Item(b); // See http://bugzilla.audacityteam.org/show_bug.cgi?id=451. - if (bb->f->GetLength() > mMaxSamples) + if ( (bb->f->GetLength() > mMaxSamples) & (!bb->f->IsAlias()) ) { wxString sMsg = wxString::Format( which is a relatively small patch, and just allows them aliased blockfiles to stay there and do their thing. But I'm no expert on aliased blockfiles. HTH Martyn On 29/02/2012 22:37, Michael Chinen wrote: > On Wed, Feb 29, 2012 at 11:43 AM, Gale Andrews<ga...@au...> wrote: >> >> Vaughan wrote: >> >>> Has this fix been tested and confirmed on all platforms, at least >>> for the new bug? >> >> As I understand it, it can't be QA-tested on Mac yet because the fix >> was made after the 03:15 GMT Mac Nightly today. I understand >> Michael thought the fix was OK on Mac? >> >> Anyway sadly I've found a repeatable issue on Windows 7 x64. >> >> 1 Set Quality Prefs to 16-bit >> 2 Import any 16-bit WAV, choose "Read Directly" >> 3 From Track Drop-Down menu, choose "Set Sample Format"> >> 32-bit float >> 4 Many dozens of "Length in Writing Sequence" messages appear >> (see attached) >> 5 When all messages dismissed, Play then crash. >> >> Does not happen if you copy in the WAV. > > Looking into it. > FYI I'm on irc.freenode.net #audacity. > I'll commit if I fix it, let me know if I should post a patch instead > to compare and avoid collision if someone else is looking at it > already. > > Michael > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Vaughan J. <va...@au...> - 2012-03-01 01:39:43
|
Glad to see you came to the same conclusion, Martyn! Your message arrived about 10 minutes after I made the commit. I think that probably means you came up with the fix faster than I did! My clause is the reverse of yours, though, because there's no reason to even check the length if IsAlias() is true (sequential evaluation of &&). Also, I think something as obtuse as this needed commenting. :-) - V On 2/29/2012 4:59 PM, Martyn Shaw wrote: > Hi there > > Clearly we decided not to 'actually' convert aliased files: > Sequence::ConvertToSampleFormat has > // No conversion of aliased data. > //v Should the user be alerted, as we're not actually > converting the aliased file? > // James (2011-12-01, offlist) believes this is okay > because we are assuring > // the user we'll do the format conversion if we turn this > into a non-aliased block. > // TODO: Confirm that. > > but we change mSampleFormat to floatSample, and then mMaxSamples as > well (lines 164-169), for this Sequence. Any aliased blockfiles in > the Sequence remain at the different format, and that's ok. The rest > of the code is all set up to handle that, including playing, I believe. > > So the problem is with > Sequence::WriteXML > if (bb->f->GetLength() > mMaxSamples) > which does not take into account there may be (possibly longer) > aliased blocks around and so truncates them which later causes the > crash on 'play'. > > This is relatively recent code, trying to to flag up the > ('moon-phase') errors that some were encountering, but not considering > aliased blockfiles (they weren't under discussion at the time) > > So I propose: > > Index: Sequence.cpp > =================================================================== > --- Sequence.cpp (revision 11553) > +++ Sequence.cpp (working copy) > @@ -1034,7 +1034,7 @@ > SeqBlock *bb = mBlock->Item(b); > > // See http://bugzilla.audacityteam.org/show_bug.cgi?id=451. > - if (bb->f->GetLength() > mMaxSamples) > + if ( (bb->f->GetLength() > mMaxSamples) & (!bb->f->IsAlias()) ) > { > wxString sMsg = > wxString::Format( > > which is a relatively small patch, and just allows them aliased > blockfiles to stay there and do their thing. But I'm no expert on > aliased blockfiles. > > HTH > Martyn > > On 29/02/2012 22:37, Michael Chinen wrote: >> On Wed, Feb 29, 2012 at 11:43 AM, Gale Andrews<ga...@au...> wrote: >>> >>> Vaughan wrote: >>> >>>> Has this fix been tested and confirmed on all platforms, at least >>>> for the new bug? >>> >>> As I understand it, it can't be QA-tested on Mac yet because the fix >>> was made after the 03:15 GMT Mac Nightly today. I understand >>> Michael thought the fix was OK on Mac? >>> >>> Anyway sadly I've found a repeatable issue on Windows 7 x64. >>> >>> 1 Set Quality Prefs to 16-bit >>> 2 Import any 16-bit WAV, choose "Read Directly" >>> 3 From Track Drop-Down menu, choose "Set Sample Format"> >>> 32-bit float >>> 4 Many dozens of "Length in Writing Sequence" messages appear >>> (see attached) >>> 5 When all messages dismissed, Play then crash. >>> >>> Does not happen if you copy in the WAV. >> >> Looking into it. >> FYI I'm on irc.freenode.net #audacity. >> I'll commit if I fix it, let me know if I should post a patch instead >> to compare and avoid collision if someone else is looking at it >> already. >> >> Michael >> >> ------------------------------------------------------------------------------ >> Virtualization& Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Vaughan J. <va...@au...> - 2012-03-01 01:15:38
|
On 2/29/2012 4:06 PM, Michael Chinen wrote: > On Wed, Feb 29, 2012 at 1:45 PM, Michael Chinen <mc...@gm...> wrote: >> On Wed, Feb 29, 2012 at 12:37 PM, Vaughan Johnson >> <va...@au...> wrote: >>> On 2/29/2012 1:43 PM, Gale Andrews wrote: >>>> >>>> [...] > > FYI I looked more into it and these patches are certainly wrong > because sequences are not homogeneous. Thanks for confirming that! (Glad I remembered that was the case.) > However, it doesn't crash or create bad behavior because we convert > the aliases to normal block files. > I was testing with copying and pasting small blocks, so I wasn't > hitting the required blocksize for a full block needed to insert an alias. Ah. - V |
From: Martyn S. <mar...@gm...> - 2012-03-01 01:21:14
|
Great minds think alike, once again! TTFN Martyn On 01/03/2012 00:59, Martyn Shaw wrote: > Hi there > > Clearly we decided not to 'actually' convert aliased files: > Sequence::ConvertToSampleFormat has > // No conversion of aliased data. > //v Should the user be alerted, as we're not actually converting the > aliased file? > // James (2011-12-01, offlist) believes this is okay because we are > assuring > // the user we'll do the format conversion if we turn this into a > non-aliased block. > // TODO: Confirm that. > > but we change mSampleFormat to floatSample, and then mMaxSamples as > well (lines 164-169), for this Sequence. Any aliased blockfiles in the > Sequence remain at the different format, and that's ok. The rest of > the code is all set up to handle that, including playing, I believe. > > So the problem is with > Sequence::WriteXML > if (bb->f->GetLength() > mMaxSamples) > which does not take into account there may be (possibly longer) > aliased blocks around and so truncates them which later causes the > crash on 'play'. > > This is relatively recent code, trying to to flag up the > ('moon-phase') errors that some were encountering, but not considering > aliased blockfiles (they weren't under discussion at the time) > > So I propose: > > Index: Sequence.cpp > =================================================================== > --- Sequence.cpp (revision 11553) > +++ Sequence.cpp (working copy) > @@ -1034,7 +1034,7 @@ > SeqBlock *bb = mBlock->Item(b); > > // See http://bugzilla.audacityteam.org/show_bug.cgi?id=451. > - if (bb->f->GetLength() > mMaxSamples) > + if ( (bb->f->GetLength() > mMaxSamples) & (!bb->f->IsAlias()) ) > { > wxString sMsg = > wxString::Format( > > which is a relatively small patch, and just allows them aliased > blockfiles to stay there and do their thing. But I'm no expert on > aliased blockfiles. > > HTH > Martyn > > On 29/02/2012 22:37, Michael Chinen wrote: >> On Wed, Feb 29, 2012 at 11:43 AM, Gale >> Andrews<ga...@au...> wrote: >>> >>> Vaughan wrote: >>> >>>> Has this fix been tested and confirmed on all platforms, at least >>>> for the new bug? >>> >>> As I understand it, it can't be QA-tested on Mac yet because the fix >>> was made after the 03:15 GMT Mac Nightly today. I understand >>> Michael thought the fix was OK on Mac? >>> >>> Anyway sadly I've found a repeatable issue on Windows 7 x64. >>> >>> 1 Set Quality Prefs to 16-bit >>> 2 Import any 16-bit WAV, choose "Read Directly" >>> 3 From Track Drop-Down menu, choose "Set Sample Format"> >>> 32-bit float >>> 4 Many dozens of "Length in Writing Sequence" messages appear >>> (see attached) >>> 5 When all messages dismissed, Play then crash. >>> >>> Does not happen if you copy in the WAV. >> >> Looking into it. >> FYI I'm on irc.freenode.net #audacity. >> I'll commit if I fix it, let me know if I should post a patch instead >> to compare and avoid collision if someone else is looking at it >> already. >> >> Michael >> >> ------------------------------------------------------------------------------ >> >> Virtualization& Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality |