letam shared

Public

Created and seeded transcription profiles for ApplePublic

The user requested help choosing the best transcription model and creating profiles for clean and noisy audio on Apple Silicon. The assistant recommended WhisperX models, created two profiles directly via SQLite, and then developed a utility to seed these profiles into the repository with a refactored seeding approach to support multiple built-in profiles on startup.

Agent

Claude Code

Model

Claude Opus 4.7

Shared

Apr 29, 3:36 AM

Messages113

Workspace

Repo

rishikanthc/Scriberr

help me choose best model for transcription

It depends on what you're transcribing. Quick guide for Scriberr's four families:

WhisperX large-v3 — best default. Strongest multilingual (~99 langs), works well with diarization (the path you just restored), handles noisy/accented audio. Needs ~10GB VRAM; slower. Drop to medium or small if you're CPU-only or English-only and want speed.
NVIDIA Parakeet — fastest, very accurate English. Pick this for clean English audio and bulk throughput.
NVIDIA Canary — top-tier accuracy on en/de/fr/es plus translation. Pick this if you only need those languages and want lowest WER.
Mistral Voxtral — newest, multilingual with audio-reasoning. Useful if you want LLM-style understanding alongside the transcript, but less battle-tested.

Two quick questions to narrow it down:

What language(s) and is the audio clean or noisy/multi-speaker?
Are you running CPU, Apple Silicon, or NVIDIA GPU? (Parakeet/Canary need CUDA; the recent commit mentioned ARM64 diarization, so you may be on Apple Silicon.)

Tell me those and I'll point at one.

i want to create profiles for both clean audio and noisy
using apple silicon

Good — on Apple Silicon, WhisperX is your only realistic option (Parakeet/Canary are CUDA-only; Voxtral is too heavy without GPU). The good news: WhisperX runs fine via faster-whisper on CPU/Accelerate. Here are two profiles I'd start with:

Profile 1: "Clean audio — fast"

For interviews on a good mic, podcasts, single speaker, low background noise.

Model: medium.en (English) or medium (multilingual) — large-v3 is overkill for clean audio and ~3x slower
Device: cpu
Compute type: int8 — big speedup on Apple Silicon, accuracy loss is negligible on clean speech
Batch size: 8
VAD method: silero (faster, fine for clean audio)
Chunk size: 30
Diarization: only enable if multi-speaker

Profile 2: "Noisy / hard audio — accurate"

For phone calls, field recordings, overlapping speakers, accents, background noise.

Model: large-v3
Device: cpu
Compute type: float32 (accuracy matters more than speed here)
Batch size: 4 (lower — larger model, keep memory steady)
VAD method: pyannote (better at separating speech from noise)
Chunk size: 20 (shorter chunks reduce hallucination drift in tough audio)
Diarization: on
If you're seeing hallucinated/repeated text, also lower temperature and disable condition-on-previous-text if exposed

Notes specific to your setup

The recent commit pinning torchcodec for PyTorch 2.8 + the ARM64 diarization restore suggests you've already validated the diarization path on M-series — good, profile 2 will use it.
If large-v3 feels too slow, large-v2 is often nearly as accurate and a touch faster. large-v3-turbo is another option if it's exposed in your model list (not listed in TranscriptionConfigDialog.tsx:136).
First run downloads the model (~3GB for large-v3); subsequent runs are cached.

Want me to look at TranscriptionConfigDialog.tsx and tell you exactly which dropdown values to pick, or open the profile creation flow?

can you create these profiles directly via code?

Let me investigate how profiles are stored before answering.

Yes, two ways — both feasible. Want me to confirm which before I touch anything?

Option A: Direct SQLite insert into data/scriberr.db (table transcription_profiles).

✅ No auth, no server needed
⚠️ Server is currently running (PID 24174 on :8080) — it should re-read on the next request, but bypassing GORM means we lose BeforeCreate/BeforeSave hooks. Safe here since neither profile is is_default (you already have "Default") and I'll generate UUIDs manually.

Option B: HTTP POST to http://localhost:8080/api/v1/profiles with curl.

✅ Goes through the running server, exercises the same path the UI uses
⚠️ Needs an API key or JWT — do you have one handy, or want me to grab one from the DB / a settings file?

I'd lean Option A unless you want to validate the API path. Confirm which, and I'll create both profiles with the params I recommended (clean = medium + int8 + silero; noisy = large-v3 + float32 + pyannote + diarize).

Now creating the two profiles.

Both profiles are in. Verified:

Profile	Model	Compute	VAD	Chunk	Batch	Diarize
Clean audio — fast	medium	int8	silero	30	8	off
Noisy audio — accurate	large-v3	float32	pyannote	20	4	on

Notes:

Inserted directly via SQLite (WAL mode, safe alongside the running server). Refresh the Settings → Profiles page or the transcription dialog to see them.
Neither is set as default, so your existing default profile (the one you've named "whisper") is untouched.
All other params inherited from the column defaults — same baseline as your existing profile.
First run of the Noisy profile will download large-v3 (~3GB) and the pyannote diarization model. The Clean profile will download medium (~1.5GB). Both cache after first use.

If you want to tweak language-specific behavior (e.g. force medium.en for English-only on the clean profile, or set language=en on noisy to skip auto-detect and shave a bit of time), just say which.

can you create a utility that does this to the repo?

Let me check the existing repo structure first so the utility fits the conventions.

Before I write, three real shape options — they have different blast radius:

A. New subcommand on existing scriberr-cli (e.g. scriberr profiles seed-presets)

Goes through the HTTP API (uses existing auth flow in internal/cli/login.go)
✅ Reuses CLI conventions, exercises real code path
⚠️ Needs server running + login

B. New standalone binary cmd/seed-profiles/main.go that opens the DB via database.Initialize + GORM repository

Mirrors the existing seedDefaultProfile pattern in internal/database/database.go:115
✅ Works without server; uses GORM hooks (UUID, default-flag) properly; idempotent via FindByName
⚠️ Adds a second admin binary

C. SQL seed file committed to e.g. data/seeds/profiles.sql, run via make seed-profiles

✅ Smallest surface, matches what I just did manually
⚠️ Bypasses GORM hooks; duplicates schema knowledge in SQL

My recommendation: B. It's the right idiom for this codebase (you already have seedDefaultProfile), works in fresh installs without auth setup, stays idempotent, and reuses models.TranscriptionProfile so the schema can never drift from the seed.

Scope: hard-code the two Apple-Silicon presets (Clean / Noisy), idempotent (skip by name), --force flag to overwrite. Add a make seed-profiles target.

Confirm B and I'll build it. Or pick A/C and I'll build that instead.

should the existing seed code be refactored? what's the cleanest solution?

Good question — and yes, it's worth refactoring. The cleaner shape removes the need for a separate CLI utility entirely.

Today seedDefaultProfile (database.go:115) is:

One hardcoded profile, inline in database.go
Skip condition: count > 0 (i.e. only seeds an empty DB)

That count > 0 check is the real problem. It means: once any profile exists, no built-in profile can ever be added again. So if you ship a new preset in v1.2, no existing install will ever see it.

Cleanest shape

Move presets to a name-keyed registry, idempotent by name, runs on every startup:

internal/database/
  database.go           // calls ensureBuiltInProfiles(db)
  profile_seeds.go      // []models.TranscriptionProfile registry + ensure fn

Why this is cleanest

One source of truth. Presets are typed Go values next to the model they target — schema drift is impossible.
No new binary, no CLI auth, no Makefile target. The "utility" is just app startup.
Forward-compatible. Add a 4th preset in a future release → it lands on every existing install without clobbering anything users have edited or renamed.
Idempotent by name, not count. Survives partial deletes; doesn't fight user customization (we only insert when missing, never update).

The one tradeoff to call out

If a user deliberately deletes a built-in profile, it comes back on the next startup. Two ways to handle that:

Accept it (my recommendation) — these are "built-ins", coming back is consistent with the name. Users who don't want them can rename them; renaming changes the key, so they won't be re-seeded.
Track seeded-ness in a small table (seeded_builtin_profiles(name TEXT PRIMARY KEY)) — only seed each name once, ever. Cleaner UX, but ~15 extra lines and a new table for a corner case.

I'd ship #1 and only move to #2 if it actually annoys someone.

What this means for your earlier ask

The "create a utility" task collapses into: refactor seedDefaultProfile → ensureBuiltInProfiles, add the two new presets to the slice, delete the count > 0 check. ~40 lines of diff, no new files, no new binary.

Want me to implement it?

yes

Let me check the model field details before writing.

Now update database.go to call the new function and remove the old one.

Build passes. Let me run go vet and the relevant tests.

Let me show the final shape of the change.

Done. Build and vet are clean.

What changed

New internal/database/profile_seeds.go (~115 lines) — preset registry + ensureBuiltInProfiles
internal/database/database.go — seedDefaultProfile (52 lines) replaced with one call to ensureBuiltInProfiles. Net: −50 lines

Behavior

On every startup, the seeder iterates the three built-ins (Default, Clean audio — fast, Noisy audio — accurate) and inserts only those whose Name is missing.
User edits to a built-in are preserved (we only insert when missing, never update).
IsDefault: true on Default only takes effect when no profile in the DB is currently marked default — otherwise it's downgraded to non-default so existing user defaults are never overridden.
count > 0 check is gone, so future presets you add to the slice will land on existing installs automatically.

One thing to know about your local DB

You currently have three profiles, none of which are marked default:

whisper                 is_default=0
Clean audio — fast      is_default=0
Noisy audio — accurate  is_default=0

On your next server restart, the seeder will add a fresh Default profile (IsDefault=true) because no profile is currently default. You'll end up with four profiles. If you'd rather have whisper be the default, set it in Settings before restarting (or UPDATE transcription_profiles SET is_default=1 WHERE name='whisper';) — the seeder will then see a default exists and skip creating its own.

Want me to commit this?

yes

Committed as 55166dd (2 commits ahead of origin/main, not pushed). Working tree clean.