Re: [Audacity-devel] [Audacity-quality] Importing multiple MP3 files with FFMpeg WAS: Re: Exporting
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Gale A. <ga...@au...> - 2010-03-03 11:49:29
|
| From LRN <lr...@gm...> | Wed, 03 Mar 2010 09:09:13 +0300 | Subject: [Audacity-quality] [Audacity-devel] Importing multiple MP3 files with | FFMpeg WAS: Re: Exporting multiple MP3 files with FFMpeg > On 03.03.2010 7:25, Gale Andrews wrote: > > | From LRN <lr...@gm...> > > | Sun, 17 Jan 2010 18:14:48 +0300 > > | Subject: Exporting multiple MP3 files with FFMpeg > > > >> On 17.01.2010 16:25, Gale Andrews wrote: > >> > >>> | From Steve the Fiddle > >>> | Sat, 16 Jan 2010 17:39:55 +0000 > >>> | Subject: Exporting multiple MP3 files with FFMpeg > >>> > >>> > >>>> A user has recently reported that on their machine FFMpeg import of MP3s > >>>> is about 2x faster than the standard MP3 import method so they would > >>>> like to use FFMpeg when importing multiple files. However, when > >>>> importing multiple files and selecting "FFMpeg compatible files", the > >>>> first MP3 file is imported using FFMpeg, but every other file uses the > >>>> normal Audacity file import method. > >>> > >>> ... My assumption is that the behaviour switching away from FFmpeg after the > >>> first import was introduced in 1.3.9 when we fixed a crash importing a > >>> file by drag or recent files where the format differed from that set by > >>> the filter in the window. I've commented in situ: > >>> http://forum.audacityteam.org/viewtopic.php?f=16&t=22255&p=68248#p68248 > >>> > >> Yes, that is because the general importer does > >> gPrefs->Write(wxT("/LastOpenType"),wxT("")); > >> after > >> wxString type = gPrefs->Read(wxT("/LastOpenType"),wxT("")); > >> > >> I think it is easily fixable by moving > >> gPrefs->Write(wxT("/LastOpenType"),wxT("")); > >> somewhere lower on the stack. > >> Diff attached (tested - compiles OK and works as intended; It might be > >> necessary to make Audacity show OpenFileDialog once before starting to > >> drag'n'drop files, to clear the LastOpenType setting). CC'ing to devel- > >> I still think that passing valuable data via gPrefs is bad, but doing it > >> the other way (passing extra arguments around) is going to be even > >> worse, i think. > >> > > I've had this fix in the Windows Nightly for some time. It fixes the problem > > of unwanted switching to native import when multiple-importing files via > > File > Open or File > Import using FFmpeg. However, using File > Recent > > Files, dragging in or using Explorer "Open With" still always uses the native > > importer for me on Windows XP, however many times I first of all import > > via File > Import using FFmpeg. Any thoughts? > > At this moment i don't remember whether this is the way i intended it to > work or not (i'll take a look this evening). > > Right now the only thing i can do is ask: isn't it a bit awkward that > Audacity automatically used the last import filter you happened to use? > This was unobvious (was it even documented anywhere?) and highly > unintuitive, IMO. > > Back in the days i had an idea of a preferences section that allowed one > to change the order in which import filters are checked for > compatibility with the file being imported - that would have solved the > problem of hard-coding native importer to be of highest priority than > libavcodec or using unobvious heuristics like LastOpenType. But it would > have been unflexible. Or maybe the problem is that there are two > distinct importers with overlapping functionality, which is confusing by > itself, not to mention that there seems to be no simple/easy way to > specify which one you want to use. > > Users would (reasonably) expect Audacity to "just open the goddamn file" > the best way it could, without having to decide which importer to use > (implying that when there is a choice, the developers can choose the > best option and implement it, instead of implementing both and giving > the choice to users). Yes, I think the key is that there is no easy way to specify which importer you want to use, and that builds an expectation that Audacity will use the current one when the import method means you can't access the open or import window. And this expectation is fuelled by the Manual: "When "All files" or "All supported files" is chosen in the file types dropdown inside the file selection window, Audacity will automatically select the most appropriate importer for your file. A "native" format like WAV or MP3 will therefore use the built-in importer for that format. If this importer fails to open the file, FFmpeg will be used instead. To force Audacity to import a native file format using FFmpeg, choose "FFmpeg-compatible files" in the file types dropdown. This will disable On-Demand Loading for WAV and AIFF files." That isn't now what happens (unless you read that as meaning "only if you actually use File > Open or > Import"). People do seem to have various reasons for wanting to use FFmpeg even for native formats, and I have several people pulling my ear about this as well as the Forum complainant. Anyway, I have it as a "Review" P3 at the moment: http://bugzilla.audacityteam.org/show_bug.cgi?id=140 Thanks Gale > Well, i'll look at it anyway and will try to make it consistently use > the heuristic. > > > > > > > > > >>> and Cc'd to LRN. Perhaps he will also have some comment about the speed > >>> differences when importing. > >>> > >>> > >> What can i say, FFmpeg stands for "Fast Forward mpeg". It's fast. Though > >> i can't tell you whether that leads to quality degradation or not. You > >> could try to import the same file via Audacity's importer (libmad, isn't > >> it?) and via libavcodec, invert one of them, then mix them together and > >> see the difference. > >> > >> Actually, i just did that. Dismissing the alignment problems (fixed them > >> by shifting one of the tracks) two tracks were identical. Though this is > >> only one file, maybe there is a difference when special files are > >> imported (joint stereo, for example). > >> > > Interesting to see that libmad and libavcodec give similar results. But > > what I was really asking was why the situation was reversed on Ubuntu, > > where FFmpeg is twice as slow importing MP3s compared to the native > > importer. > > > No idea. |