In regards to the speed control option in Shotcut that is in the Properties menu, I was wondering if a 2nd option could be added that would be a setting based on percentage similar to Audacity. Audacity has two options for Speed control one being “Speed Multiplier” (which functions similar to Shotcut’s “Speed” control) and a second option right next to it called “Percent Change” which allows for even more specific control of the speed as it even goes into the negatives. Could a “Percent” option for speed control be added in Shotcut?
“Percent change” does not allow for more specific control of a single clip; -75% and 0.25 are equivalent. Aside from personal preference, is there a time where you see percent change having a superior function? Is -75% easier to communicate than 0.25x speed? For example, if a filter were going to be applied repeatedly, I could see percent change making more sense than a decimal, or with anything that iterates… Or maybe I am overlooking something? In what ways do you find percent change to be helpful in audio/video editing?
Yes, it does. I’ve compared it on Audacity. Audacity’s “Percent Change” counter doesn’t measure it by just two numbers like in 75% as you wrote it. It’s like “1.000” just as how its “Speed Multiplier” has it and how the Speed counter in Shotcut is now. It measures the speed control differently than the “Speed Multiplier”. It also allows for negatives which in “Percent Change” matters since that’s how one can correct PAL speed up.
To give a specific example, in Audacity I put in the audio file of a movie with a PAL speed up. Its running time:
1h48m40.992s
I used the Speed control on Shotcut (18.07.02) to set it at 0.959 and it came out:
1h53m19.829s
I ran it with an equivalent video that does not have PAL speed and it was at sync at first but went out of sync as time went on.
I went on Audacity and used 0.959 also on its “Speed Multiplier” and it came out:
1h53m19.783s
It went out of sync again after a bit.
Then I used Audacity’s 2nd option “Percent Change” with a figure of -4.094 and the file came out to:
1h53m19.358s
And this time it ran completely in sync from start to finish. The Speed control options in both Audacity and Shotcut cannot hit the above time. The difference between 0.959 and 0.958 in Shotcut is about 7 seconds so with the current options it’ll just go over or under the speed needed.
An equivalent Percentage feature in Shotcut as a 2nd option would be fantastic so that way conversion of both video and audio from PAL speed could be done in one program. And aside from PAL speed up issues, one could end up getting faulty video and/or audio that needs speed correction that needs more specific timing and that’s where a Percentage option would be most useful which again could all be done all in one program rather than having to use multiple ones for video and audio. Shotcut’s almost there for this. I hope a feature like this can be added.
Just to summarize - this has little to do with multipliers vs percentages, and everything to do with the number of digits the field accepts
The -4.094% comes out to a multiplier of 0.95906 , but the speed input field only allows for 3 decimal digits, meaning 0.959 is as close as the user can get. Over very long clips (in this case, almost 2 hours), that can add up to a noticeable difference.
A short term ‘fix’ would thus be to accept more digits in that UI field, presuming that internally it doesn’t drop digits. You might also in the interim edit the .mlt file directly (‘warp_speed’ value - there’s a few others, but those should only be for display purposes) and see if that does the trick or not.
@DRM and @SteeveB Thank you for explaining the decimal place accuracy issue.
If your ultimate goal is to convert to/from PAL, a little googling suggests that you may want a LOT of decimal places, not just 1 or 2 more, but dozens of them.
(I suspect that Audacity ultimate uses either Speed Multiplier or Percent Change, and converts one to the other before doing the final calculation. In which case it really would be all about those decimal places…)
Yes, long term it would be good to have the ‘duration’ field reflect the actual clip length (rather than source media), be stable, and calculate the necessary multiplier internally. That way if the clip is 1h2m3s and you know it should be 1h exactly, that can be entered directly rather than doing the calculation manually and trying to see if “0.967” is close enough, or “0.9669621” would be needed, or even more precision than that.
There is a practical limit to the accuracy required, though. At some point the least significant digit isn’t going to change a difference of 1 frame at the end of, say, a 10 hour clip (those are still a thing on YouTube, I suppose) - and you’d pass the threshold for noticing audio/video sync issues long before that. I’ll leave figuring out how many digits are required for that as an exercise
As I have detailed above, dozens of decimal points are not needed. That would just be pedantic.
From what I see, “Speed Multiplier” and “Percent Change” are used in Audacity as simply different units of measure with one being more broad and the other being more minute. Think meters vs millimeters. A 0.001 “Speed Multiplier” makes a difference of 0.100 in “Percent Change”.
To be more clear, typing in 0.001 in “Speed Multiplier” will give you an equivalent of -99.900 in “Percent Change”. Typing in 0.002 in “Speed Multiplier” will give you an equivalent of -99.800 in “Percent Change”.
Practically and functionally, sure, that does seem to be how Audacity is treating those two fields. And even someone who is used to using multipliers (like me) might consider starting by inputting a multiplier, and then tweaking Audacity’s Percent Change field’s extra digits for added resolution.
Personally, though I have no opinion about a potential implementation in Shotcut, if I were going to code both fields, I might make two fewer digits in the Percent Change field so that they were more equivalent…
Pedantically speaking, in case anyone finds this thread while searching for Percent Change information: I would not recommend that anyone think of it as meters vs millimeters (though you are certainly welcome to think of it that way if that is what works for you). The multiplier is describing the resultant magnitude after transformation; the percent change is the amount of transformation that will occur. It’s not a simple decimal place change.
Hey, SteeveB, first I want to thank you for making a good summary of my post as it hits the points I was making in a much more efficient fashion.
I tried your suggestion of editing the mlt file directly with that number you calculated and sadly it did not work.
Now you seemingly have a good understanding of this area so I would like to ask you that since it appears to me that “Speed Control” and “Percent Change” is essentially just a different way of measuring the speed with one simply being more minute in the control than the other, would a remedy of simply adding two more decimal points to Shotcut’s “Speed” function be the adequate solution? Seeing as how you would able to calculate it I am wondering if you would verify if just adding two (or maybe three?) decimal points cover those numbers that “Percent Change” can hit. I am suggesting this in case adding an actual “Percent Change” option or some kind of an equivalent be too much trouble.
I was actually thinking of suggesting just adding more decimal points in the opening post but I didn’t know if adding two or more decimal points would result it looking more intimidating to users especially beginners in video editing. Maybe there could be like a checkbox above it or something that says something like “Advanced” that when checked would make the “Speed” function add more decimal points in the box?
Adding 2 digits should cover practically anything that the “% change” would cover as well, yes. Whether that is sufficient for all cases is another matter entirely. And, yes, you are probably correct that it might be daunting for new users to see that many digits in a user interface field. Ideally the field itself can be displayed by default with just 2-3 digits, using increase/decrease modifiers would adjust by that least significant digit as well, but you could enter a more precise number and have that displayed as well. I have no idea if the Qt framework allows for that.
I’m also not sure that just adding those digits to the field’s settings (it’s set in a UI descriptor file) is all that is needed if adjusting the XML did not work (d’oh), as that would imply there’s some internal limits as well.
If you opened the MLT XML in Shotcut and selected the clip with a speed change, then the Properties panel reduced the number of decimal digits. Internally, it is using double precision floating point numbers and is able to have more digits. I can add 2 more decimal digits easily enough.
As I said, I didn’t know if simply asking for more decimal points would result in the Speed option looking more intimidating for most users so I suggested that maybe adding a tick box somewhere near the Speed option like it saying “Advanced” would then add more decimal points. So, if it’s not ticked then it just looks like it does now (0.000) but if ticked then it adds more decimal points (0.000000)? What do you reckon?
I might as well ask for 3 more decimal points and not just 2 just to be sure. Plus, it’ll one up Audacity.
I actually did it last night with 3 additional digits instead of 2. No advanced checkbox; I do not think the extra digits are necessarily advanced or too obnoxious.
Dan, I just tried the latest version released (18.08.11) and it looks like there might be a bug with the added decimal points. It won’t let me change the last decimal point. So, for example, I keep trying to enter 1.000105 but when I hit enter it always goes to 1.000110.
Is this bug that you found affecting the conversion of the Speed control itself so it’s not as precise as it should be or is it just related to entering numbers in the decimal points?
It is related to the entering of digits using the widget/control; it never gives me more than 5 decimal digits even though it is configured for more. I tried configuring it for 7 and 8 decimal digits as well - no difference. I will test it with a newer version of Qt sometime soon, I hope.
Any update on this, @shotcut? According to the info I see on that wiki here, QT 5.12 is right now in the middle of its beta stages. Have you contacted them regarding this bug in hopes that they can fix it in time for its final release slated for the end of November?
