DEV Community: Algoza Solutions

How to Convert Scanned PDF Books into AI-Ready Markdown for Audiobook Generation

Algoza Solutions — Tue, 14 Jul 2026 10:59:57 +0000

Generating an audiobook with AI can look deceptively simple:

Extract the text.
Send it to a text-to-speech system.
Export the audio.

That workflow works reasonably well when the source is a clean EPUB, HTML file, or Word document. It becomes much harder when the book exists only as a scanned or layout-heavy PDF.

A PDF can look perfectly readable to a person while containing no usable text layer at all. Even when extraction succeeds, the result may preserve the words without preserving their meaning, sequence, or hierarchy.

For audiobook production, that distinction matters. A text-to-speech model will faithfully narrate page numbers, misplaced footnotes, duplicated headers, and scrambled columns unless they are removed first.

Three levels of extraction quality

It helps to separate extraction quality into three layers:

Character accuracy: Were the words recognized correctly?
Structural accuracy: Are headings, paragraphs, lists, tables, and notes represented properly?
Narration readiness: Will the text sound natural when spoken aloud?

A document can perform well at the first level and still fail at the other two.

For example, OCR might recognize every word in a two-column page but alternate between the left and right columns. The extracted characters are correct, but the reading order is not. To a listener, the result sounds like unrelated sentences have been stitched together.

Why scanned PDFs cause problems

A scanned PDF usually contains images of pages rather than selectable text. Optical character recognition, or OCR, is required before the content can be passed to an audiobook-generation system.

Some PDFs are hybrids: they contain a scanned page plus a hidden OCR layer. That hidden text is not necessarily reliable. It may have been produced years ago, use the wrong language model, or contain incorrect word boundaries and reading order.

A complete conversion process may need to perform several operations:

Detect page orientation and rotation
Improve contrast or compensate for faded paper
Identify text blocks, images, tables, and page furniture
Recognize characters in the appropriate language
Reconstruct lines and paragraphs
Determine the correct reading order
Identify headings and document hierarchy
Join words split across lines or page breaks
Distinguish body text from captions, footnotes, and marginal notes

OCR systems that return only flat text may recognize the words while losing these relationships.

The resulting output can contain:

Headers and footers inside the narration
Incorrect reading order
Broken paragraphs and missing chapter boundaries
Page numbers mixed with sentences
Tables read one cell at a time
Footnotes inserted in the middle of body text
Words split across lines or page breaks
Repeated text from facing pages
Captions detached from the images they describe
List items merged into a single paragraph
Characters from one script confused with another

How layout errors become audio errors

Errors that are tolerable on screen often become much more noticeable in audio.

Source-document problem	Extracted result	What the listener hears
Repeated page header	The book title appears on every page	The title interrupts the story repeatedly
Line-end hyphenation	`inter-` and `national` remain separate	A broken or mispronounced word
Two-column layout	Lines from both columns are interleaved	Sentences jump between unrelated topics
Detached footnote	The note appears in the next paragraph	An unexpected interruption
Page number in body text	`42` is inserted between sentences	A random number is narrated
Table flattened into text	Labels and values lose their relationships	A confusing sequence of disconnected facts

Text-to-speech does not usually know that these are extraction errors. From the model’s perspective, they are part of the script.

A better PDF-to-audiobook pipeline

A more reliable workflow treats the scanned document as a structured reconstruction problem:

Scanned PDF or page images
            ↓
Image preparation and page analysis
            ↓
OCR and layout detection
            ↓
Document structure reconstruction
            ↓
Structured Markdown
            ↓
Editorial cleanup and narration rules
            ↓
Chapter and section segmentation
            ↓
Text-to-speech generation
            ↓
Audio quality review
            ↓
Mastering, metadata, and delivery

The most important step is document reconstruction.

Extracting characters is not enough. The system must determine which content represents a chapter heading, paragraph, list, footnote, caption, or table—and place those elements in the correct reading order.

Why use Markdown as the intermediate format?

