Thread: [Audacity-devel] libsoxr VS libsamplerate bug
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Benjamin D. <bd...@de...> - 2013-01-19 00:08:09
|
Hi, I created a test package from the rc1 tarball and called configure with --without-libresample --with-libsamplerate=system --with-libsoxr=yes. configure told me: configure: Using SYSTEM libraries for LIBSOXR configure: disabling LIBRESAMPLE at your request configure: Using the SYSTEM libraries for LIBSAMPLERATE because you specifically requested this [...] configure: Both libsoxr and libsamplerate were requested: favouring libsoxr [...] Finished configure: [...] LIBSOXR: disabled LIBRESAMPLE: disabled LIBSAMPLERATE: using SYSTEM libraries So configure lied about favouring libsoxr, because the resulting binary was only linked against libsamplerate. There was a discussion about const-rare and var-rate sampling. Can libsoxr do both and can fully replace libsamplerate? Another question: Which resample library do you recommend distro-packager to use and why? -- Benjamin Drung Debian & Ubuntu Developer |
From: Vaughan J. <va...@au...> - 2013-01-19 03:04:10
|
Thanks, Benjamin. On 1/18/2013 4:07 PM, Benjamin Drung wrote: > Hi, > > I created a test package from the rc1 tarball and called configure with > --without-libresample --with-libsamplerate=system --with-libsoxr=yes. > configure told me: > > configure: Using SYSTEM libraries for LIBSOXR > configure: disabling LIBRESAMPLE at your request > configure: Using the SYSTEM libraries for LIBSAMPLERATE because you specifically requested this > [...] > configure: Both libsoxr and libsamplerate were requested: favouring libsoxr > [...] > Finished configure: > [...] > LIBSOXR: disabled > LIBRESAMPLE: disabled > LIBSAMPLERATE: using SYSTEM libraries > > So configure lied about favouring libsoxr, because the resulting binary > was only linked against libsamplerate. This is because of Richard's changes, and my allowing it (and subsequently fixing errors in it, I think) as I understand linux distros usually will want libsamplerate for both const-rate and var-rate. Or at least they historically have, and Richard thinks strongly that the same lib should be used for both const-rate and var-rate, at least on Linux. Rob and I have contradicted that generally, but this is no time to go further into the details of why. I think forcing a single lib for both const-rate and var-rate is acceptable for 2.0.3, because some 90-98% of our users (Windows and Mac) will not be changing the settings and will get libsoxr for both const-rate and var-rate. (Gale cited all the Linux users who get Audacity from distros rather than download, but didn't cite all the Win/Mac users who get Audacity from mirrors -- so I still think it's probably closer to 98% Win/Mac than 90%, but very dominant for Win, then Mac, obviously.) We should announce for linux users that if they set the configuration to use either libresample or libsamplerate, libsoxr will not be enabled, and we *recommend* that they switch to libsoxr for both. That is, the precedence order if modified from the standard libsoxr-only, is libresample, libsamplerate, then libsoxr. We strongly believe libsoxr const-rate is best, and want to test the var-rate. So we recommend *not* changing the configuration to use libsamplerate instead. The comments/release-note/not-sure-where about Linux configure need to be updated for this change. I changed only the source code for it, but the Mac xCode stuff defaults to libsoxr, as we want. It's another example of why committers should observe code freeze. Richard's changes have had lots of repercussions, past original deadline on Monday (for Pete's sake!). However, your build from tarball did the right thing as specified by the configure settings, as Richard's change mean that only one of the libs will be used for both const-rate and var-rate. And since the precedence order for both is libresample, libsamplerate, and libsoxr, theses lines: > LIBSOXR: disabled > LIBRESAMPLE: disabled > LIBSAMPLERATE: using SYSTEM libraries ...are accurate. So is this "configure:" progress output issue a release blocker, given it handles the configuration correctly? I think that post-2.0.4, the majority opinion is that we should be able to mix and match different libs for doing const-rate and var-rate. More changes to configure setting and USE_* flags. But I don't think that's necessary now. > > There was a discussion about const-rare and var-rate sampling. Can > libsoxr do both and can fully replace libsamplerate? Yes, and should. It does on Win and Mac, and I think in the tarball, if you build with only --with-libsoxr=yes (or --with-libsoxr=system, I don't know configure), and the other two off, i.e., --without-libresample --without-libsamplerate. > > Another question: Which resample library do you recommend > distro-packager to use and why? > In QA testing over the past couple of months, libsoxr has proven better on const-rate, and probably on var-rate. So now that Richard's change requires one lib for both, we recommend distro-packagers use libsoxr. That's what we're using everywhere else, and we'd like testing comparisons vs 2.0.2 with libsamplerate. Anybody who wants to compare them A/B on Linux, needs to do their own builds. That's how I see it, at least! Thanks, Vaughan |
From: Gale A. <ga...@au...> - 2013-01-19 12:03:47
|
| From Vaughan Johnson <va...@au...> | Fri, 18 Jan 2013 19:04:32 -0800 | Subject: [Audacity-devel] libsoxr VS libsamplerate bug > Thanks, Benjamin. > > On 1/18/2013 4:07 PM, Benjamin Drung wrote: > > Hi, > > > > I created a test package from the rc1 tarball and called configure with > > --without-libresample --with-libsamplerate=system --with-libsoxr=yes. > > configure told me: > > > > configure: Using SYSTEM libraries for LIBSOXR > > configure: disabling LIBRESAMPLE at your request > > configure: Using the SYSTEM libraries for LIBSAMPLERATE because you specifically requested this > > [...] > > configure: Both libsoxr and libsamplerate were requested: favouring libsoxr > > [...] > > Finished configure: > > [...] > > LIBSOXR: disabled > > LIBRESAMPLE: disabled > > LIBSAMPLERATE: using SYSTEM libraries > > > > So configure lied about favouring libsoxr, because the resulting binary > > was only linked against libsamplerate. > > This is because of Richard's changes, and my allowing it (and > subsequently fixing errors in it, I think) as I understand linux distros > usually will want libsamplerate for both const-rate and var-rate. Or at > least they historically have, and Richard thinks strongly that the same > lib should be used for both const-rate and var-rate, at least on Linux. > > Rob and I have contradicted that generally, but this is no time to go > further into the details of why. I think forcing a single lib for both > const-rate and var-rate is acceptable for 2.0.3, because some 90-98% of > our users (Windows and Mac) will not be changing the settings and will > get libsoxr for both const-rate and var-rate. > > (Gale cited all the Linux users who get Audacity from distros rather > than download, but didn't cite all the Win/Mac users who get Audacity > from mirrors -- so I still think it's probably closer to 98% Win/Mac > than 90%, but very dominant for Win, then Mac, obviously.) FWIW, my suspicion is that English-speaking users are predominantly downloading Audacity from google code. Users in other languages may well be downloading more from mirrors (especially German users). > We should announce for linux users that if they set the configuration to > use either libresample or libsamplerate, libsoxr will not be enabled, > and we *recommend* that they switch to libsoxr for both. > > That is, the precedence order if modified from the standard > libsoxr-only, is libresample, libsamplerate, then libsoxr. > > We strongly believe libsoxr const-rate is best, and want to test the > var-rate. So we recommend *not* changing the configuration to use > libsamplerate instead. > > The comments/release-note/not-sure-where about Linux configure need to > be updated for this change. I changed only the source code for it, but > the Mac xCode stuff defaults to libsoxr, as we want. > > It's another example of why committers should observe code freeze. > Richard's changes have had lots of repercussions, past original deadline > on Monday (for Pete's sake!). > However, your build from tarball did the right thing as specified by the > configure settings, as Richard's change mean that only one of the libs > will be used for both const-rate and var-rate. And since the precedence > order for both is libresample, libsamplerate, and libsoxr, theses lines: > > > LIBSOXR: disabled > > LIBRESAMPLE: disabled > > LIBSAMPLERATE: using SYSTEM libraries > > ...are accurate. > > So is this "configure:" progress output issue a release blocker, given > it handles the configuration correctly? README.txt says: "The SoX Resampler library (libsoxr) has replaced libresample in Audacity releases, offering both higher quality and greater speed." I didn't particularly want to get into politics, but is that strong enough? If so, and unless we want to add an INSTALL.txt file into the tarball and mention it there (which I think would be the most prominent solution), all the other places to mention it are online (so don't demand an rc2). > I think that post-2.0.4, the majority opinion is that we should be able > to mix and match different libs for doing const-rate and var-rate. I'm still like to vote -1 on that. It doesn't make sense to me if we are still moving to obsolesce libsamplerate and libresample, as was confirmed in off-list discussions. Of course this assumes there are no substantial and unresolvable problems with libsoxr var-rate (as found in testing them in Audacity releases). > > There was a discussion about const-rare and var-rate sampling. Can > > libsoxr do both and can fully replace libsamplerate? > > Yes, and should. It does on Win and Mac, and I think in the tarball, if > you build with only --with-libsoxr=yes (or --with-libsoxr=system, I > don't know configure), and the other two off, i.e., > --without-libresample --without-libsamplerate. Should not be necessary. Default ./configure in Steve's pre-rc1 tarball leaves you with only libsoxr enabled (as I said): http://audacity.238276.n2.nabble.com/Tarballs-td7557311.html#a7557314 . I have not tested rc1 yet, but this should not have changed. So, only people deliberately using non-default configure will see a problem. > > Another question: Which resample library do you recommend > > distro-packager to use and why? > > > > In QA testing over the past couple of months, libsoxr has proven better > on const-rate, and probably on var-rate. Libsamplerate is almost unusable on slower machines, so by definition on those machines libsoxr is better than libsamplerate. :=) On any machines, the amount of artefacting if you compare spectrograms of rendered time tracks shows (I believe) that libsoxr is preferable to libresample and even to libsamplerate. Is that not right, Rob? Gale > So now that Richard's change requires one lib for both, we recommend > distro-packagers use libsoxr. That's what we're using everywhere else, > and we'd like testing comparisons vs 2.0.2 with libsamplerate. > > Anybody who wants to compare them A/B on Linux, needs to do their own > builds. |
From: Gale A. <ga...@au...> - 2013-01-19 19:45:56
|
| From Rob Sykes <aq...@ya...> | Sat, 19 Jan 2013 13:39:36 +0000 (GMT) | Subject: [Audacity-devel] libsoxr VS libsamplerate bug > ----- Original Message ----- > > On any machines, the amount of artefacting if you compare > > spectrograms of rendered time tracks shows (I believe) that > > libsoxr is preferable to libresample and even to libsamplerate. > > > Yes to libresample, but there's no real difference in var-rate artefacts > compared to libsamplerate, because the artefact level is then dominated > by audacity's current var-rate rendering (this situation may change > with future audacity & libsoxr work). Thanks, Rob. How about if you compare var-rate libsoxr with a libsamplerate var-rate quality that gives you a similar speed? Is the quality still similar between the two libs? > BTW, as folk may know, many users look to http://src.infinitewave.ca/ to > judge resampler quality. So presenting a clear picture of things there > is probably a good idea. Dave Horrocks, who runs the site, is amenable > to renaming (for clarification purposes) existing results (and probably > removing out-of-date results), so there's an opportunity to do > something about the current situation, which ostensibly show audacity > performing worse in 2.0 than in a previous version. Maybe it would be good to drop the Audacity 1.3.9 entry and compare Audacity 2.0.0 libresample High-quality with libsoxr "Best" in 2.0.3? Gale |
From: Vaughan J. <va...@au...> - 2013-01-20 02:59:45
|
On 1/19/2013 4:02 AM, Gale Andrews wrote: > > | From Vaughan Johnson <va...@au...> > | Fri, 18 Jan 2013 19:04:32 -0800 > | [...] >> Rob and I have contradicted that generally, but this is no time to go >> further into the details of why. I think forcing a single lib for both >> const-rate and var-rate is acceptable for 2.0.3, because some 90-98% of >> our users (Windows and Mac) will not be changing the settings and will >> get libsoxr for both const-rate and var-rate. >> >> (Gale cited all the Linux users who get Audacity from distros rather >> than download, but didn't cite all the Win/Mac users who get Audacity >> from mirrors -- so I still think it's probably closer to 98% Win/Mac >> than 90%, but very dominant for Win, then Mac, obviously.) > > FWIW, my suspicion is that English-speaking users are predominantly > downloading Audacity from google code. >From our website, right? Yes, probably. But we simply do not have those numbers, Gale. I suspect most users who download from http://download.cnet.com/1770-20_4-0.html?query=audacity&searchtype=downloads are English speakers, and for 2.0.2, that's "5,164,916 total downloads 8,372 last week" for Windows and "206,451 total downloads 825 last week" for Mac, not to mention Audacity Portable. Mirrors are big for English and non-English speakers. And btw, for http://download.cnet.com/1770-20_4-0.html?query=audacity&searchtype=downloads, it shows "436 total downloads 22 last week". That's means that Win downloads there are 4 orders of magnitude bigger than Linux there. > > Users in other languages may well be downloading more from mirrors > (especially German users). But I think the platform usage shares are still unquestionably in low single digits for Linux. > [...] > README.txt says: > > "The SoX Resampler library (libsoxr) has replaced libresample in > Audacity releases, offering both higher quality and greater speed." > > I didn't particularly want to get into politics, but is that strong > enough? Thanks. Up to linux distro managers to dispute if they don't like it. > > If so, and unless we want to add an INSTALL.txt file into the tarball > and mention it there (which I think would be the most prominent > solution), all the other places to mention it are online (so don't > demand an rc2). Let's stay with it online, see if any confusion arises. > > >> I think that post-2.0.4, the majority opinion is that we should be able >> to mix and match different libs for doing const-rate and var-rate. > > I'm still like to vote -1 on that. It doesn't make sense to me if we > are still moving to obsolesce libsamplerate and libresample, as was > confirmed in off-list discussions. Depends on feedback from 2.0.3 (especially success of var-rate libsoxr vs libsamplerate) and progress in var-rate changes that might subsequently be implemented in libsoxr. I'm convinced libresample is toast, so fine with removing it from 2.0.4 (depending, of course, on 2.0.3 feedback). Maybe libsamplerate, too, based on 2.0.3 feedback. > > Of course this assumes there are no substantial and unresolvable > problems with libsoxr var-rate (as found in testing them in Audacity > releases). Yes, and 2.0.3 will be the first ever Audacity release supporting it. > > [...] > Libsamplerate is almost unusable on slower machines, so by definition > on those machines libsoxr is better than libsamplerate. :=) Orthogonal to quality of results. Most of us have fast machines these days. > > On any machines, the amount of artefacting if you compare > spectrograms of rendered time tracks shows (I believe) that > libsoxr is preferable to libresample and even to libsamplerate. Okay, but *hugely* wider testing, via a release, will be important info in that decision. - V |
From: Gale A. <ga...@au...> - 2013-01-20 08:15:52
|
| From Vaughan Johnson <va...@au...> | Sat, 19 Jan 2013 19:00:07 -0800 | Subject: [Audacity-devel] libsoxr VS libsamplerate bug > On 1/19/2013 4:02 AM, Gale Andrews wrote: > > > > | From Vaughan Johnson <va...@au...> > > | Fri, 18 Jan 2013 19:04:32 -0800 > > | [...] > >> Rob and I have contradicted that generally, but this is no time to go > >> further into the details of why. I think forcing a single lib for both > >> const-rate and var-rate is acceptable for 2.0.3, because some 90-98% of > >> our users (Windows and Mac) will not be changing the settings and will > >> get libsoxr for both const-rate and var-rate. > >> > >> (Gale cited all the Linux users who get Audacity from distros rather > >> than download, but didn't cite all the Win/Mac users who get Audacity > >> from mirrors -- so I still think it's probably closer to 98% Win/Mac > >> than 90%, but very dominant for Win, then Mac, obviously.) > > > > FWIW, my suspicion is that English-speaking users are predominantly > > downloading Audacity from google code. > > >From our website, right? Yes. > But we simply do not have those numbers, Gale. I suspect most users who > download from > http://download.cnet.com/1770-20_4-0.html?query=audacity&searchtype=downloads > > are English speakers, and for 2.0.2, that's "5,164,916 total downloads > 8,372 last week" for Windows and "206,451 total downloads 825 last week" > for Mac, not to mention Audacity Portable. Mirrors are big for English > and non-English speakers. I'll concede I didn't know any individual mirror would have getting on for as many Windows installer downloads as google code, so thanks for posting that. I just had anecdotal information in mind, which is when we know where a user got Audacity from, it's almost always said to be from audacity.SF.net, unless the user is outside English-speaking territories. In that case, the download site often seems to be a mirror on a domain for that country. Gale |
From: Rob S. <aq...@ya...> - 2013-01-21 08:29:22
|
----- Original Message ----- > From: Gale Andrews <ga...@au...> > How about if you compare var-rate libsoxr with a libsamplerate > var-rate quality that gives you a similar speed? Is the quality > still similar between the two libs? There isn't a libsamplerate var-rate quality that gives a greatly similar speed: libsamplerate's linear interpolation is about 2x faster than libsoxr var-rate (but quality is too low for rendering/exporting); libsamplerate's fastest sinc interpolation is slower (~10 secs vs.~ 6 secs) and has higher artefact levels (~16 bit vs. ~20 bit precision). >> BTW, as folk may know, many users look to http://src.infinitewave.ca/ to >> judge resampler quality. So presenting a clear picture of things there >> is probably a good idea. Dave Horrocks, who runs the site, is amenable >> to renaming (for clarification purposes) existing results (and probably >> removing out-of-date results) > Maybe it would be good to drop the Audacity 1.3.9 entry and compare > Audacity 2.0.0 libresample High-quality with libsoxr "Best" in 2.0.3? Okay, I'll volunteer to take this up with Dave @ infinitewave as soon as 2.0.3 is out. Cheers, Rob |
From: Vaughan J. <va...@au...> - 2013-01-21 08:34:42
|
Thanks, guys! - V On 1/21/2013 12:29 AM, Rob Sykes wrote: > ----- Original Message ----- >> From: Gale Andrews <ga...@au...> > > >> How about if you compare var-rate libsoxr with a libsamplerate >> var-rate quality that gives you a similar speed? Is the quality >> still similar between the two libs? > > > There isn't a libsamplerate var-rate quality that gives a greatly similar speed: libsamplerate's linear interpolation is about 2x faster than libsoxr var-rate (but quality is too low for rendering/exporting); libsamplerate's fastest sinc interpolation is slower (~10 secs vs.~ 6 secs) and has higher artefact levels (~16 bit vs. ~20 bit precision). > >>> BTW, as folk may know, many users look to http://src.infinitewave.ca/ to >>> judge resampler quality. So presenting a clear picture of things there >>> is probably a good idea. Dave Horrocks, who runs the site, is amenable >>> to renaming (for clarification purposes) existing results (and probably >>> removing out-of-date results) >> Maybe it would be good to drop the Audacity 1.3.9 entry and compare >> Audacity 2.0.0 libresample High-quality with libsoxr "Best" in 2.0.3? > > > Okay, I'll volunteer to take this up with Dave @ infinitewave as soon as 2.0.3 is out. > > Cheers, > Rob > |
From: Rob S. <aq...@ya...> - 2013-01-19 13:39:44
|
----- Original Message ----- > "The SoX Resampler library (libsoxr) has replaced libresample in > Audacity releases, offering both higher quality and greater speed." > > I didn't particularly want to get into politics, but is that strong > enough? Fine by me. >> I think that post-2.0.4, the majority opinion is that we should be able >> to mix and match different libs for doing const-rate and var-rate. > > I'm still like to vote -1 on that. It doesn't make sense to me if we > are still moving to obsolesce libsamplerate and libresample, as was > confirmed in off-list discussions. > > Of course this assumes there are no substantial and unresolvable > problems with libsoxr var-rate (as found in testing them in Audacity > releases). So let's wait for a little feedback on 2.0.3 before deciding the next step. > On any machines, the amount of artefacting if you compare > spectrograms of rendered time tracks shows (I believe) that > libsoxr is preferable to libresample and even to libsamplerate. Yes to libresample, but there's no real difference in var-rate artefacts compared to libsamplerate, because the artefact level is then dominated by audacity's current var-rate rendering (this situation may change with future audacity & libsoxr work). BTW, as folk may know, many users look to http://src.infinitewave.ca/ to judge resampler quality. So presenting a clear picture of things there is probably a good idea. Dave Horrocks, who runs the site, is amenable to renaming (for clarification purposes) existing results (and probably removing out-of-date results), so there's an opportunity to do something about the current situation, which ostensibly show audacity performing worse in 2.0 than in a previous version. Cheers, Rob |
From: Vaughan J. <va...@au...> - 2013-01-20 03:03:33
|
On 1/19/2013 5:39 AM, Rob Sykes wrote: >> [...] >>> I think that post-2.0.4, the majority opinion is that we should be able >>> to mix and match different libs for doing const-rate and var-rate. >> >> I'm still like to vote -1 on that. It doesn't make sense to me if we >> are still moving to obsolesce libsamplerate and libresample, as was >> confirmed in off-list discussions. >> >> Of course this assumes there are no substantial and unresolvable >> problems with libsoxr var-rate (as found in testing them in Audacity >> releases). > > > So let's wait for a little feedback on 2.0.3 before deciding the next step. :-) +1. > >> On any machines, the amount of artefacting if you compare >> spectrograms of rendered time tracks shows (I believe) that >> libsoxr is preferable to libresample and even to libsamplerate. > > > Yes to libresample, but there's no real difference in var-rate artefacts compared to libsamplerate, because the artefact level is then dominated by audacity's current var-rate rendering (this situation may change with future audacity & libsoxr work). Thanks for that point. > > BTW, as folk may know, many users look to http://src.infinitewave.ca/ to judge resampler quality. So presenting a clear picture of things there is probably a good idea. Dave Horrocks, who runs the site, is amenable to renaming (for clarification purposes) existing results (and probably removing out-of-date results), so there's an opportunity to do something about the current situation, which ostensibly show audacity performing worse in 2.0 than in a previous version. Yes, excellent reminder. Any volunteer to update him when 2.0.3 is out? :-) Thanks, Vaughan |
From: Rob S. <aq...@ya...> - 2013-02-01 07:23:36
|
----- Original Message ----- > From: Rob Sykes <aq...@ya...> > Sent: Saturday, 19 January 2013, 13:39 > BTW, as folk may know, many users look to http://src.infinitewave.ca/ to judge > resampler quality. So presenting a clear picture of things there is probably a > good idea. Dave Horrocks, who runs the site, is amenable to renaming (for > clarification purposes) existing results (and probably removing out-of-date > results), so there's an opportunity to do something about the current > situation, which ostensibly show audacity performing worse in 2.0 than in a > previous version. Dave has finally got round to putting up the results for 2.0.3, which look to me as expected. He didn't pick up on the request to remove the 1.3 results; this means that all 3 libs as used in Audacity are shown at the site (but not explicitly identified). The keen-eyed might spot that the pass-band is slightly narrower with libsoxr than libsamplerate: libsoxr's default bandwidth of 95% @ 3dB is chosen to give 0dB from DC to >20kHz @ 44100Hz sample-rate (libsamplerate has 96%; IIRC libsamplerate's website says 97%, but that was for an older version). Compared to SoX VHQ sweep graph, there is some dark-blue background noise visible (due to the 25-bit precision floats used in Audacity); the SoX result also had sox's 'steep filter' option so has a wider (99%) passband. A (good IMO) decision was made on this list some months ago not to expose a bunch of libsoxr options (including passband width) that would probably just confuse most users (I notice that one user on the forum has requested them though). Cheers, Rob |
From: Vaughan J. <va...@au...> - 2013-02-05 03:49:15
|
Congrats and thanks, Rob! - V On 1/31/2013 11:23 PM, Rob Sykes wrote: > ----- Original Message ----- > >> From: Rob Sykes <aq...@ya...> >> Sent: Saturday, 19 January 2013, 13:39 > > >> BTW, as folk may know, many users look to http://src.infinitewave.ca/ to judge >> resampler quality. So presenting a clear picture of things there is probably a >> good idea. Dave Horrocks, who runs the site, is amenable to renaming (for >> clarification purposes) existing results (and probably removing out-of-date >> results), so there's an opportunity to do something about the current >> situation, which ostensibly show audacity performing worse in 2.0 than in a >> previous version. > > > Dave has finally got round to putting up the results for 2.0.3, which look to me as expected. He didn't pick up on the request to remove the 1.3 results; this means that all 3 libs as used in Audacity are shown at the site (but not explicitly identified). > > The keen-eyed might spot that the pass-band is slightly narrower with libsoxr than libsamplerate: libsoxr's default bandwidth of 95% @ 3dB is chosen to give 0dB from DC to >20kHz @ 44100Hz sample-rate (libsamplerate has 96%; IIRC libsamplerate's website says 97%, but that was for an older version). > > Compared to SoX VHQ sweep graph, there is some dark-blue background noise visible (due to the 25-bit precision floats used in Audacity); the SoX result also had sox's 'steep filter' option so has a wider (99%) passband. A (good IMO) decision was made on this list some months ago not to expose a bunch of libsoxr options (including passband width) that would probably just confuse most users (I notice that one user on the forum has requested them though). > > Cheers, > Rob > |
From: Gale A. <ga...@au...> - 2013-02-24 05:12:17
|
| From Rob Sykes <aq...@ya...> | Fri, 1 Feb 2013 07:23:29 +0000 (GMT) | Subject: [Audacity-devel] Audacity @ infinitewave site > ----- Original Message ----- > > > From: Rob Sykes <aq...@ya...> > > Sent: Saturday, 19 January 2013, 13:39 > > > > BTW, as folk may know, many users look to http://src.infinitewave.ca/ to judge > > resampler quality. So presenting a clear picture of things there is probably a > > good idea. Dave Horrocks, who runs the site, is amenable to renaming (for > > clarification purposes) existing results (and probably removing out-of-date > > results), so there's an opportunity to do something about the current > > situation, which ostensibly show audacity performing worse in 2.0 than in a > > previous version. > > > Dave has finally got round to putting up the results for 2.0.3, which look > to me as expected. He didn't pick up on the request to remove the 1.3 > results; this means that all 3 libs as used in Audacity are shown at the > site (but not explicitly identified). > > The keen-eyed might spot that the pass-band is slightly narrower with > libsoxr than libsamplerate: libsoxr's default bandwidth of 95% @ 3dB is > chosen to give 0dB from DC to >20kHz @ 44100Hz sample-rate > (libsamplerate has 96%; IIRC libsamplerate's website says 97%, but that > was for an older version). > > Compared to SoX VHQ sweep graph, there is some dark-blue background > noise visible (due to the 25-bit precision floats used in Audacity); the > SoX result also had sox's 'steep filter' option so has a wider (99%) > passband. A (good IMO) decision was made on this list some months ago > not to expose a bunch of libsoxr options (including passband width) that > would probably just confuse most users (I notice that one user on the > forum has requested them though). I still think it was the correct decision. :=) However for very advanced users would it be possible to expose a few more libsoxr options which a user could add to audacity.cfg? If nowhere else, you could list those .cfg settings on your Wiki page about libsoxr. More generally, some programs make much more use of text editing of .ini files to tweak advanced settings than we do. To make this less risky for users, we could even have a .cfg file editor (perhaps as another tab in Preferences) that let you insert a block of text without breaking the rest of .cfg. Perhaps the editor might be preloaded with the more useful extra settings to reduce the risk further. This would be independent of a button in Prefs to "Reset Preferences". I think such a button has a very strong case notwithstanding the reset preferences checkbox we have in the Windows installer (thanks to Martyn). Gale |
From: Rob S. <aq...@ya...> - 2013-02-28 14:49:06
|
----- Original Message ----- > From: Gale Andrews <ga...@au...> > However for very advanced users would it be possible to expose > a few more libsoxr options which a user could add to audacity.cfg? > If nowhere else, you could list those .cfg settings on your Wiki > page about libsoxr. It's certainly possible, but I think that if one wants to tweak options, it's more likely to be on a case-by-case basis (dependent on the source & destination rates, on whether or not the signal already contains aliasing from previous processing or A/D conversion, and possibly on the source material). So if it's needed, perhaps the Tracks/Resample dialogue would be a better place. > More generally, some programs make much more use of text > editing of .ini files to tweak advanced settings than we do. Not keen generally, but it might make sense in some specific cases. Cheers, Rob |
From: Steve t. F. <ste...@gm...> - 2013-02-28 16:45:48
|
On 28 February 2013 13:32, Rob Sykes <aq...@ya...> wrote: > ----- Original Message ----- > >> From: Gale Andrews <ga...@au...> > >> However for very advanced users would it be possible to expose >> a few more libsoxr options which a user could add to audacity.cfg? >> If nowhere else, you could list those .cfg settings on your Wiki >> page about libsoxr. > > It's certainly possible, but I think that if one wants to tweak options, it's more likely to be on a case-by-case basis (dependent on the source & destination rates, on whether or not the signal already contains aliasing from previous processing or A/D conversion, and possibly on the source material). So if it's needed, perhaps the Tracks/Resample dialogue would be a better place. > >> More generally, some programs make much more use of text >> editing of .ini files to tweak advanced settings than we do. > > Not keen generally, but it might make sense in some specific cases. I'm not keen either. The current settings are very well suited for "normal" user cases. If we were to offer "very advanced" options for power users, then that is likely to create a lot more complexity for the vast majority of users unless we are able to "hide" the very advanced features. In any case this would require either a lot of new documentation (duplicating SoX documentation), or some new documentation and links to the SoX documentation, but if we link to the SoX documentation then we may as well just advise users to use SoX for these features. Writing a SoX command line is likely to be no more difficult than manually editing the audacity.cfg file (and also makes available all of the other features of SoX). Also, SoX can be used with Audacity's "External Encoder" export option, so power users are able to use SoX to resample files as necessary before or after the main editing job. If that's too complicated then the additional options being suggested are probably more than the user will benefit from (imho). Steve > > Cheers, > Rob |
From: Vaughan J. <va...@au...> - 2013-03-01 01:42:47
|
On 2/28/2013 8:33 AM, Steve the Fiddle wrote: > On 28 February 2013 13:32, Rob Sykes <aq...@ya...> wrote: >> ----- Original Message ----- >> >>> From: Gale Andrews <ga...@au...> >> >>> However for very advanced users would it be possible to expose >>> a few more libsoxr options which a user could add to audacity.cfg? >>> If nowhere else, you could list those .cfg settings on your Wiki >>> page about libsoxr. >> >> It's certainly possible, but I think that if one wants to tweak options, it's more likely to be on a case-by-case basis (dependent on the source & destination rates, on whether or not the signal already contains aliasing from previous processing or A/D conversion, and possibly on the source material). So if it's needed, perhaps the Tracks/Resample dialogue would be a better place. >> >>> More generally, some programs make much more use of text >>> editing of .ini files to tweak advanced settings than we do. >> >> Not keen generally, but it might make sense in some specific cases. > > I'm not keen either. Absolutely. Having to manually edit any settings file is bush league. :-) We can and should do better than that. - V |
From: Benjamin D. <bd...@de...> - 2013-01-19 16:39:07
|
Am Freitag, den 18.01.2013, 19:04 -0800 schrieb Vaughan Johnson: > Thanks, Benjamin. > > On 1/18/2013 4:07 PM, Benjamin Drung wrote: > > Hi, > > > > I created a test package from the rc1 tarball and called configure with > > --without-libresample --with-libsamplerate=system --with-libsoxr=yes. > > configure told me: > > > > configure: Using SYSTEM libraries for LIBSOXR > > configure: disabling LIBRESAMPLE at your request > > configure: Using the SYSTEM libraries for LIBSAMPLERATE because you specifically requested this > > [...] > > configure: Both libsoxr and libsamplerate were requested: favouring libsoxr > > [...] > > Finished configure: > > [...] > > LIBSOXR: disabled > > LIBRESAMPLE: disabled > > LIBSAMPLERATE: using SYSTEM libraries > > > > So configure lied about favouring libsoxr, because the resulting binary > > was only linked against libsamplerate. > > [...] > > That is, the precedence order if modified from the standard > libsoxr-only, is libresample, libsamplerate, then libsoxr. > > So is this "configure:" progress output issue a release blocker, given > it handles the configuration correctly? So the line "configure: Both libsoxr and libsamplerate were requested: favouring libsoxr" should be fixed to tell the user the correct favoured library. It's up to you to decide if this is worth blocking the release. Correcting a configure output seems to be a low risk change. > > Another question: Which resample library do you recommend > > distro-packager to use and why? > > > > In QA testing over the past couple of months, libsoxr has proven better > on const-rate, and probably on var-rate. So now that Richard's change > requires one lib for both, we recommend distro-packagers use libsoxr. > That's what we're using everywhere else, and we'd like testing > comparisons vs 2.0.2 with libsamplerate. Thanks for the feedback from you and the other developers. I will change the Debian/Ubuntu package to use libsoxr instead of libsamplerate. The choice to use libsamplerate over libresample predates my involvement in packaging audacity. Therefore I have no insight why it was chosen. -- Benjamin Drung Debian & Ubuntu Developer |
From: Vaughan J. <va...@au...> - 2013-01-20 03:10:12
|
On 1/19/2013 8:38 AM, Benjamin Drung wrote: > Am Freitag, den 18.01.2013, 19:04 -0800 schrieb Vaughan Johnson: >> Thanks, Benjamin. >> >> On 1/18/2013 4:07 PM, Benjamin Drung wrote: >>> Hi, >>> >>> I created a test package from the rc1 tarball and called configure with >>> --without-libresample --with-libsamplerate=system --with-libsoxr=yes. >>> configure told me: >>> >>> configure: Using SYSTEM libraries for LIBSOXR >>> configure: disabling LIBRESAMPLE at your request >>> configure: Using the SYSTEM libraries for LIBSAMPLERATE because you specifically requested this >>> [...] >>> configure: Both libsoxr and libsamplerate were requested: favouring libsoxr >>> [...] >>> Finished configure: >>> [...] >>> LIBSOXR: disabled >>> LIBRESAMPLE: disabled >>> LIBSAMPLERATE: using SYSTEM libraries >>> >>> So configure lied about favouring libsoxr, because the resulting binary >>> was only linked against libsamplerate. >> >> [...] >> >> That is, the precedence order if modified from the standard >> libsoxr-only, is libresample, libsamplerate, then libsoxr. >> >> So is this "configure:" progress output issue a release blocker, given >> it handles the configuration correctly? > > So the line > "configure: Both libsoxr and libsamplerate were requested: favouring libsoxr" > should be fixed to tell the user the correct favoured library. It's up > to you to decide if this is worth blocking the release. Correcting a > configure output seems to be a low risk change. Yes, but also low importance, I believe, so I think probably not worth another release candidate 48-hour cycle (which would begin January 20). Better to fix immediately after release, I think, but I'm open to convincing otherwise. If we need another rc anyway, sure, it's good to fix it. > >>> Another question: Which resample library do you recommend >>> distro-packager to use and why? >>> >> >> In QA testing over the past couple of months, libsoxr has proven better >> on const-rate, and probably on var-rate. So now that Richard's change >> requires one lib for both, we recommend distro-packagers use libsoxr. >> That's what we're using everywhere else, and we'd like testing >> comparisons vs 2.0.2 with libsamplerate. > > Thanks for the feedback from you and the other developers. I will change > the Debian/Ubuntu package to use libsoxr instead of libsamplerate. Great! I think that will be best. Certainly give us the most feedback on libsoxr on Linux. >The > choice to use libsamplerate over libresample predates my involvement in > packaging audacity. Therefore I have no insight why it was chosen. Audacity originally used libsamplerate, but then Erik (the author) had some licensing issues, I think with the Windows build. So then Dominic wrote libresample, which Audacity can use without objection from Erik, but which I think is generally regarded (even by Dominic) as not as good as libsamplerate. That's my understanding of the history. :-) Thanks, Vaughan |