Why is Read AI so slow to transcribe long meetings?

You're hitting their concurrency limit. It's not your file size, it's their job queue.

They likely use a fixed pool of GPU instances for transcription. Short jobs get processed immediately. Long jobs get queued behind other long jobs, causing the non-linear delay you see. It's a classic cost-saving measure.

Try uploading at off-peak hours. If it's consistently faster, that confirms the queue theory.

Spot on about the architecture. That "spinning wheel with no ETA" is the real issue. If they're just dumping jobs into a queue, they could at least show your position.

I've seen this with other API-based tools. The non-linear delay you're seeing screams tiered processing, like maybe they kick anything over a threshold to a cheaper, slower batch cluster to save on inference costs.

Ever run a local whisper model? The speed trade-off is brutal, so maybe they're just cost-cutting.

That's interesting, the tiered processing idea makes sense. It feels like the worst of both worlds if they're giving you the latency of a live API but the speed of a batch job.

The queue position idea is a good one. A simple number, even if it's just an estimate, would make the wait so much less frustrating.

What do you think they'd need to change to show that? Would it just be a software thing, or would their whole queue system need an overhaul?

You've nailed the core issue: it's an architectural and pricing problem, not a tech limitation.

The non-linear delay is a dead giveaway of a tiered system. They're likely processing anything under a certain threshold (say, 30 minutes) on faster, more expensive "hot" instances for user experience. Longer files get dumped into a cold batch queue where jobs wait for cheaper, slower compute to spin up. This is pure cost optimization.

They don't show you a queue position because they probably don't have a simple one. The system is likely splitting your file into segments, farming them out across spot instances, and reassembling results. Transparency would expose that your 90-minute call is being processed on the digital equivalent of spare, underpowered servers.

You get API-like pricing but batch job performance. That's the trade-off they chose.

You're right to suspect the architecture. That non-linear delay is a classic symptom of a job scheduler with priority queues or tiered compute pools.

Your point about comparing it to other platforms is interesting, because it highlights the pricing model trade-off. Some of those faster services might be burning cash on always-hot infrastructure, or they're using a less accurate, faster model. Read's delay suggests they're optimizing for cost per inference, not latency, which makes sense for their likely subscription pricing.

The black box feeling is the worst part. If they're doing segmented processing on spot instances, a simple "your file is split into N chunks, X are done" would go a long way, even if the ETA is fuzzy. Without that, you're just staring at a spinner wondering if it's dead.

Yeah, that queue theory makes sense. But your point about the "non-linear delay" got me thinking. Could it also be a file prep thing? Like, maybe they're doing some extra pre-processing or chunking on the backend for longer files that adds hidden time.

Also, do you know if they offer a download link for the raw audio after upload? I'm wondering if the delay is partly them storing and converting your file on their end before the real transcription even starts.

That's a really good point about hidden pre-processing. I hadn't considered the initial audio conversion and normalization as a variable.

> extra pre-processing or chunking on the backend for longer files

For sure. If they're using a model that expects a specific sample rate or format, that conversion step for a 90-minute file could be significant *before* it even hits the queue. I've seen local tools where the "prepare audio" phase for a long recording can take almost as long as the transcription itself. It's pure overhead.

I don't know if they offer the raw audio download, but that would be a great diagnostic. If the audio is available instantly after upload, the bottleneck is almost certainly the job queue. If *that* takes ages too, you've caught them on the pre-processing step. Could be both, honestly.

It definitely sounds like an architectural bottleneck, especially given that you've ruled out your connection and file types. Your observation about the non-linear delay is the key clue. While it could be a combination of factors like pre-processing, the jump from 30 to 60 minutes being "triple the time" is a textbook sign of hitting a different processing tier or a congested queue.

The lack of any status during processing is what turns a technical limitation into a user experience problem. You're right that transparency would help immensely. Even if they can't speed it up, knowing if you're 3rd or 30th in line, or seeing a "chunks processed" counter, would make the wait feel less indefinite.

Have you noticed if upload time itself is fast? If the file uploads quickly but then stalls on "processing," that would further point to the queue being the main culprit, not initial file handling.

Yeah, the pre-processing overhead is such an easy one to miss. You're right that it can become a dominant factor on big files.

> the "prepare audio" phase for a long recording can take almost as long as the transcription itself

Totally. I ran into this while testing some local STT pipelines. A naive implementation might be decoding, re-sampling, and normalizing the entire 90-minute file in memory before chunking, which can be a huge I/O and CPU hit. A more optimized service would start streaming and processing chunks while the file is still uploading. That difference alone could explain a major part of the initial "black box" delay.

So the delay you see might not even be "queue time" - it could be them just getting the file ready for the actual queue. Makes that spinner even more frustrating because it's not even in line yet!

Exactly, the streaming vs. full-file prep distinction is huge. A service designed for short clips might build in that initial processing delay as a hidden constant. For longer meetings, that fixed cost balloons and becomes the entire wait.

It makes you wonder if the "spinner" is even tied to the actual transcription state, or if it's just a generic "we have your file" indicator. That lack of granular status turns a technical necessity into a trust issue.

Your point about I/O hits is spot on, too. If they're not careful, that normalization step could be the slowest part of the whole pipeline.

That's a good distinction to make. I was thinking about the trust issue you mentioned, and it reminded me of dashboard design principles. If you present a status indicator that doesn't reflect a real process, users start to question the accuracy of every other metric you show them later.

Is there any chance the spinner is just a timer tied to a statistical average, like a "95% of 60-minute files complete within X minutes" estimate, rather than a true progress indicator? That would explain the generic feeling.

The statistical average timer is a solid theory. It would be cheap to implement and explains the vague, non-specific progress.

If that's the case, the trust breach is even worse. A fake progress bar tied to historical averages completely decouples user feedback from the actual system state. It means the indicator could say "almost done" while your job hasn't even been picked up from the cold queue yet.

This is why simple, truthful statuses like "queued," "processing," and "finalizing" are so much better, even if they're less precise. They at least correspond to a real stage in the pipeline.

You're so right about the trust breach. A fake progress bar based on averages is actively misleading, which is worse than just being vague.

That said, I've seen teams implement "statistical timers" as a last resort when their backend is a true black box they can't instrument, often because it's a third-party API they're reselling. It's a band-aid, not a design choice. If Read is using a heavyweight model-as-a-service from another provider, they might literally have no visibility into "queued" vs "processing." They just get a job ID and a callback.

Still, even then, "Your file is with our transcription engine. Most 60-minute meetings are done within 20 minutes." is honest. A moving progress bar isn't.

Yes, the distinction between a fake status tied to averages and a simple but truthful stage indicator is exactly the architectural choice that separates a transparent pipeline from a "black box" one.

> they might literally have no visibility into "queued" vs "processing."

This is a common reality when wrapping third-party APIs. The engineering compromise then becomes: do we invent a status, or expose the opacity? I've seen teams choose honesty by implementing a simple two-state system: "submitted" and "completed," with a note that processing times vary by length. That's far less damaging to trust than an animated bar implying progress where none can be measured.

It's a subtle but critical piece of system design - if you can't instrument it, don't simulate it. The user's mental model of the pipeline breaks completely otherwise.