Re: [Audacity-quality] [Audacity-devel] Importing multiple MP3 files with FFMpeg WAS: Re: Exporting multiple MP3 files with FFMpeg

[LRN <lr...@gm...>]

On 03.03.2010 14:49, Gale Andrews wrote:
> | 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").
>   
Now, here's the situation (assuming that my patch is applied):
Each call to ShowOpenDialog() unconditionally sets LastOpenType to the
last open type (who would have thought!):
gPrefs->Write(wxT("/LastOpenType"), mask.BeforeFirst(wxT('|')));

There are a few places where this function is called. Each one checks
for the number of selected files, and if it is equal to zero, the code does:
gPrefs->Write(wxT("/LastOpenType"),wxT(""));
that is, erases LastOpenType (restoring normal importer priority order).
Also, this is done after an import (of one or more file) is done -
either via Import->Audio or the call to OpenFiles() (seems to be an
external API function).

To allow people to drop files on Audacity (or select them from Recent
Files) and have them opened by LastOpenType, these LastOpenType cleanups
have to go.
The only question is whether selecting a different filter and canceling
the dialog will switch LastOpenType or not. On one hand, requiring a
user to actually import something with the filter reduces the number of
accidental filter switches. On the other hand, it might be undesirable
for a user to have to import something to merely switch a filter.

I'm still thinking that this trick theatens to traumatize typical (7
t-words (8 with "to") in a row! Hight score!) users, we need different
solution. Can you ask the users? What do they want?
You can make a poll, like this:
a) Dedicated preferences section that deals with import filter priority.
b) Same as (a), but different priority can be assigned to different
extensions (that is, you can have all your WAVs imported by libavcodec,
while AIFFs will be opened by libsndfile).
c) Same as (a), but without UI (can be accessed only by tweaking ini-file).
d) Use LastOpenType. Count canceled OpenFileDialog as valid when a
filter was switched in it.
e) Use LastOpenType. Ignore filter switches made in canceled OpenFileDialog.
f) Ask user for a filter each time file(s) is(are) dropped on Audacity.
Remember filters used for files in Recent Files list (don't ask for a
filter).
g) Same as (f), but LastOpenType is the filter selected by default when
a dialog asking for filter is shown.
h) Something else.

(d and e) or (f and g) can be implemented simultaneously and controlled
by a preference.