Part of the Astro series

I’ve written so much about images and image optimization and yet the reality is I still have no clue exactly how it works.

Case in point: I installed Christian Ohanaja’s Astro Remark Eleventy Image plugin to parse my Friends with Brews show notes markdown files and replace any markdown images with responsive images (it both generates the image sources and creates the responsive HTML, as with any real image optimizer).

In the version I installed at the time, I immediately found that because the large source image’s width and height were included in the img element’s width and height properties, the browser ignored the size directives in the sources, and displayed the image at the x and y dimensions specified in the img tag.

Kind of defeats the point of size directives.

This is NOT an issue with Astro Remark Eleventy Image. In fact Christian now allows custom HTML markup to override this. This happens with any Picture element that includes an img tag with width and height properties. It doesn’t matter if it’s handwritten, generated by this plugin, generated directly using eleventy-img, or generated using some other image optimization plugin or scheme.

The biggest issue with NOT including them so that the browser respects the size directives instead is that now you’re subject to Cumulative Layout Shift (CLS)¹ because the browser doesn’t understand how large the image will be in advance.

If anyone knows of a way to use Picture element sizes without overriding them unintentionally with img height and width but still managing to avoid CLS, I’d love to hear more about it. Tell me!

Bunch

Tuesday, 14 Feb 2023

Part of the Mac series

I’ve written a bunch of words on this site about programming stuff in Astro, but there are bunches of other things that can be scripted too. Literal Bunches in fact – enter Bunch, a Mac automation app for launching apps and running commands with just a click. It’s written by Brett Terpstra, which is a name any Mac automation geek will know.

Bunch works as a menubar app that lists your Bunches. Click on a Bunch in the list, and it executes whatever is inside that Bunch, be it names of apps to launch or to close, or commands that can include system tasks, AppleScripts, Automator workflows, or even Bash scripts.

By default, Bunches are toggles – the first time you click on a Bunch name in the menubar list, the Bunch opens. Any apps or commands that are set to open or run do so. The next time you click the Bunch in the menubar list, it does the reverse. It closes any apps that are not explicitly set to remain open when the Bunch is toggled off (or “closed”, in Bunch parlance). It also runs any commands you have set up specifically to run when the Bunch is closed.

Talking about in the abstract isn’t super helpful. So here’s a podcast Bunch of mine! Please note that I’m still not super fluent in Bunch and this is void where prohibited and etc, etc, etc.

---
title:

That’s a lot. Here’s how it works:

---
title:

This top section is frontmatter and just determines what this Bunch is called in the menubar.

call_app = ?[FaceTime, Discord, Skype, Zoom] "Which calling app?" pops up a dialog box with a menu too choose which app I’m talking to cohosts on. Truthfully, it’s going to almost always be FaceTime for Friends with Brews, but other people on other podcasts use different ones. Slight aside, I’m a firm believer of podcasters always recording their end locally and the editor using all the original (better sounding) tracks, but not everyone does this.

Farrago
${call_app}

The next couple lines open my soundboard app Farrago and then whichever communication app I selected from the menu mentioned above.

%Safari
https://docs.google.com/

These two lines open Safari and then load Google Docs, which we use for show notes. The %Safari notation with the percent sign means that when I close the bunch, Safari is not closed along with the other apps in this bunch, but stays open.

%Finder
- ~/Documents/Podcasts/FwB
- ~/Library/Mobile Documents/com~apple~CloudDocs/Documents/Podcasts/FwB
- ~/Music/Audio Hijack

This section opens a finder window and opens tabs for me with some podcast related file locations.

Audio Hijack^ just opens Audio Hijack and makes it the active (focused) program.

(audio output AirThingies)
(audio input Shure Beta 87a & Farrago)

These illustrate one of Bunch’s coolest features, the ability to call system level commands. These lines do just what they look like: They set my Mac to output audio through my AirPods Pro and to use my virtual Loopback device that combines my mic and my soundboard as my audio in. This means I can set FaceTime or Zoom (or whatever app we’re talking on) to use this as its audio input, and my cohosts can hear whatever I play on the soundboard.

