[MPlayer-dev-eng] [PATCH] fix for -srate bug

[Ed Wildgoose]

>>Why did you do this:
>>    
>>
>>>@@ -351,15 +402,34 @@
>>> src_data.data_in = input ;
>>> src_data.input_frames = BUFFER_LEN ;
>>>
>>>- src_data.src_ratio = 1.999 ;
>>>+ src_data.src_ratio = 0.4999 ;
>>>      
>>>
>
>the bandwidth test simply failed without this change
>  
>

Sure.  But why?  Haven't you now just changed the test completely from 
upsampling to downsampling?  Presumably if the test fails then there is 
something wrong with the lavc code not the existing code (since the 
existing code worked before..)

Note, please double check here, I noticed you changed the bracketing 
code and that at least I can slightly understand, this might be a 
different bit of code than you thought it was?

>>I can't quite follow your logic here?
>>    
>>
>
>as the *2 upsampling is replaced by /2 downsampling the maximum frequency 
>changes from samplingrate/2 -> /4
>  
>

Hmm, not sure on that...  Can you just double check...?

In particular, since you are now downsampling, instead of upsampling 
then I definitely think there is a bug here if you still claim to be 
keeping 99% of the bandwidth!!  Some of the assumptions in the test code 
might have been violated by changing from upsampling to downsampling 
perhaps?  (Still not quite sure what's wrong with just using lavc to 
upsample?)


>>I have been in touch with the libsamplerate author and he also agrees
>>that since you are starting and ending with 16 bit integers, then you
>>really should be seeing a 96dB limit on your results?
>>    
>>
>
>yes, thats what i would expect too, still its not what the code returns, so 
>either the rounding errors happen to be smaller then with random data or the 
>test code is plain buggy
>  
>

Well, I think we should check what you are doing with your downsampling 
stuff.  Why not upsample like the other tests? Otherwise I don't think 
your numbers are comparable?  (Although I agree the technique is identical)


>my resampler is already supported, just try -af 
>lavcresample=<samplerate>:<filter_length>:<linear_flag>:<polyphase_size>:<cutoff>
>  
>

Aha.  Interesting.  Can you provide the numbers for this filter to match 
those that were in your test? 

(Actually, without digging too deeply in the code, can you describe the 
settings here a little better?  I'm looking at av_resample_init, which 
is where I assume these are used, but for example, is linear_flag used 
to indicate linear NON bandlimited resmpling, or does it change the 
interpolator for the resampler?  (I'm looking at the code in 
av_resample, but I haven't got my head around how it is working yet). 

As an aside, can you also give me a some notes on how to resample 
multiple channels?  I am looking at the "update_ctx" parameter in the 
av_resample, but I'm not sure I understand how this is used for multiple 
channels (how does is accumulate the data for the other channels if you 
don't update?) - in any case, it always seems to function regardless of 
the flag...?


>btw, iam very interrested in any feedback about its quality especially if it 
>includes a hint on how to improve it
>  
>

Sure.  It's late here, but if you can give me some idea on the suggested 
options to equate to the tests you did before then I will do some 
testing tomorrow.

As for improvements on quality... Well, the vodoo hifi crowd think you 
can improve the quality by resampling.  The DSP crowd are divided as to 
whether you can improve quality by doing sinc interpolation on the new 
samples, or whether zero stuffing is enough...

Since you appear to be linear interpolating, then this is likely to 
explain the difference in speed against libsamplerate?  Sinc 
interpolation is pretty heavy duty stuff.  On the other hand, to be 
honest, if you don't need to sinc interpolate, then I would have thought 
that the zero stuffing would be LOADS faster than the linear 
interpolation (because you don't need to process all the coeffs anymore). 

So perhaps it's worth studying the impact of interpolation or no 
interpolation and going one way or the other...  If iinterpolation makes 
little audible difference, then I should switch to the theoretically 
better sinc interpolation for the max quality sampler, and drop it 
completely for the faster resampler...

I look forward to some testing tomorrow.  Thanks for continuing this thread!

Ed W