AUP3 File Sizes

Feedback and Discussion Forum Audacity 3.x Feedback and Reviews
1

Hi all,

This post is part question and part suggestion.
First, the background for context:

I import two audio clips (each around 10 min duration, 320KB/s MP3) on individual tracks.
These are then cut up and I’m left with 3 shorter clips (around 25 secs each) at different points on each track.
Then I record some audio onto a third track, approx. 30 seconds worth.

Now the question…
When I save the project (AUP3 format Audacity 3.1.3 64 bit on Win 8), it comes to just under 120MB.
(Even after Audacity has “COMPACTED” the data).
However, if I create a folder and export each of the 3 tracks as 32 bit wavs, it only comes to 10MB.
(Important to uncheck “ignore empty space” when exporting multiple, else the clips won’t line up afterwards).

Why the huge difference?
I can understand a bit of overhead for metadata, project specs, cut-points, etc.
But 12X the size?

I suspect I know what is going on, Audacity is saving audio data (in 32 bit PCM samples) before and after the cut-points.
All good and well, but what if I don’t need it?

Can there not be an option when creating a project, to decide as to whether this extra audio data is kept or not?
If kept, then one can “expand” on the cut-points anytime in the future.
However, there are often times when the extra audio will never be required, so why be forced to keep it?

2

Yes. But that that depends on which version of Audacity you are using and on exactly how you " cut up [creating] 3 shorter clips (around 25 secs each) at different points on each track."

Part I.
So in 3.1.3, I “Generated” a single 10 minute mono track. When I saved and closed this project, the size was 104.7MB.

I reopened the project and did two split-cuts one at 1-3minutes, the other at 5-9, leaving 3 1-second clips. You might think the project would have 30% of the original size. But no - when I saved and closed the project, the result was 106.3GB. :astonished:

So apparently a split cut removes audio only from the screen. The underlying audio “information” is retained in the project. And in fact, if you reload the project, you will see the edges of the clips are draggable. So I have inadvertently created “smart” clips.

Part II.
Still in 3.1.3, I created a new project and generated a 10-minute track as before.

To produce the same result a different way, I now create an 2nd (empty) mono track, then select three 1-minute sections from the original track, which I copy and paste into the 2nd track. I then delete the original track. This results in a project that is 31.2MB, which is what would be expected.

However…

Part III.
If I repeat the steps from Part II with Audacity 3.2.1, the results are different. :confused:

The resultant file is 105MB, and guess what - the edges are draggable.

So it depends not only on how you create your clips, but on which version of Audacity you use.

Also, see these related issues:
Full Tracks Are Copied When Only A Small Portion Is Requested #3820
Not Responding after copy/paste to new Window #3790

3

And the exact behaviour is neither intuitive, or documented. For example, “Delete” does (now) delete the selected audio (including the underlying audio data), whereas “Split Delete” doesn’t.

4

Thanks for your input guys.
Yes, it’s a bit of a hit and miss affair at the moment, as regards what completely deletes and what does not.
Since I typically do about 3-4 shortish projects per day, using the AUP3 format would very quickly fill up my drives
with unnecessary audio data that will never be used.

So the workflow I have adopted is as follows:

  1. Do what ever edits are required per track.
  2. Mix the tracks to another “master” track, this way, the original edits are still available.
  3. Export each one (using the export multiple) option to a dedicated folder.

The important points are:

  • Export as 32 bit wav
  • Uncheck “ignore blank spaces”
  • Select the “Numbering before label/track name” option.

Lastly, make sure all tracks are unmuted before exporting.
You can always mute them again afterwards.

5

OOH so it does (tested on 3.2.2 beta) …

That’s a bit of a nasty Easter Egg - and totally undocumented AFAICT

@Jademan and @Steve - do we think this is a bug that should be logged? Or is it a “feature” that Muse have forgotten to tell us about?

Peter

6

Yes - as I mentioned earlier - this is already logged as #3820: https://github.com/audacity/audacity/issues/3820

7



Yes - as I mentioned earlier - this is already logged as #3820: > https://github.com/audacity/audacity/issues/3820

I added these use cases to the bug thread - and marked the bug as a regression

A close cousin of this is that the Edit>Remove Special commands
a) Split Cut
b) Split Delete
c) Trim Audio
do NO LONGER delete the removed audio.

Rather the remaining audio clips are turned into “smart clips” with the ostensibly removed audio still present as part of the clip(s) but hidden. This new behavior is a regression on earlier Audacity, introduced in 3.1.0 - and will be a surprise to most users (if they notice it at all).

What it does do is to unnecessarily increase the size of a users project as several users have reported - and this is how we found this odd behavior.

Normally when one uses a delete, cut or trim command one expects the removed data to be actually removed (and in the case of cut placed on the clipboard). Certainly that is the case when one uses Word or Excel, or other apps that I us.

It seems to me that if you do want to have such functionality it should be new commands which make it explicitly clear that data is not being removed but merely hidden.

AFAICT this hidden creation of “smart clips” is not documented or announced anywhere.[/quote]

See:https://github.com/audacity/audacity/issues/3820

Peter

8

Also note that creating a clip or clips from another clip will result in both/all clips containing all the audio data of the originating clip - BUT “hidden” as “smart clips” which can all be dragged out to the full data of the originating clip.

This is NOT how clips behaved in Audacity prior to 3.1.0. In those earlier versions a clip was just the clip that you made and contained no other hidden data.


Steps to reproduce

  1. Generate a 30 second chirp
  2. Place the cursor at 20 seconds and Ctrl+I to split the chirp
  3. zoom out 2 or 3 times
  4. Move the second clip well to the right
  5. Click on the upper left of the second clip and drag Rightwards by 5 seconds
  6. Observe: clip shrinks to a 5 second on-screen (and playable) chirp - expected behavior
  7. Click on the upper left of the second clip and drag leftwards for 25 seconds or more
  8. Observe: the second clip now shows as a full 30 second clip and not just the ten second clip that it was at Steps 2 & 3
  9. Click on the upper right of the first clip and drag Rightwards for ten seconds or more
  10. Observe: the first clip now also shows as a full 30 second clip
  11. Observe: we now have two 30 second clips and NOT a 20 second clip and a 10 second clip

The behaviors shown in steps 8, 10 and 11 just look totally wrong to me in fact the opposite of “smart” clips.

This is made even worse by the fact that there is NO visual cue to show the user that a clip has hidden data.
There is no visual cue for a shrunk clip #1912
https://github.com/audacity/audacity/issues/1912


I have added this to the GitHub bug thread
https://github.com/audacity/audacity/issues/3820
Full Tracks Are Copied When Only A Small Portion Is Requested #3820

Peter.