Thank you for reading. Since opening this thread we’ve successfully implemented Railway Storage Bucket caching and solved most of our reliability issues.

The remaining challenge is achieving a truly audiobook-quality experience comparable to Audible or Dwell.

Specifically:

• We currently generate one MP3 per verse.
• Playback now works reliably.
• However, short verses (especially in Psalms, Proverbs and Ecclesiastes) still produce noticeable pauses between verses.
• For a paid product, I don’t think the experience is yet at audiobook quality.

My question is:

What architecture would experienced audiobook/audio engineers recommend to achieve a seamless listening experience?

For example:

• Continue with verse-level audio and optimize further?
• Generate chapter-level audio for book playback?
• Generate grouped verse blocks?
• Use some other approach?

The goal is that a user could realistically listen continuously from Genesis to Revelation in a way that feels comparable to Audible or Dwell.

Any advice would be hugely appreciated.

I think the core issue isn't Railway, caching, or OpenAI TTS. It's the granularity of the audio.

If your goal is to provide an Audible/Dwell-quality listening experience, I'd recommend a hybrid architecture instead of relying entirely on one MP3 per verse.

For normal playback, generate and cache one audio file per chapter. That gives listeners continuous narration without the gaps that inevitably occur when switching between hundreds of tiny MP3 files.

For search, saved verses, collections, and sharing, continue generating individual verse audio. Those use cases actually benefit from verse-level files.

Alongside each chapter MP3, store a small metadata file containing the timestamp of every verse (start/end time). That allows you to highlight the current verse, jump to a specific verse, synchronize progress across devices, and resume playback, all while using a single continuous audio file.

I'd also generate the entire chapter in a single TTS request, rather than one request per verse. Giving the TTS model the full context generally produces much more natural pacing, intonation, and transitions.

Finally, preload the next chapter while the current one is playing. By the time the listener reaches the end of Chapter 1, Chapter 2 should already be available locally, making the transition effectively seamless.

I wouldn't recommend grouped verse blocks (e.g. Proverbs 1:1-5, 1:6-10). They reduce the number of transitions, but they don't eliminate them. You'll still hear a pause every few verses.

In short, I'd use:

Chapter audio for normal listening.

Verse audio for search, favorites, and sharing.

Per-verse timestamps for synchronization, navigation, and progress tracking.

That architecture is much closer to how I'd expect a professional audiobook platform to be built.

Hi again, thank you very much for your detailed reply.

I discussed the chapter-level audio approach with my developer and he raised one potential drawback.

We agree that chapter-level audio would likely create a much better audiobook experience by removing the pauses between short verses.

However, our current implementation highlights the exact verse being played, updates progress continuously, and allows the user to see exactly where they are in the chapter.

My developer’s concern is that if we switch to chapter-level MP3 files, it may become impossible (or very difficult) to know which verse is currently being spoken at any given moment.

For example, if the user is listening to Psalm 119 or Genesis 19:

• the current verse is highlighted,
• progress is saved at verse level,
• the car Bluetooth display can potentially show the current verse,
• and the user can resume at the exact verse they stopped.

My question is:

How do audiobook or podcast platforms solve this problem?

Is there a standard architecture for:

• having a seamless chapter-level audiobook experience,
• while still knowing the current verse position within that chapter,
• and allowing resume, highlighting and progress tracking?

Or is the normal trade-off simply that audiobook quality is prioritised over exact verse-level tracking?

Many thanks again for your help.

Thank you very much for the detailed explanation. This makes a lot of sense.

One question from my developer:

If we move to chapter-level audio (for example Psalm_119.mp3 or Genesis_19.mp3), how would you recommend maintaining the currently active verse?

Our current implementation tracks:

• active verse highlighting,
• verse-level progress,
• exact resume position,
• UI updates during playback,
• and potentially Bluetooth/car metadata.

Would the usual approach be to maintain a timestamp index for each chapter, for example:

Verse 1 → 00:00

Verse 2 → 00:14

Verse 3 → 00:31

and then derive the current verse from the playback position?

Or would you recommend a different architecture?

We are trying to achieve both:

1. Audible/Dwell-quality continuous playback.
2. Exact verse-level tracking and highlighting.

Many thanks again for your help.

Thank you again for the excellent advice on chapter-level audio. We’ve discussed this further with our developer and have one remaining architectural question that we’re struggling to solve: preserving active verse highlighting and verse-level progress tracking when using chapter-level audio.

Is anyone able to provide me expert advice on this please?

Hi are you able to provide me expert advice on the latest question please?