Bugzilla – Bug 340
(external program) export unreasonably slow compared to "files" export
Last modified: 2018-08-20 11:45:40 UTC
Split from bug 176 Win 7 x64 desktop/FFmpeg 0.6.1/libfaac: "M4A files" - 35 seconds (external program) - 100 seconds Win 7 x64 desktop/lame 3.98.4 "MP3 files" - 20 seconds (external program - 100 seconds
Using what I take to be a 64-bit optimised build of LAME "for 64-bit Windows only" (http://www.rarewares.org/dancer/dancer.php?f=322), I can get the command-line export time down a little, but it's still 4 times slower: Win 7 x64 desktop/lame 3.98.4 "MP3 files" - 20 seconds (external program) (lame.exe supplied by Audacity) - 100 seconds (external program) (lame.exe for 64-bit Windows supplied by rarewares) - 80 seconds
What are the options you're using? For me, the external program exports, whether 32-bi or 64-bit, run faster than library exports. I'll wait for you options before I post numbers.
(In reply to comment #2) > What are the options you're using For MP3, I was using JS VBR preset 4 for both "MP3 Files" and CLI. For M4A, defaults. Now just using defaults for MP3. That wipes 1/3rd of all timings, so the differences remain. Is this a VM you are using, Leland?
(In reply to comment #3) > (In reply to comment #2) > > What are the options you're using > For MP3, I was using JS VBR preset 4 for both "MP3 Files" and CLI. For M4A, > defaults. > > Now just using defaults for MP3. That wipes 1/3rd of all timings, so the > differences remain. Is this a VM you are using, Leland? Yepper. Have you tried it under XP? Do you get the same results?
(In reply to comment #4) "Importance" changed from REPEATABLE to REVIEW. Tests above on Windows 7 x64 were using an old machine 1.6 GHz, 2 GB RAM single core which tended to struggle with many tasks. Retested on Windows 7 x64 using 2.4 GHz Dual Core 6 GB RAM. * Using FFmpeg version SVN-r26400 (somewhere before current FFmpeg 0.8 release): over three tests with a five-minute stereo track, using identical format options, AAC, WMA and AC3 export takes the same time or a little less using (external program) than the specific encoding option such as "AC3 Files (FFmpeg)". * Using LAME 3.99.3, MP3 encoding takes the same time or a little less using (external program) than the specific "MP3 Files" option. Repeating tests on Windows 7 32-bit using 1 GHz single core 1 GB RAM, LAME and FFmpeg exports generally take the same time or are about 10% slower using (external program). One exception is AAC export which is 20% faster using (external program). As an OS comparison, Steve on Debian (Squeeze) finds the (external program) around 3 to 4 times faster than the built-in FFmpeg export options. So looks like there may be no significant case to keep this bug open, unless there is contradictory input on other Win machines. Maybe slower machines will be slightly slower with command-line export for most formats.
I stumbled across this while looking at LAME issues recently and decided to do some testing. On W10 this bug no longer appears to be valid. I can't text on Mac right now as the Export to (external program) fails - I'll follow this up elsewhere. On W10 exporting a 20 minute project usiing the default LAME command in the Export dialog jc5 WAV 6 seconds MP3 46 seconds AAC 29 seconds (external Program) 60 seconds 2.1.3 alpha WAV 6 seconds MP3 45 seconds AAC 29 seconds (external Program) 60 seconds 2.1.2 WAV 13 seconds MP3 44 seconds AAC 50 seconds (external Program) 62 seconds So comparing the MP3 export at around 45 seconds with the (external program) with default LAME at arounnd 60 seconds - it looks to me as if the difference is within tolerance - certainly not the "unreasonably slow) as in the bug title
Audacity 2.1.3 alpha, Debian Linux, LAME 3.99r Test project: 1 track, 3 minutes, 44100 Hz, 32-bit float, stereo. Internal: CBR 128: 10s VBR Standard: 9s (VBR Standard = -m j -V 2 -q 0 -lowpass 18.5 --vbr-new -b 32) External: CBR 128: 12s VBR -V2: 11s (-V2 = -m j -V 2 -q 0 -lowpass 18.5 --vbr-new -b 32) On my machine, for MP3 export, external program export is "a little slower" compared to "files" export.
My testing on W10 with audacity-2.3.0-alpha-83 10 minute stereo track MP3 export 16 seconds lame ext prog export 26 seconds this is not as extreme as Gale's earlier findings - but nit as good a Steve's M4A export 28 seconds ffmpef ext prog - failed to export (this is a different issue) So we see that the lame ext prog export 26 seconds is actually quicker than the M4A - so I think acceptable. I propose closing this as NOT-A-BUG
Re comment #8 CLOSED WORKSFORME instead. 20s vs 100s as in comment 0 is arguably worth reporting as a bug, indicative that something might be wrong somewhere. 16s vs 26s as in Comment 8 is too small to worry about, and 'just' indicates different software being used.
