Forem: Haruki Tanaka

Bringing Microsoft SAM Back to Life: How SAPI4 TTS Works in the Browser

Haruki Tanaka — Tue, 24 Feb 2026 20:58:18 +0000

Do You Remember That Voice?

If you grew up with Windows 2000 or XP, you probably remember Microsoft SAM — the robotic, slightly eerie text-to-speech voice that could say anything you typed. It was the default voice of the Microsoft Speech API 4.0 (SAPI4), and for an entire generation, it was the first encounter with speech synthesis.

Kids would type absurd sentences into the Narrator tool just to hear SAM butcher them in the most entertaining way possible. And then there was BonziBUDDY — that infamous purple gorilla desktop companion — which used the same underlying engine to "talk" to you.

Fast forward to 2026, and these voices have become internet legend. Memes, YouTube compilations, and nostalgic threads keep them alive. But what if you could actually run these voices again — not through a dusty Windows VM, but directly in your browser?

How SAPI4 Actually Worked

Before we get into the modern implementation, let's understand what made SAPI4 tick.

Microsoft's Speech API 4.0 (released around 1998) was a COM-based framework that sat between applications and speech engines. The architecture looked like this:

Application → SAPI4 COM Interface → TTS Engine (e.g., SAM) → Audio Output

The TTS engine itself was a formant synthesizer — it didn't use recorded speech samples like modern neural TTS. Instead, it generated sound by manipulating:

Formant frequencies — resonant frequencies that shape vowel sounds
Pitch contours — the rise and fall of the voice
Duration rules — how long each phoneme is held
Noise generation — for consonants like "s" and "f"

This is why SAM sounds robotic: it's literally constructing speech from mathematical parameters, not stitching together recordings.

The Text-to-Phoneme Pipeline

When you type "Hello World" into a SAPI4 engine, here's what happens:

1. Text Normalization

Numbers, abbreviations, and symbols get expanded:

"Dr." → "Doctor"
"123" → "one hundred twenty three"
"$5" → "five dollars"

2. Grapheme-to-Phoneme Conversion

English text is converted to phoneme sequences using a combination of:

Dictionary lookup — common words have stored pronunciations
Letter-to-sound rules — fallback rules for unknown words

For example: "Hello" → /HH EH L OW/

3. Prosody Generation

The engine applies pitch and timing rules based on sentence structure. Questions get rising intonation. Periods trigger falling pitch. Commas insert pauses.

4. Waveform Synthesis

Finally, the formant synthesizer generates raw PCM audio by:

// Simplified formant synthesis concept
function generateFormant(frequency, bandwidth, amplitude, duration) {
  const samples = [];
  for (let t = 0; t < duration * sampleRate; t++) {
    const sample = amplitude * Math.sin(2 * Math.PI * frequency * t / sampleRate);
    samples.push(sample);
  }
  return applyBandpassFilter(samples, frequency, bandwidth);
}

The real implementation is far more complex, with multiple formants blended together, but this gives you the idea.

Bringing It to the Browser

The original SAPI4 engine was written in C/C++ and tightly coupled to Windows COM. Getting it to run in a browser required a few key steps:

Emscripten / WebAssembly Compilation

The core synthesis engine can be compiled to WebAssembly, allowing it to run at near-native speed in any modern browser. The key challenges:

No COM dependency — the COM interface layer has to be replaced with direct function calls
Audio output — Windows audio APIs are swapped for the Web Audio API
Memory management — WASM has its own linear memory model

Web Audio API Integration

const audioContext = new AudioContext();

function playTTSBuffer(pcmData, sampleRate) {
  const buffer = audioContext.createBuffer(1, pcmData.length, sampleRate);
  buffer.getChannelData(0).set(pcmData);

  const source = audioContext.createBufferSource();
  source.buffer = buffer;
  source.connect(audioContext.destination);
  source.start();
}

The Result

The entire synthesis happens client-side. No server calls, no API keys, no rate limits. You type text, it becomes speech — all in your browser, just like it's 2001 again.

You can try this yourself at SAM TTS, which brings together multiple classic SAPI4 voices in one free web tool:

