Difference between revisions of "Talk:Completed: Proposal User-safe Aliasfiles"

From Audacity Wiki
Jump to: navigation, search
(comment)
m (PeterSampson moved page Talk:Proposal User-safe Aliasfiles to Talk:Completed: Proposal User-safe Aliasfiles: Proposal was completed in 1.3.12 and 1.3.13 Betas and is now in 2.0.x)
 
(13 intermediate revisions by 5 users not shown)
Line 1: Line 1:
*'''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).
+
* '''Peter 18Apr11:''' Is the content of this page now redundant? I would suggest that we archive the discssion up to now on the discussion/talk page.
**New users are presumably downloading Audacity for the first time, and many are complete novices. Rule #3 may be incomprehensible to them.
+
** '''James:''' Wiki has a history, so it is 'already archived'. If someone has time trimming the page down to a summary would be good. Can provide a link to [http://wiki.audacityteam.org/w/index.php?title=Proposal_User-safe_Aliasfiles&oldid=17102 this specific version] for people who want to see the history. Should also trim back the talk page too.
*** '''Gale:''' And they may never RTFM anyway, which is why this warning ought to be in the software. 
+
* '''Peter 19Apr11:''' I have trimmed both the main page for this topic and this talk/discussion pageThe (pre 1.3.13) history of the Talk page can be seen [http://wiki.audacityteam.org/w/index.php?title=Talk:Proposal_User-safe_Aliasfiles&oldid=17103 here].
**Seasoned users who prefer this option will have it set in their preferences which will be retained when they upgrade to a new version.
 
**Performing an effect on an entire imported track (such as Amplify or Normalize) completely negates the disk space saving nature of the "read directly" preference as Audacity must save (internally) the changed version of the track. It seems to me that if the "Normalize all tracks in project" preference is checked then this will happen automatically.
 
*** '''Gale:'''  Editing the imported track does not completely negate the space saving of importing a WAV via On-Demand. If you have a 750 MB WAV, copy in takes 1.5 GB, then an edit takes another 1.5 GB (total 3 GB). If you import via On-Demand, the 1.5 GB of space from the copy-in is saved. "Normalize on import" is off by default. I agree space-saving is the weaker of the two arguments for On-Demand. 
 
**Surely 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:''' I'm intending to make it a P2 bug that a file existence check should be done when the dependencies dialogue is invoked, if I don't get lobbied down. I don't know whether what you are suggesting can also be done as part of that. It's less critical, I think.
 
****'''Bill:''' What I'm seeing on the forum is users who save a project and come back to it days or weeks later, and have in the meantime moved or deleted a dependent file. An existence check on opening the project is critical for them, I believe. They will at least know what has happened and may have the opportunity to correct it.   
 
**Perhaps a warning when importing using "read directly"? This could be turned off in the warning dialog or in Warnings Preferences.
 
*** '''Gale:''' I support that and believe it should probably be a P3. It should be done because it then makes a much stronger case for retaining On Demand as default.
 
**Is there better wording/description to "read directly"? This confused me initially. What's the opposite? Read INdirectly?
 
*** '''Gale:''' I think "make a copy" is clear. I think the "read directly" could be something like "Use the original uncompressed audio file (faster, less safe)" 
 
  
*'''Peter 21Jan10:'''  I wholeheartedly support the idea of making the "Safer" option the default.  It is mainly inexperienced users (but not always) who fall foul of this.  My understanding is that the "faster" option was chosen as the default to make working with Audacity faster for power users.  But my contention is that power users are the ones most likely to probe and understand the various settings in Preferences - and in particular understand the import settings there.  With Audacity OOTB we should aim to make things as foolproof as possible for the new user.
+
__TOC__
  
'''Bill 22Jan10:'''
 
*'''Regarding the warning when importing using "read directly". What information do we need to impart?'''
 
**The file you are importing will not be copied into your Audacity project
 
**Audacity will read from (depend upon) the original file for all unedited portions
 
