Audacity Forum

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 ?

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

Alrighty then. Found which setting was causing the problem. It was the bit reservoir setting. We disable its usage and this was a carry over from the Blade API. But we definitely want to use it. Good articles:

http://www.hydrogenaudio.org/forums/ind ... opic=64935
http://www.hydrogenaudio.org/forums/ind ... opic=42194

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.

Leland

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?

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

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

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 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

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

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