I’m going to cover the rest of this Bunch all at once.

!<<#On Close

___

#[On Close]
studio = $ studio_display_check.sh

if studio is "true"
    (audio output studio display speakers)
else
    (audio output MacBook Pro Speakers)
end

Basically the first line of this says “hey, when this Bunch is closed (toggled off), run the #On Close snippet”. The On Close snippet is in a special section at the bottom that is reserved for any snippets or snippet fragments you want to include.

My On Close snippet just runs a shell script located in the same folder as the Bunch to see if I’m connected to my Studio Display or not, and if I am, sets the output back to the Studio Display speakers. Otherwise, it sets the output to the Mac’s internal speakers.

Because this only runs when the Bunch is closed, meaning I’m done podcasting, this is exactly what I want.

This looks confusing, and I’m not going to lie – it took me awhile to get this working the way I wanted. Part of my issue was that I didn’t understand how Bunches work by default, and I thought I had to make a “Start Podcasting” Bunch and a “Stop Podcasting Bunch”, not realizing that it was set to toggle and just by choosing “Podcasting” again it would close any apps I didn’t explicitly say not to close. The rest of it was just learning the syntax. Fortunately, Brett has written excellent documentation for Bunch.

The fact that you can use conditional logic and use the output from shell scripts and set system settings and so many other things makes this a super flexible, powerful automation tool for the Mac. I used to open all these programs and set my audio settings manually, and now it requires just that many fewer clicks every time I want to podcast.

By the way, Brett has many more amazing utilities. Check out Gather CLI, for example, which lets you fetch the contents of a web page and have them converted to markdown syntax. It’s amazing and it’s perfect for doing things like saving information to Obsidian.

Part of the Astro series

So there I was, playing with eleventy-img to find a way to generate responsive images for image links in markdown files, when Christian Ohanaja did the work for me and created the Astro Remark Eleventy Image plugin.

I’m glad he did too, because looking at the remark part of the code, I feel confusion more than anything. I guess I have another rabbit hole to pop down to learn about THAT.

Anyway, being the true jerk that I am, instead of just being grateful and using his plugin, I forked it to add some additional options (such as the ability for the inline image to link to the high resolution version) and to add an Astro component for image optimization. That way I can have one plugin that provides image optimization in both markdown files and inside Astro components.

I’m assuming that I can technically combine a plugin and an Astro component in one project. I actually have no idea, but I’ll find out.

Whispering Podcast Transcripts

Wednesday, 25 Jan 2023

Part of the Mac series

In what feels like a lifetime ago, I had a podcast called Pocket Sized Podcast, talking about iOS apps and devices, mostly. At some point, for reasons I can’t even begin to recall, I joined up with a fledgling podcast network called Fiat Lux, which was later rebranded Constellation by the two fairly angry guys running it. The whole thing was a giant fiasco full of insane stories, but it’s relevant to me now because podcast transcription is having a moment.

Fiat Lux/Constellation decided that the core feature of the podcast network would be incredibly detailed show notes on all podcasts. Unfortunately they had some really bad ideas about exactly what those show notes should be like.¹ None of us wanted anything to do with their plan, mainly because of how they presented it and the amount of shouting involved in their attempts to convince us.

If you’re going to try to herd cats, you’d better be a cat person is what I’m saying.

But the idea of making podcast episodes available in text IS a good idea, and several very popular podcasters I know of are looking at all kinds of options for creating good transcripts without spending hours and hours on them.

There are several paid and soon-to-be-paid options such as Adobe Podcast (currently in beta, pricing to be determined), and Otter. But the completely free option that got my attention is a Mac port of OpenAI’s Whisper, called Whisper.cpp.

Whisper runs locally on your own machine, and Whisper.cpp jettisons the Python runtime for C and C++, which has obvious positive performance implications. Better yet, it’s even optimized for Apple Silicon.