**You must not delete, move or rename this file unless you first copy it into your project using the "Check Dependencies" command in the File menu, or when you are prompted to do so when saving your project.
 
**|_| Don't show this warning again (button:)I Understand
 
*** '''Gale:''' I think it's too long. User will be confused, and devs will be reluctant. Once it's in, it's probably tweakable. Something like:<ul>''' 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><p> This gives us several possibilities. If we force this dialogue on first WAV import, with "Always copy" checked  (irrespective of user's current preference setting) this protects 1.2 users  who had the default preference, but gives users who want fast import the choice from the outset, instead of disadvantaging them by making them find it in Preferences. Checking "Always copy" copies in the files the user was importing. </p><p>"Don't show again" could mean "even if I subsequently change my preference", in which case checking "Always copy" would not grey out "Don't show". We "could" show the Dependencies dialogue here too, but on first thoughts the above seems neater. </p>
 
 
  
*'''Regarding the dependencies dialog'''
+
==Disk usage with "read directly"==
:[[image:DependenciesDialog.png]]
+
I think it is worth noting that using "read directly" can actually '''increase''' disk usage. Consider a 16-bit project that depends on an external file, say a raw interview with lots of irrelevant stuff. The users edits out the bad stuff, reducing the length of the interview by half. If this audio were copied in, its length would be reduced by half, but instead the project continues to depend on the original file, making the disk footprint of the project bigger than if the audio were copied in. Furthermore, Audacity will create .au files (containing audio) to cover the edit points that certainly will not fall on block boundaries - so the project is now bigger than the original file. It is easy to conceive of situations that would have a similar effect. For this reason "removing dependencies" on saving a project is to the user's benefit - there is not longer a speed penalty when opening the project and disk usage is reduced (assuming the user then deletes the original file).
**It needs to be bigger so it can show the entire path. At present, on Mac, the dialog is too small to show this, is not resizable, and there are no horizontal scroll bars in the list.
 
**"Project depends on other audio files" gets lost as the title of the dialog
 
**Note that the button "Copy Selected Audio Into Project" remains enabled even when nothing is selected in the list
 
**Improved messages?
 
***Dependencies (title of the dialog)
 
***Your project depends on the following audio files which were imported using the 'read directly' option in Import / Export Preferences.
 
***As long as your project depends on these files you must not delete, move or rename the files.
 
***You can choose to copy the contents of these files into your project, which will remove the dependency.
 
***This may require more disk space, but is safer and will make your project self-contained.
 
  
:[[image:SaveDependencies.png]]
 
**The dialog that appears when saving a project with the "ask user" option in Projects Preferences is wider, but has a silly third column with nothing in it. A savvy user can drag to make the first column wider but it still may not be able to show the full path (which includes the most vital information - the name of the file).
 
**IMO needs expanded explanation as above
 
  
* '''Gale:''' My suggestion is that we have essentially one Dependencies dialogue rather than two variants according to route. The "Cancel Save" button when you see this dialogue by exiting becomes "Save" if you approach it via "Check Dependencies". Here is my take on a cleaner wording:
+
==Proposal (Vaughan)==
:[[Image:Dependsmod.JPG]]
+
Vaughan's proposal varied somewhat from what was implemented for 1.3.13, therefore retained here on the Talk page.
I particularly dislike "other audio files" so I would change all instances of that to "imported files". If we go with the warning on first import, I think we could get away with minimal wording here. We still have the option of context-sensitive help at a later stage. Note that on Windows there is a tooltip if you hover over the filename, but I certainly think the dialogue should be resizable. A possible tweak may be to have a checkbox in the window to select files, then just one button to copy whatever files are checked.    
 
  
 +
As understood by James. Please edit and correct.
 +
*Link-to-audio is default in 2.0
 +
*Warning about aliasfiles should be done at save/export.
 +
*We aren't doing any proactive locking or looking for files to check they are there.
  
*'''Regarding what happens when an alias file is not available'''
 
**What happens now is that the user sees the "blue wave" but hears no sound, and is thoroughly confused.
 
**I feel strongly that Audacity should check for the existence of alias files when opening a project and give the user an explanation if any files are not found.
 
**Perhaps a dialog similar to a (revamped) dependencies dialog (listing the missing alias files), with the message:
 
***This project depends on the following files, but Audacity could not find them.
 
***You can choose to open the project, but portions may be silent even though a waveform is visible.
 
***It is recommended that you quit immediately, find the files on your computer and return them to their original locations.
 
**Even fancier would be a "Browse" or "Find" button that allows the user to find the moved/renamed files and point Audacity to their new names and/or locations, although this is potentially very dangerous as the user could easily point Audacity to the wrong files!
 
**If the user chooses to open the project anyway (why would they?), could the waveforms for the missing sections be rendered in a different colour, say pink?
 
  
*'''Conclusion:''' IMO (as of today, and I reserve the right to change my mind), I could be persuaded that "read directly" would be the default option if the above were implemented, that is:
+
<div id="speed"></div>
#warning when importing using read directly
+
== Speed Differences between On-Deamnd and Copy-In==
#improved dependencies dialogs
+
* '''Bill:''' <br>
#check for missing alias files when opening a project
+
: Test file is 35:40 AIF, 16-bit 44100 Hz on same disk as Audacity project and temp directory.
**''In the meantime I believe that "copy in" should be the default until these improvements can be made''.
+
:{|border=1
 +
|+
 +
|Test||G4 PowerBook 1.67 gHz 10.4.11||G5 dual 2 GHz 10.5.8||iMac Intel Core 2 Duo 2 GHz 10.4.11
 +
|-
 +
|OD import||0:35||0:23||0:11
 +
|-
 +
|Copy-in import|| 0:25 || 0:17 || 0:19
 +
|-
 +
|Amplify linked|| 1:29 || 1:00 || 0:29
 +
|-
 +
|DC offset linked|| 2:01 || 1:20 || 0:39
 +
|-
 +
|Amplify copy-in|| 1:04 || 0:48 || 0:28
 +
|-
 +
|DC offset copy-in|| 1:20 || 0:57 || 0:36
 +
|-
 +
|Save after linked w/copy-in|| 0:53 || 0:31 || 0:14
 +
|-
 +
|Save after copy-in|| 0:04 || 0:11 || 0:05
 +
|-
 +
|}
 +
:"OD Import" is time until waveform is completely calculated and drawn.
 +
:"Save after linked w/copy-in" means remove dependencies, and is the total time for the save - remove dependencies plus save project.
 +
:There seems to be a definite PPC/Intel divide, with OD being faster on Intel, and slower on PPC. On Intel there is little difference in processing times for OD versus copy-in, whereas on PPC processing copied-in data looks faster.
  
*'''Other issues:'''
+
* '''Koz:''' (paraphrased0 On Mac, I import 2 hour WAVs all the time. OD is the difference between getting the job done or not.
**I think it is worth noting that using "read directly" can actually '''increase''' disk usage. Consider a 16-bit project that depends on an external file, say a raw interview with lots of irrelevant stuff. The users edits out the bad stuff, reducing the length of the interview by half. If this audio were copied in, its length would be reduced by half, but instead the project continues to depend on the original file, making the disk footprint of the project bigger than if the audio were copied in. Furthermore, Audacity will create .au files (containing audio) to cover the edit points that certainly will not fall on block boundaries - so the project is now bigger than the original file. It is easy to conceive of situations that would have a similar effect. For this reason "removing dependencies" on saving a project is to the user's benefit - there is not longer a speed penalty when opening the project and disk usage is reduced (assuming the user then deletes the original file).
+
 
 +
* '''Gale:''' Win 7 and XP machines 1.6 GHz or higher, 512 MB RAM or greater, it takes a minimum of 2.5 minutes to import a 38 minute WAV (with minimum space free of 30 GB out of 65 GB). Takes circa 30 seconds to OD-import and calculate.<p>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.</p>
 +
** '''Peter 7Feb11:''' I would be happy to see such a dialogue on first import, but adding new conditional dialogue could probably not be done pre 2.0 due to the current feature freeze - whereas the simple reversal of the default could be done pre 2.0.  I would advocate making the default reversal now and then adding Gale's other proposed changes (on the [[Talk:Proposal User-safe Aliasfiles|discussion tab]])shortly thereafter in the next Betas.
 +
<br>
 +
 
 +
* '''Peter 08Dec10:'''
 +
**WAV File 24 mins 22 seconds in length – resident on my onboard hard-drive
 +
<ul><ul>Import/linking    49 seconds</ul></ul>
 +
<ul><ul>Import/copying  2 mins 19 seconds</ul></ul>
 +
<ul><ul>Amplify whole linked file    2 mins 8 secs</ul></ul>
 +
<ul><ul>Amplify whole copied file  2 mins 36 secs</ul></ul>
 +
<ul><ul>Remove DC linked file      3 mins 17 secs</ul></ul>
 +
<ul><ul>Remove DC copied file      2 mins 14 secs</ul></ul>
 +
<ul><ul><li> WAV file  1 hour 29 mins 30 secs in length – resident on my external USB disk</ul></ul>
 +
<ul><ul>Import/linking    1 min  41 secs</ul></ul>
 +
<ul><ul>Import/copying  4 mins 26 secs</ul></ul>
 +
 
 +
<p><ul>These results are insufficient to show statistical significance, however they indicate that it takes roughly 3 times longer to copy the WAV files in compared with linking to them.</ul></p>
 +
<p><ul>The processing figures are puzzling – the DC offset removal indicates my preconceptions in that processing on a copied in Audacity project is faster than with an external linked project.  But the Amplification processing is contra-indicating.</ul></p>
 +
 
 +
<ul><ul><ul><li> '''Gale 08Dec10:''' I wouldn't expect consistent speed differences in editing copied-in and aliased files from the same drive. One major benefit from OD is that you can work with the imported file as soon as the waveform drawing has commenced - this is normally a matter of seconds. </ul></ul></ul>
 +
 
 +
*<b>Bill 09Dec10:</b> Still waiting on Bruno to test on Linux, but this exercise has been very revealing so far. Putting aside my PPC results (with old machines, and looking at the one Intel Mac test I have available), it appears that Audacity is slow on Windows machines in general - not only in copying in, but in processing as well. 39 seconds to amplify a 35-minute stereo track on an Intel iMac, versus 2:36 to amplify a 24-minute stereo track on Windows. Extrapolating that Windows time to a 35-minute track would give 3:38. That's 5.6 times faster on the iMac! What's going on?

Latest revision as of 18:18, 13 November 2013

  • Peter 18Apr11: Is the content of this page now redundant? I would suggest that we archive the discssion up to now on the discussion/talk page.
    • James: Wiki has a history, so it is 'already archived'. If someone has time trimming the page down to a summary would be good. Can provide a link to this specific version for people who want to see the history. Should also trim back the talk page too.
  • Peter 19Apr11: I have trimmed both the main page for this topic and this talk/discussion page. The (pre 1.3.13) history of the Talk page can be seen here.


Disk usage with "read directly"

I think it is worth noting that using "read directly" can actually increase disk usage. Consider a 16-bit project that depends on an external file, say a raw interview with lots of irrelevant stuff. The users edits out the bad stuff, reducing the length of the interview by half. If this audio were copied in, its length would be reduced by half, but instead the project continues to depend on the original file, making the disk footprint of the project bigger than if the audio were copied in. Furthermore, Audacity will create .au files (containing audio) to cover the edit points that certainly will not fall on block boundaries - so the project is now bigger than the original file. It is easy to conceive of situations that would have a similar effect. For this reason "removing dependencies" on saving a project is to the user's benefit - there is not longer a speed penalty when opening the project and disk usage is reduced (assuming the user then deletes the original file).


Proposal (Vaughan)

Vaughan's proposal varied somewhat from what was implemented for 1.3.13, therefore retained here on the Talk page.

As understood by James. Please edit and correct.

  • Link-to-audio is default in 2.0
  • Warning about aliasfiles should be done at save/export.
  • We aren't doing any proactive locking or looking for files to check they are there.


Speed Differences between On-Deamnd and Copy-In

  • Bill:
Test file is 35:40 AIF, 16-bit 44100 Hz on same disk as Audacity project and temp directory.
Test G4 PowerBook 1.67 gHz 10.4.11 G5 dual 2 GHz 10.5.8 iMac Intel Core 2 Duo 2 GHz 10.4.11
OD import 0:35 0:23 0:11
Copy-in import 0:25 0:17 0:19
Amplify linked 1:29 1:00 0:29
DC offset linked 2:01 1:20 0:39
Amplify copy-in 1:04 0:48 0:28
DC offset copy-in 1:20 0:57 0:36
Save after linked w/copy-in 0:53 0:31 0:14
Save after copy-in 0:04 0:11 0:05
"OD Import" is time until waveform is completely calculated and drawn.
"Save after linked w/copy-in" means remove dependencies, and is the total time for the save - remove dependencies plus save project.
There seems to be a definite PPC/Intel divide, with OD being faster on Intel, and slower on PPC. On Intel there is little difference in processing times for OD versus copy-in, whereas on PPC processing copied-in data looks faster.
  • Koz: (paraphrased0 On Mac, I import 2 hour WAVs all the time. OD is the difference between getting the job done or not.
  • Gale: Win 7 and XP machines 1.6 GHz or higher, 512 MB RAM or greater, it takes a minimum of 2.5 minutes to import a 38 minute WAV (with minimum space free of 30 GB out of 65 GB). Takes circa 30 seconds to OD-import and calculate.

    I've proposed on the 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 7Feb11: I would be happy to see such a dialogue on first import, but adding new conditional dialogue could probably not be done pre 2.0 due to the current feature freeze - whereas the simple reversal of the default could be done pre 2.0. I would advocate making the default reversal now and then adding Gale's other proposed changes (on the discussion tab)shortly thereafter in the next Betas.


  • Peter 08Dec10:
    • WAV File 24 mins 22 seconds in length – resident on my onboard hard-drive
      Import/linking 49 seconds
      Import/copying 2 mins 19 seconds
      Amplify whole linked file 2 mins 8 secs
      Amplify whole copied file 2 mins 36 secs
      Remove DC linked file 3 mins 17 secs
      Remove DC copied file 2 mins 14 secs
    • WAV file 1 hour 29 mins 30 secs in length – resident on my external USB disk
      Import/linking 1 min 41 secs
      Import/copying 4 mins 26 secs

    These results are insufficient to show statistical significance, however they indicate that it takes roughly 3 times longer to copy the WAV files in compared with linking to them.

    The processing figures are puzzling – the DC offset removal indicates my preconceptions in that processing on a copied in Audacity project is faster than with an external linked project. But the Amplification processing is contra-indicating.

      • Gale 08Dec10: I wouldn't expect consistent speed differences in editing copied-in and aliased files from the same drive. One major benefit from OD is that you can work with the imported file as soon as the waveform drawing has commenced - this is normally a matter of seconds.
  • Bill 09Dec10: Still waiting on Bruno to test on Linux, but this exercise has been very revealing so far. Putting aside my PPC results (with old machines, and looking at the one Intel Mac test I have available), it appears that Audacity is slow on Windows machines in general - not only in copying in, but in processing as well. 39 seconds to amplify a 35-minute stereo track on an Intel iMac, versus 2:36 to amplify a 24-minute stereo track on Windows. Extrapolating that Windows time to a 35-minute track would give 3:38. That's 5.6 times faster on the iMac! What's going on?