This section is now closed.
Forum rules
Audacity 1.3.x is now obsolete. Please use the
current Audacity 2.1.x version.
Mac 0S X 10.3 and earlier are no longer supported but you can download legacy versions of Audacity for those systems
HERE.
-
steve
- Site Admin
- Posts: 80677
- Joined: Sat Dec 01, 2007 11:43 am
- Operating System: Linux *buntu
Post
by steve » Sun Mar 20, 2011 7:46 pm
Gale Andrews wrote:
Unfortunately the Audacity CLI (on tests on Windows 7 x64) is up to five time slower than using lame_enc.dll
There appear to be a whole host of optimisations available for Lame, including builds that optimised for multi-core processors, AMD processors, and 64-bit systems. How well does Audacity using a fully optimised build of Lame running through the CLI run compared with Audacity using lame_enc.dll?
If Audacity used the command line front end of Lame, could Audacity on a 64-bit system use Lame that was compiled for 64-bit machines ?
-
Leland
- Developer
- Posts: 174
- Joined: Thu Jul 26, 2007 8:55 pm
- Operating System: Please select
Post
by Leland » Thu Mar 31, 2011 3:59 am
Sorry folks. Didn't mean to abandon this. I got off onto something else and just tonight remembered this issue. I'll start looking into it again and keep y'all informed.
Leland
-
steve
- Site Admin
- Posts: 80677
- Joined: Sat Dec 01, 2007 11:43 am
- Operating System: Linux *buntu
Post
by steve » Thu Mar 31, 2011 4:28 pm
Leland wrote:
You can test it out by adding "--nores" to the lame external command export and you should get a similar size to what Audacity produces.
Yes, very similar.
Leland wrote: Good articles:
Yes, thanks. They explain it very well.
Leland wrote:We disable its usage and this was a carry over from the Blade API. But we definitely want to use it.
Yes we do. Are you able to enable it?
-
Leland
- Developer
- Posts: 174
- Joined: Thu Jul 26, 2007 8:55 pm
- Operating System: Please select
Post
by Leland » Thu Mar 31, 2011 4:59 pm
steve wrote:Leland wrote:We disable its usage and this was a carry over from the Blade API. But we definitely want to use it.
Yes we do. Are you able to enable it?
Yepper, it's a very easy change.
Leland
-
Gale Andrews
- Quality Assurance
- Posts: 41761
- Joined: Fri Jul 27, 2007 12:02 am
- Operating System: Windows 10
Post
by Gale Andrews » Thu Mar 31, 2011 8:59 pm
Thanks for following up, Leland. Confirmed too on Windows on some VBR "Medium" preset exports that --nores using (external program) produces similar file size to a comparable "MP3 files" export.
steve wrote:Gale Andrews wrote:
Unfortunately the Audacity CLI (on tests on Windows 7 x64) is up to five time slower than using lame_enc.dll
There appear to be a whole host of optimisations available for Lame, including builds that optimised for multi-core processors, AMD processors, and 64-bit systems. How well does Audacity using a fully optimised build of Lame running through the CLI run compared with Audacity using lame_enc.dll?
If I test a 64-bit version of LAME through (external program) - assuming it works - I will post to
bug 340. I've so far only tested on Win 7 x64, using the Audacity-distributed LAME. However that is the LAME that most people will use on WIndows/Mac, so we ought to try and get it running as fast as possible through our command-line interface.
Gale
-
vinylivo
- Posts: 32
- Joined: Wed Mar 02, 2011 3:41 am
- Operating System: Please select
Post
by vinylivo » Thu Mar 31, 2011 9:01 pm
Hey Leland,
that would be really cool, then I don't need to run the vbr files thru mp3packer anymore
so my assumption in the thread start about the bit reservoir was right.
will this be fixed in one of the following nightly builds? and is it a change in audacity or the lame library?
very big thanks for looking into this!
-
Gale Andrews
- Quality Assurance
- Posts: 41761
- Joined: Fri Jul 27, 2007 12:02 am
- Operating System: Windows 10
Post
by Gale Andrews » Thu Mar 31, 2011 9:29 pm
Gale Andrews wrote:If I test a 64-bit version of LAME through (external program) - assuming it works - I will post to
bug 340. I've so far only tested on Win 7 x64, using the Audacity-distributed LAME.
Using what I assume to be a 64-bit optimised version of LAME, I can make the Audacity command-line export 4 times slower instead of 5 times slower:
http://bugzilla.audacityteam.org/show_bug.cgi?id=340#c1
Those timings are on export of a four-minute mono tone.
Gale
-
Leland
- Developer
- Posts: 174
- Joined: Thu Jul 26, 2007 8:55 pm
- Operating System: Please select
Post
by Leland » Thu Mar 31, 2011 10:10 pm
vinylivo wrote:Hey Leland,
that would be really cool, then I don't need to run the vbr files thru mp3packer anymore
so my assumption in the thread start about the bit reservoir was right.
will this be fixed in one of the following nightly builds? and is it a change in audacity or the lame library?
very big thanks for looking into this!
It's a simple matter of change "true" to "false" on one line. I'll make the change and see if we can get it into the nightly builds.
Leland
-
Leland
- Developer
- Posts: 174
- Joined: Thu Jul 26, 2007 8:55 pm
- Operating System: Please select
Post
by Leland » Thu Mar 31, 2011 10:21 pm
Gale Andrews wrote:Gale Andrews wrote:If I test a 64-bit version of LAME through (external program) - assuming it works - I will post to
bug 340. I've so far only tested on Win 7 x64, using the Audacity-distributed LAME.
Using what I assume to be a 64-bit optimised version of LAME, I can make the Audacity command-line export 4 times slower instead of 5 times slower:
http://bugzilla.audacityteam.org/show_bug.cgi?id=340#c1
Those timings are on export of a four-minute mono tone.
Gale
I'll look into this next. It could be (I'm TOTALLY guessing here) that there's a cost to "traverse" the 32bit -> 64bit boundary.
Leland
