David P. Goldman is deputy editor of Asia Times and a fellow of the Claremont Institute’s Center for the American Way of Life.
What a fash-coded name for a think tank. Might as well call it the Center for Securing the Existence of Our People and a Future for White Children.
In text form:
Abstract
Amid the current U.S.-China technological race, the U.S. has imposed export controls to deny China access to strategic technologies. We document that these measures prompted a broad-based decoupling of U.S. and Chinese supply chains. Once their Chinese customers are subject to export controls, U.S. suppliers are more likely to terminate relations with Chinese customers, including those not targeted by export controls. However, we find no evidence of reshoring or friend-shoring. As a result of these disruptions, affected suppliers have negative abnormal stock returns, wiping out $130 billion in market capitalization, and experience a drop in bank lending, profitability, and employment.
Quote from conclusion
Moreover, the benefits of U.S. export controls, namely denying China access to advanced technology, may be limited as a result of Chinese strategic behavior. Indeed, there is evidence that, following U.S. export controls, China has boosted domestic innovation and self-reliance, and increased purchases from non-U.S. firms that produce similar technology to the U.S.-made ones subject to export controls.
Yeah I know that feeling, I posted and add unnecessary noise to Phil Harvey’s forum about something I though was a “bug” or odd behavior with EXIF-tool, while it’s was just my lacking reading skills… I felt so dumb :/
Happens to the best of us! As long as you make a genuine effort to find a solution, I think most people will be happy to help regardless.
As for the version of the unique name code you wrote, you got the spirit! The problem is that the try block will only catch the exception the first time around, so if there are two duplicates the uncaught exception will terminate the script. Separately, when working with exceptions it’s important to be mindful of which particular exceptions the code in the try block might throw and when. In this case, if the move is to another directory in the same filesystem, shutil.move will match the behavior of os.rename which throws different types of exceptions depending on what goes wrong and what operating system you’re on. Importantly, on Windows, it will throw an exception if the file exists, but this will not generally occur on Unix and the file will be overwritten silently.
(actually, I just realized that this may be an issue with pasting in your Python code messing up the indentation–one of the flaws of Python. If this was your actual code, I think it would work:)
try:
shutil.move(d['SourceFile'], subdirectory)
except:
i = 0
while os.path.exists(d['SourceFile']):
i += 1
base_name, extension = os.path.splitext(d['SourceFile'])
new_filename = f"{base_name}-{i}{extension}"
print(new_filename)
os.rename(d['SourceFile'], new_filename)
shutil.move(new_filename, subdirectory)
(oh, and I should have mentioned this earlier, but: for Markdown parsers that support it (including Lemmy and GitHub) if you put the name of the language you’re writing in after your opening triple ` (e.g. ```python or ```bash) it’ll give you syntax highlighting for that language (although not as complete as what you’d see in an actual code editor))
Really cool that you figured out how to do it with exiftool natively–I’ll be honest, I probably wouldn’t have persevered enough to come up with that had it been me! Very interesting that it ended up being slower than the Python script, which I wouldn’t have expected. One thing that comes to mind is that my script more or less separates the reads and writes: first it reads all the metadata, then it moves all the files (there are also reads to check for file existence in the per-file operations, but my understanding is that this happens in compact contiguous areas of the drive and the amount of data read is tiny). If exiftool performs the entire operation for one file at a time, it might end up being slower due to how storage access works.
Happy to have been able to help! Best of luck to you.
Wow, nice find! I was going to handle it by just arbitrarily picking the first tag which ended with CreateDate, FileModifyDate, etc., but this is a much better solution which relies on the native behavior of exiftool. I feel kind of silly for not looking at the documentation more carefully: I couldn’t find anything immediately useful when looking at the documentation for the class used in the script (ExifToolHelper) but with the benefit of hindsight I now see this crucial detail about its parameters:
All other parameters are passed directly to the super-class constructor:
exiftool.ExifTool.__init__()
And sure enough, that’s where the common_args parameter is detailed which handles this exact use case:
common_args (list of str*, or* None.) –
Pass in additional parameters for the stay-open instance of exiftool.
Defaults to
["-G", "-n"]as this is the most common use case.
-G(groupName level 1 enabled) separates the output with groupName:tag to disambiguate same-named tags under different groups.
-n(print conversion disabled) improves the speed and consistency of output, and is more machine-parsablePassed directly into common_args property.
As for the renaming, you could handle this by using os.path.exists as with the directory creation and using a bit of logic (along with the utility functions os.path.basename and os.path.splitext) to generate a unique name before the move operation:
# Ensure uniqueness of path
basename = os.path.basename(d['SourceFile'])
filename, ext = os.path.splitext(basename)
count = 1
while os.path.exists(f'{subdirectory}/{basename}'):
basename = f'{filename}-{count}{ext}'
count += 1
shutil.move(d['SourceFile'], f'{subdirectory}/{basename}')
Alright, here’s what I’ve got!
#!/usr/bin/env python3
import datetime
import glob
import os
import re
import shutil
import exiftool
files = glob.glob(r"/path/to/photos/**/*", recursive=True)
# Necessary to avoid duplicate files; if all photos have the same extension
# you could simply add that extension to the end of the glob path instead
files = [f for f in files if os.path.isfile(f)]
parent_dir = r'/path/to/sorted/photos'
start_date = datetime.datetime(2015, 1, 1)
end_date = datetime.datetime(2024, 12, 31)
date_extractor = re.compile(r'^(\d{4}):(\d{2}):(\d{2})')
with exiftool.ExifToolHelper() as et:
metadata = et.get_metadata(files)
for d in metadata:
for tag in ["EXIF:DateTimeOriginal", "EXIF:CreateDate",
"File:FileModifyDate", "EXIF:ModifyDate",
"XMP:DateAcquired"]:
if tag in d.keys():
# Per file logic goes here
year, month, day = [int(i) for i in date_extractor.match(d[tag]).group(1, 2, 3)]
filedate = datetime.datetime(year, month, day)
if filedate < start_date or filedate > end_date:
break
# Can uncomment below line for debugging purposes
# print(f'{d['File:FileName']} {d[tag]} {year}/{month}')
subdirectory = f'{parent_dir}/{year}/{month}'
if not os.path.exists(subdirectory):
os.makedirs(subdirectory)
shutil.move(d['SourceFile'], subdirectory)
break
Other than PyExifTool which will need to be installed using pip, all libraries used are part of the standard library. The basic flow of the script is to first grab metadata for all files using one exiftool command, then for each file to check for the existence of the desired tags in succession. If a tag is found and it’s within the specified date range, it creates the YYYY/MM subdirectory if necessary, moves the file, and then proceeds to process the next file.
In my preliminary testing, this seemed to work great! The filtering by date worked as expected, and when I ran it on my whole test set (831 files) it took ~6 seconds of wall time. My gut feeling is that once you’ve implemented the main optimization of handling everything with a single execution of exiftool, this script (regardless of programming language) is going to be heavily I/O bound because the logic itself is simple and the bulk of time is spent reading and moving files, meaning your drive’s speed will be the key limiting factor. Out of those 6 seconds, only half a second was actual CPU time. And it’s worth keeping in mind that I’m doing this on a speedy NVME SSD (6 GB/s sequential read/write, ~300K IOPS random read/write), so it’ll be slower on a traditional HDD.
There might be some unnecessary complexity for some people’s taste (e.g. using the datetime type instead of simple comparisons like in your bash script), but for something like this I’d prefer it to be brittle and break if there’s unexpected behavior because I parsed something wrong or put in nonsensical inputs rather than fail silently in a way I might not even notice.
One important caveat is that none of my photos had that XMP:DateAcquired tag, so I can’t be certain that that particular tag will work and I’m not entirely sure that will be the tag name on your photos. You may want to run this tiny script just to check the name and format of the tag to ensure that it’ll work with my script:
#!/usr/bin/env python3
import exiftool
import glob
import os
files = glob.glob(r"/path/to/photos/**/*", recursive=True)
# Necessary to avoid duplicate files; if all photos have the same extension
# you could simply add that extension to the end of the glob path instead
files = [f for f in files if os.path.isfile(f)]
with exiftool.ExifToolHelper() as et:
metadata = et.get_metadata(files)
for d in metadata:
if "XMP:DateAcquired" in d.keys():
print(f'{d['File:FileName']} {d[tag]}')
If you run this on a subset of your data which contains XMP-tagged files and it correctly spits out a list of files plus the date metadata which begins YYYY:MM:DD, you’re in the clear. If nothing shows up or the date format is different, I’d need to modify the script to account for that. In the former case, if you know of a specific file that does have the tag, it’d be helpful to get the exact tag name you see in the output from this script (I don’t need the whole output, just the name of the DateAcquired key):
#!/usr/bin/env python3
import exiftool
import json
with exiftool.ExifToolHelper() as et:
metadata = et.get_metadata([r'path/to/dateacquired/file'])
for d in metadata:
print(json.dumps(d, indent=4))
If you do end up using this, I’ll be curious to know how it compares to the parallel solution! If the exiftool startup time ends up being negligible on your machine I’d expect it to be similar (since they’re both ultimately I/O bound, and parallel saves time by being able to have some threads executing while others are waiting for I/O), but if the exiftool spin-up time constitutes a significant portion of the execution time you may find it to be faster! If you don’t end up using it, no worries–it was a fun little exercise and I learned about a library that will definitely save me some time in the future if I need to do some EXIF batch processing!
Yeah, I think the fact that you need to capture the output and then use that as input to another exiftool command complicates things a lot; if you just need to run an exiftool command on each photo and not worry about the output I think the -stay_open approach would work, but I honestly have no idea how you would juggle the input and output in your case.
Regardless, I’m glad you were able to see some improvement! Honestly, I’m the wrong person to ask about bash scripts, since I only use them for really basic stuff. There are wizards who do all kinds of crazy stuff with bash, which is incredibly useful if you’re trying to create a portable tool with no dependencies beyond any binaries it may call. But personally, if I’m just hacking myself together something good enough to solve a one-off problem for myself I’d rather reach for a more powerful tool like Python which demands less from my puny brain (forgive my sacrilege for saying this in a Bash community!). Here’s an example of how I might accomplish a similar task in Python using a wrapper around exiftool which allows me to batch process all the files in one go and gives me nice structured data (dictionaries, in this case) without having to do any text manipulation:
import exiftool
import glob
files = glob.glob(r"/path/to/photos/**/*", recursive=True)
with exiftool.ExifToolHelper() as et:
metadata = et.get_metadata(files)
for d in metadata:
for tag in ["EXIF:DateTimeOriginal", "EXIF:CreateDate", "File:FileCreateDate", "File:FileModifyDate", "EXIF:DateAcquired"]:
if tag in d.keys():
# Per file logic goes here
print(f'{d["File:FileName"]} {d[tag]}')
break
This outline of a script (which grabs the metadata from all files recursively and prints the filename and first date tag found for each) ran in 4.2 s for 831 photos on my machine (so ~5 ms per photo).
Since I’m not great in bash and not well versed in exiftool’s options, I just want to check my understanding: for each photo, you want to check if it’s in the specified date range, and then if it is you want to copy/move it to a directory of the format YYYYMMDD? I didn’t actually handle that logic in the script above, but I showed where you would put any arbitrary operations on each file. If you’re interested, I’d be happy to fill in the blank if you can describe your goal in a bit more detail!
Without looking too carefully at your script, I strongly suspect the issue is the time it takes to spin up an exiftool process once per file (not ideal for any program, but I find that exiftool is especially slow to start).
I have never done this myself, but apparently there’s an option -stay_open which allows you to start up exiftool once and have it continually read arguments from a file or pipe. If you were to write your script around this flag I suspect it would be much faster. Here’s a brief forum discussion which may prove useful.
If you decide to do that, let me know how it goes! Might use it myself should the need arise.
I think you meant to post this in a thread about MGS
Thanks liberal justices, very cool!
According to a site admin from that forum post (which is from April 2021–who knows where things stand now):
If you use the OpenSubtitles website manually, you will have advertisements on the web site, NOT inside the subtitles.
If you use some API-software to download subtitles (Plex, Kodi, BSPlayer or whatever), you are not using the web site, so you do NOT have these web advertisements. To compensate this, ads are being added on-the-fly to the subtitles itself.
Also, from a different admin
add few words from my side - it is good you are talking about ads. They not generating a lot of revenue, but on other side we have more VIP subscriptions because of it :) We have in ads something like “Become VIP member and Remove all ads…”
Also, the ads in subtitles are always inserted on “empty” space. It is never in middle of movie. What Roozel wrote - “I think placing those ads at the beginning and end is somewhat OK but not in the middle or at random points in the film” - should not happen, if yes, send me the subtitle.
If the subtitle is from tv series, there are dialogues from beginning usually. System is finding “quiet” place where ads would fit, and yes, this can be after 3 minutes of dialogue…
This is important to know, I hope now it is more clear about subtitle ads - why we are doing this, there is possibility to remove them and how system works.
so a scenario like in the screenshot isn’t supposed to happen. I guess if you really wanted to see if it happens you could grab all the English subs via the API and just do a quick grep or what-have-you
deleted by creator
There’s a variable that contains the number of cores (called cpus) which is hardcoded to max out at 8, but it doesn’t mean that cores aren’t utilized beyond 8 cores–it just means that the scheduling scaling factor will not change in either the linear or logarithmic case once you go above that number:
/*
* Increase the granularity value when there are more CPUs,
* because with more CPUs the 'effective latency' as visible
* to users decreases. But the relationship is not linear,
* so pick a second-best guess by going with the log2 of the
* number of CPUs.
*
* This idea comes from the SD scheduler of Con Kolivas:
*/
static unsigned int get_update_sysctl_factor(void)
{
unsigned int cpus = min_t(unsigned int, num_online_cpus(), 8);
unsigned int factor;
switch (sysctl_sched_tunable_scaling) {
case SCHED_TUNABLESCALING_NONE:
factor = 1;
break;
case SCHED_TUNABLESCALING_LINEAR:
factor = cpus;
break;
case SCHED_TUNABLESCALING_LOG:
default:
factor = 1 + ilog2(cpus);
break;
}
return factor;
}
The core claim is this:
It’s problematic that the kernel was hardcoded to a maximum of 8 cores (scaling factor of 4). It can’t be good to reschedule hundreds of tasks every few milliseconds, maybe on a different core, maybe on a different die. It can’t be good for performance and cache locality.
On this point, I have no idea (hope someone more knowledgeable will weigh in). But I’d say the headline is misleading at best.
Great, I’m so glad to hear that! Tartube can be a little intimidating with it’s sprawling menus and sub-menus, but when it comes down to it most of the core functionality is pretty accessible once you know where to look and can ignore all the hyper-specific options for power users.
1. No idea, to be honest. In the environment I tested this in (Windows 10 Sandbox) Windows Defender didn’t complain, and I’ve never had an issue with my actual install either. In fact, I just checked my installation folders on my PC and didn’t even find that executable (maybe it’s only used during installation?) although I do have it on my system for a different program. I only found one Google hit from 5 years ago on the glslang Github itself, and the user seemed to think it was a false positive for what it’s worth.
2. They are supposed to be there by default (they store metadata) but you can set up Tartube to put them in separate folders if you want to just have a nice clean folder with only videos or just not write them in the first place if you don’t want them. I believe the metadata is copied into Tartube’s database, so deleting them shouldn’t change anything (they’re mostly useful for archival purposes or if you want to do some processing with external tools), but Tartube references the thumbnail image files for display in the GUI so removing them will remove the thumbnail from the GUI like so:
This is pretty straightforward to configure, thankfully:
3. (hosted externally due to Lemmy sanitization bug causing less-than symbols to be HTML escaped)
edit: accidentally left out a line in the externally hosted markdown
Okay, Tartube can definitely handle what you want with a few additional flags! Here’s the mediainfo for the output file after doing a test run on this MrBeast video (note that the audio track is incorrectly marked as English but is indeed Japanese, and that S_TEXT is how SRT appears in an MKV file):
General
Unique ID : 242275721910232180380466434100717751726 (0xB6449B54C970D7DBA0EB469BBD590DAE)
Complete name : C:\Users\WDAGUtilityAccount\Tartube\Test Audio Playlist\$1 vs $100,000,000 House!.mkv
Format : Matroska
Format version : Version 4
File size : 556 MiB
Duration : 17 min 35 s
Overall bit rate : 4 418 kb/s
Frame rate : 29.970 FPS
Writing application : Lavf60.3.100
Writing library : Lavf60.3.100
ErrorDetectionType : Per level 1
Video
ID : 1
Format : VP9
Format profile : 0
Codec ID : V_VP9
Duration : 17 min 35 s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (29970/1000) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Title : ISO Media file produced by Google Inc. Created on: 11/09/2023.
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
VENDOR_ID : [0][0][0][0]
Audio
ID : 2
Format : Opus
Codec ID : A_OPUS
Duration : 17 min 35 s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Bit depth : 32 bits
Compression mode : Lossy
Delay relative to video : 7 ms
Language : English
Default : Yes
Forced : No
Text
ID : 3
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Duration : 17 min 30 s
Language : English
Default : No
Forced : No
I did this all on Windows 10 in Windows Sandbox with a fresh Tartube install to make sure I didn’t have some lurking non-default setting causing unexplained behavior. Here’s what to do to get the same results, along with a screen recording of the same process with some rough edits (don’t be scared off by the long instructions–it’s mostly me just explaining what the options do, and it should only take about five to ten minutes!):
Grab the 64-bit Windows installer here
Go through the install process leaving everything as default and installing yt-dlp and FFmpeg when prompted
Go through the tutorial just to get a sense of how things are laid out (it’s a lot to take in so don’t expect to remember everything, and I’m going to guide you through the exact steps do don’t worry)
Add your channel by first copying the /videos URL (e.g. https://youtube.com/@MrBeast/videos), clicking the Add channel icon (second from the left in the toolbar), and entering the channel name (this will be the name of the folder that videos are stored in). If the URL isn’t automatically grabbed, paste it into the second box.
Right-click the channel in the left-hand menu and select Downloads -> Apply download options
Make sure Create new download options is selected and click OK
(Optional) Give the options a sensible name, e.g. “Japanese Audio with embedded English SRT”
Paste these options into the Additional download options box:
--format bv*+ba[language=ja]/bv*+ba[language=en]/bv*+ba/best
--convert-subs srt
--compat-options no-keep-subs
Explanation of the options:
--convert-subs is pretty self explanatory–it will convert the YouTube VTT subs to SRT.
--format: the format selection is a hierarchy delineated by the /. First, it tries to download the best video with the best audio in Japanese (bv*+ba[language=ja]). If Japanese audio isn’t present, it tries English audio (bv*+ba[language=en]). If neither are present (which can also happen if the uploader failed to mark the language correctly), it grabs whatever the default audio track is. If all else fails, it grabs the best combined format (this should realistically never happen on YouTube). If you dislike any of those fallback options and/or would prefer that the download simply fail, feel free to delete any/all of them along with the preceding /, although I recommend at least leaving bv*+ba. For your use case, --format bv*+ba[language=ja] is the bare minimum which will fail if there isn’t an audio track explicitly labeled as Japanese.)
--compat-options no-keep-subs is necessary to make sure the subtitles are deleted after merging them into the MKV, since the options we will be setting through the GUI include both --write-subs and --embed-subs, and the default behavior in this scenario is to both embed the subs and write them to an external file. If you prefer to keep the external SRT file, simply remove this line.
(Optional) Click the Files tab at the top and customize the filename format. Personally, I’m partial to
%(upload_date)s %(title)s-%(id)s.%(ext)s
so that I can naturally sort things by upload date and easily go between URLs and videos (since YouTube URLs are just https://youtube.com/watch?v=[id]), but if you’re happy with the default title-only you can leave this be.
Click the Formats tab at the top. Set the drop-down for If merge is required after post-processing, output this format: to mkv. It will give you a warning that you need to also add it above, but as far as I can tell this is neither true (works fine without it) nor possible (mkv isn’t even listed there). If you do prefer specific video/audio formats or want a specific/maximum resolution, let me know and I can change the format option to accommodate that preference, since unfortunately this tab doesn’t account for multiple audio tracks.
Click the Subtitles tab at the top. Ensure that Download subtitle file for these languages: is selected and that English [en] is listed (if your default Windows language is English I think it’ll already be there, but if not, add it from the list on the left). Note that this will not grab the automatically-generated subtitles from YouTube, but it sounds like you don’t need these for your specific situation.
Click the More options sub-tab. Under Preferred subtitle formats write srt/best (I honestly don’t think this will affect YouTube since all subs seem to be VTT, but it can’t hurt). More importantly, check the box for During post-processing, merge subtitles file with video.
Click OK in the lower-right to save the download options. You’re done with the setup!
If you want to download the entire channel in this way, right-click the channel in the left-hand menu and click Download channel. You can monitor the download progress in the Progress tab and see the raw yt-dlp command line output in the Output tab. If you only want certain videos, instead choose Check channel. This will grab all the metadata for the channel’s videos, displaying them as a grid of thumbnails, and then you can select them through the GUI and download the specific ones you want. It also might be a good idea to do this if you want to test the options on one video to make sure you’re getting the result you want before going all-in on downloading the channel.
Looking over the yt-dlp output as a sanity-check, I can confirm it does the following things:
Writes en.vtt subtitles (English subtitles in the default YouTube format)
Selects the best video format (1080p VP9)
Selects the audio format 251-1 (which is the best Japanese audio on this particular video)
Converts subtitles to SRT
Merges all three tracks into MKV
Deletes external SRT
which I think is all the functionality you requested! Let me know if you have any further questions and I’ll do my best to answer them.
yt-dlp is gonna be the go-to tool for any YouTube downloading, but I don’t have much experience with frontends for it. I use Tartube for archiving channels, but it can be a bit byzantine and might be overkill for what you need–plus, there’s a decent chance you will need to manually enter some yt-dlp options anyway (although only during the setup process). That being said, it’s the only one I have experience with, so it’s the one I’ll recommend!
Couple of clarifying questions:
When you say “download a YouTube channel in a particular language”, do you just mean a general monolingual channel (e.g. Masahiro Sakurai’s Japanese channel), or do you mean a channel that has videos with multiple audio tracks (such as this video with three different language tracks)? Both are doable, but I think you’ll need to add an actual command line flag for the latter whereas the former should be achievable pretty simply through Tartube’s GUI.
Are the subtitles you’re talking about added by the uploader, or are they auto subs (in this case, auto subs that are auto translated)? Both are easily achievable through the GUI, just slightly different instructions for either one. Also, depending on the scope of things, the simplest approach might be to simply download all subtitles (may not want to do that for like a MrBeast video with a dozen subtitle tracks), which also sidesteps the possible issue where the language of tracks isn’t properly indicated by the uploader.
When you say “put all streams for a single video together”, do you mean that you don’t want the video and audio tracks merged into a single file, or just that when you try to download the video you get a pre-merged file that doesn’t contain the tracks that you want? Was a little confused by this part.
I know you’re looking for a GUI solution, but while I wait for clarification I might as well drop a basic yt-dlp command to give you an idea of the parameters we’re dealing with (here I’m assuming separate audio tracks and uploader-added subs):
yt-dlp --format bv+ba[language=ja] --sub-langs en --write-subs --convert-subs srt --download-archive channel_archive.txt video_or_channel_url_goes_here
--format bv+ba[language=ja]: gets the “best” video track and Japanese audio track (for a 4K video yt-dlp prefers the VP9 encode, but if it’s a video with a lot of views there may also be an AV1 encode–if you want that AV1 encode you have to explicitly opt for it by using bv[vcodec^=av01] instead of plain bv)
--sub-langs en: downloads English subtitle(s)
--write-subs: write subs to an external file (as opposed to embedding them)
--convert-subs srt: converts subs to srt format, if possible
--download-archive channel_archive.txt: writes the IDs of successfully downloaded videos to the specified file channel_archive.txt. If you re-run this command, these videos will be automatically and very speedily skipped over without needing to fetch any additional information. Even without this option, yt-dlp is smart enough to skip over videos that have already been downloaded (assuming the output filenames will be the same), but it will go through the entire process of fetching all the video information for each video up to the point it is about to start downloading, which is a huge waste of time if you’re just updating a channel archive and need only the newest three videos.
Everything in that command (except for the audio track bit, to my knowledge) can be handled in the Tartube GUI in relatively simple fashion, provided you know which menus to dig into.
edit: forgot the URL in my command, kinda important!
O Tannentag, o Tannentag…
Beat me to it.
Something Joe Biden will proudly admit!