Plain text loses hierarchy. The original PDF preserves hierarchy visually, but it is difficult to edit or automate. Markdown provides a useful middle layer.

For example:

# Chapter 4: The Journey Begins

The train left the station shortly before sunrise.

## An Unexpected Stop

By noon, the weather had changed.

> The original edition presents this passage as an indented quotation.

This structure can be used to:

Split the book at chapter boundaries
Apply different pauses to headings and paragraphs
Find tables, lists, and block quotations
Review edits in Git or another version-control system
Regenerate only the chapters that changed
Keep the cleaned source independent of a particular TTS provider

Markdown is not automatically narration-ready, but it makes the remaining editorial decisions visible and manageable.

Converting scanned books with AlgoOCR

Once Markdown has been chosen as the intermediate format, the next step is to create it from the scanned pages. AlgoOCR performs this conversion in the browser, turning scanned PDFs and images into structured Markdown that can be reviewed, edited, and prepared for narration.

The workflow is straightforward:

Upload a scanned PDF or page images.
Select the pages you want to convert.
Let AlgoOCR read the content and reconstruct its structure.
Download the result as a Markdown (.md) file.
Review and adapt the Markdown for narration.

Depending on the clarity of the scan and the complexity of its layout, the generated Markdown can preserve or rebuild:

Headings and document hierarchy
Paragraphs
Ordered and unordered lists
Tables
Reading order

The difference between flat OCR text and structured Markdown becomes important when the content enters an audiobook workflow. A flat extraction might produce:

CHAPTER THREE
THE LONG JOURNEY
The train left the station
shortly before sunrise.

A structured Markdown version can make the relationships explicit:

# Chapter Three

## The Long Journey

The train left the station shortly before sunrise.

Downstream scripts can use those headings to divide the book into chapters and sections. Paragraph boundaries can guide narration chunks, while tables and lists can be identified for manual rewriting when their visual format would not translate naturally into speech.

Visit AlgoOCR and convert up to three scanned pages to Markdown for free.

Preparing the Markdown for narration

Structured Markdown is a strong starting point, but audiobook preparation still involves editorial choices. These choices should be documented and applied consistently.

1. Preserve the original output

Keep three separate versions when possible:

original-scan.pdf
algoOCR-output.md
narration-ready.md

The original scan remains the visual source of truth. The OCR output provides a record of the conversion, while the narration-ready file contains editorial changes.

This separation makes it easier to investigate errors without repeating the entire conversion.

2. Remove non-narrative content

Decide whether the audiobook should include:

Page numbers
Repeated headers and footers
Copyright and publication information
Dedications
Tables of contents
Image captions
Indexes
Bibliographies
Running section titles
Decorative text

Not every visible element should be spoken. The correct decision depends on the type of book and the intended audience.

A reference book may need citations and figure descriptions. A novel probably should not narrate its index or repeat the author’s name every few minutes.

3. Repair paragraphs carefully

Scanned pages often contain hard line breaks that do not represent real paragraph boundaries.

This:

The road continued through the
forest until it reached the river.

should usually become:

The road continued through the forest until it reached the river.

Hyphenation needs particular care. Joining inter- and national is probably correct, but removing the hyphen from a genuine compound such as well-known is not.

Automated cleanup should therefore be followed by human review, especially around page boundaries.

4. Check chapter boundaries

Use consistent heading levels so automated splitting remains predictable:

# Chapter 1

## Section 1.1

### A smaller subsection

Avoid using bold text as a substitute for headings:

**Chapter 1**

A heading communicates structure to both people and scripts. Bold text communicates only presentation.

5. Handle tables intentionally

A table that is clear on the page may sound confusing when narrated row by row.

Consider this table:

| Plan | Storage | Price |
| --- | ---: | ---: |
| Basic | 10 GB | ₹199 |
| Pro | 100 GB | ₹799 |

A narration-friendly version might be:

The Basic plan includes 10 gigabytes of storage and costs 199 rupees. The Pro plan includes 100 gigabytes and costs 799 rupees.