Microsoft SAM — the iconic default voice
BonziBUDDY (Adult Male #2) — the purple gorilla's voice
TruVoice (Adult Male #1) — smoother, more natural
BetterSAM — enhanced version with cleaner output

Why Formant Synthesis Still Matters

In a world of neural TTS models that sound nearly human (looking at you, ElevenLabs and OpenAI), why bother with 25-year-old formant synthesis?

1. Zero Latency

Formant synthesis is computationally trivial. No GPU needed, no model loading, no network round-trip. Input text → output audio in milliseconds.

2. Runs Anywhere

Since it's pure computation with no model weights, the entire engine fits in a few hundred KB of WASM. It works on a Raspberry Pi, a budget phone, or an airplane with no WiFi.

3. Full Privacy

Everything runs locally. Your text never leaves your device. For applications where privacy matters, this is a genuine advantage over cloud-based TTS.

4. Creative / Meme Use Cases

Let's be honest — sometimes you want the robotic voice. For memes, game mods, retro-themed projects, or just making your friends laugh, neural TTS is too "normal." The charm is in the jank.

5. Educational Value

Understanding formant synthesis gives you insight into how speech actually works — the physics of vocal tracts, the linguistics of phonemes, and the engineering of real-time audio. It's a great rabbit hole.

Try It Yourself

If you want to hear Microsoft SAM TTS in action, the easiest way is to visit the web tool directly. Type any text, pick a voice, and hit play. No sign-up, no downloads.

Some fun things to try:

Type "ROFLcopter goes soi soi soi soi" (classic meme)
Switch between SAM and BonziBUDDY to hear the difference
Try extremely long words — the grapheme-to-phoneme engine handles them surprisingly well
Type "aeiou" repeatedly for the iconic sound

Wrapping Up

Classic speech synthesis is a fascinating intersection of linguistics, signal processing, and software engineering. The fact that we can now run a 1998 Windows speech engine inside a modern browser — with no plugins, no installation — is a testament to how far web technology has come.

If you're interested in retro computing, audio programming, or just want to hear that nostalgic robot voice again, give SAM TTS a spin. It's free, it's instant, and it's a fun piece of computing history preserved for the modern web.

What's your favorite retro software that you wish had a modern web version? Drop a comment below!

Why Kaomoji Still Matter in 2026: A Developer's Guide to Japanese Text Emoticons

Haruki Tanaka — Mon, 23 Feb 2026 04:03:22 +0000

We live in an age of emoji pickers and animated stickers. So why would anyone still use plain-text emoticons made from punctuation marks?

That's what I thought too — until I started building Kaomojiya, a free kaomoji collection site, and realized just how alive Japanese text emoticons still are in 2026.

Let me share what I've learned, why kaomoji deserve a spot in every developer's toolkit, and how you can use them to make your apps, docs, and messages more expressive.

What Are Kaomoji, Exactly?

If you've ever seen (╥﹏╥) or ٩(◕‿◕｡)۶ floating around in a chat, you've encountered kaomoji — Japanese-style emoticons built entirely from Unicode characters.

Unlike Western emoticons (:-) read sideways), kaomoji are read face-on. And unlike emoji, they don't depend on any rendering engine, OS version, or font. They're pure text.

Here's a quick comparison:

Type	Example	Needs Rendering?	Cross-Platform?
Emoji	😀	Yes (OS-dependent)	Varies by device
Western Emoticon	:-)	No	Yes
Kaomoji	(◕‿◕)	No	Yes, everywhere

That last column is what makes kaomoji interesting for developers.

Why Developers Should Care

1. They Work Everywhere — Literally

Kaomoji are plain Unicode text. They render identically in:

Terminal output and CLI tools
Git commit messages
Code comments
Markdown files
Slack, Discord, email — you name it

No image assets. No emoji font dependencies. No broken squares on older systems.

2. They Add Personality to Developer Tools

I've seen kaomoji used in:

Error messages: (╯°□°)╯︵ ┻━┻ Something went wrong!
Loading states: (　-_-)旦~ Brewing your coffee...
Success notifications: ヾ(＾∇＾) Deploy complete!
404 pages: (；⌣̀_⌣́) Page not found

They make your tools feel human without adding any asset overhead.

3. Great for Internationalization

If you're building for a Japanese audience (or any audience that values cute/expressive text), kaomoji feel native. They're part of everyday Japanese digital communication — used in LINE, X (Twitter), blogs, and even business emails.

Building Kaomojiya: What I Learned

When I started Kaomojiya, the goal was simple: build the most comprehensive, searchable kaomoji collection on the web.

Here's what the project looks like today:

500+ pages covering every emotion and situation
Thousands of kaomoji organized by category (happy, sad, angry, love, animals, food, and dozens more)
One-click copy — tap any kaomoji and it's on your clipboard
Completely free — no login, no paywall, no ads
Blazing fast — built on Next.js 14 with Edge Runtime, deployed on Cloudflare

The Surprising Challenge: Categorization

The hardest part wasn't building the site — it was organizing the kaomoji. Japanese internet culture has produced an incredible variety of expressions, and many kaomoji don't fit neatly into a single category.

Is ( ˘ω˘ ) sleepy or relaxed? Is (ノ´ー)ノ` a shrug or dismissal?

We ended up with a two-layer system: main categories (like "happy" or "angry") and subcategories (like "sparkle," "gentle," or "intense") that let users browse naturally.

The SEO Angle

Here's something interesting for fellow devs: kaomoji pages get surprisingly good search traffic. People Google things like "shrug kaomoji" or "cat emoticon copy paste" all the time. By building individual, well-structured pages for each category, we've been able to capture that long-tail traffic organically.

If you're interested in the technical details of how we handle 500+ pages with a single dynamic route, I covered that in my previous article on programmatic SEO with Next.js.

How to Use Kaomoji in Your Projects

Here are some practical ways to sprinkle kaomoji into your work:

In Your README

Add a kaomoji to your project title or status badge:

My Awesome Project ٩(◕‿◕｡)۶ — Status: Working (☞ﾟヮﾟ)☞

In Git Commits

git commit -m "fix: resolve race condition in auth flow (╥﹏╥)"
git commit -m "feat: add dark mode support ヾ(＾∇＾)"

In Error Handling

404: '(；⌣̀_⌣́) We could not find what you were looking for.'
500: '(╯°□°)╯︵ ┻━┻ Our server is having a bad day.'
Default: '(・_・ヾ Something unexpected happened.'

In Notifications / Toasts

Success: toast.success('File uploaded! ٩(◕‿◕｡)۶')
Error: toast.error('Upload failed (╥﹏╥) Please try again.')
Info: toast.info('(　-_-)旦~ Processing your request...')

My Favorite Kaomoji for Developers

Here's a quick cheat sheet you can bookmark:

Situation	Kaomoji
Success / Celebration	`ヾ(＾∇＾)`
Error / Frustration	`(╯°□°)╯︵ ┻━┻`
Thinking / Loading	`(　-_-)旦~`
Approval / Thumbs Up	`(☞ﾟヮﾟ)☞`
Confusion	`(・_・ヾ`
Sadness	`(╥﹏╥)`
Love / Like	`(◕‿◕✿)`
Shrug	`¯\_(ツ)_/¯`
Cat	`(=^・^=)`
Bear	`ʕ•ᴥ•ʔ`

Want more? Browse the full collection at Kaomojiya — thousands of kaomoji, searchable by mood, category, or keyword. Just tap to copy.

Wrapping Up

Kaomoji aren't going anywhere. In a world where emoji look different on every device and require specific Unicode support, these little text faces remain the most portable, lightweight, and universally compatible way to add emotion to text.

Whether you're writing documentation, building a CLI tool, or just want to make your Slack messages more fun — give kaomoji a try.

And if you need a solid collection to pull from, Kaomojiya has you covered. No signup, no cost, just copy and paste.

Happy coding! ٩(◕‿◕｡)۶

How I Built 500+ SEO-Optimized Pages with Next.js 14 and Edge Runtime

Haruki Tanaka — Fri, 20 Feb 2026 03:50:59 +0000

A practical guide to programmatic SEO with Next.js App Router, hybrid rendering, and Cloudflare Pages — based on real production experience and trade-offs.

When I set out to build a kaomoji (Japanese emoticon) website, I knew I'd need hundreds of individual pages — one for each emotion category. Manually creating 500+ pages wasn't an option. Instead, I built a system that programmatically generates SEO-optimized pages from structured data, deploys them on Edge Runtime, and handles everything from metadata to Schema.org markup automatically.

Here's exactly how I did it — including the trade-offs and gotchas I ran into along the way.

The Challenge

Japanese kaomoji like (╥﹏╥) and (づ｡◕‿‿◕｡)づ are searched thousands of times per month. Each emotion category (cry, cute, angry, etc.) needs its own page with:

Unique title, description, and keywords
Structured kaomoji data grouped by subcategories
Schema.org markup (FAQ, ItemList, BreadcrumbList)
Consistent layout with sidebar navigation
Fast load times globally (especially Japan)

Doing this for 500+ categories by hand would be unmaintainable. Programmatic SEO was the answer.

Architecture Overview

data/kaomoji/
├── cry.ts          # KaomojiItem[] data
├── cute.ts
├── smile.ts
└── ... (524 files)

public/data/
├── kaomoji/*.json  # Runtime data (fetched, not bundled)
└── config/*.json   # Page configs (title, description, FAQ, etc.)

app/[locale]/(default)/[slug]/page.tsx   # Single dynamic route

The key insight: one dynamic route serves all 524 pages. The [slug] parameter (e.g., cute-kaomoji) determines which data and config to load.

Step 1: Define Your Data Schema

Every kaomoji item follows a strict TypeScript interface:

export interface KaomojiItem {
  kaomoji: string;       // "(╥﹏╥)"
  category: string;      // "cry"
  subcategory: string;   // "basic" | "sparkle" | "dramatic"
  popularity: number;    // 0-100
  tags: string[];        // ["悲しい", "泣く", "涙"]
}

Each category file exports an array of these items. For example, data/kaomoji/cry.ts contains 50-100 kaomoji grouped by subcategory.

The data files are compiled to JSON at build time and served from /public/data/kaomoji/. This is critical — more on why below.

Step 2: Hybrid Rendering Strategy

Here's where it gets interesting. With 524 pages, pre-rendering everything at build time would be slow and wasteful. Instead, I use a hybrid approach:

// app/[locale]/(default)/[slug]/page.tsx

export const runtime = 'edge';
export const revalidate = 3600; // ISR: revalidate every hour
export const dynamicParams = true;

export async function generateStaticParams() {
  const topPages = [
    'cute', 'cry', 'smile', 'happy', 'sad', 'angry',
    'surprised', 'love', 'shy', 'sleepy', 'please',
    'thank', 'sorry', 'cat', 'dog', 'rabbit', 'bear',
    'animal', 'heart', 'star', 'wink', 'hug', 'kiss',
    'punch', 'tired', 'confused', 'mendokusai', 'nemui',
    'gorogoro', 'uttori'
  ];

  return topPages.map(slug => ({
    slug: `${slug}-kaomoji`,
    locale: 'ja'
  }));
}

What this does:

30 top pages are pre-rendered at build time (instant load)
494 remaining pages are generated on-demand at first request
dynamicParams = true allows paths not in generateStaticParams to be handled at runtime

Important nuance: dynamicParams = true alone doesn't guarantee caching. For the on-demand pages to be cached and reused (ISR behavior), the route must be ISR-compatible — meaning you need export const revalidate set, and you must avoid Dynamic APIs like cookies() or headers() in the render path. Without this, each request triggers a fresh server render.

Step 3: Dynamic Data Loading (Not Static Imports)

This was the biggest performance win. Initially, I imported kaomoji data directly:

// BAD: This bundles ALL data into the page
import { cryKaomoji } from '@/data/kaomoji/cry';

With 524 categories, this approach bloated the JavaScript bundle to 25MB+. The solution: load data via fetch at runtime.

// GOOD: Fetch only what's needed
async function getKaomojiData(category: string) {
  const response = await fetch(
    `${baseUrl}/data/kaomoji/${category}.json`,
    { next: { revalidate: 3600 } }
  );
  return await response.json();
}

A note on what revalidate controls here: The { next: { revalidate } } option in fetch controls Next.js Data Cache — the framework's own server-side persistent cache. It does NOT automatically set CDN cache headers or Cloudflare cache policies. Those are separate concerns (more on this in the caching section).

Results:

Bundle size dropped from 25MB to under 5MB
Each page only loads its own category data
Edge Runtime compatible (no Node.js fs needed)
Next.js Data Cache handles revalidation at the framework level

Step 4: Automated SEO Metadata

Each page needs unique metadata. I store page configs as JSON:

{
  "metadata": {
    "title": "泣く顔文字 500選【コピペ可】",
    "description": "泣く・悲しい顔文字を500個以上収録...",
    "keywords": ["泣く 顔文字", "悲しい 顔文字", "涙 顔文字"]
  },
  "hero": {
    "title": "泣く顔文字",
    "subtitle": "悲しい時に使える顔文字コレクション",
    "description": "..."
  },
  "faqItems": [
    {
      "question": "泣く顔文字の使い方は？",
      "answer": "..."
    }
  ]
}

The generateMetadata function loads this config and returns proper Next.js metadata:

import type { Metadata } from "next";

export async function generateMetadata(
  { params }: { params: { locale: string; slug: string } }
): Promise<Metadata> {
  const category = params.slug.replace(/-kaomoji$/, "");
  const config = await getPageConfig(category);

  return {
    title: "config.metadata.title,"
    description: "config.metadata.description,"
    keywords: config.metadata.keywords,
    openGraph: {
      title: "config.metadata.title,"
      description: "config.metadata.description,"
      type: "website",
      locale: params.locale,
    },
    alternates: {
      canonical: `https://www.kaomojiya.org/${params.slug}`,
    },
  };
}

