This post is about why the one-sentence brief works, and what the text-to-rap mode actually does with it.

The sentence is a spec

A topic like the one above contains everything a verse needs: a subject (the cat), an object (the laptop), an emotion (grief, mostly), and a punchline that writes itself. The lyric stage reads the topic for those parts and builds bars around them — couplets that name the culprit, a hook that mourns the laptop, a closing line for the comeback. If the user writes their own lyrics instead, the generator skips this stage entirely and treats their text as the vocal track.

From text to performance

The bars go to a rap-styled vocal model that delivers them with flow — stress on the right syllables, push against the beat. This is where text-to-rap differs from reading text aloud: the same sentence performed straight is a sentence; performed with cadence, it is a verse. Then an original beat composed for the video carries it home.

Where the words show up

The finished video puts the performance on a stage — and if you add a photo, on a face. The text-to-rap page at https://useairapvideo.com/ai-rap-generator/text-to-rap has the mode itself; the free 6-second preview per account means your first sentence costs nothing to try.

One practical note

Topics with concrete nouns work best: objects, names, places. "My cat knocked my coffee onto my laptop" gives the writer (human or model) something to grab. Abstract topics — "the passage of time" — produce verses too, but they lean on the template's energy more than the lyrics' content.

The whole thing lives at https://useairapvideo.com. One video $3.99, credit packs from $9.99, no subscription, original beats only.

— AI Rap Video team

Our product generates rap performance videos: lyrics written for your topic, an AI rap voice, and a beat, with your photo lip-synced on camera. The tempting shortcut in this space is obvious. Famous instrumentals drive engagement. Everyone recognizes them. Why compose anything?

Copyright is not a rounding error

A generated video that rides on a copyrighted instrumental is a derivative work sitting on someone else's rights. For a user, that means a takedown on the platforms they share to. For the tool that produced it, it means the whole catalog is radioactive: one rights-holder sweep and every rendered video is a liability. Training data debates aside, the output of a generator using licensed audio is squarely actionable today, and "the AI made it" is not a defense anyone has won with.

So the rule in our pipeline is simple: the beat is composed per video, the lyrics are generated for the user's topic, and nothing in the output samples or bundles an existing song. There is a DMCA takedown flow for edge cases, and users who own the rights to a track can upload it themselves — the escape hatch is theirs to exercise, not ours to assume.

What it costs

Two things, honestly:

1. Recognition. A famous beat does half the marketing. An original boom-bap pattern does none. Our videos rise or fall on the joke in the lyrics, which is more pressure on the writing stage.
2. Engineering. Per-video composition means the audio stage cannot be a lookup table. It has to actually generate, matched to the vocal take.

What it buys

Listings that do not get swept. Group-chat videos that do not get muted mid-share. And a clearer conscience: the person making a birthday rap for their dad is not unknowingly building on a producer's unlicensed work.

If you are building in AI music or AI video, we think this constraint is worth stealing. The workflows it forces — generate, don't sample — end up cheaper than the licensing mess you avoid.

The tool itself lives at https://useairapvideo.com, free 6-second preview per account, videos from $3.99 one-time, no subscription. Come for the roast generator, stay for the beats you do not have to clear.

— AI Rap Video team

The request

const res = await fetch('https://api.x.ai/v1/tts', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.XAI_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    text: 'Stand back. <loud>This is not a drill.</loud>',
    voice_id: 'eve',
    language: 'en',
    output_format: { codec: 'mp3', sample_rate: 24000, bit_rate: 128000 },
  }),
});
const mp3 = Buffer.from(await res.arrayBuffer());

language also takes auto. Price is $15 per million characters (xAI pricing page, checked 2026-10-30).

Two kinds of tags

• Inline tags insert a sound where they sit: [pause], [long-pause], [hum-tune], [laugh], [chuckle], [giggle], [cry], [tsk], [tongue-click], [lip-smack], [breath], [inhale], [exhale], [sigh].
• Wrapping tags change how the enclosed phrase is read: <soft>, <whisper>, <loud>, <build-intensity>, <decrease-intensity>, <higher-pitch>, <lower-pitch>, <slow>, <fast>, <sing-song>, <singing>, <emphasis>.

What two of them measured

Same sentence, voice Eve, English, one clip with and one without the tag. One clip each, so this is a quick check rather than a benchmark.

So <loud> is closer to "raised, urgent delivery" than a volume control: if you need a louder file, normalise it afterwards. <singing> stretches the words into a melody, which also makes the clip longer (and, on a per-character price, not more expensive).

Trying tags without writing code

If you want to hear the tags on all 28 voices before wiring up the API, I built a free front-end: Grok Text to Speech. The speech tag reference has a before/after sample for each group, and there are preset pages for whisper, shouting and singing. It's an independent project, not affiliated with xAI.

