Audacity Forum

I much prefer to import mp3 files using FFmpeg rather than Audacity's built-in mp3 importer using the "Files of type: FFmpeg-compatible files" option. This works fine when importing a single mp3 file at a time, however if you select multiple mp3's for import, only the first one correctly imports using FFmpeg, then the rest in the queue fall back to using the built-in importer. Is this a known issue?

FFmpeg imports mp3 files in half the time it takes the built-in importer, which is a very big deal to me since I routinely import numerous mp3 files per session. The time savings really adds up, so I'm hoping this bug can be fixed in time for the next release. Thanks!

Audacity 1.3.10
FFmpeg 52.36.0
Windows XP

Strangely, on my machine, importing MP3s with Audacity's built-in importer is about 2x faster than using FFMpeg import.
The behaviour is because Audacity defaults to native import when available as this is generally more reliable across different computer platforms.
You can force Audacity to use FFMpeg by renaming the files with a .MPEG extension rather than the MP3 extension.

Thanks for the reply, Steve.

That is odd that you see the opposite results I do. On my machine, it takes approximately 20 seconds to import a 10.5 MB mp3 with the built-in importer, compared to 10 seconds using FFmpeg.

I agree that the built-in importer should be the default, but it just doesn't make any sense that I can import 5 files one-by-one during the same session with FFmpeg, but if I try to import all 5 consecutively by selecting them all at once, only the first one imports with FFmpeg, the rest switch to the built-in. Oddly, if I import another single mp3 after a multiple-file import, it will go back to FFmpeg with no problem! There is definitely some sort of bug that is causing this behavior, it just doesn't make sense that you can force FFmpeg import with individual files, but when multiple are queued up for import, only the first uses FFmpeg.

In any case, I did know about the extension trick, but I had hoped to avoid that.

goodfella wrote:it just doesn't make sense that you can force FFmpeg import with individual files, but when multiple are queued up for import, only the first uses FFmpeg.

I'll enquire about that and see if it is actually intended or an oversight.

The "change extension" workaround becomes dead easy if you use a bulk rename utility. Most media players should play MP3 files correctly even if they have a MPEG extension, but again, changing the names back to .MP3 is a trivial matter with a bulk rename application. You can also use a .MPG extension if you prefer.

BTW, whenever possible it is better to edit the original uncompressed (WAV) files rather than MP3s as the sound quality of MP3s deteriorates each time it is encoded.
For simple editing such as splitting or trimming files there is a free open source program called MP3Split http://mp3splt.sourceforge.net/mp3splt_page/home.php which can do simple edits without decoding the MP3 (hence no further loss in sound quality).

Thanks Steve, I appreciate it.

I have used the extension rename trick in the past using a bulk renaming utility, and it worked just fine. I just prefer to leave the file extension in its native form, and since I deal with hundreds of files per day, even using a bulk renaming utility it does get a bit tedious having to add two extra steps to the process (rename to mpeg, rename back to mp3). After using Audacity for years and wishing there were a way to force it to use FFmpeg by default, I only discovered the "Files of type: FFmpeg-compatible files" setting the other day by total accident. It sure seemed to be the ideal answer to my situation that I had been hoping for, except when I discovered this bug. I double checked the help manual and found this bit:

If for some reason you want to force Audacity to import AIFF, WAV, OGG, FLAC or MP3 file via FFmpeg, select those files using the "Files of type: FFmpeg-compatible files" box.

It makes no mention of any limitation when importing multiple files in one step. In fact, the wording suggests that it should work just fine when selecting multiple files.

I'm dealing with files that are native mp3, no uncompressed WAV version exists. The editing I perform on these files is in-depth and includes using effects, not just a little cutting and trimming here or there. I appreciate the last part of your post, but it does not apply to my situation.

Thanks again!

stevethefiddle wrote:

goodfella wrote:it just doesn't make sense that you can force FFmpeg import with individual files, but when multiple are queued up for import, only the first uses FFmpeg.