Step 5: Schema.org Structured Data

Each page includes structured data merged into a single @graph. Choose your schema types based on what your page actually represents:

const schemas = mergeSchemas(
  generateBreadcrumbSchema(category, title, locale),
  generateFAQSchema(config.faqItems),
  generateItemListSchema(kaomojiData, config)
);

This tells search engines what each page contains:

BreadcrumbList — navigation hierarchy
FAQPage — common questions (rich snippet eligible). Make sure the Q&A content is also visible on the page itself — Google requires this.
ItemList — the kaomoji collection

Tip: Pick schema types that match your page's actual content. For a collection/reference page, CollectionPage + ItemList is often more appropriate than WebApplication. Using the wrong type won't necessarily hurt, but it won't help either.

Step 6: Caching — Two Separate Concerns

This is where things get nuanced. There are two distinct caching layers, and they're often conflated:

Layer 1: Next.js Data Cache (framework level)

// This controls Next.js server-side Data Cache
const response = await fetch(url, {
  next: { revalidate: 3600 } // Revalidate after 1 hour
});

This tells Next.js to cache the fetch result server-side and serve stale data while revalidating in the background. It has nothing to do with CDN behavior.

Layer 2: CDN / Edge Cache (infrastructure level)

On Cloudflare, CDN caching is controlled by:

