Re: [Audacity-devel] [Audacity-quality] Fwd: Re: Fw: SoX resampling

[Martyn S. <mar...@gm...>]

Hi

Only on -devel here, and this is for devs only.  Not related to if 
'range' prefs are stored.

I have found the problem with the discontinuities that we see when 
resampling!  After many hours of looking.

The problem is in Mixer::MixVariableRates where the *pos 
(&mSamplePos[i] in Mixer::Process) does not get updated correctly.

I have made a local usedInputSamples and updated it thus
       *queueStart += input_used;
       *queueLen -= input_used;
usedInputSamples += input_used;

and see that it correctly measures the number of input samples 
actually used.  This does not get set accurately in *pos, far from it.

I would have fixed this already but I have not looked into the current 
code that alters *pos.  I will try and come up with a solution in the 
next few days.

TTFN
Martyn

On 07/11/2012 01:27, Martyn Shaw wrote:
>
>
> On 06/11/2012 06:19, Rob Sykes wrote:
>> ----- Original Message -----
>>
>>> From: Vaughan Johnson <va...@au...>
>>> To: audacity-quality <aud...@li...>
>>> Cc: Audacity-Devel list <aud...@li...>
>>> Sent: Tuesday, 6 November 2012, 5:41
>>> Subject: Re: [Audacity-devel] [Audacity-quality] Fwd: Re: Fw: SoX
>>> resampling
>>>
>>> On 11/5/2012 4:16 PM, Steve the Fiddle wrote:
>>>>   On 5 November 2012 17:53, Gale Andrews <ga...@au...>
>>>> wrote:
>>>>>
>>>>>   | From Steve the Fiddle <ste...@gm...>
>>>>>   [..]
>>>>
>>>>   I've Cc'd this to devel because the next part is probably important
>>>>   for anyone fixing this:
>>>>
>>>>   ** The results are different depending on which resampling
>>>> library is used
>>> **
>>>
>>> Well, yes, they're different algorithms, right? Isn't that to be
>>> expected?
>>
>>
>> I think that the reason for the noticeable difference is due to the
>> "disjointed spectrogram" time-track bug—i.e the two libs respond to
>> discontinuities in different ways, but they should never be called
>> upon to deal with such discontinuities.
>
> I don't think that 'Time Tracks' have ever worked very well (at least
> for higher warp factors), and the fact that Rob has recently
> highlighted the problem during discussions about resampling libraries
> has led to those libraries being unfairly blamed.
>
> It looks like a much deeper problem to me.  Those sudden jumps with
> higher/lower warps look to me like the wrong audio being read out of a
> buffer, rather than a basic problem with resampling (which 'should' be
> difficult as the rate/timebase changes).  But I haven't looked into
> the code there.
>
> I've tried Time Tracks a few times and always given up with them as
> being badly implemented / not really working.  Maybe they did work in
> the +-10% range once.
>
> I see that very little changes have been made to TimeTrack.cpp/.h
> since 2003, implying nobody has really kept it up to date.
>
> So I propose turning off Time Tracks in future releases, until such
> time that somebody has given the code a good make-over.  This proposal
> would
> * remove an item that doesn't really work (for me at least)
> * reduce the arguments over which library is used for what
> * reduce prefs for users
> also it would
> * remove a 'feature' that some users love (?)
>
> An alternative to removing it would be to restrict the range to +-10%
> and so (perhaps) remove the observed problem.
>
> TTFN
> Martyn
>
>> Cheers,
>> Rob
>>
>> ------------------------------------------------------------------------------
>>
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command
>> center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>