On 1/14/2013 9:27 AM, Bill Wharrie wrote:
> On 14/01/2013, at 2:16 AM, Gale Andrews <gale@...> wrote:
>> | From Bill Wharrie <billwh@...>
>> | Sun, 13 Jan 2013 23:20:47 -0500
>> | Subject: [Audacity-quality] changes in Resample code
>>> On 13/01/2013, at 5:41 PM, Vaughan Johnson <vaughan@...> wrote:
>>>> On 1/13/2013 2:07 PM, Rob Sykes wrote:
>>>>> ----- Original Message -----
>>>>>> From: Vaughan Johnson <vaughan@...>
>>>>>> To: audacity-quality@...
>>>>>> Sent: Saturday, 12 January 2013, 21:46
>>>>>> Subject: Re: [Audacity-quality] changes in Resample code
>>>>>> T hanks for checking, Rob. Should also be fixed for any of the var-rate.
>>>>> I tried exporting with a time-track & libsamplerate but the spectrogram of the result showed very high artefact levels -- I'd expect this should be libsamplerate's best quality and therefore low artefact levels. This was after a make clean so I'm fairly sure that my build was true -- can anyone else confirm this behaviour?
>>>> Did you reset your Audacity preferences before this test? If not,
>>>> because libsoxr was using the same keys as libsamplerate, libsamplerate
>>>> could be getting the pref values set for libsoxr.
>>>> (That's why I also made the change to have libsoxr use distinct
>>>> keys/defaults for its prefs. Henceforth, each resampler gets its own set
>>>> of prefs.)
>>> So how do I (as a user) know which resampler is being used? The latest Mac
>>> nightly About Audacity > Build Information shows libresample and libsoxr
>>> both "enabled". I can't find anything in Prefs where I can choose which
>>> one to use.
>> This is why we have the P1 in the Manual for Quality Prefs.
>> Default builds on Windows and Linux now only enable libsoxr. The
>> aim (I think) is still to bring Mac into line.
>> For Win and Linux now, libsoxr will thus be used for Time Tracks
>> All that needs to be clarified for Win and Linux in Quality Preferences
>> in the Manual is that when using Time Tracks, the Preference
>> choices do not apply. Instead, Time Tracks use a single rate "roughly"
>> equivalent to "High Quality". This is still quite fast for playback (it
>> seems faster than libresample on my slow netbook under Linux).
>> Rob is pretty sure that libresample Time Track rendering is correctly
>> using "High-quality" and libresample Time Track playback is using
>> "Fast". This "should" I believe be true either in Mac nightlies or if
>> someone builds Audacity on any platform and chooses to enable
>> libresample for var-rate instead of libsoxr.
>> Also Rob (latest message) seems to think libsamplerate is now using
>> a higher quality for Time Track rendering than playback, but I am
>> not sure exactly which rate. Libsamplerate has five choices in
>> ZOH Interpolator
>> Linear Interpolator
>> Fastest Sinc Interpolator
>> Medium Sinc Interpolator
>> Best Sinc Interpolator
>> Do we know which of those is used for Time Track rendering and which
>> for Time Track playback?
>> Also perhaps the Manual needs to mention that to be sure which
>> libsamplerate quality is used for Time Tracks, initialise Prefs.
> Not just for time tracks, but for any resampling operation, apparently.
> With the latest Mac nightly (which has both libresample and libsoxr enabled):
> 1) Install over 2.0.2 - audacity.cfg will contain:
> 2) Generate tone
> 3) Tracks > Resample
> 4) Quit without saving changes.
> - audacity.cfg has not changed.
> This implies that a) libresample was used to resample the track, and that quality setting 1 was used (instead of 3) or b) libsoxr was used to resample the track, and that quality setting 1 was used (instead of 3)
No it doesn't. As Richard explained, all three could cumulate, and the
cfg doesn't say anything about what's currently in the build. And if you
don't resample, then the current resampler's keys are not added. The cfg
is the wrong thing to look at.
> If the inclusion of libsoxr is one of our headline features for 2.0.3 it seems odd to require that the user reset prefs in order to use it (either at all, or at the recommended quality settings).
It's simply not the case. We are not requiring that of the user.
As soon as the user changes Quality prefs, the libsoxr keys will be
added. And before that, it will use the default (which each resampler
defines for itself.) Each resampler has its own keys and defaults, so
they do not interfere.
> It seems to me that it would be reasonable for Audacity to check the Quality section of .cfg on launch and change it to reflect the enabled resamplers.
Nope. Richard correctly explained to you how that works. Unused,
historic keys in the cfg are simply not relevant. Each build "knows"
what resampler(s) are enabled, it doesn't need to look in cfg.
And I believe the About dialog was correct in saying both libsoxr and
libresample were enabled, prior to Paul's change.
For our releases, it's always libsoxr at this point. Total non-issue for
>If the intention is that only libsoxr will be enabled, then this seems necessary, otherwise we will get the situation that Rob encountered where it appeared that the wrong quality setting was being used.
Nope, each resampler now has its own pair of keys. In an earlier
implementation (up until a few days ago), libsoxr interface code
incorrectly had just used the libsamplerate keys, so both would use the
same values, even though they meant different quality settings to
libresample than libsoxr. That bug has been fixed, and that problem
eliminated. Rob ran into the problem because he was testing
libsamplerate, but the previous implementation had the libsoxr interface
store its prefs in the libsamplerate keys, so when libsamplerate ran,
the prefs were the libsoxr values. That's why I suggested he needed to
reset his prefs.
But we've never released libsoxr, and the bug has been fixed, so no
users should ever have that problem from 2.0.3 forward.
Only those of use who have been testing with different resampler builds
before the bug was fixed might run into the problem, but we're used to
playing with razor blades. :-)