Feature request: audio speedup

[yuripetnys]

Hello. I use Aegisub a lot for spotting/timing and I could really use a function that speeds up the audio reproduction by a multiplier (1.5-2.0x). I did some tests by speeding up the video with ffmpeg and it did enhance my productivity, but scaling the subs back to normal messes up the keyframe alignment. Having it natively would fix the issue.

Thanks for updating Aegisub

[MaxHasBeenUsed]

Do you mean a speed control for both video and audio stream or just the audio stream? Also why would you speed up the stream to spot/time the subtitle, isn't it harder to get frame-scale accuracy if you speed things up?

I've thought about 1.5x/2x speed to roughly check for mistakes after subtitle is finished, wonder if that's what you want. Either way, I just found this so don't think the feature is ever gonna land.

Quote:

Before you press the “play” button

Think it through. Do you really want to play the video? (Hint: the answer is “no”, you don’t want to do that, at least not in Aegisub.) If you’re trying to check if a subtitle matches up to something in the video, wouldn’t it be easier to just step through the video frame-by-frame with the arrow keys? If you’re proofwatching, it would be a better idea to watch it in a player your viewers might actually use.

Edit: dup of #115 ?

[yuripetnys]

A few things to consider:

• I believe speeding up audio/video would be adequate for slower content such as travelogues and nature documentaries, which usually have long runtimes and people talk at a slower pace, at irregular intervals with long periods of silence. I've done my share of that type of content and that's where I came up with the idea to speed up the raw to enhance workflow, and it worked - although a native solution would be better.
• Frame accuracy isn't an issue, since that's mostly controlled by the horizontal scale on the audio spectrum and not by the audio speed. Also, keyframe snapping and proper keyframe generation helps a bunch.
• VLC isn't very reliable rendering subs in higher speeds - for some reason, the renderer forgets to start/stop rendering certain lines at the correct time, so for proof-checking it isn't an ideal solution. I could hardsub prior to checking, but at this point I'd rather simply proofcheck in 1x. Sometimes you just want to give it a quick pass to ensure everything is in place.
• You could argue that slowing down audio/video playback could also help translators to understand/untangle particularly complicated lines where people talk too fast, so there's another use for a global video/audio speed control.

I understand if this ticket is closed/dropped, but I thought it'd be a fair shot since this is the one thing in my workflow that I can't easily work around with Lua scripts or external solutions.

[MaxHasBeenUsed]

Thank you for the ideas!

I believe speeding up audio/video would be adequate for slower content such as travelogues and nature documentaries

I totally get your point on this. Have worked with similar content myself, and a speed up surely can elevate efficiency.

VLC isn't very reliable rendering subs in higher speeds

Not sure what you mean by this. In settings in arch1t3cht's fork I can only see FFmpeg, Avisynth, BestSource, and VapourSynth as video source. Though after looking up online I found someone saying VLC could be used as an external video player, maybe you are using that? Aside from all these, I would say performance is a big concern. If Aegisub can't hit performance target with higher play speed, then it'd better not provide this feature at all.

I have found a similar issue (#115), perhaps you want to put some of your ideas and suggestions there.

Also bit off-topic here: how do you "scaling the subs back to normal"? Do you use Aegisub or anything else?

[yuripetnys]

About VLC: I was referring to the idea of proofwatching content on external players, as suggested by the Aegisub docs. In my experience, it isn't really adequate for high-speed proofwatching.