View source for Completed: Proposal User-safe Aliasfiles

{{Proposal_Header| This proposal page is about making use of aliased audio files safe in Audacity. }}

* Currently using aliased audio (we reference it rather than copy) is the default in Audacity.
* This has caused some users to lose audio projects.  They mistakenly believe the Audacity project contains everything itself and delete the original audio.


== Proposed Feature ==
Some combination of:
* Make copy-audio (safer) the default.
** Make copying audio faster than currently.  One bottleneck may be sample rate conversion.
** '''Gale:''' Another is the Windows problem since 1.3.8 of much slower waveform drawing
** Do copying 'in the background' so that the safer mode works with on-demand.
* A warning when importing using "read directly"? This could be turned off in the warning dialog or in Warnings Preferences.  Warn the user every time they include aliased audio.
** '''Gale:''' I favour the "warning" approach (at first import of WAV/AIFF irrespective of Prefs setting), unless copy in can be done *after* OD completes - otherwise I fear the time penalty will be too great. This is my idea (more detail on the Discussion tab):  
::''' Project depends on imported files'''<br>Your preferences are set to import %s without copying in. This is very fast, but the file(s) must not be moved or deleted. <br>[ ] Always copy in uncompressed files <br>[ ] Don't show this warning again 
<ul><ul><li> [[User:Vaughan|Vaughan]] prefers "read directly" should stay as the default preference, but that warning about aliasfiles should be done at save/export. </ul></ul>
* Audacity could check if referenced aliasfiles are available and warn the user rather than blithely playing silence while simultaneously displaying a waveform. This check could be done on opening a project and a comprehensive error message displayed.
** '''Gale:''' SVN HEAD now has a warning for missing aliasfiles on project opening which Vaughan and Gale are [http://bugzilla.audacityteam.org/show_bug.cgi?id=113#c13 discussing].
* Better wording/description to "read directly" This confused me (BillW) initially. What's the opposite? Read INdirectly? ("link external file"? SD)

== Alternative Proposal ==
'''Peter - 17Feb10 - updated 24Feb10 following feedback received''' 
*'''Import:'''  this command will always properly import a copy of a file into the project whether it is compressed or un-compressed.  There will be no dependencies on external files whatsoever.
** On first use of of "Import", display an advice message that informs the user of the benefits (and risks) of Linking to alias files - this message should have an option to not be shown again if required.
** Faster copying and background copying as above in original proposal.
*'''Link:''' introduce a new command (name TBD) this will not import, but will reference external uncompressed aliased files (as the “faster” Preference option currently does).  
** On first use of "Link", display an advice message that informs the user of the safer nature of import and warning them that this takes longer - as well as warning them of the dependency risks of linking to alias files - this message too should have an option to not be shown again if required. 
**Will not link to uncompressed audio files - but will warn the user that compressed files cannot be linked but must rather be imported.
*'''Drag-and-drop:''' will switchably either Import or Link.  The current Preferences setting "safer"/"faster" would be redundant as far as the two Import/Link commands are concerned - but could be retained to influence behaviour of "drag-and-drop".
**Default shoud be set to the "safer" option for "drag and drop" - to protect inexperienced users.
**User would get warning message on first use - message depends on the mode that is set

* '''Gale:''' ''I think it could be confusing because except for WAV/AIFF the "unsafe" import command would do the same as the "safe" one. Plus, it adds menu clutter. Plus. it's pretty easy to finger slip in a routine operation and choose the "wrong" one.''
*'''Peter 22Feb10:''' ''no more confusing than the current set up surely - except in the new case it would be experienced users not newbies who can become confused.''

== Developer/QA Backing ==
*'''BillW 20Jan10:''' IMO changing the default in [http://manual.audacityteam.org/index.php?title=Import_/_Export_Preferences Import / Export Preferences] to "Make a copy of uncompressed audio files before editing (safer)" would go a long way towards shielding new users from this problem. We could then possibly dispense with "Rule #3" in [http://manual.audacityteam.org/index.php?title=Quick_Guide Audacity for the Impatient] (or wherever the "3 rules" are eventually placed).
* [[User:James|James]] - I back doing something about making alias files safer, though I am not sure exactly what until this proposal shapes up.  Making (safer) the default and better warnings (as long as they can be switched off) both sound good to me.
* '''Gale:''' I'm interested in the possibility of copying in "in the background" by default while OD proceeds, as an alternative to giving everyone a dialogue on first WAV import. On slower, fuller machines though, I doubt the time penalty versus straight OD import will be acceptable.    
'''Peter:''' I wholeheatedly support the idea of making the "Safer" option the default.  
* '''Gale:''' I am strongly against turning On-Demand off by default by the simple means of changing which radio button is default in Preferences. User will then have to find Preferences to learn there is a fast import possibility (which ultimately we want to have for all formats). Bill on a 2 GHz G5 Mac can copy in a 38-minute AIFF in 21 seconds, but on similar specification Win 7 and XP machines it takes me a minimum of 2.5 minutes to do that (with space free of 30 GB out of 65 GB). For both of us, it takes circa 30 seconds to OD-import and calculate. I've proposed on the [[Talk:Proposal User-safe Aliasfiles|discussion tab]] a possibility to force a dialogue on first WAV/AIFF import for everyone irrespective of previous preference. That would make it acceptable (to me) to have copy in as default.
*'''Peter 16Feb10''':  part of the problem lies in the use of the command word '''"Import"''' - this undoubtedly, and unsurprisingly, implies to many naive users that they are actually importing the uncompressed audio file or clip i.e. getting a copy of it in their project - whereas the current default setting does not do this for them.
*'''Peter 16Feb10''':  the other thing that foxes many naive users is that if they have removed dependent audio files they do still see the full blue waveforms in the tracks in the projects.  There is no visual cue that the audio data is missing - this is misleading for the user.


== Use Cases ==
<b>Bill 07Dec10:</b> I hope this is the right place for this.<br>There is a use case that is particular to Mac - importing directly from a CD. AFAIK Windows and Linux do not support this. Mac does this by "faking" a volume and files corresponding to the CD and tracks. Importing directly from a CD with "read directly" (on demand) simply does not work as intended. You can't click in the cross-hatch wave and get reliable playback. If you try to play from the beginning immediately after the cross-hatch appears you get stuttered playback and wave calculation slows appreciably. If you wait for the waveform to draw, when clicking and playing at various points in the wave there is a delay as the OS reads the data from the CD.<br>
Timings:
*OD import and draw wave for a 3-minute CD track: 46 seconds
*non-OD import and draw: 24 seconds.
*after OD import then save and copy-in: 45 seconds to copy in and 3 seconds to save project data.
** '''Gale 07Dec10:''' Windows can't mount an audio CD directly and I don't think Linux can. If Auacity reads a file (aliased or not) from a slow external drive (which seems to be similar in effect to what you see) then reading will be slow. I'd suggest the time to import/draw the wave under OD and the poor performance once drawn needs to be raised on -quality (which I've done) whatever we decide about OD being default.<p>Of course, copying files in at "save project" stage if you decide to do so negates most of the overall time saving of OD, though I'd argue that if you copy in when you save project you may be "done" and able to walk away. You probably don't want to make the coffee while you are importing...</p>
*Following up on this, consider the case of the Mac user who want to make a mash-up. Import CD track, eject CD, insert new CD, import track, etc. When they're done they don't really have any of that audio in their project.
*<b>A radical proposal:</b> Is it possible (and desirable) to have "copy in" the default in Mac builds? Since copy-in is <b>faster</b> on Mac than "read directly", and it solves the CD importing issue, why not?

== Details ==
'''Peter 17Feb10:'''  Supporting case for the alternative proposal.
 
I believe that the confusion and user-error arises because with “Import” we have a command that does two different things depending upon:
# whether the file to be imported is compressed or un-compressed
# an obscure setting in Preferences
And what is worse, Import often (including with the current default setting) doesn’t actually do what many users would expect it to do. 
 
Further, having one command doing distinctly differing things is bad ergonomics.

The alternative proposal will have the advantage that we will no longer need the Preferences setting of “faster” versus “safer” – but the disadvantage of introducing a new menu command. 

Key user advantages:
* It should be much clearer to the user what is going on.
* It will be harder for the naive user to make a costly mistake .
* It will not hide the “faster” functionality from the power-user.
* The documentation can become more straightforward.


'''Peter 22Feb10:''' - I have now started a workflow which involves me switching between "safer" and "faster" (I use "faster" for LP transcriptions and revert to "safer" for other work).  It becomes tedious to keep switching by repeated access to the Preferences with multiple clicks - and I can never remember which mode it is switched into (there is no visual cue).  This use-case would benefit greatly from my proposal of the two distinct commands.

== GUI Implementation Idea ==
[[User:Stevethefiddle|Stevethefiddle]] 18:10, 21 February 2010 (CST)

[[Image:Link-audio.png]]

"Import Audio" would import audio into the project (as with On Demand = off)
"Link Audio" would open a browser window called "Link Uncompressed Audio" - this would enable uncompressed file types to be linked to the project (alias files - as when currently selecting "import" with "faster" option.

The "Supported File Types" in the browser window would only show uncompressed file types for which OD loading is possible.
In the event of an attempt to "link" an MP3 or other unsupported file type, the following message would show:

[[Image:Compressed-filetype-warning.png]]

Appropriate warnings could still be shown as discussed earlier.


'''Gale: 23Feb10''' 

* In the file window that opens from "Link Audio", are you saying that there is only one filter available "WAV, AIFF, and other uncompressed types"? Or also an "All files" filter? Which is default? <p>I think the big problem here is the compressed file type warning. How many novices are going to know at this point what a compressed and uncompressed file is? What happens if they click "Yes" - do they import their MP3 anyway? If so this looks like "one command doing different things" too. And if they get to learn the "you can't" is an empty warning, they might well use this to import WAV's anyway. So I think if this is to work, "Link Audio" must be confined to supported on-Demand formats. The menu item should really say "Link to WAV" (if wxMac, "Link to WAV or AIFF"), but the problem with that is, it might encourage people who know they have a WAV to use "Link" rather than import. So how to handle the inability to import MP3 etc. is crucial. </p><p>How does this scheme cope with users who use File > Open or drag files in? Dragging may be a bit geekish but File > Open is novice behaviour. Many will use this instead of import as you know, because they don't understand "Import". If there is to be no preference for aliasing behaviour, should File > Open always copy in, drag always read directly, or only the "Import > Link to Audio" read directly? My own typical workflow is to drag in aliased WAVs, so I would be very inconvenienced if dragging copied in. </p><p> When you say  "I use "faster" for LP transcriptions" I'm not quite clear - you mean you alias WAVs you have already recorded in a previous session, but copy in WAVs ripped from CD for example? Certainly your menu item gives user an on-the-fly equivalent way to "change preferences" but is it a common use case? </p><p>You say "appropriate warnings could still be shown as discussed earlier." Which warnings and where? You say "It will not hide the “faster” functionality from the power-user". Leaving aside that not only power users want On-Demand, where is the explanation that tells user they can import WAVs much faster if they use "Link to WAV", but that "Import Audio" will be safer? If they choose "Import Audio", they will not receive the Dependencies Dialogue, so they will not find out that way. </p><p>In summary, I think the "Import/Link" idea is quite powerful, but looks at the moment that it has flaws as a single panacea. It would be compatible with my proposal of a global first time warning for all methods of WAV/AIFF opening if we used it as an on-the-fly toggle for Preferences, and a "reminder" feature for novices.</p>


*'''Peter 23Feb10:'''  I am a great believer in the simplicity and clarity of one command for one function, it leads to a purer UI.  I will try to summarize the core of Steve's suggestions and to address Gale's objections.
#'''Import:''' always copies in uncompressed files (WAV and AIFF - note,AIFF is usabel in Windows too) - and copies in compressed files MP3, AAC etc.  All imports are of course turned into Audacity project format.
#'''Link:''' will only Link to uncompressed files.  I am somewhat agnostic as to whether Steve's suggested message of offering an import if the user tries to Link to compressed files - or an alternative message that just blocks the user from linking to a compressed file with an error message that just tells them to use the import command instead.  I have a slight preference for the latter on grounds of purity.
#'''Open:''' The behaviour of this command should be changed so that all it can ever do is open an Audacity project.  It should not be possible to "open" a WAV/AIFF file which in current Audacity behaviour is actually an Open Audacity project coupled with an implied and hidden "import compressed audio" command.  ''This has very recently been raised by Steve on the forum (see http://forum.audacityteam.org/viewtopic.php?f=20&t=26504 ) where it has already attracted several votes in favour.''  I support this on grounds of command purity.
#:* '''Gale:''' However this makes a two step process to "open" audio files into a new project window, a common task. I think the rationale for making this one step is that (to the user) it's rather like Open in a word processor, which doesn't open a new project window, but opens the new document in a new self-contained tab (we could equally have tabs instead of new project windows). This is why it is "unexpected" that "Open" opens a new window. Plus, almost any well behaved app will have Open for opening generic file formats, which is why many users go for it rather than Import. <p>So I'm -1 on restricting Open to .aup on usability grounds and I think "what open does" is a separate issue that should go on [[Proposal Menu Reorganisation]]. If we don't change Open behaviour, we need to know whether in your scheme Open copies in or reads directly. But FWIW, I think having a separate submenu for "Project actions" and "Open" does not handle .aup files might be better. It might help stop people opening the .au files from their project that way. If anything, I would get rid of "Import". It clearly isn't understood by novices. Where and how audio files "open" should be decided in an Open menu.</p>
#:* '''Peter 24Feb10:''' I'd obviously prefer to restrict Open to native .aup format only - but I can see your reasoning.  So if we did not restrict Open, then I would prefer it to adopt the "safer" Import - this way it would have the same action for both compressed and uncompressed files.
* '''File > Open:''' this would then only Open Audacity projects and not WAV/AIFF audio files nor uncompressed audio
**<b>Bill 07Dec10:</b> <b>+1</b> Rename to "File > Open Project...". Users can curretly use this to "open" a WAV file, leading to the conclusion that Audacity is a WAV editor. When they then "Save", what they see doesn't make sense given that assumption.
* '''Dragging audio files in:''' this would invoke an Import (i.e. "safer" copy in) for compressed and uncompressed audio.  It should not be a mechanism to open an Audacity project by dragging in an aup file.  This obviously has the disadvantage of disrupting Gale's current workflow - but has the advantage of command purity.  I am pretty sure that most users think that they are copying a file in rather than just linking to it when they do drag-and-drop. 
** '''Gale:''' Dragging isn't an explicit command, which is why we probably still need a preference for copy/read directly. In fact some us expect that dragging in an .aup would simply open the project in a new window, not give an "unknown format" error as now! Most project-based apps support dragging in the native project file. 
** '''Peter 24Feb10:''' I have added a note to the alternative proposal to retain the preferences setting to control the behaviour of drag-and-drop (it would obviously be redundant as far as the Import/Link commands were concerned)
* '''Advice & warnings:''' On first use of of Import, the user should be displayed the advice message that informs them of the benefits (and risks) of Linking to alias files - this message should have an option to not be shown again if required.   On first use of Link, the user should be displayed the advice message that informs the of the safer nature of import and warning them that this takes longer - as well as warning them of the dependency risks of linking to alias files - this message too should have an option to not be shown again if required.
** '''Gale:''' So you think there should be different warnings for "link" and "import", and in your scheme you get the "import" warning for dragging in? Isn't better design to tell someone of the consequences of doing something before they do it, rather than make their action take a specific consequence (copy in or read directly) and then tell them the consequences of the action we forced them to take?
** '''Peter 24Feb10:'''Since I have now revised my scheme to offer both behaviours for dragging in (dependent on the Preferences "safer"/"faster" option) the message displayed would depend on the mode the user (or the default) has set.