Talk:Completed: Proposal User-safe Aliasfiles

From Audacity Wiki
Jump to: navigation, search
  • 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?