I heard about Whisper.cpp while listening to Rebuild from Tatsuhiko Miyagawa, a very enjoyable Japanese language tech podcast. It’s actually one of my favorite podcasts in any language. Anyway, at the time Miyagawa-san was experimenting with Whisper.cpp on his new Apple Silicon Mac, and I filed that information away in my brain, figuring it would be some time before I got an Apple Silicon Mac of my own. It was, but now I have, and so I recently jumped into performing Whisper.cpp experiments of my own.²

Whisper.cpp has several models you can download, depending on what kind of quality vs time tradeoffs you want to make. I’ve tested Whisper.cpp on Friends with Brews episodes using the ggml-base.en.bin, ggml-medium.en.bin, and ggml-large.bin models, with interestingly varying results.

The first thing I found is that the base model is FAST. I transcribed a 50 minute podcast episode in about a minute with decent results. I had to fix a few names and technical terms, but otherwise it was quite good.

I couldn’t tell a huge difference between the medium and large models with the two particular episodes I experimented with, but the time difference between all three models was noticeable. I tested all three models on Friends with Brews episode 21, which is 45 minutes and 29 seconds long and roughly 24 MB in size.

Base.en – 1.5 minutes
Medium.en – 10 minutes
Large – 19 minutes

Even with the large model, transcribing a podcast at 2x speed is pretty good.

The end result is that I think it’s worth going with the medium or large models. It’ll cost you disk space – the base english model is 142MB, the medium english model is 1.5GB, and the large model is 2.9GB. But I think it’s worth it in terms of results.

You may have to do some testing to decide between the medium and large though, even if you’re convinced that the base model isn’t the way to go. Generally I think I like the large model results better, but there are some instances where the medium transcribed something more accurately.

Personally I’m using the large model, but that’s because I’m actually using yet another port, which I’ll talk about in another post very soon.

By the way, if you want to hear the Fiat Lux/Constellation stories, just slip @Vichudson1@appdot.net a nice glass of whiskey.³ He has a much better memory than I do about pretty much anything in the past, and especially about the saga of the world’s unhappiest podcast network.

As I mentioned in my last post, I want to use standard markdown (text only, no ability to use components) for Friends with Brews episodes so that I can use Astro’s ability to render full post body content of each episode in the RSS feed. This way the RSS feed shows each episode’s show notes instead of just a summary.

Step 1 of the Great Show Note Images odyssey is generating optimized versions of any images to be included in episode show notes. Figuring out which images those are is easy – I have a directory named src/images/episodes, and I’ll just dump my images in there.

From there it’s a matter of reading all the files in the directory, generating the desired sizes, and dumping them in public/images/episodes, which in the published site will be located at /images/episodes.

Because I’m not doing this inside an Astro file with pre-imported or pre-linked images, I can’t use the Astro Image component like I do for all the other images on the Friends with Brews website. I need something I can call from a JavaScript function. Fortunately, as I noted last time, I can use the eleventy-image plugin this way. Ben Holmes details how on his website in Picture perfect image optimization for any web framework article.

If you look at section 4 of his post, Using 11ty image with any framework, you can see a script Ben wrote to look in a directory and generate optimized images for each image file in the directory in the specified widths and formats using the Node package @11ty/eleventy-img.

I modified the script a little bit as shown below. I would have included it as a code block instead of an image, but for some reason it triggers modsecurity on my server and blocks the IP of whoever tries to load this page. Not exactly ideal.

If I run this script with the following images in src/images/episodes

-rw-r--r--@ 571969 Oct  4  2020 18749389.jpg
-rw-r--r--@ 723612 Jan  4 23:20 ChonkChart-816246A9-8775-4561-B9DA-1D9E7E0413B1-20220323095602.png

the script generates the following images in public/images/episodes:

-rw-r--r--@ 11229 Jan  9 13:36 18749389-1000.avif
-rw-r--r--@ 54111 Jan  9 13:36 18749389-1000.jpeg
-rw-r--r--@ 29588 Jan  9 13:36 18749389-1000.webp
-rw-r--r--@ 15438 Jan  9 13:36 18749389-1400.avif
-rw-r--r--@ 85912 Jan  9 13:36 18749389-1400.jpeg
-rw-r--r--@ 44008 Jan  9 13:36 18749389-1400.webp
-rw-r--r--@ 41218 Jan  9 13:36 18749389-4000.avif
-rw-r--r--@ 331928 Jan  9 13:36 18749389-4000.jpeg
-rw-r--r--@ 150688 Jan  9 13:36 18749389-4000.webp
-rw-r--r--@ 6960 Jan  9 13:36 18749389-600.avif
-rw-r--r--@ 26053 Jan  9 13:36 18749389-600.jpeg
-rw-r--r--@ 16014 Jan  9 13:36 18749389-600.webp
-rw-r--r--@ 30453 Jan  9 13:36 ChonkChart-816246A9-8775-4561-B9DA-1D9E7E0413B1-20220323095602-600.avif
-rw-r--r--@ 78709 Jan  9 13:36 ChonkChart-816246A9-8775-4561-B9DA-1D9E7E0413B1-20220323095602-600.jpeg
-rw-r--r--@ 60118 Jan  9 13:36 ChonkChart-816246A9-8775-4561-B9DA-1D9E7E0413B1-20220323095602-600.webp
-rw-r--r--@ 38504 Jan  9 13:36 ChonkChart-816246A9-8775-4561-B9DA-1D9E7E0413B1-20220323095602-677.avif
-rw-r--r--@ 98443 Jan  9 13:36 ChonkChart-816246A9-8775-4561-B9DA-1D9E7E0413B1-20220323095602-677.jpeg
-rw-r--r--@ 78596 Jan  9 13:36 ChonkChart-816246A9-8775-4561-B9DA-1D9E7E0413B1-20220323095602-677.webp

This is good news. First of all, Ben did all of my work for me. Second, I can generate optimized images without having to know anything about them in advance. Now I just have the very little problem of replacing image links in my episode markdown file with picture elements that contain the sources for the different file types and srcsets for each of the different image sizes.

By the way, check out the file size differences on the optimized versions versus the originals in those file listings! Even the full width and height optimized images are quite a bit smaller in terms of file size than the originals, and the smaller ones are minute compared to the images I started with.

A couple of things I’d like to note about working with eleventy-img here:

• Eleventy-img doesn’t stupidly try to generate image sizes larger than the original. If you specify widths: ["auto", 600, 1000, 1400] and one of the images is only 677 pixels wide, it will only generate the 600 and 677 pixel width versions (the “auto” option tells eleventy-img to also make a copy at the original size).
• As you must have guessed by now, just because eleventy-img was developed as a plugin for the Eleventy SSG framework, it’s just JavaScript and can be installed with npm and used with any other Node.js compatible framework. That includes Astro.

Next time I write anything on this site, it may be completely incoherent depending on what Rube Goldberg mechanism I come up with for getting the responsive html for images into my show notes markdown files in the correct location. My writing workflow allows for a few different possibilities since I already know in advance the default width I want these images. Maybe next time I’ll detail that workflow and what options I think might be available to me, and then we can get into implementation.

Part of the Astro series

I’ve talked a lot about image optimization and RSS feed handling with Astro. I’m about to talk about it some more. I presume you’re like me and obsess endlessly about these topics, so you should enjoy this.¹ In my case, I don’t know how much of it is enjoyment and how much of it is a compulsive search for a better way.

Now that Astro has support for full post content RSS feeds with the compiledContent property for markdown content, I modified Friends with Brews to use standard markdown files (.md) instead of MDX (.mdx). My reasoning was that, since I almost never include images in the show notes for Friends with Brews and since using standard markdown would let me use compiledContent to put full episode show notes in the podcast RSS feed, it was an automatic must-do.