Keep the original table in the archival Markdown if it is important, but create a prose version for narration when necessary.

6. Establish a footnote policy

Footnotes can be:

Narrated immediately after the referenced sentence
Collected at the end of the section
Moved to the end of the chapter
Excluded from the audiobook

There is no universal answer. The important thing is to choose a policy before generating dozens of chapters.

Inline footnotes may interrupt narrative flow, while end-of-chapter notes can make it difficult to connect a note to its original passage.

7. Review lists, captions, and quotations

Lists may need introductory language so listeners understand their structure. Long nested lists often work better when rewritten as prose.

Block quotations may require a short spoken cue such as “The letter reads” or “The author writes.” Without such a cue, the listener may not know where the quotation begins or ends.

Image captions should be evaluated individually. A decorative caption can be removed, while a diagram containing essential information may need an audio description.

8. Prepare a pronunciation guide

Names, acronyms, abbreviations, dates, formulas, and regional terms are common sources of TTS errors.

Maintain a small pronunciation file alongside the book:

# Pronunciation guide

- AlgoOCR: "Algo O-C-R"
- Dr. Kulkarni: expand "Dr." to "Doctor"
- 1998: "nineteen ninety-eight"
- ₹250: "two hundred and fifty rupees"

Some narration systems support pronunciation dictionaries or SSML. If yours does not, the narration copy can contain controlled phonetic substitutions while the archival Markdown retains the original spelling.

Multilingual narration requires two decisions

OCR language support and narration language support are related but separate.

A system may recognize Hindi, Marathi, and English correctly, but the selected voice must still pronounce each language naturally. Mixed-language passages can be particularly difficult when a sentence changes script or language midway through.

Test:

Proper nouns written in multiple scripts
English technical terms inside Hindi or Marathi sentences
Numbers, dates, currencies, and abbreviations
Poems and passages with unusual rhythm
Words that look similar across languages but are pronounced differently

For heavily mixed-language books, it may be necessary to segment the text by language, use a multilingual voice, or generate certain passages with different voices before assembling the chapter.

Split chapters at semantic boundaries

Many TTS APIs impose input-size limits. Even without a hard limit, sending an entire book in one request makes failures expensive and difficult to repair.

Split at meaningful boundaries:

Chapter
Section
Paragraph
Sentence

Avoid cutting text at an arbitrary character count when possible. A split in the middle of a sentence can change pacing, pronunciation, and context.

Here is a simple chapter-splitting script:

from pathlib import Path
import re

source = Path("book.md")
output_dir = Path("chapters")
output_dir.mkdir(exist_ok=True)

markdown = source.read_text(encoding="utf-8")

# Adjust this expression if the book uses a different chapter format.
chapter_pattern = re.compile(
    r"(?im)^#\s+Chapter\b.*$"
)

matches = list(chapter_pattern.finditer(markdown))

if not matches:
    raise SystemExit(
        "No chapter headings found. Check the Markdown heading format."
    )

# Preserve content before the first chapter, such as a title page or preface.
front_matter = markdown[:matches[0].start()].strip()

if front_matter:
    (output_dir / "00-front-matter.md").write_text(
        front_matter + "\n",
        encoding="utf-8",
    )

for number, match in enumerate(matches, start=1):
    start = match.start()
    end = matches[number].start() if number < len(matches) else len(markdown)

    chapter = markdown[start:end].strip()

    path = output_dir / f"{number:02}-chapter.md"
    path.write_text(chapter + "\n", encoding="utf-8")

print(f"Created {len(matches)} chapter files.")

This version keeps front matter separate and fails visibly when the expected headings are missing. For Hindi or Marathi books, adjust the pattern to match the chapter labels used in the source.

Each chapter can now be reviewed, narrated, and regenerated independently.

Make TTS generation reproducible

For every generated chapter, record:

Source filename
Voice and language
Model or API version
Speaking rate
Pronunciation substitutions
Generation date
Output filename
Whether the audio passed review

