For some time now, Audacity began to insert extra silence about the time of processing audio tracks with a macro. Moreover, as far as I remember, I did not change the macro (or I did not change it dramatically). I used it for about six months without any problems - until, it seems, I upgraded to version 3.1.3.
And now I can’t catch the root cause of bug in any way. I have already changed the bit (x32 x64) and older versions, tried to change the composition of the macro-commands. And even when I didn’t change anything - the same track was either processed normally, or not randomly.
Silence is inserted by the program exactly to the length by which the track is shortened when shortening the track-length after @truncate silence" and “change speed” the track.
I continue to try experiments in search of the error dependency, but still without success.
I’m having difficulty understanding the screenshot that you posted. The grey section that you have marked “Silence after change speed” does not look like a normal silent audio clip - there is no horizontal “silent audio” line and no “Clip Handles” (drag bar at the top) so I’m unsure what you are trying to show.
Sorry for the delay in responding. This week I have been trying to determine whether this problem is a bug in the program or a failure of my system specifically. I have installed the latest version of Audacity completely on the latest version of Windows 10 and Ubuntu. And my macro causes exactly the same random (sometimes a track is processed correctly, and sometimes a piece of silence is added to it) bug…
Can someone check the work of my macro on their set of tracks?
jademan, thanks for the leading question. He made me do more thorough tests.
Operation fails on exactly the same files.
Moreover, it seems I have found out the mandatory combination of factors that lead to the bug: 1) SetProject (Rate)
2) High-passFilter
3) TruncateSilence
4) ChangeSpeed
If I delete any of these steps, the operation proceeds normally.
So the issue seems to be that when the macro shortens the clip, for some reason audacity thinks the audio extends to the full length of the original clip. I can see why Steve was thinking there was a little audio out there - but there just isn’t.
Curiously, I was able to reproduce the issue on your test case using a macro with just the High Pass Filter and the Truncate Silence - several times. Then I issued the two commands manually - and I could not reproduce it anymore. Subsequently, the macro worked the way you wanted it to. And I have not been able to reproduce the issue since. Of course when I run an effect manually, I have to select which version of the effect I want to use - I wonder if that had any bearing…
I’ve done a little macro work in the past, but honestly I have been baffled in the past by the apparent length of a track compared to the apparent length of a clip. Someone else is going to have to look into this…
Sorry but I’m (probably) out as I can’t reproduce the issue.
However, since you have been able to reproduce the issue, perhaps you could answer my previous query:
So the .mp3 file starts out as a single 10-minute stereo clip and gets reduced to a single mono 5 1/2 minute clip. There is nothing beyond the 5 1/2 minute mark. You can zoom way out and there is nothing else there - not even a little tiny one sample clip (I zoomed way in and it wasn’t there). However, clicking “Select” on the Track Control Panel highlights the original 10 minutes of audio - not actually the original audio, but the 5 1/2 minute clip and an additional 4 1/2 minutes of ghost (nothing). Somehow Select thinks the clip is 10 minutes long - but it is not, and again, there is nothing out there. So it is the export that actually creates the silence out of nothing.
And, as I said before, I am currently unable to reproduce the issue. It has gone away for me.
Yes. BTW, when I did get it to “fail”, I was able to whittle down the macro to simply High-pass Filter and TruncateSilence. And I suspect the High-passFilter was important specifically for this particular test case. I wonder if he is or I was running an older buggy version of Truncate Silence, and the version (or default) was changed when I ran it manually.
So, rexen, try running TruncateSilence manually on any audio, but make sure you run the 3.1.3 version of TruncateSilence and use the defaults. Then see if that changes your macro behavior.
Exactly! This is what I tried to explain with a screenshot with captions.
I just remembered that the problems started around the time when I decided to improve the processing of audio tracks and added a “High-Pass Filter” to the script. Before that, I tried to use the “Classic Filters” - and it leads to a crash of the program. Now I tried to use the “Filter Curve EQ” and it seems that everything works fine with it.
That is, at the moment it seems that the HPF leads to incorrect data in the audio stream, which is why further processing causes errors.
The strange thing is that this behavior doesn’t happen on every track. And that a combination of processes is needed.
By the way, in this picture you can see that, indeed, there is some incorrect information in the cut-off tail. This is a screenshot of an incorrectly processed track in the mp3DirectCut program. It feels like DC-offset is present there. The “pit” in the middle is the “silence” inserted by mp3DirectCut itself.
so I’m unsure what you are trying to show.