Unfortunately for me, the second I made the switch, I needed to add an image to the show notes of an upcoming episode, which would make it the second time I’ve had to add an image to FwB show notes. The first time was back on episode 8, Satan is not normally depicted as being purple, and that was the critical piece of visual information known as the Chonk Chart.

If I have to do anything more than once, it means I will have to do it several times, and that means I have to support it properly. And that means being able to combine image optimization AND standard markdown in Astro, and that’s not currently possible - the Astro Image components are only supported in Astro and MDX files, for the obvious reason that they’re components, and markdown can’t execute components.

I can continue to process the usual images of episode brews (coffee, beer, tea) with Astro image in my layout templates, as well as all the other images used on the site, so that’s not a problem. Those brew images are not actually in the show notes. Instead, I have a JSON file of brews that contains a bunch of information about them, including which episode(s) they’re associated with. So I only have to concern myself with how to optimize the inline images in the show notes markdown files.

The good news is that manually writing Picture elements complete with sources and srcsets and default images is simple. And if it’s simple for a human, it’s simple for a script. I can easily assume a certain standard width for images I’m going to put in my show notes, and then generate optimized images for that size plus 2x and 3x resolutions, as well as the original for linking to. Then the html for the Picture element associated with the optimized images can be generated fairly simply. Ben Holmes, who now works for Astro, has a post about this approach using eleventy-image. Because eleventy-image can be manipulated directly in JavaScript, it’s a great candidate for this.

So here’s the plan:

• Continue to optimize permanent site images and episode brew images using the Astro Image components in my Astro layout files,
• Use eleventy-image to optimize inline show notes images to predetermined widths and image formats,
• Figure out how to insert the associated Picture elements for the optimized images into my markdown files. This step might take the most work.

If you noticed that the last step of the plan looks a bit like the Far Side cartoon with scientists drawing out a diagram of the creation of the universe with a “and then a miracle occurs” note tagged onto the end, it’s true. The good news is, there are several places in my writing and publishing workflow I can inject the html. I’ll write more about that as I start implementing a system.

Part of the Astro series

Earlier today I posted about the new compiledContent() property for use in Astro RSS. What I didn’t mention was that Astro RSS 1.1.0 had a bug in its XML parsing that ignored custom content (which in my case I am using for audio enclosures) and also choked on my link constructors for my post and audio file links.

Today Astro RSS 1.2.0 was released with a fix for this, thanks to a pull request from Matt Stein, so now my RSS layout for Siracusa Says looks like this:

import rss from "@astrojs/rss";
import config from "config";
import path from "path";
import sanitizeHtml from "sanitize-html";
import { rfc2822 } from "../components/utilities/DateFormat";

const episodeImportResult = import.meta.globEager("../content/episodes/*.md");
let episodes = Object.values(episodeImportResult);
episodes = episodes.sort(
  (a, b) =>
    new Date(b.frontmatter.pubDate).valueOf() -
    new Date(a.frontmatter.pubDate).valueOf(),
);

export const get = () =>
  rss({
    title: config.get("title"),
    description: config.get("description"),
    site: config.get("url"),
    items: Array.from(episodes).map((episode) => ({
      title: episode.frontmatter.title,
      link: `${new URL(
        path.join(config.get("episodes.path"), episode.frontmatter.slug),
        config.get("url"),
      )}`,
      pubDate: rfc2822(episode.frontmatter.pubDate),
      description: episode.frontmatter.description,
      customData: `<enclosure url="${new URL(
        path.join(
          config.get("episodes.audioPrefix"),
          episode.frontmatter.audiofile,
        ),
        config.get("url"),
      )}" length="${episode.frontmatter.bytes}" type="audio/mpeg" />`,
      content: sanitizeHtml(episode.compiledContent()),
    })),
  });

I noticed today that on my enclosure links I wasn’t providing the domain in the enclosure link url, just the path. This fixes that and also makes sure that my post links (which are also used by Astro RSS for item entry GUIDs) are always correct. I hadn’t had any problems with them, but this is a safer way of making sure I don’t ever get any extra slashes or other malformed URL issues.