A small manifest makes later corrections much easier:

{
  "chapter": 4,
  "source": "04-chapter.md",
  "voice": "narrator-a",
  "language": "en-IN",
  "speaking_rate": 0.95,
  "output": "04-chapter.wav",
  "status": "reviewed"
}

If Chapter 4 contains a pronunciation error, you can change its source and regenerate only that chapter instead of rebuilding the entire audiobook.

Review the text before paying to narrate it

Automated checks can catch many problems before TTS generation.

Search for:

Isolated page numbers
Repeated lines
Empty or unusually short chapters
Words ending in a hyphen
URLs and email addresses
Markdown tables
Footnote markers
OCR artifacts such as unexpected symbols
Headings without body text
Very long paragraphs with no punctuation

These checks do not replace editorial review, but they can identify high-risk passages quickly.

Test a representative sample

Do not test only the cleanest page in the book. Choose a sample that contains several difficult elements:

A chapter transition
Dialogue
A list or quotation
Proper nouns
Mixed-language text
A footnote
Numbers or dates
A page break in the middle of a paragraph

Listen for:

Incorrect pauses
Broken sentences
Mispronunciations
Unwanted page furniture
Repeated passages
Abrupt changes in volume or pace
Poor transitions between headings and paragraphs

A five-minute test can reveal problems that would otherwise be repeated across ten hours of audio.

Audio review and mastering

Text accuracy is only one part of audiobook quality. The generated audio should also be checked for:

Consistent voice and speaking rate
Consistent loudness between chapters
Clipping or distortion
Excessively long or short silences
Missing chapter openings or endings
Duplicated audio after retries
Correct chapter order
Accurate filenames and metadata

Keep an uncompressed working copy when practical. Delivery formats can be created after editing and mastering are complete.

Rights and privacy still matter

Before converting or narrating a book, confirm that you have the necessary rights to reproduce and distribute it. A physical copy or scanned PDF does not automatically include audiobook-production rights.

Sensitive or unpublished documents also require extra care. Review the OCR provider’s current privacy and retention policies before uploading confidential material.

Final thoughts

The quality of an AI-generated audiobook depends on more than the voice model. It depends just as much on the structure and editorial quality of the text sent to that model.

When the source is a scanned PDF, ordinary extraction can push layout errors directly into narration. A better workflow reconstructs the document first, creates a structured and reviewable Markdown source, and only then begins speech generation.

The practical lesson is simple:

Treat OCR output as an editable production asset, not as a finished audiobook script.

That additional reconstruction and review step is what turns a technically successful extraction into an audiobook people can comfortably listen to.

India Runs on Scanned Documents. Why Can't We Convert Them Properly?

Algoza Solutions — Thu, 19 Feb 2026 04:18:44 +0000

How we built AlgoOCR — an AI-powered tool that converts scanned Hindi, Marathi & English documents into structured Word and Excel files, not just raw text.

India runs on paperwork. Government offices, gram panchayats, schools, courts, taluka offices — millions of documents are printed, stamped, signed, and filed every single day. And when someone finally tries to digitize them? They hit a wall.

Google Lens reads the text — sure. But it dumps everything into one unformatted blob. Tables from a जन्म-मृत्यू नोंदवही? Gone. Column headers from a ration card list? Flattened into a single line. The document you spent 10 minutes scanning now needs another 30 minutes of manual cleanup in Word.

For anyone working with Indian language documents — especially Devanagari script — this is a daily frustration. We kept running into it, and we decided to fix it.

The Problem: OCR ≠ Document Conversion

Most OCR tools solve one narrow problem: extracting text from images. And they do it well for English. But when you're working with:

Devanagari script (Hindi, Marathi)
Multilingual documents (Hindi + English, Marathi + English mixed)
Tabular government records and meeting minutes
Scanned PDFs from gram panchayats, schools, and offices

...the existing tools fall apart. You get raw text with zero structure. No tables, no headings, no formatting. Just a wall of Unicode characters you have to reassemble manually.