I'll enquire about that and see if it is actually intended or an oversight.

I suspect the problem arises from a fix we made (first released in 1.3.9) for an issue where non-MP3 files imported via drag or Recent Files caused a crash if the import filter in the file open window was set to MP3.

--- Project.cpp 26 Jul 2009 02:44:50 -0000 1.445
+++ Project.cpp 26 Jul 2009 21:38:06 -0000 1.446
Fix P2 Use different pref in Import.cpp to detect the chosen filter
and reset it afterwards to prevent Import from importing files with that
type through other means (RecentFiles or DragnDrop)

The switch from FFmpeg to the native filter for the subsequent files occurs for all the formats where we have a native filter as far as I can see. Another symptom is that if you use Recent Files or drag, you can't now force FFmpeg to be used by setting the filter to it - the native filter will always be used, even for the first file. Neither symptom was the original intention, but it depends if a solution can be found to force FFmpeg to be always used when set, without bringing back the crash.

Quick answer for you then is to roll back to 1.3.8 where you willl be able to import multiple MP3s via FFmpeg:
http://audacity.googlecode.com/files/au ... -1.3.8.exe

As for the speed differences, it seems to be a Windows/Linux difference. On my Ubuntu machine it takes 25 seconds to import a 10 MB MP3 via the native importer, as against 50 seconds for FFmpeg. On XP, the native importer takes 55 seconds and FFmpeg 25 seconds. So this wants looking at in case there is any action we could take.

Thanks for the report.



Gale

Thanks Gale, I appreciate the detailed reply.

Unfortunately, I was affected by various bugs in 1.3.8 and earlier releases that were subsequently fixed in 1.3.9 and 1.3.10, so rolling back is not an option for me. While I would love to be able to import multiple files using FFmpeg, it's not a critical issue.

The difference between Linux and Windows mp3 import times is very interesting, especially that the import times are flip-flopped and either encoder seems to take double the time of the other on each OS. How utterly strange. It would be great if a way were found to speed up the native importer in Windows, that would certainly increase productivity by cutting import times in half.

Or, perhaps an option could be added to disable the native importers and force FFmpeg import. It could either be a single option that would globally disable all native importers and force FFmpeg import full time, or it could be multiple options that would disable the native importers individually based on file type/extension. Naturally, the default would be for all native importers to be active, and for the disable options to be inactive if FFmpeg is not installed/found by Audacity. Doing so would give advanced users much greater control of the import process, without adversely affecting the bulk of users who prefer the native importers.

Interesting...I noted that 1.3.11-alpha-Jan 18 2010 was importing multiple files with FFmpeg as I expected it should, however the final release of 1.3.11 beta has reverted back to the behavior I described above. Thankfully I grabbed that nightly alpha release when I did, because it solves my issue for now, and has worked flawlessly the past couple of days. Hopefully this will become a permanent fix soon.

goodfella wrote:Interesting...I noted that 1.3.11-alpha-Jan 18 2010 was importing multiple files with FFmpeg as I expected it should, however the final release of 1.3.11 beta has reverted back to the behavior I described above. Thankfully I grabbed that nightly alpha release when I did, because it solves my issue for now, and has worked flawlessly the past couple of days. Hopefully this will become a permanent fix soon.

A developer submitted a fix which I put into 1.3.11 Alpha for testing, but it wasn't committed into 1.3.11 Beta because we didn't have the time (and in any case it hasn't fixed the problem with dragging in files - they still always use the native importer whatever your choice in the filter).

I'll keep the partial fix in the Nightly Build (now 1.3.12 Alpha) for the time being:
http://wiki.audacityteam.org/index.php? ... tly_Builds



Gale

Gale,

I just downloaded 1.3.12 RC2 for testing, and noticed the fix for FFmpeg import was removed, much to my dismay. I guess there's not much hope that it's going to make the cut for the final 1.3.12 release? I will continue to use the 1.3.12 Alpha if that is the case. Thanks!