Cache-Control response headers
Cloudflare Page Rules / Cache Rules
Cloudflare Cache API (programmatic)

These are not automatically set by Next.js revalidate. You need to configure them separately.

My caching config

export const CACHE_CONFIG = {
  pageConfig: 3600,      // Next.js Data Cache: 1 hour
  kaomojiData: 3600,     // Next.js Data Cache: 1 hour
  sitemap: 86400,        // Next.js Data Cache: 24 hours
  inMemory: 3600000,     // App-level memory cache: 1 hour (ms)
};

A warning about in-memory cache on Edge: Edge/Workers memory is per-isolate and can be evicted at any time. It's not shared across edge locations. Treat it as a best-effort hot cache, not a reliable persistence layer — it's closer to a request-local optimization than Redis.

In development, all caches are disabled (isDev ? 0 : ...) for instant feedback.

Step 7: Deploy to Cloudflare Pages

My app runs on Cloudflare Pages with Edge Runtime using @cloudflare/next-on-pages:

# wrangler.toml
name = "kaomojiya"
compatibility_date = "2024-07-29"
compatibility_flags = ["nodejs_compat"]
pages_build_output_dir = ".vercel/output/static"

[vars]
NEXT_PUBLIC_WEB_URL = "https://www.kaomojiya.org"