That's the gap AlgoOCR fills. It doesn't just read text — it rebuilds the entire document.

What AlgoOCR Actually Does

AlgoOCR is a web-based tool that takes a scanned PDF or image and outputs an editable .docx or .xlsx file with:

Tables reconstructed with proper rows and columns
Headings, paragraphs, and lists preserved
Hindi, Marathi ↔ English translation built in
Layout and formatting that matches the original

Here's the difference in practice:

Google Lens output:

ग्रामपंचायत कार्यालय दिनांक 01/02/2026 अ.क्र. नाव गाव 1 रामचंद्र पाटील सातारा 2 सुनील जाधव पुणे

AlgoOCR output: A properly formatted .docx with the heading intact and a clean table:

अ.क्र.	नाव	गाव
1	रामचंद्र पाटील	सातारा
2	सुनील जाधव	पुणे

That's the difference between reading a document and converting it.

Who Is This For?

We built AlgoOCR for people who deal with Indian language documents daily:

Government offices and gram panchayats digitizing records and registers
Schools, colleges, and universities converting exam papers, mark sheets, and notices
Legal professionals working with regional language court documents
Businesses across India processing invoices, contracts, and compliance paperwork
Researchers and students digitizing texts in Devanagari
Anyone tired of retyping scanned documents by hand

AlgoOCR currently supports Hindi, Marathi, and English (including multilingual documents), with more Indian languages on the roadmap.

Try It Right Now (No Signup)

One thing we're proud of: you can try AlgoOCR without creating an account.

Head to algoocr.com, scroll to the demo section, drop a scanned PDF or image, and get a converted file in seconds. You get 3 free pages with no signup, and 15 free pages when you create an account.

