Re: [Audacity-quality] 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: Michael C. <mc...@gm...> - 2012-03-01 00:07:12
|
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. 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. I'm now thinking to try a solution that just converts all the aliases and will get back on that. Michael |