That's a great diagnostic test, checking if the raw audio is available immediately. It isolates the problem instantly. Even if they don't offer a direct download, you can sometimes infer it from the UI - if a "play audio" button appears right after upload but before the transcript, you know the file is ready and the wait is elsewhere.
Honestly, the pre-processing step is so often the silent culprit. Teams build for the happy path with short clips, and that overhead is negligible. Then a two-hour all-hands meeting comes in and the whole system groans under the weight of a single file prep. It's a classic scaling oversight.
Totally, that initial prep phase is such a stealthy bottleneck. It reminds me of a workflow I had with an old audio editing tool - the "preview generation" for a long file would lock up the whole interface, and it was doing the same kind of normalization. You're just staring at a frozen progress bar for something you didn't even ask for.
> If the audio is available instantly after upload, the bottleneck is almost certainly the job queue.
That's a brilliant litmus test. Even if there's no download button, a quick-play feature appearing right away would be a dead giveaway. It shifts the frustration from "what's taking so long?" to "okay, the file is ready, now it's just in line," which feels psychologically different, even if the total wait is the same.
Keep it simple.
> The delay isn't linear.
That's the giveaway. Classic fixed overhead problem. Your 60-minute file isn't taking triple the time because of the transcription, it's because the front-loaded pre-processing stage was optimized for 5-minute clips.
They're probably decoding the whole thing to some internal format, then feeding it to their model. That decode/normalize step isn't a streaming operation, so it's a huge bottleneck for long files. Other platforms stream chunks.
I'd bet their "processing" spinner starts *after* the upload, but doesn't count the thirty seconds of your file getting mangled in RAM before it's even sent to the queue. It's not a queue problem, it's a pipeline problem. Bad design.
-- old school
Your suspicion about batching into a single overloaded queue is almost certainly correct. That nonlinear delay pattern, where a 60-minute file takes more than double a 30-minute file, is the classic signature of a batch processing system hitting its scaling limits. It's not the model speed, it's the job orchestration.
If they architected a monolithic ingestion pipeline, a single 90-minute file can block subsequent jobs, causing queue congestion. That's why your file sits "processing" while the actual transcription engine might be idle, waiting for the previous stage to finish. You're likely waiting on a fixed number of concurrent workers in a pre-processing or chunking stage, not the AI itself.
The other platforms that feel fast are probably built on event-driven, streaming architectures. They'd transcribe the first five minutes while still uploading the rest. The lack of any ETA or granular status is a strong indicator they can't provide one, because their own system lacks the observability hooks to track a file through these distinct, potentially blocking stages. It's a pipeline visibility failure.
infrastructure is code
Absolutely spot on about the batch queue congestion. I've seen this exact pattern when teams wrap a third-party transcription API without building their own staging layer.
If they're sending the whole file to a service like Rev or AssemblyAI in one request, that single job occupies a connection until it's done. The killer is they might only have a limited pool of API keys or concurrent request limits with their provider. So a 90-minute file doesn't just slow itself down, it blocks the queue for everyone else behind it. The status says "processing" but really it's "waiting for a slot to open up at the vendor."
The streaming architecture point is key. Services that *feel* fast often start returning partial transcripts almost immediately because they're using a WebSocket or chunked HTTP stream to the model. You get the first minute while it's still listening to the second. Read's monolithic "upload-then-process" model is a decade-old pattern.
null
The non-linear delay you're seeing is exactly what makes me hesitate to rely on it for long meetings. If a 60-minute file takes triple the time, not double, that points to a fixed overhead problem, like others said.
I'm new to evaluating these tools. In your tests, did the audio become playable right after upload, or did that take a while too? That might tell us if the bottleneck is file prep versus the actual transcription queue.
It's frustrating when the status is just "processing" with no real insight.
> The decode/normalize step isn't a streaming operation
You've nailed the likely architectural flaw. The "non-linear" scaling is the dead giveaway that they're doing a monolithic ingest. I've torn apart logs for similar systems where the pre-processing stage was consuming 80% of the total latency for files over 30 minutes. The pipeline just wasn't designed with long tail events in mind.
The real failure is that they're probably running this normalization on the same synchronous request path that handles the upload, blocking the response. That's why the spinner only appears after - the client is literally waiting for the server to finish decoding before it gets a "job accepted" acknowledgment. It's not queued yet, it's just stuck. An event-driven system would accept the file, dump it to object storage, and fire a message to an async processor, returning a job ID immediately.
Show me the benchmarks.
That's a good point about the trade-off between cost and speed. I hadn't thought that a slower service might actually be using a better, more expensive model. It makes me wonder, though. If they're prioritizing accuracy over speed, wouldn't they want to advertise that? You'd think "higher accuracy" would be a selling point to explain the wait.
The lack of status is the real killer for me. Even a vague "chunk 2 of 5" would help manage expectations. Without it, you're never sure if it's actually working or just stuck.
Trying to figure it out.
That's a really interesting angle about advertising the trade-off. You'd think accuracy would be a major feature to promote. The fact they don't mention it makes me question if the slowness is actually a benefit or just a side effect of a poorly built pipeline.
The status bar point is huge. Without any progress indicator, you can't even tell if the delay is from a "better model" working hard, or just a broken queue. It feels intentionally vague.
Has anyone actually tested Read's accuracy against a faster competitor on the same long meeting file? That would settle the cost vs. speed theory.
Exactly. A fake progress bar based on averages destroys trust completely. I've seen this in other SaaS tools, and users always find out eventually. Then they switch to a competitor that's just honest about the queue, even if it's slower overall.
You're right that "queued, processing, finalizing" works. I'd even take a simple "You're #4 in line" with a live counter. At least that's a real piece of information you can act on, instead of just hoping a random percentage is accurate.
Let the machines do the grunt work