I know I’m not the first person to encounter this, but I haven’t seen any satisfactory answers. Using 2.2.2 I am frequently using the ability to snap select.
I am doing a lot of work with making preexisting files loop. This means some combination of draggin in a new file, splitting it somewhere, copying it to a new track, reversing stereo channels, lots of transporting, doing some more cuts and then saving the intro/loop parts out. Generally I close the tracks and drag in a new file rather than creating a new project, so I don’t need to be constantly opening and closing Audacity.
I’m doing work that is down to the sample, and this is driving me crazy. It was a problem I had occasionally before, now I’ve started up again after a few weeks and it is happening within a few actions of opening the program. Is there anything known about this issue?
Unfortunately changing that setting does nothing. The only way to get snapping back that I have found to work is restarting the program. When I say disabling itself, I mean somewhere below the GUI layer (I can see how that is not clear in my title).
Really
Try setting that to “Nearest”, then, in the Selection Toolbar (bottom of the main Audacity window), set the time format to “seconds” (see: Selection Toolbar - Audacity Manual), then try and make a time selection of 3.5 seconds. Do you not see the selection snap to exact seconds?
Unfortunately setting the format to seconds doesn’t help either. One interesting thing I DID discover is that a clip I haven’t moved is still snappable, but the ones that have been copied and moved are not.
I wasn’t suggesting that it would help. I was surprised that you said that it didn’t work and was asking you to clarify what you meant.
I now see that you are referring to the (similarly named, but different feature) “Snap to clip boundaries” Boundary Snap Guides - Audacity Manual
For “Snap to clip boundaries” to work, the “Snap To” control must be set to “Off”. If it is set to either of the other settings, then the “strong snapping” to time positions (seconds, milliseconds, or whatever) overrides the “weak snapping” to clip boundaries.
Aaaaah, that explains what I am seeing. It also explains the somewhat confused answers I found searchign the issue. Many things are coming together. I’m curious, in samples mode shouldn’t “strong snapping” be disabled entirely? It seems to behave that way sometimes but not others.
That’s a bit of an edge case. Personally I think that audio should always be aligned to an exact number sample periods relative to time=0, which would make “strong snapping” irrelevant when time is displayed in sample mode. Not all of the developers agree.
Very interesting. I suppose I can imagine a scenario where somebody might want some kind of sub-one-sample offset between clips, but I’m having to imagine pretty hard. How is clip placement quantized if not to the project sample rate?
We’re going a little “off-topic” here, but it sounds like your original issue is now resolved, so …
Samples within each audio clip are quantized to exact sample periods relative to the start of the audio clip. Currently, the start of the audio clip can be anywhere (not quantized). This means that you could have two tracks with the same sample rate and the samples not line up:
Indeed we are, but as you say problem solved. I suspect this subject may still be of interest to some people who may come along later looking into the same thing.
What I mean is, the start point of an audio clip must be quantized somehow, computers being digital machines and all. Is it to an internal sample rate of 384000, or something else? Entirely an academic question of course.
and the answer is quite technical. The start position of clips are defined in seconds, represented as 32-bit floating point number. Because of how floating point numbers work, the precision varies depending on the value being represented. Small values are represented more precisely than large values, but even for very large values we are still talking about precision in the order of +/- 0.000000000001 seconds or better.
I am somewhat familiar with the floating point precision oddities of which you speak (the same thing that makes identical weather software running on different processors predict temperatures several degrees out from one another). Thanks for answering my questions!