Pricing (It's Affordable)

We intentionally kept pricing accessible for Indian users:

Plan	Price	Pages/Month
Free	₹0	15 (lifetime)
Starter	₹99/mo	100
Standard	₹299/mo	300
Professional	₹999/mo	1,000
Max	₹2,999/mo	5,000

API access is coming soon on the Max plan for developers who want to integrate AlgoOCR into their own workflows.

What's Next

We're actively working on:

More Indian languages — Tamil, Telugu, Kannada, Bengali, and others are on the roadmap
API access for developers and SaaS integrations
Batch processing for bulk document conversion
Improved handwriting recognition for Devanagari

Wrapping Up

OCR has been a "solved problem" for English for years. But for India's regional languages — especially when you need real document output, not just raw text — there's been a massive gap. AlgoOCR is our attempt to close it, starting with Hindi, Marathi, and English — and expanding to more Indian languages soon.

If you work with Hindi or Marathi documents, give it a spin: algoocr.com

We'd love your feedback. Drop a comment below or reach out at info@algozasolutions.com.

Built with ❤️ in India by Algoza Solutions

Tags: #ocr #ai #india

Why I Removed All Notifications from My Task App

Algoza Solutions — Sun, 08 Feb 2026 09:42:20 +0000

Every task app on the market wants your attention. I built one that doesn't.

When I set out to build CalmLoop, I made a decision that most product people would call insane: zero push notifications. No badges. No buzzing. No red dots screaming at you from your home screen. The app sits quietly until you decide to open it.

This wasn't laziness. It was the whole point.

The attention trade you didn't agree to

Somewhere along the way, productivity tools stopped being tools. They became attention machines. Every app on your phone is competing for the same limited resource - your focus - and they're using every trick in the book to win.

Push notifications. Badge counts. Streaks that guilt you into opening the app. Reminder pings that interrupt the very work you're trying to do.

Think about that for a second. The app that's supposed to help you focus is actively breaking your focus to remind you to focus.

We've normalized this so deeply that when I tell people CalmLoop has no push notifications, their first reaction is "then how do you remember your tasks?" As if humans were incapable of remembering things before 2012.

Notifications don't help you - they train you

There's a difference between being reminded and being interrupted. A reminder serves you. An interruption serves the app.

When a task app pings you at 2 PM to "review your goals," it's not doing that because 2 PM is the optimal time for you to review your goals. It's doing it because engagement metrics go up when you open the app more. Your attention is being monetized, even if you're not seeing ads.

Every notification trains a subtle dependency: you stop trusting yourself to remember, and you start trusting the app to tell you. Over time, you don't check your tasks because you want to - you check because the app told you to. That's not productivity. That's compliance.

One email. Once a day. That's it.

CalmLoop sends one email at 8 AM in your timezone. It shows you three things: what's overdue, what's due today, and what's coming soon.

That's your one decision point for the day. You scan it, you open the app if you want, you pick your focus tasks, and you get to work. After that, the app disappears. It doesn't chase you. It doesn't nudge you at lunch. It doesn't send you a passive-aggressive "you haven't checked in today!" message at 6 PM.

Why email instead of a push notification? Because email is pull, not push. It waits in your inbox until you're ready. You process it on your own terms, at your own pace. It doesn't hijack your phone's lock screen while you're in the middle of deep work.

The Focus Zone: decide once, execute all day

Most task apps show you everything at once. You open the app and you're staring at 40 tasks across 6 projects, trying to figure out what to do next. That's not a productivity tool — that's a decision fatigue generator.

CalmLoop splits your world into two modes: planning and execution.

Your pending list is where everything lives. All your tasks, across all your projects, with due dates and priorities. That's for planning - you interact with it when you're thinking ahead, usually during your morning review.

Your Focus Zone is what you'll actually work on today. You pick a few tasks, add them to Focus Zone, and everything else gets minimized. Now your screen shows only what matters right now. No distractions. No reshuffling. Just your commitments for the day.

This separation sounds obvious, but almost no task app does it. They treat planning and doing as the same activity, which is why people spend more time reorganizing their task list than actually doing the tasks.

Progress notes, not performance metrics

CalmLoop doesn't have streaks. It doesn't gamify your productivity. It doesn't show you charts of how many tasks you completed this week compared to last week.

What it does have is timestamped notes on every task. When you add a note, it records when you wrote it. When you complete a task, it records when you finished. When you look at your notes timeline, you see the story of your day — what you worked on, when you worked on it, and what progress you made.

This isn't about measuring yourself. It's about having a record. When someone asks "when did you finish that?" you know. When you sit down tomorrow morning, you can read yesterday's notes and pick up exactly where you left off. When review season comes around, you have months of timestamped evidence of what you shipped and when.

The difference is subtle but important: metrics pressure you to perform. A record helps you remember. One creates anxiety. The other creates clarity.

Your attention is not our product

Most apps are free because you are the product. Your usage data, your behavior patterns, your engagement metrics - that's what gets sold, either to advertisers or to investors as proof of growth.

CalmLoop costs $1 a month. That's it. No free tier with ads. No premium upsells. No tracking, no analytics, no third-party anything. You pay a dollar, you get the full app, your data stays yours.

I built CalmLoop as a solo founder because I was tired of my own tools fighting for my attention. I use it every single day. I have no investors to please, no growth targets to hit, no engagement metrics to optimize.

The app makes money when you pay for it. Not when you open it, not when you click on it, not when you spend more time inside it. This means my incentive is the opposite of every other app: I want you to open CalmLoop as little as possible and spend your time doing actual work.

This isn't for everyone

If you love Notion's infinite customization, CalmLoop will feel too simple. If you need team collaboration and Gantt charts, this isn't your tool. If you want AI-powered task suggestions and smart scheduling, look elsewhere.

CalmLoop is for people who have tried all of that and felt more overwhelmed, not less. It's for the person who muted their last three apps. The developer who loses track of time during deep work. The professional who spends more time managing their system than using it.

It's a quiet app for people who want less noise and more clarity.

And it will never, ever ping you.

CalmLoop is a calm task management app built by a solo founder. No notifications, no tracking, no tricks. Just your tasks, waiting when you're ready. Try the demo - no sign-up needed.