Free space for editing

[Baylink]

In the 2.1 release notes, I see

Be aware that every edit on a track takes as much in disk space as if you were recording that track, due to the ability to undo and redo.

That means that every single edit I make to a 30MB track costs me another 30MB of disk? If I make 100 edits, it's 3GB?

I thought the internal chunking format was at least partially intended to preclude that particular problem; have I misunderstood that?

[kozikowski]

In the 2.1 release notes, I see

We hope you're reading the 2.1.0 notes. Version 2.1 and 2.10 are bogus.

If I make 100 edits, it's 3GB?

As far as I know, yes. A recent poster got in trouble by making far fewer edits, but on a large show. "Wait, where did my xxxGB go?"

Koz

[cyrano]

it's the same with all "creative" programs. Photoshop needs 3 times the ram compared to the size of the file you're editing.

I don't know any DAW that can do non-destructive editing without using boatloads of disk and/or ram storage.

Besides, for audio or video editing you really need a large free contiguous space. Otherwise, fragmentation will affect your workspeed and might just lead to stuttering if you work on one disk.

That's why most professional editors put their audio files on a separate harddisk and not on the disk containing the OS.

[Gale Andrews]

In the 2.1 release notes, I see

Be aware that every edit on a track takes as much in disk space as if you were recording that track, due to the ability to undo and redo.

That means that every single edit I make to a 30MB track costs me another 30MB of disk? If I make 100 edits, it's 3GB?

Assuming the track contains 30 MB of audio data, yes.

If you import a compressed 30 MB file, say a 30 minutes MP3, then the internal data usage by Audacity is up to 600 MB for a stereo file at Audacity's default 32-bit float sample format and 44100 Hz project rate.

I thought the internal chunking format was at least partially intended to preclude that particular problem; have I misunderstood that?

That's about access times and whether the existing data chunk can be reused without rewriting it.

If you import a WAV or AIFF using On-Demand Loading then the file is read "directly" without copying the data in until you edit the audio, then it's copied in. It saves the disk space the initial import would take.


Gale

[Baylink]

So, to clarify, Gale, undo is *not* handled internally at the chunk level?

(And, for the record, "2.1" == "2.1.0"

[Gale Andrews]

So, to clarify, Gale, undo is *not* handled internally at the chunk level?

I am not sure exactly what you are asking, but check it out for yourself. Import a file (copy in if WAV or AIFF) then apply an effect to the whole track. Observe that the number of AU files (and hence disk space usage) doubles.

Undo and Redo and nothing happens to the AU files.

If you only apply the effect to part of the track, then the number of AU files will less than double.

Gale

[Baylink]

"Will less than double" is the magic phrase, implying that undo *is* handled at the chunk level, and that the phrasing in the release notes which inspired this thread is somewhere between pessimistic and wildly pessimistic, depending on what and how you edit. Thanks.

[Gale Andrews]

"Will less than double" is the magic phrase, implying that undo *is* handled at the chunk level, and that the phrasing in the release notes which inspired this thread is somewhere between pessimistic and wildly pessimistic, depending on what and how you edit. Thanks.

For 2.1.1 release that text will now say

Be aware that every edit on a complete track takes as much in disk space as if you were recording that entire track, and partial edits take proportional amounts of space, due to the ability to undo and redo.

It wasn't really wrong before, if you view it that editing a section of the track costs you about as much disk space as if you recorded that section.


Gale

[Baylink]

I agree; pessimistic isn't "wrong". I prefer it to optimistic, actually.