There is always a need to add fade-in and fade-out to audio tracks. Here is a way of doing it for a bunch of video files. It may come in handy with the audio normalization script I have shown previously. That script is based on continuously normalizing the audio, which may result in some noise in the beginning and end (because there is little/no sound in those parts, hence they are normalized more).
It is easy to add a fade-in to the beginning of a file using FFmpeg’s afade function. From the documentation, you can do a 15-second fade-in like this:
And a 25-second fade-out like this:
Unfortunately, the latter requires that you specify when to start the fade-out. That doesn’t work well in general, and particularly not for batch processing.
A neat trick
Searching for solutions, I found a neat trick that solved the problem. First, you create the normal fade-in. Then you make the fade-out by reversing the audio stream, applying a fade-in, and then reversing again. The whole thing looks like this:
After exploring some visualizations of kayaking, I was eager to see how a similar approach could work for walking. On a trip to the Norwegian mountains, specifically at Haugastøl, situated halfway between Oslo and Bergen, I strapped a GoPro Hero Black 10 on my chest and walked up and down a nearby hill called Storevarden. The walk was approximately 25 minutes up and down, and a fast-forward version of the video can be seen here:
The first trial was to create some static visualizations from the video recording.
The average image is not particularly interesting in this case. Then it may be better to create a history video that averages images over a shorter period, such as in this video:
Still quite shaky, but it creates an interesting soft-focus rendition of the video. This may resemble how I perceived the scenery as I walked up and down.
A better visualization, then, are the videograms, which give more information about the spatiotemporal features of the video recording.
The videograms are based on collapsing the original images in the video sequence. Motiongrams, on the other hand, collapse the motion image sequence, clearly showing what changed between frames.
What can one get out of the audio recording of walking? The waveform does not tell much, except that the average levels look higher in the second half (where I was walking down).
It is fascinating how the estimated tempo of my walking was almost 120 BPM, which happens to be similar to the 2 Hz frequency found in many studies of walking and everyday activities. It will be interesting to try a similar approach for other walking videos.
The idea has been to do as little processing as possible to the recordings. That is because I want to capture sounds and actions as naturally as possible. The recorded files will also serve as source material for both scientific and artistic explorations later. For that reason, I only trim the recordings non-destructively using FFmpeg.
Recording the dice example, however, I noticed an unfortunate low-frequency hum in the original recording:
I like the rest of the recording, so I thought it would be a pity to skip publishing this sound action only because of the hum. So I decided to break my rule of not processing the sound and apply a simple highpass filter to remove the noise.
Fortunately, FFmpeg, as always, comes to the rescue. It has myriad audio filters that can be combined in various ways. I only needed to add a highpass filter, which can be accomplished using this one-liner:
Here I use the -c:v copy to copy the video stream directly. This avoids re-compressing the file and saves time. Then I use the -af highpass=400 function to add the highpass filter to the audio stream with a frequency of 400 Hz. This is relatively high but works well for this example.
Adding a filter means that the audio stream needs to be re-compressed. So it breaks with the original (conceptual and technical) idea. However, the result sounds more like how I experienced it. I didn’t notice the hum while recording, and this project is focused on foreground sounds, not the background. However, this example is relevant for my upcoming project, AMBIENT, in which I will focus on the background sound of various in-door environments.
I stumbled upon the feature “horizon leveling” by accident when going through the settings on the GoPro Max. The point is that it will stabilize the recorded image so that the horizon will always be leveled. I haven’t found any tech details about the feature, but assume that it uses a built-in gyroscope for the leveling. As it turns out, this feature also appears to be included on the GoPro Hero 9 and 10.
This feature works amazingly well, as can be seen from an excerpt of my kayaking adventure below:
The Musical Gestures Toolbox for Python is in active development and I, therefore, thought it could be interesting to test some video visualization methods on the kayaking video. The whole video recording is 1.5 hours long, which is a good starting point for exploring some of the video visualization techniques in the toolbox. After all, one of the points of the toolbox was to develop solutions for visualizing long video recordings without scene changes.
My recordings of music or dance performances are similar to my kayaking videos in that they are based on continuous single-camera recordings. So I tested some of the basic visualization techniques.
Kayaking is a rhythmic activity, so I was interested in also looking at whether I could find any patterns in the audio signal. For now, I have only calculated a tempogram, which estimates the tempo of my kayaking strokes to 114 BPM. I am not sure if that is good or bad (I am only a recreational kayaker) but will try to make some new recordings and compare.
After testing the Musical Gestures Toolbox for Python more actively over the last few weeks, I see that we have now managed to get it to a state where it really works well. Most of the core functions are stable and they allow for combinations in various ways, just like a toolbox should. There are still some optimization issues to sort out, particularly when it comes to improving the creation of motion videos. But overall it is a highly usatile package.
In my ever-growing collection of FFmpeg-related blog posts, I will today show how to add subtitles to videos. These tricks are based on the need to create a captioned version of a video I made to introduce the Workshop on NIME Archiving for the 2022 edition of the International Conference on New Interfaces for Musical Expression (NIME).
Why add subtitles to videos?
I didn’t think much about subtitles previously but have become increasingly aware of their importance. Firstly, adding subtitles is essential from an accessibility point of view. In fact, at UiO, it is now mandatory to add subtitles to all videos we upload to the university web pages. The main reason is that people that have problems hearing the content can read.
Also, for people that can hear sound in the video, it is helpful to have subtitles available. On Twitter, for example, videos will play automatically when you hover over them. However, the sound will usually be off, so without subtitles, it is impossible to hear what is said. There are also times when you may want to only watch some content without listening, for example, if you don’t have headphones available in a public setting.
I guess that having subtitles also helps search engines find your content more efficiently, which may lead to better dissemination of the content.
There are numerous ways of doing this, but I usually rely on some machine listening service as the first step these days. At UiO, we have a service called Autotekst that will create a subtitle text file from an audio recording. The nice thing about that service is that it supports both English and Norwegian and two people talking. It is pretty ok but does require some manual cleanup. I typically do that in a text editor while checking the video.
YouTube offers a more streamlined approach for videos uploaded to their service. It has machine listening built in that works quite well for one person talking in English. It also has a friendly GUI where you can go through and check the text and align it with the audio.
I typically use YouTube for all my public videos in English and UiO’s service for material in Norwegian and with multiple people.
Closed Caption formats
Various services and platforms support at least 25 different subtitle formats. I have found that SRT (SubRip) and VTT (Web Video Text Tracks) are the two most common formats. Both are supported by YouTube, while Twitter prefers SRT (although I still haven’t been able to upload one such file successfully). The video player on UiO prefers VTT, so I often have to convert between these two formats.
Fortunately, FFmpeg comes to the rescue (again). Converting from one subtitle format to another is as simple as writing this one-liner:
ffmpeg -i caption.srt caption.vtt
This will convert an SRT file to VTT in a split second. As the screenshot below shows, there is not much difference between the two formats.
Playing back videos with subtitles
Web players will play subtitles associated with them, but what about on a local machine. If the subtitle file is named the same as the video file, most video players will use the subtitles when playing the file. Here is how it looks in VLC on Ubuntu:
It is also possible to go into the settings to turn the subtitles on and off. I guess it is also possible to have multiple files available to add additional language support, and that would be interesting to explore another time.
Embedding subtitles in video files
We are exploring using PubPub for the NIME conference, a modern publication platform developed by The MIT Press. There are many good things to say about PubPub, but some features are still missing. Adding a subtitle file to uploaded videos is one missing feature. I, therefore, started exploring whether it is possible to embed the subtitles inside the video file.
A video file is built as a “container” that holds different content, of which video and audio are two (or more) “tracks” within the file. The nice thing about working with FFmpeg is that one quickly understands how such containers are constructed. And, just as I expected, it is possible to embed an SRT file (and probably others too) inside of a video container.
As discussed in this thread, many things can go wrong when you try to do this. I ended up with this one-liner:
The trick is to think of the subtitle file as just another input file that should be added to the container. The result is a video file with subtitles built in, as shown below:
It may have been a long shot, but the PubPub player didn’t support such embedded subtitles either. Then I started exploring a more old-school approach, “burning” the text into the video file. I feared that I had to do this within a video editor, but, again, it turned out that FFmpeg could do the trick:
This “burns” the text into the video, which is not the best way of doing it, I think. After all, the nice thing about having the subtitles in text form is that they can be turned on and off and adjusted in size. Still, having some subtitles may be better than nothing.
Posting on Twitter
After having gone through all that trouble, I wanted to post the video on Twitter. This turned out to be more difficult than expected. Three problems arose.
First, Twitter does not support 4K videos, so I had to downsample to Full HD. Fair enough, that is easily done with FFmpeg. Second, Twitter only supports videos shorter than 2:20 minutes; mine is 2:34. Fortunately, I could easily cut out the video’s first and last sentence, and it still made sense. However, this also leads to trouble with the subtitles. The subtitles are based on the timing of the original video. So if I were to trim the video, I would also need to edit the subtitle file to adjust all the timings (Happy to get input on tools for doing that!).
After spending too much time on this project, I reverted to the “burned” text approach. Writing the text into the video and trimming it would ensure some text together with the video. While preparing the one-liner, I wondered whether FFmpeg would be smart enough to also “trim” the subtitles when trimming the video file:
The command above does it all one go: downscale from 4K to HD, add the subtitles, and trim the video to the desired duration. Unfortunately, this command kept text from the sentence that was trimmed out in the beginning:
The extra words at the beginning of the video are perhaps not the biggest problem. I would still be interested to hear thoughts on how to avoid this in the future. After all, subtitles are here to stay.