I’ve read in a post within the topic ‘Tiny clicks (encore)’
waxcylinder wrote: ↑Sun Dec 18, 2022 11:02 am
The good news:
I’ve recently been testing (in a developer’s branch build) the new feature which gives you the option, when copying a selection from a clip, to paste just the selection and not the whole “smart clip”. This works well with a dialog on the paste action and an accompanying prefs setting.
It needs a little polish to make it properly accessible to VI users who use screen readers.
I’m hoping that it will make it into the upcoming 3.2.3 release.
I was hoping to find this feature in the latest 3.2.3 version which I’ve just downloaded for this very reason, but I can not find it (I am working on Mac OS High Sierra). Does anyone know if it was indeed implemented, or if it is still under test for future versions ?
If not, I will go back to version 3.1.3, which seems to be the latest where copying a selection from one track into another (either in the current project or in another one) did not add any other part of the waveform. I confess that I can not get used to the way smart clips work, it does seem to increase the size of my projects, and I have not seen any circumstance in which it could be useful for me - at least in my simple use of Audacity for recording and editing audiobooks - if ever it is for more advanced users.
No it’s not there yet, but I’m recalling a comment from @Lwinterberg that a patch is now ready (it was waiting for changes that David Bailes requested for VI accessibility) but it has not been pulled into “master”.
I did test it on W10 on branch builds a while back and it worked fine.
Vitaly is the developer working on this. I think this is his latest branch build for this:
But that PR was made 3 weeks ago and there has been no progress since, but I think Muse may have been avoiding it going into 3.2.2 Update
This is the relevant thread: Clip copy dialog #4033
You may not that is marked as “Review Required” and Paul is marked as the requested reviewer
This is the main bug thread Performance and file size issues when copying and pasting a small portion of a very large clip #3820
Ah yes, that’s in Vitaly’s branch, but I notice that it only affects copying clips from one project into another project. It does not have any effect when copy / pasting in a single project.
Indeed an Muse do not think that they need to do anything about that as it doesn’t actually make a copy - at least bot until you start editing the track with the copied clip.
Dmitry wrote in the bug thread
Copying clips within a project doesn’t create a data copy.
There is no data copy performed in this case. The new data will be created only when you perform destructive editing.
So they don’t see copying a clip within a project to be an issue - I still do …
The workaround once this gets fixed would be;
Copy the selection to an empty temp project
select that clip in the temp project and use Cut
return to the original project and use Paste.
This may be a bit simpler than the Mix&Render workaround.
Yes, I was rather surprised to read that after I had demonstrated that sometimes it does.
Yes, but what an ugly workaround for an issue that should never have occurred. I really don’t understand their reasoning for forcing a radical new behaviour on all Audacity users when it was clear from the outset that it would not be appropriate for all users. I’m pleased that they have eased back a bit, but imo “smart clips” should be an “option” so that users can choose to use the feature when appropriate to their workflow, and not use it when it would be a hindrance.
Here’s one: Project bloat when resampling · Issue #3951 · audacity/audacity · GitHub
The situation is not as bad now as when I reported the issue. Following the steps to reproduce with Audacity 3.3.0 alpha the total project size is “only” 10 GiB, whereas it was more than double that for 3.2.1 (and 7.6 GiB for Audacity 2.4.2). However, if you add an extra step like so:
What is the use case for using those steps? If you want to re-sample why not do that first, then create the clips? Of course each clip needs to have the entire data associated with the clip re-sampled since you can’t (as I understand it) have different sample rates within 1 clip.
If instead, with your example, Step 2 is to apply Amplify, the project size will only double in size since only the “visible” data in each clip is amplified. But, again, why not do the Amplify step first, then make the clips?
The use case is based on the fact that a user might not need or want “smart clips” and so may not be aware that some actions may cause enormous growth in the project size.
An example that could have a very bad outcome for the unsuspecting user:
I’m not saying that this is the only way, or even the best way to do this particular task, but it is one way that would be perfectly reasonable were it not for this bear trap.
Say that you have an 8 hour audio book with 26 chapters, all in one file. The task is to split the file into one file per chapter, possibly treating each chapter separately (such as EQ / gain) if necessary after previewing the chapters.
Import the 8 hour audio file - you notice that its sample rate is 48000, but you want the final files to be 44100 Hz.
Locate the start of each chapter and split the track at that position
Drag each chapter onto a separate track
Align each of the clips to start at time = 0
Solo each track in turn to preview each chapter (or parts of)
Adjust track gain / EQ / … anything else necessary according to taste
Resample the track to 44100 Hz. You do that now so that you are previewing the audio as it will be after export.
When you’re happy with all of the tracks, you intend to Export Multiple, but given the massive size of the project at this stage, you may have run out of disk space, and you might not even be able to save the project.
“Undoing” in the hope that some space will be recovered will probably fail, and most likely you loose all of your work.
Of course, if the user was aware of the issues with “smart clips”, then they could have gone about the task differently, such as using an older version of Audacity that didn’t require them to work around such issues.