Originally published on dev.to.

A dated log page is useful, but people asked for a way to hear about changes without coming back to look. The answer is old and boring: RSS. The interesting part is that the site is fully prerendered — there's no server at request time — so the feed has to be a static file generated at build time from the same JSON the page uses.

Here's how that works in TanStack Start.

A server route that only runs at build time

In TanStack Start, a file route can define server.handlers instead of a component. Normally that runs on a server. With prerendering, the build calls it once and writes the response body to disk.

The file name does the URL work. A literal dot is escaped with brackets, and the trailing underscore on updates_ stops the route from nesting under the /updates/ page layout:

src/routes/updates_.feed[.]xml.ts   →   /updates/feed.xml

export const Route = createFileRoute('/updates_/feed.xml')({
  server: {
    handlers: {
      GET: () => {
        const xml = buildFeed(liveLog); // plain string building
        return new Response(xml, {
          headers: { 'Content-Type': 'application/rss+xml; charset=utf-8' },
        });
      },
    },
  },
});

The JSON is a normal import (import liveLog from '@/data/live-log.json'), so it gets bundled at build time. No file reads, no fetch.

Tell the prerenderer it exists

The prerenderer discovers pages by crawling links from /. Nothing links to an XML file with an <a> tag, so the crawler would never find it. It has to be listed explicitly, next to the other non-HTML outputs:

// vite.config.ts → tanstackStart({ prerender: { ... }, pages: [...] })
pages: [
  { path: '/robots.txt',  prerender: { enabled: true, outputPath: '/robots.txt' } },
  { path: '/sitemap.xml', prerender: { enabled: true, outputPath: '/sitemap.xml' } },
  { path: '/updates/feed.xml',
    prerender: { enabled: true, outputPath: '/updates/feed.xml' } },
],

I set outputPath explicitly so the file lands exactly where the feed URL says, with the .xml name intact.

Three kinds of entries, one sorted list

The log has three arrays — law changes, daily headlines, gem-hunt clues. Each gets a small mapper to a common shape, then they're merged, filtered to the last 30 days and sorted newest first:

type Item = { guid: string; title: string; description: string; link: string; at: number };

const items = [
  ...log.laws.map(lawItem),
  ...log.daily.filter((d) => d.headline).map(dayItem),
  ...log.hunt.filter((h) => h.clue).map(clueItem),
]
  .filter((i) => Number.isFinite(i.at) && i.at >= since)
  .sort((a, b) => b.at - a.at);

A few details that took a second try:

• Stable GUIDs. Feed readers decide "new item" by guid. I build it from the kind and the date (day-2026-10-13, hunt-2026-10-13) with isPermaLink="false", so a rebuild every few hours never re-announces old items.

• The game's day, not mine. The game runs on Lagos time (WAT, UTC+1). A headline for "13 October" should be dated midnight in Lagos, not midnight UTC: Date.parse(`${day}T00:00:00+01:00`). Get this wrong and items show up a day off for half the readers.

• Escape everything. Headlines contain quotes and apostrophes ("Lagos says 'case closed'"). A five-line esc() for & < > " on every text node is enough for RSS 2.0; no XML library needed.

• Anchor links. Every item links to a section of the one page (/updates/#daily-headlines, #law-log, #daily-gem-hunt) rather than to a page per item. There are no per-item pages, and I didn't want to create thin ones just for the feed.

• <ttl>180. The data only changes every three hours, so the feed says so.

Same red lines as the page

The feed is built from the same JSON as the page, so it can't leak anything the page doesn't show — but it could show more if a mapper got careless. The gem-hunt items carry the clue word for word and nothing else: no answers, no rewards, no leaderboard names. The governor's own announcements never reach the JSON in the first place.

Make it discoverable

Two small things so readers can actually find the feed:

// root route head(): every page advertises the feed
links: [{ rel: 'alternate', type: 'application/rss+xml',
          title: 'Lagos Life updates (unofficial guide)',
          href: absoluteUrl('/updates/feed.xml') }],

…and a visible block on the page with the feed address and a copy button, because no major browser shows a feed button for <link rel="alternate"> anymore.

The result

The log page, with its feed linked at the bottom, is here: Lagos Life updates: this week's law, daily headlines and gem hunt clues. Each rebuild regenerates the page and the feed together from one JSON file, so they can't drift apart.

The game itself is at lagoslife.app; my site is an independent fan guide, not affiliated with the developers.

Takeaways

• A prerendered "server route" is a clean way to emit non-HTML files (RSS, sitemap, robots) from the same data as your pages.

• List those routes in the prerender pages config with an explicit outputPath — the crawler won't find them.

• Date items in the source's timezone, and make GUIDs deterministic so frequent rebuilds don't spam readers.