Aetras — Infrastructure for Sound

Purpose

Aetras Labs is where we test ideas, keep what proves useful, and turn the best parts into reusable systems.

We like starting many things. Small tools, strange concepts, technical sketches, unfinished prototypes, and high-dopamine ideas all have a place here.

Not every idea needs to become a product. Some are discontinued. Some become internal tools. Some reveal one useful piece that can be extracted, refined, and used somewhere else.

That is the point of Labs: create many possibilities, select the useful ones, refine them, and let the strongest pieces become part of the Aetras platform, infrastructure, or future solutions.

Method

Start with an experiment.

A project may begin as a question: can this be built, would this be useful, does this workflow feel better, or is there a better way to approach the problem?

Look for the reusable part.

Even if the original project does not continue, it may reveal a useful component: a processor, interface pattern, data model, workflow, service, or technical foundation.

Refine what survives.

The pieces that prove useful can be improved over time and reused across the platform, internal tools, commercial systems, and future products.

Selected

Reusable Service

Transcription

A focused experiment that grew out of a larger voice-agent idea and became reusable infrastructure for the Aetras platform.

Origin

The larger question was voice.

Transcription started inside a larger question: could we build a useful voice agent? That larger system would need modular speech capabilities such as transcription, voice activity detection, diarization, audio enhancement, and scalable inference.

Instead of trying to build the entire agent at once, we selected one piece and built it as a standalone prototype: transcription. Upload audio, process it reliably, return structured text, and learn what real infrastructure would be required.

What survived

The useful part was not just the app.

The experiment proved that transcription works best as a modular capability: a service that can be improved independently and reused wherever speech needs to become structured text.

That means the same transcription foundation can support a public transcription tool, future voice agents, media archives, dataset preparation, creator workflows, and other audio systems.

If the transcription layer improves, every project that depends on it improves with it. That is the kind of pattern Labs is designed to find.

Infrastructure

Durable jobs

Long-running audio work needs to survive refreshes, disconnects, restarts, and worker failures. The system treats transcription as background work with persistent state.

Worker scaling

Processing can be handled by workers that coordinate through durable state instead of depending on one fragile request or one local machine.

Platform reuse

Once transcription is a service, it becomes a building block. It can be used directly, embedded into other products, or improved as part of a larger sound platform.

Research

No Prototype

RZ.JS

A research idea for bringing Razor-style syntax to frontend development while keeping JavaScript as the language.

+

Idea

Enhance HTML, do not replace the web.

RZ.JS explores whether Razor-inspired syntax can make simple frontend work clearer without becoming another large framework.

It is not intended to replace React, Svelte, Vue, or other frontend frameworks. The idea is smaller: enhance native HTML with a clean transition syntax for values, expressions, logic, and component-like behavior.

We like Razor because it lets markup remain readable while allowing logic to appear where it naturally belongs. RZ.JS asks whether that feeling can exist in browser-focused JavaScript without adding unnecessary ceremony.

Syntax

@{
    let count = 0;

    function increment() {
        count++;
    }
}

<button @click="increment">
    Count: @count
</button>

@if (count > 5) {
    <p>That is enough clicks.</p>
}

Direction

HTML should stay readable.

Many interfaces are mostly markup. RZ.JS explores whether simple components can keep that markup visible instead of hiding it inside layers of JavaScript structure.

JavaScript should remain JavaScript.

The goal is not to invent a new language. Logic should remain ordinary JavaScript, with a small Razor-style syntax where markup and logic meet.

Small tools can still matter.

RZ.JS is intentionally modest. If it works, it could make simple frontend work feel clearer. If it does not, the experiment will still teach us something useful.

Status

Research only.

RZ.JS currently has no public prototype, package, documentation, or stable syntax.

The current work is about deciding whether the idea is useful enough to prototype: what the syntax should be, how much it should do, what it should avoid, and whether it can remain simple.

Start many things. Keep what proves useful.

Ideas become infrastructure.