Re: [Audacity-devel] WaveClip mis-reporting start time
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Vaughan J. <va...@au...> - 2010-09-30 23:07:07
|
I see from recent posts that your head didn't explode, so I'm glad you went to bed. On 9/28/2010 5:25 PM, Martyn Shaw wrote: > Top-posting to myself here (others may like to skip) (or contribute)... > > Martyn, if you read the code for ControlToolBar::PlayCurrentRegion > with cutpreview true, you'll see that we are dealing with a > 'temporary' track here in the AudioIO thread, which has the 'cut' > region cut out. So the 'track' you see in the debugger is not the > track that you see drawn on the Audacity project window. > > Fair enough, I see that now, but I still get that assert in Envelope > (which I failed to fully report). > > I'm seeing in WaveTrack::GetEnvelopeValues > double startTime = t0; > double endTime = t0+tstep*bufferLen; > and have (in my current Assert) t0 as 3.6622222222222223, tstep as > 2.2675736961451248e-005 (originated as 1.0/mRate I believe, but is > probably a very little bit off) and bufferLen as 44100, giving endTime > as 4.6622222222222227 (or > 4.6622222222222223368 on my calculator). Yikes! That's alarming in itself. And from the screenshot in the original report, mOffset is not even close to 5, i.e., it's not 4.99999999_ , it's ~10% off. > clip->GetEndTime() may be calculated using slightly different double > variants of these numbers and causing the '>' to be true when really > it shouldn't (li 1718 in WT). > > Martyn, surely that's indicative of a larger problem and you shouldn't > be comparing calculated 'double' times to the last dp in this context. Yes, I think so. > Shouldn't you be looking at quantizing to sample accuracy at > whatever the relevant sample rate is? In clips and envelopes (where > envelopes relate to clips (they are used elsewhere))? > > Yes, probably, but unless the offsets of clips are always taken to be > at a whole sample (at their sampling rate), I don't see how we can fix > this in the general case. Yes, plus QUANTIZED_TIME does rounding... I was about to say we can take comfort, in this "Play Cut Preview" case, because in Release builds, the assert won't show up, and the user probably won't hear a difference. But if it's about a half second and the envelope changes dramatically in that half second, they might, right? - Vaughan > > Martyn, if you were to think about this to hard wouldn't it do your > head in and you'd start talking to yourself? > > Yes, probably. I'd better go to bed. > > TTFN > Martyn > > > On 21/09/2010 01:21, Martyn Shaw wrote: >> This one has me stumped. A simple generated wave file with a split in >> it, and the RH bit moved to the right. Bottom part of >> http://dl.dropbox.com/u/1327769/WaveClip.png. >> >> I press 'C' (I didn't know about that until recently) under debug and >> about 50% of the time get an assert (under debug). Looking at that >> screenshot >> http://dl.dropbox.com/u/1327769/WaveClip.png >> >> we see that the second clip starts at about 5s but the reported >> clip->mOffset is at 4.49...s. How can that be? >> >> The 'Call Stack' (mid left) shows where I put the breakpoint. >> >> Ideas? >> >> TTFN >> Martyn > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |