Thread: [Audacity-quality] changes in Resample code
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Vaughan J. <va...@au...> - 2013-01-11 00:16:54
|
Rob pointed out a problem in the Resample code, where the wrong methods were being called, i.e., base class rather than intended descendant class. Result was that it used the wrong quality pref in most cases. I believe I've fixed this. Please test it, especially with regard to different quality settings. Thanks, Vaughan |
From: Rob S. <aq...@ya...> - 2013-01-12 15:33:45
|
----- Original Message ----- > From: Vaughan Johnson <va...@au...> > Rob pointed out a problem in the Resample code, where the wrong methods > were being called, i.e., base class rather than intended descendant > class. Result was that it used the wrong quality pref in most cases. > > I believe I've fixed this. Please test it, especially with regard to > different quality settings. All 4 qualities now working with const-rate: http://dl.dropbox.com/u/8835547/4qualities.png Cheers, Rob |
From: Vaughan J. <va...@au...> - 2013-01-12 21:45:53
|
Thanks for checking, Rob. Should also be fixed for any of the var-rate. - V On 1/12/2013 7:33 AM, Rob Sykes wrote: > ----- Original Message ----- > >> From: Vaughan Johnson <va...@au...> > > >> Rob pointed out a problem in the Resample code, where the wrong methods >> were being called, i.e., base class rather than intended descendant >> class. Result was that it used the wrong quality pref in most cases. >> >> I believe I've fixed this. Please test it, especially with regard to >> different quality settings. > > > All 4 qualities now working with const-rate: http://dl.dropbox.com/u/8835547/4qualities.png > > Cheers, > Rob |
From: Rob S. <aq...@ya...> - 2013-01-13 22:07:20
|
----- Original Message ----- > From: Vaughan Johnson <va...@au...> > To: aud...@li... > Cc: > 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? /Rob |
From: Vaughan J. <va...@au...> - 2013-01-13 22:40:46
|
On 1/13/2013 2:07 PM, Rob Sykes wrote: > ----- Original Message ----- > >> From: Vaughan Johnson <va...@au...> >> To: aud...@li... >> Cc: >> 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.) - Vaughan |
From: Gale A. <ga...@au...> - 2013-01-14 07:17:28
|
| From Bill Wharrie <bi...@go...> | 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 <va...@au...> wrote: > > > On 1/13/2013 2:07 PM, Rob Sykes wrote: > >> ----- Original Message ----- > >> > >>> From: Vaughan Johnson <va...@au...> > >>> To: aud...@li... > >>> Cc: > >>> 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 Audacity: 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. Thanks Gale |
From: Rob S. <aq...@ya...> - 2013-01-14 07:35:23
|
From: Gale Andrews <ga...@au...> > > >Libsamplerate has five choices in >Audacity: > >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. > >Copy of some info I just sent to Gale, off-list: Here's the situation for var-rate @ r12165: RenderPlay libsoxrVar-rate-q*Var-rate-q* libresampleHigh-q sincFast sinc libsamplerateBest sincFastest sinc * libsoxr currently has a single, dedicated quality level for var-rate resampling. >Cheers, Rob |
From: Gale A. <ga...@au...> - 2013-01-14 07:43:22
|
| From Rob Sykes <aq...@ya...> | Mon, 14 Jan 2013 07:35:10 +0000 (GMT) | Subject: [Audacity-quality] changes in Resample code > > > From: Gale Andrews <ga...@au...> > > > > > >Libsamplerate has five choices in > >Audacity: > > > >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. > > > >Copy of some info I just sent to Gale, off-list: > > Here's the situation for var-rate @ r12165: > > Render Play > libsoxrVar-rate-q* Var-rate-q* > libresampleHigh-q sinc Fast sinc > libsamplerateBest sinc Fastest sinc > > * libsoxr currently has a single, dedicated quality level for var-rate resampling. Thanks, Rob and for your testing. All seems clear now, except for which var-rate resampler Mac is going to use. Gale |
From: Vaughan J. <va...@au...> - 2013-01-14 21:00:23
|
On 1/13/2013 11:16 PM, Gale Andrews wrote: > > | From Bill Wharrie <bi...@go...> > | Sun, 13 Jan 2013 23:20:47 -0500 >> On 13/01/2013, at 5:41 PM, Vaughan Johnson <va...@au...> wrote: >>> On 1/13/2013 2:07 PM, Rob Sykes wrote: >>>>> From: Vaughan Johnson <va...@au...> >>>>> Sent: Saturday, 12 January 2013, 21:46 >>[...] >> 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. I think he was asking about how you tell from Audacity. And on Windows currently, "About Audacity" > "Build Information" shows libresample and libsamplerate "Disabled" and libsoxr "Enabled". > > Default builds on Windows and Linux now only enable libsoxr. The > aim (I think) is still to bring Mac into line. Thanks, Paul, for seeing to that. That should fix the problem Bill was having. - Vaughan |
From: Bill W. <bi...@go...> - 2013-01-14 17:27:28
|
On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: > > | From Bill Wharrie <bi...@go...> > | 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 <va...@au...> wrote: >> >>> On 1/13/2013 2:07 PM, Rob Sykes wrote: >>>> ----- Original Message ----- >>>> >>>>> From: Vaughan Johnson <va...@au...> >>>>> To: aud...@li... >>>>> Cc: >>>>> 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 > Audacity: > > 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: [Quality] LibresampleSampleRateConverter=0 DitherAlgorithm=0 LibresampleHQSampleRateConverter=1 HQDitherAlgorithm=3 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) 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 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. 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. -- Bill |
From: Vaughan J. <va...@au...> - 2013-01-14 21:48:21
|
On 1/14/2013 9:27 AM, Bill Wharrie wrote: > > On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: > >> >> | From Bill Wharrie <bi...@go...> >> | 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 <va...@au...> wrote: >>> >>>> On 1/13/2013 2:07 PM, Rob Sykes wrote: >>>>> ----- Original Message ----- >>>>> >>>>>> From: Vaughan Johnson <va...@au...> >>>>>> To: aud...@li... >>>>>> Cc: >>>>>> 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 >> Audacity: >> >> 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: > [Quality] > LibresampleSampleRateConverter=0 > DitherAlgorithm=0 > LibresampleHQSampleRateConverter=1 > HQDitherAlgorithm=3 > 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 users. >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. :-) - Vaughan |
From: Richard A. <ri...@au...> - 2013-01-14 19:52:04
|
On Mon, 14 Jan 2013 12:27:20 -0500 Bill Wharrie <bi...@go...> wrote: > On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: > > 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. If a build of Audacity has only one resampling library linked (which I view as the only sane sort of build to produce, anyone who can make the configure script do otherwise please let me know so it can be fixed), then I am confident that the settings in the preferences not withstanding, that library is used for resampling! This does not mean that settings will be written for that library if the user never opens the Preferences dialog - the settings writing code is not run, so nothing is written. > With the latest Mac nightly (which has both libresample and libsoxr > enabled): 1) Install over 2.0.2 - audacity.cfg will contain: > [Quality] > LibresampleSampleRateConverter=0 > DitherAlgorithm=0 > LibresampleHQSampleRateConverter=1 > HQDitherAlgorithm=3 > 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) I presume the latest Mac nightly missed my changes last night, which is how it gets both libraries, and I see Paul has since fixed this subsequently. You are getting confused because you think the numbers mean something, which they don't. The only meaning a resampling setting number has in the preferences is that the code in Audacity can convert it back into a specific setting for that library. They are not transferable between libraries and different values will be valid for each library. In your example above (if you used what I now believe should be the case) then you would get whatever the default High Quality algorithm is for that library in use - which would be 1 for libresample, 2 for libsoxr, and something else (it's a symbolic constant) for libsamplerate. I was tempted to make the quality settings for libsamplerate -9 and -10 just to make the point - the numbers used are not meaningful except when re-loading the preference into Audacity. > 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). Re-setting the preferences has never made the slightest difference to what resampling _library_ is used. It does remove (possibly invalid) quality settings that the previous code may have introduced, e.g. selecting a quality of 0 (when using a build with libresample) would be invalid as a quality for libsoxr (where qualities go 1 to 4). This I think was Rob's test problem - an invalid quality had got in and was being passed to libsamplerate, which was choosing it's own default as a result. As far as I know this would have been rectified if the preferences had been opened and OKed in the current build, as this would have forced a read and write of the preferences (using the default if the value was invalid). If the old prefs file still exists I would be very interested to see it if this isn't the case to work out why the wrong quality is being selected, as it is possible we need better error checking in the resample classes to cope with cases like this. Richard |
From: Vaughan J. <va...@au...> - 2013-01-14 21:59:24
|
On 1/14/2013 11:51 AM, Richard Ash wrote: > On Mon, 14 Jan 2013 12:27:20 -0500 > Bill Wharrie <bi...@go...> wrote: >> On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: >>> Also perhaps the Manual needs to mention that to be sure which >>> libsamplerate quality is used for Time Tracks, initialise Prefs. Really? We're not releasing libsamplerate. Let's just gradually obsolesce it and libresample, not increase the documentation of them. >> >> Not just for time tracks, but for any resampling operation, >> apparently. > > If a build of Audacity has only one resampling library linked (which I > view as the only sane sort of build to produce, We've heard that several times already. I don't recall seeing any whole-hearted agreement. In fact, my saying it sounded "reasonable" is the only endorsement I think you've gotten. >anyone who can make > the configure script do otherwise please let me know so it can be > fixed), "Fixed" per your opinion, which conflicts with the decision we as a group had already come to. >then I am confident that the settings in the preferences not > withstanding, that library is used for resampling! Yes, absolutely. Bill was just not clear on what cfg actually does. >This does not mean > that settings will be written for that library if the user never opens > the Preferences dialog - the settings writing code is not run, so > nothing is written. Yes, thanks. I was hoping to avoid this level of having to explain how the prefs work. Suffice to say, Bill, that was a bug that has been fixed. No 2.0.3 release user will need to reset their prefs to get libsoxr to work right. > >> With the latest Mac nightly (which has both libresample and libsoxr >> enabled): 1) Install over 2.0.2 - audacity.cfg will contain: >> [Quality] >> LibresampleSampleRateConverter=0 >> DitherAlgorithm=0 >> LibresampleHQSampleRateConverter=1 >> HQDitherAlgorithm=3 >> 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) > I presume the latest Mac nightly missed my changes last night, which is > how it gets both libraries, and I see Paul has since fixed this > subsequently. > > You are getting confused because you think the numbers mean something, > which they don't. The only meaning a resampling setting number has in > the preferences is that the code in Audacity can convert it back into a > specific setting for that library. They are not transferable between > libraries and different values will be valid for each library. Well explained. Thanks. > [...] > I was tempted to make the quality settings for libsamplerate -9 and -10 > just to make the point - the numbers used are not meaningful except > when re-loading the preference into Audacity. Without discussion, regardless that it would screw up anybody who has existing libsamplerate prefs? > >> 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). > Re-setting the preferences has never made the slightest difference to > what resampling _library_ is used. It does remove (possibly invalid) > quality settings that the previous code may have introduced, e.g. > selecting a quality of 0 (when using a build with libresample) would be > invalid as a quality for libsoxr (where qualities go 1 to 4). This I > think was Rob's test problem - an invalid quality had got in and was > being passed to libsamplerate, which was choosing it's own default as a > result. Correct, of course. The issue was just that Bill didn't know it was a previous bug that libsoxr had just used the libsamplerate keys, and that bug is fixed. - V > As far as I know this would have been rectified if the preferences had > been opened and OKed in the current build, as this would have forced a > read and write of the preferences (using the default if the value was > invalid). If the old prefs file still exists I would be very interested > to see it if this isn't the case to work out why the wrong quality is > being selected, as it is possible we need better error checking in the > resample classes to cope with cases like this. > > Richard |
From: Gale A. <ga...@au...> - 2013-01-15 06:38:10
|
| From Vaughan Johnson <va...@au...> | Mon, 14 Jan 2013 13:59:47 -0800 | Subject: [Audacity-quality] changes in Resample code > On 1/14/2013 11:51 AM, Richard Ash wrote: > > On Mon, 14 Jan 2013 12:27:20 -0500 > > Bill Wharrie <bi...@go...> wrote: > >> On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: > >>> Also perhaps the Manual needs to mention that to be sure which > >>> libsamplerate quality is used for Time Tracks, initialise Prefs. > > Really? We're not releasing libsamplerate. At the time I suggested documenting to initialise Prefs, I had not seen your comment that each resampler now has its own pair of keys. I don't think that was in any commit message but I understand that resolves the issue Rob encountered. It's true the Manual has never documented libsamplerate, the main reason being that of course we never release libsamplerate. So the Quality Prefs. page in the Manual has never shown libsamplerate options. That's correct I think. However most Linux distros use libsamplerate rather than libresample as you know. So when we revert Richard's changes I do have a concern that people building Audacity on Linux will enable only libsamplerate and end up with a build that says "Resampling Disabled" in Quality Prefs. When I compiled Audacity (pre current HEAD) on Linux with only libsamplerate enabled, there were no warnings in the ./configure output to suggest I was going to end up with a build with no resampling except for Time Tracks. I did not look in ./configure --help, but who does? So given all that, I foresee a lot of libsamplerate users looking at the Quality Prefs page for some guidance, and I think in the current "transitory" state we may well need to mention libsamplerate on the Quality Prefs. page. > Let's just gradually obsolesce it and libresample I think that is the only logical outcome of the direction we agreed to take (but Richard's idea is equally "logical" to me). > not increase the documentation of them. See above for my take on that. > >> Not just for time tracks, but for any resampling operation, > >> apparently. > > > > If a build of Audacity has only one resampling library linked (which I > > view as the only sane sort of build to produce, > > We've heard that several times already. I don't recall seeing any > whole-hearted agreement. In fact, my saying it sounded "reasonable" is > the only endorsement I think you've gotten. No, I endorsed Richard's view as a valid alternative when I wrote to Team (and just did so again above). But I happen to align with the majority view - aim to only allow libsoxr as the single resampler as soon as this is viable. Gale |
From: Steve t. F. <ste...@gm...> - 2013-01-15 07:27:59
|
On 15 January 2013 06:37, Gale Andrews <ga...@au...> wrote: > > | From Vaughan Johnson <va...@au...> > | Mon, 14 Jan 2013 13:59:47 -0800 > | Subject: [Audacity-quality] changes in Resample code >> On 1/14/2013 11:51 AM, Richard Ash wrote: >> > On Mon, 14 Jan 2013 12:27:20 -0500 >> > Bill Wharrie <bi...@go...> wrote: >> >> On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: >> >>> Also perhaps the Manual needs to mention that to be sure which >> >>> libsamplerate quality is used for Time Tracks, initialise Prefs. >> >> Really? We're not releasing libsamplerate. > > At the time I suggested documenting to initialise Prefs, I had > not seen your comment that each resampler now has its own > pair of keys. I don't think that was in any commit message but > I understand that resolves the issue Rob encountered. > > It's true the Manual has never documented libsamplerate, > the main reason being that of course we never release > libsamplerate. So the Quality Prefs. page in the Manual has > never shown libsamplerate options. That's correct I think. > > However most Linux distros use libsamplerate rather than > libresample as you know. So when we revert Richard's changes > I do have a concern that people building Audacity on Linux will > enable only libsamplerate and end up with a build that says > "Resampling Disabled" in Quality Prefs. When I compiled Audacity > (pre current HEAD) on Linux with only libsamplerate enabled, > there were no warnings in the ./configure output to suggest > I was going to end up with a build with no resampling except > for Time Tracks. I did not look in ./configure --help, but who > does? > > So given all that, I foresee a lot of libsamplerate users looking > at the Quality Prefs page for some guidance, and I think in the > current "transitory" state we may well need to mention > libsamplerate on the Quality Prefs. page. I see your reasoning Gale, but as a matter of emphasis I think it best that the documentation gives guidance to using libsox. libsamplerate should be no more than a side note to say that it has been superseded by libsoxr. Steve |
From: Gale A. <ga...@au...> - 2013-01-15 15:11:59
|
| From Steve the Fiddle <ste...@gm...> | Tue, 15 Jan 2013 07:27:52 +0000 | Subject: [Audacity-quality] changes in Resample code > On 15 January 2013 06:37, Gale Andrews <ga...@au...> wrote: > > > > | From Vaughan Johnson <va...@au...> > > | Mon, 14 Jan 2013 13:59:47 -0800 > > | Subject: [Audacity-quality] changes in Resample code > >> On 1/14/2013 11:51 AM, Richard Ash wrote: > >> > On Mon, 14 Jan 2013 12:27:20 -0500 > >> > Bill Wharrie <bi...@go...> wrote: > >> >> On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: > >> >>> Also perhaps the Manual needs to mention that to be sure which > >> >>> libsamplerate quality is used for Time Tracks, initialise Prefs. > >> > >> Really? We're not releasing libsamplerate. > > > > At the time I suggested documenting to initialise Prefs, I had > > not seen your comment that each resampler now has its own > > pair of keys. I don't think that was in any commit message but > > I understand that resolves the issue Rob encountered. > > > > It's true the Manual has never documented libsamplerate, > > the main reason being that of course we never release > > libsamplerate. So the Quality Prefs. page in the Manual has > > never shown libsamplerate options. That's correct I think. > > > > However most Linux distros use libsamplerate rather than > > libresample as you know. So when we revert Richard's changes > > I do have a concern that people building Audacity on Linux will > > enable only libsamplerate and end up with a build that says > > "Resampling Disabled" in Quality Prefs. When I compiled Audacity > > (pre current HEAD) on Linux with only libsamplerate enabled, > > there were no warnings in the ./configure output to suggest > > I was going to end up with a build with no resampling except > > for Time Tracks. I did not look in ./configure --help, but who > > does? > > > > So given all that, I foresee a lot of libsamplerate users looking > > at the Quality Prefs page for some guidance, and I think in the > > current "transitory" state we may well need to mention > > libsamplerate on the Quality Prefs. page. > > I see your reasoning Gale, but as a matter of emphasis I think it best > that the documentation gives guidance to using libsox. libsamplerate > should be no more than a side note to say that it has been superseded > by libsoxr. Yes, I only see it as a side mention. But remember these users will not see they have done anything "wrong" in enabling one of the alternative libraries (unless we are going to blatantly spell it out in the news item what happens if you don't enable libsoxr). I think they deserve the respect of a sentence to say why the Prefs say "Resampling Disabled". Gale > > Steve |
From: Vaughan J. <va...@au...> - 2013-01-16 01:54:45
|
On 1/14/2013 10:37 PM, Gale Andrews wrote: > > | From Vaughan Johnson <va...@au...> > | Mon, 14 Jan 2013 13:59:47 -0800 >> On 1/14/2013 11:51 AM, Richard Ash wrote: >>> On Mon, 14 Jan 2013 12:27:20 -0500 >>> Bill Wharrie <bi...@go...> wrote: >>>> On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: >>>>> Also perhaps the Manual needs to mention that to be sure which >>>>> libsamplerate quality is used for Time Tracks, initialise Prefs. >> >> Really? We're not releasing libsamplerate. > > [...] > > However most Linux distros use libsamplerate rather than > libresample as you know. Hmm, I knew some do, but I hadn't heard it's most. But the reason for it is that libsamplerate is better than libresample, and they can do it because it's not us distributing it, and they use the libs as part of the OS. Right? Now that we have libsoxr support, the demand for libsamplerate should decrease, I expect. >So when we revert Richard's changes > I do have a concern that people building Audacity on Linux will > enable only libsamplerate and end up with a build that says > "Resampling Disabled" in Quality Prefs. Well that's a bug. In light of that, I'm not going to revert Richard's changes for 2.0.3. From off-list discussion with Rob, there are still good reasons to separate const-rate and var-rate, at least for libsoxr. I dislike the fact that Richard's change just duplicated a lot of code, but I'll fix that when I restructure the Resample class hierarchy, post 2.0.3. Plus, it's no big deal to make it fully configurable (also post 2.0.3!), i.e., different const-rate resampler from var-rate, as opposed to Richard's change, which always uses the same resampler for both. Richard thinks that flexibility is daft, but I could see some users wanting to use libsoxr for const-rate and libsamplerate for var-rate. >[...] > So given all that, I foresee a lot of libsamplerate users looking > at the Quality Prefs page for some guidance, and I think in the > current "transitory" state we may well need to mention > libsamplerate on the Quality Prefs. page. Easier and better to do nothing. By not reverting Richard's changes, problem is solved. - V |
From: Gale A. <ga...@au...> - 2013-01-16 07:36:49
|
| From Vaughan Johnson <va...@au...> | Tue, 15 Jan 2013 17:55:03 -0800 | Subject: [Audacity-quality] changes in Resample code > On 1/14/2013 10:37 PM, Gale Andrews wrote: > > > > | From Vaughan Johnson <va...@au...> > > | Mon, 14 Jan 2013 13:59:47 -0800 > >> On 1/14/2013 11:51 AM, Richard Ash wrote: > >>> On Mon, 14 Jan 2013 12:27:20 -0500 > >>> Bill Wharrie <bi...@go...> wrote: > >>>> On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: > >>>>> Also perhaps the Manual needs to mention that to be sure which > >>>>> libsamplerate quality is used for Time Tracks, initialise Prefs. > >> > >> Really? We're not releasing libsamplerate. > > > > [...] > > > > However most Linux distros use libsamplerate rather than > > libresample as you know. > > Hmm, I knew some do, but I hadn't heard it's most. > > But the reason for it is that libsamplerate is better than libresample, > and they can do it because it's not us distributing it, and they use the > libs as part of the OS. Right? Now that we have libsoxr support, the > demand for libsamplerate should decrease, I expect. I think part of the reason is the assumed strong ethical stance of libsamplerate, as well as the high quality. But I would not only expect but hope that demand for libsamplerate would decrease, now that libsoxr is available and has speed as well as quality (slowness is a serious problem with libsamplerate on less capable machines). > >So when we revert Richard's changes > > I do have a concern that people building Audacity on Linux will > > enable only libsamplerate and end up with a build that says > > "Resampling Disabled" in Quality Prefs. > > Well that's a bug. I thought it was a direct consequence of forcing libsoxr as const-rate resampler? > In light of that, I'm not going to revert Richard's > changes for 2.0.3. From off-list discussion with Rob, there are still > good reasons to separate const-rate and var-rate, at least for libsoxr. So what is the end game now? I would guess by continuing to allow Audacity to be built with a working const-rate libsamplerate, it will take longer for the demand for libsamplerate to fall off. If so this means that we still need to address bugs with the libsamplerate implementation in Audacity (and take flack from users on slow machines where the distro uses libsamplerate). Plus we need to monitor (in so far as we can) for when demand for libsamplerate has fallen away to the point it's no longer "economic" to support it. > Plus, it's no big deal to make it fully configurable (also post 2.0.3!), > i.e., different const-rate resampler from var-rate, as opposed to > Richard's change, which always uses the same resampler for both. Richard > thinks that flexibility is daft, but I could see some users wanting to > use libsoxr for const-rate and libsamplerate for var-rate. I would assume that flexibility could impact on the intuitiveness and screen estate of the Quality Prefs (if that is how the flexibility is accessed). And if the aim is still to work towards libsoxr as the single resampling library on quality and speed grounds, I don't even see the point of adding this flexibility. > >[...] > > So given all that, I foresee a lot of libsamplerate users looking > > at the Quality Prefs page for some guidance, and I think in the > > current "transitory" state we may well need to mention > > libsamplerate on the Quality Prefs. page. > > Easier and better to do nothing. By not reverting Richard's changes, > problem is solved. Certainly this is a far nicer experience for those who enable another resampler than libsoxr, but I'm now much less clear on the eventual goal. Gale |
From: Vaughan J. <va...@au...> - 2013-01-16 08:51:06
|
On 1/15/2013 11:35 PM, Gale Andrews wrote: > | From Vaughan Johnson <va...@au...> > | Tue, 15 Jan 2013 17:55:03 -0800 >> On 1/14/2013 10:37 PM, Gale Andrews wrote: >>> | From Vaughan Johnson <va...@au...> >>> | Mon, 14 Jan 2013 13:59:47 -0800 >>>> On 1/14/2013 11:51 AM, Richard Ash wrote: >>>>> On Mon, 14 Jan 2013 12:27:20 -0500 >>>>> Bill Wharrie <bi...@go...> wrote: >>>>>> On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: >>> [...] >> But the reason for it is that libsamplerate is better than libresample, >> and they can do it because it's not us distributing it, and they use the >> libs as part of the OS. Right? Now that we have libsoxr support, the >> demand for libsamplerate should decrease, I expect. > > I think part of the reason is the assumed strong ethical stance > of libsamplerate, as well as the high quality. Assumed ethics...? Like libresample was less ethical? Are you contradicting the reasons I mentioned, or adding a small extra reason in agreement? Whatever, you have voted for superseding both with libsoxr, so let's go forward with that. > > But I would not only expect but hope that demand for libsamplerate > would decrease, now that libsoxr is available and has speed as well > as quality (slowness is a serious problem with libsamplerate on less > capable machines). Thanks. Yes, we agree, libsoxr should dominate. > > >>> So when we revert Richard's changes >>> I do have a concern that people building Audacity on Linux will >>> enable only libsamplerate and end up with a build that says >>> "Resampling Disabled" in Quality Prefs. >> >> Well that's a bug. > > I thought it was a direct consequence of forcing libsoxr as const-rate > resampler? Nope. It was direct result of making libsoxr the *only* const-rate resampler and not still allowing the other resamplers to do const-rate if their USE_* flags were on. Richard's change made any of the 3 be used for both const-rate and var-rate (each exclusively for both modes). Not reverted. > > >> In light of that, I'm not going to revert Richard's >> changes for 2.0.3. From off-list discussion with Rob, there are still >> good reasons to separate const-rate and var-rate, at least for libsoxr. > > So what is the end game now? I would guess by continuing to allow > Audacity to be built with a working const-rate libsamplerate, it will > take longer for the demand for libsamplerate to fall off. Whu-ut? These are *very* marginal. "Continuing to allow"? That's about letting a tiny percentage (<1%)of people still play with razor blades. We're releasing 2.0.3 with libsoxr for const- and var-rate, on Windows and Mac. That's about 99% of our users. If those 1%-usage-share Linux suppliers don't switch to libsoxr, it's on them. > > If so this means that we still need to address bugs with the > libsamplerate implementation in Audacity (and take flack from > users on slow machines where the distro uses libsamplerate). More reason to completely abandon it in 2.0.4. Not something to deal with for 2.0.3 so very late in the cycle, past agreed freeze date. > > Plus we need to monitor (in so far as we can) for when demand > for libsamplerate has fallen away to the point it's no longer > "economic" to support it. I say we just eliminate it in 2.0.4, and see who whines. But irrelevant to 2.0.3. > > >> Plus, it's no big deal to make it fully configurable (also post 2.0.3!), >> i.e., different const-rate resampler from var-rate, as opposed to >> Richard's change, which always uses the same resampler for both. Richard >> thinks that flexibility is daft, but I could see some users wanting to >> use libsoxr for const-rate and libsamplerate for var-rate. > > I would assume that flexibility could impact on the intuitiveness > and screen estate of the Quality Prefs (if that is how the flexibility > is accessed). That's a post-2.0.3 discussion. Let's get back to focus on 2.0.3. > > And if the aim is still to work towards libsoxr as the single > resampling library on quality and speed grounds, I don't even > see the point of adding this flexibility. Still to be proven. Rob still thinks libsoxr var-rate needs proving in the bigger user population. And hey, libsoxr is new for both const- and var-rate in the 2.0.3 release! So absolutely, we should make these decisions after we get a few *million* more users testing, with 2.0.3 release. > > >>> [...] >>> So given all that, I foresee a lot of libsamplerate users looking >>> at the Quality Prefs page for some guidance, and I think in the >>> current "transitory" state we may well need to mention >>> libsamplerate on the Quality Prefs. page. >> >> Easier and better to do nothing. By not reverting Richard's changes, >> problem is solved. > > Certainly this is a far nicer experience for those who enable > another resampler than libsoxr, but I'm now much less clear on > the eventual goal. ? Eventual goal is all-libsoxr, as several of us have voted. - V |
From: Gale A. <ga...@au...> - 2013-01-16 14:12:14
|
| From Vaughan Johnson <va...@au...> | Wed, 16 Jan 2013 00:51:27 -0800 | Subject: [Audacity-quality] changes in Resample code > On 1/15/2013 11:35 PM, Gale Andrews wrote: > > | From Vaughan Johnson <va...@au...> > > | Tue, 15 Jan 2013 17:55:03 -0800 > >> On 1/14/2013 10:37 PM, Gale Andrews wrote: > >>> | From Vaughan Johnson <va...@au...> > >>> | Mon, 14 Jan 2013 13:59:47 -0800 > >>>> On 1/14/2013 11:51 AM, Richard Ash wrote: > >>>>> On Mon, 14 Jan 2013 12:27:20 -0500 > >>>>> Bill Wharrie <bi...@go...> wrote: > >>>>>> On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: > >>> [...] > >> In light of that, I'm not going to revert Richard's > >> changes for 2.0.3. From off-list discussion with Rob, there are still > >> good reasons to separate const-rate and var-rate, at least for libsoxr. > > > > So what is the end game now? I would guess by continuing to allow > > Audacity to be built with a working const-rate libsamplerate, it will > > take longer for the demand for libsamplerate to fall off. > > Whu-ut? These are *very* marginal. "Continuing to allow"? That's about > letting a tiny percentage (<1%)of people still play with razor blades. > > We're releasing 2.0.3 with libsoxr for const- and var-rate, on Windows > and Mac. That's about 99% of our users. > > If those 1%-usage-share Linux suppliers don't switch to libsoxr, it's on > them. Does this < 1% come from the number of tarball downloads as a % of the other downloads (33000, versus 8 million or so)? Clearly the numbers of Audacity users on Linux is far higher than that when you include distro packages. Steve suggested off list that Audacity could be installed on around 20% of all Ubuntu systems, which could extrapolate to over 2 million Audacity users just on Ubuntu. This was my concern, to clarify we'll continue to make the case for libsoxr (as we continue to work on it) and hopefully influence distro maintainers to make the switch to libsoxr. > > Plus we need to monitor (in so far as we can) for when demand > > for libsamplerate has fallen away to the point it's no longer > > "economic" to support it. > > I say we just eliminate it in 2.0.4, and see who whines. > > Eventual goal is all-libsoxr, as several of us have voted. Great! But I had to ask. > Still to be proven. Rob still thinks libsoxr var-rate needs proving in > the bigger user population. > > And hey, libsoxr is new for both const- and var-rate in the 2.0.3 > release! So absolutely, we should make these decisions after we get a > few *million* more users testing, with 2.0.3 release. Yes. Many thanks to Rob for his past and future work. Gale |
From: Vaughan J. <va...@au...> - 2013-01-17 03:20:50
|
On 1/16/2013 6:11 AM, Gale Andrews wrote: > | From Vaughan Johnson <va...@au...> > | Wed, 16 Jan 2013 00:51:27 -0800 >> On 1/15/2013 11:35 PM, Gale Andrews wrote: >>> | From Vaughan Johnson <va...@au...> >>> | Tue, 15 Jan 2013 17:55:03 -0800 >>>> On 1/14/2013 10:37 PM, Gale Andrews wrote: >>>>> | From Vaughan Johnson <va...@au...> >>>>> | Mon, 14 Jan 2013 13:59:47 -0800 >>>>>> On 1/14/2013 11:51 AM, Richard Ash wrote: >>>>>>> On Mon, 14 Jan 2013 12:27:20 -0500 >>>>>>> Bill Wharrie <bi...@go...> wrote: >>>>>>>> On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: >>>>> [...] >> If those 1%-usage-share Linux suppliers don't switch to libsoxr, it's on >> them. > > Does this < 1% come from the number of tarball downloads as > a % of the other downloads (33000, versus 8 million or so)? > > Clearly the numbers of Audacity users on Linux is far higher > than that when you include distro packages. Steve suggested > off list that Audacity could be installed on around 20% of all > Ubuntu systems, which could extrapolate to over 2 million > Audacity users just on Ubuntu. The word I used was "suppliers", not "users". Distro managers should have the skills to deal with SVN instead of tarballs. So, the majority of Linux users (2m Ubuntu + however many non-Ubuntu - 33k direct downloads, right?) would have it done for them already, by distro managers. > [...] >> And hey, libsoxr is new for both const- and var-rate in the 2.0.3 >> release! So absolutely, we should make these decisions after we get a >> few *million* more users testing, with 2.0.3 release. > > Yes. Many thanks to Rob for his past and future work. Amen to that! - V |
From: Gale A. <ga...@au...> - 2013-01-17 08:12:26
|
| From Vaughan Johnson <va...@au...> | Wed, 16 Jan 2013 19:21:16 -0800 | Subject: [Audacity-quality] somehow this is now a tarball thread (was Re: changes in Resample code) > On 1/16/2013 6:11 AM, Gale Andrews wrote: > > | From Vaughan Johnson <va...@au...> > > | Wed, 16 Jan 2013 00:51:27 -0800 > >> On 1/15/2013 11:35 PM, Gale Andrews wrote: > >>> | From Vaughan Johnson <va...@au...> > >>> | Tue, 15 Jan 2013 17:55:03 -0800 > >>>> On 1/14/2013 10:37 PM, Gale Andrews wrote: > >>>>> | From Vaughan Johnson <va...@au...> > >>>>> | Mon, 14 Jan 2013 13:59:47 -0800 > >>>>>> On 1/14/2013 11:51 AM, Richard Ash wrote: > >>>>>>> On Mon, 14 Jan 2013 12:27:20 -0500 > >>>>>>> Bill Wharrie <bi...@go...> wrote: > >>>>>>>> On 14/01/2013, at 2:16 AM, Gale Andrews <ga...@au...> wrote: > >>>>> [...] > >> If those 1%-usage-share Linux suppliers don't switch to libsoxr, it's on > >> them. > > > > Does this < 1% come from the number of tarball downloads as > > a % of the other downloads (33000, versus 8 million or so)? > > > > Clearly the numbers of Audacity users on Linux is far higher > > than that when you include distro packages. Steve suggested > > off list that Audacity could be installed on around 20% of all > > Ubuntu systems, which could extrapolate to over 2 million > > Audacity users just on Ubuntu. > > The word I used was "suppliers", not "users". Distro managers should > have the skills to deal with SVN instead of tarballs. So, the majority > of Linux users (2m Ubuntu + however many non-Ubuntu - 33k direct > downloads, right?) would have it done for them already, by distro managers. I think it's a non-issue now you've reasserted the aim to only use libsoxr in future (libresample and libsamplerate cannot be enabled at all). Any distro managers who want to persist with libsamplerate after that will have to do major hackage or stay with the last version that let you enable libsamplerate. It may be interesting to know if distro managers find it easier to package Audacity from tarballs or from SVN. I would guess the majority of tarball downloaders are users not suppliers, hence the concern over their abilities. Gale |
From: Richard A. <ri...@au...> - 2013-01-14 22:18:48
|
On Mon, 14 Jan 2013 13:59:47 -0800 Vaughan Johnson <va...@au...> wrote: > > I was tempted to make the quality settings for libsamplerate -9 and > > -10 just to make the point - the numbers used are not meaningful > > except when re-loading the preference into Audacity. > > Without discussion, regardless that it would screw up anybody who has > existing libsamplerate prefs? Not tempted to commit it - just to prove to myself that the different preferences didn't interact with each other in unintended ways by making them exclusive ranges (so never unintentionally valid). Richard |
From: Vaughan J. <va...@au...> - 2013-01-15 03:03:12
|
On 1/14/2013 2:18 PM, Richard Ash wrote: > On Mon, 14 Jan 2013 13:59:47 -0800 > Vaughan Johnson <va...@au...> wrote: > >>> I was tempted to make the quality settings for libsamplerate -9 and >>> -10 just to make the point - the numbers used are not meaningful >>> except when re-loading the preference into Audacity. >> >> Without discussion, regardless that it would screw up anybody who has >> existing libsamplerate prefs? > > Not tempted to commit it - just to prove to myself that the different > preferences didn't interact with each other in unintended ways by > making them exclusive ranges (so never unintentionally valid). Thanks. Sorry I misunderstood. Yes, "ranges" term was incorrect, but "exclusive" was not. I think your overall point is that we should be non-overlapping in those, and check for validation in each. Lots of ways to do that. That code is in progress. - Vaughan |
From: Bill W. <bi...@go...> - 2013-01-14 04:20:56
|
On 13/01/2013, at 5:41 PM, Vaughan Johnson <va...@au...> wrote: > On 1/13/2013 2:07 PM, Rob Sykes wrote: >> ----- Original Message ----- >> >>> From: Vaughan Johnson <va...@au...> >>> To: aud...@li... >>> Cc: >>> 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. -- Bill |