Build pipeline:

next build && npx @cloudflare/next-on-pages
wrangler pages deploy

Important note (2026): Cloudflare's official recommendation has shifted toward deploying Next.js apps to Cloudflare Workers using the OpenNext adapter. The @cloudflare/next-on-pages package was archived in late 2025 and is in maintenance-only mode. My setup still works on Pages, but if you're starting a new project, evaluate the Workers/OpenNext path — it has better long-term support and broader feature coverage.

I chose Pages at the time because it was the stable option, and migrating a working production app has costs. The architecture patterns in this article (hybrid rendering, runtime data fetching, structured metadata) apply regardless of which Cloudflare deployment target you choose.

Results

After deploying this system:

524 pages indexed by Google within weeks
Bundle size: 25MB → under 5MB (80% reduction)
Build time: ~2 minutes for 30 pre-rendered pages (vs. 20+ minutes for all 524)
TTFB: under 200ms globally via Edge Runtime
Zero manual page creation — add a data file, and the page exists

Key Takeaways

Don't pre-render everything — Use hybrid rendering. Pre-render your top pages, let the rest generate on demand with ISR.
Fetch data at runtime — Static imports kill your bundle size at scale. Use JSON files + fetch with caching.
Separate your cache layers — Next.js Data Cache and CDN cache are different things. Configure both intentionally.
Be precise about ISR — dynamicParams = true allows on-demand rendering, but you need revalidate and must avoid Dynamic APIs for pages to actually be cached.
Edge Runtime has trade-offs — Great for latency, but in-memory state is per-isolate and ephemeral. Design accordingly.

Forem: Haruki Tanaka

Bringing Microsoft SAM Back to Life: How SAPI4 TTS Works in the Browser

Do You Remember That Voice?

How SAPI4 Actually Worked

The Text-to-Phoneme Pipeline

1. Text Normalization

2. Grapheme-to-Phoneme Conversion

3. Prosody Generation

4. Waveform Synthesis

Bringing It to the Browser

Emscripten / WebAssembly Compilation

Web Audio API Integration

The Result

Why Formant Synthesis Still Matters

1. Zero Latency

2. Runs Anywhere

3. Full Privacy

4. Creative / Meme Use Cases

5. Educational Value

Try It Yourself

Wrapping Up

Why Kaomoji Still Matter in 2026: A Developer's Guide to Japanese Text Emoticons

What Are Kaomoji, Exactly?

Why Developers Should Care

1. They Work Everywhere — Literally

2. They Add Personality to Developer Tools

3. Great for Internationalization

Building Kaomojiya: What I Learned

The Surprising Challenge: Categorization

The SEO Angle

How to Use Kaomoji in Your Projects

In Your README

In Git Commits

In Error Handling

In Notifications / Toasts

My Favorite Kaomoji for Developers

Wrapping Up

How I Built 500+ SEO-Optimized Pages with Next.js 14 and Edge Runtime

The Challenge

Architecture Overview

Step 1: Define Your Data Schema

Step 2: Hybrid Rendering Strategy

Step 3: Dynamic Data Loading (Not Static Imports)

Step 4: Automated SEO Metadata

Step 5: Schema.org Structured Data

Step 6: Caching — Two Separate Concerns

Layer 1: Next.js Data Cache (framework level)

Layer 2: CDN / Edge Cache (infrastructure level)

My caching config

Step 7: Deploy to Cloudflare Pages

Results

Key Takeaways

Further Reading