Why did some songs never make it into the dashboard?

Lyrics come from lrclib.net, a free community database, and tracks with no match are skipped and written to a -skipped.json file beside the output, so the omission is recorded rather than silent. Add the discography size problem and you have the other half: MusicBrainz allows one request per second, so fetching a large catalogue takes a few minutes on its own before classification starts.

How do I keep a full run from getting expensive?

Use --limit to bound the number of songs, remembering that its default of 100 only applies when the CLI prompted you interactively and is unbounded otherwise, and leave --include-non-albums off unless you want singles, live albums and compilations. Caching does the rest: because discography, lyrics and classification are all cached under the data dir, raising --limit only fetches and classifies the additional songs beyond what is already on disk.

Do I have to put an API key on disk to use this?

No. If TYPESAFE_API_KEY is not set in your environment or a .env, the CLI prompts with a masked input, uses the key for that run only and never writes it anywhere. You can export it in your shell profile or drop a .env in the directory you run from. Inside a clone of the repo a 1Password secret reference also works, though it resolves only where that plugin is installed and fails like an unset key everywhere else.

Is it really one call per song, or one call per question?

One call per track, with all five classifiers sent together and artist, track and lyrics as state, which is the pattern TypeSafe's parallel questions cookbook recommends over separate calls per question. And because lyrics are already on disk by the time classification starts, songs classify concurrently rather than one at a time, including cached ones that cost nothing.

What sources does discoprint use for lyrics and metadata?

MusicBrainz (free, keyless) resolves the artist and pulls the album/EP discography, and lrclib.net (free, keyless) fetches plain lyrics per track, with unmatched tracks recorded in a skipped file.

How does discoprint cache a run?

Everything caches under /cache/, default $XDG_CONFIG_HOME/discoprint; a rerun of already-classified songs makes exactly one real network call, the artist lookup, and serves the rest from disk.

What does the discoprint terminal dashboard show?

A live Ink app with a status header, scrolling classification log, a spotlight panel per result, a theme legend and a stats footer, which morphs into the final OVERVIEW, CLASSIFICATION AVERAGE, DISCOGRAPHY and SONGS dashboard.

CommunityJev Tools & CLIs

Discoprint

Classifies an artist's discography by theme, mood and lyrical complexity with Jev, then renders it as an Ink terminal dashboard. MusicBrainz supplies the discography, lrclib.net the lyrics, one batched call per track.

See highlights

Open github.com

Stars: 3
Language: JavaScript
License: APACHE-2.0
Published by: Community
Author: lirantal
Last verified: Oct 2026

lirantal/discoprint

User repository on GitHub

View on GitHub

Classify an artist's discography by theme, mood, and lyrical complexity with Jev (TypeSafe AI), and view it as a colorful terminal dashboard

Forks: 0
Last pushed: Updated Oct 2026

Repo stats from the GitHub API, cached Oct 2026.

About this project

Classify an artist's discography by theme, mood, and lyrical complexity with Jev (TypeSafe AI), and view it as a colorful terminal dashboard. Classifying needs a TypeSafe API key (Jev). If TYPESAFEAPIKEY isn't set — in your shell, a .env in the current directory, or wherever else your environment normally sources it from — the CLI prompts for it interactively (masked, like a password) and uses it for that run only; it's never written to disk. To skip the prompt every time, either export it in your shell profile:

Quoted from the project's README. Read the full README.

Tagscommunity jevbest catalog-import awesomejev

Works forJev for Classification

Used inJev for Software & DevTools

Languages: JavaScript

Highlights

Five atomic classifiers go in a single systemOne call per track, with artist, track and lyrics as state, per the parallel questions pattern.
Every stage is cached under the data dir, so a rerun with a raised --limit makes exactly one real network call, the artist lookup, and no Jev calls at all.
In a real terminal it is one continuous Ink app: status header, scrolling log, a spotlight panel per result and a running legend.
No key needs to live on disk: with TYPESAFE_API_KEY unset the CLI prompts masked for that run only and never writes it, or reads .env in the working directory.

Watch out

Two data sources bound what you can classify. MusicBrainz is rate limited to one request per second, so a large discography takes minutes before any Jev call happens, and lrclib.net is a community lyrics database where unmatched tracks are skipped outright and recorded in a -skipped.json file next to the output, which means the dashboard can quietly cover less of the discography than you asked for. Because lyrics are already on disk when classification starts, lyrics go to the Jev API as part of state, so the cache and your key configuration are the privacy surface here. The --limit default of 100 applies only when the CLI prompts interactively; otherwise it is unbounded, so a scripted run over a big catalogue can be much larger than it looks. There is no lyric cache invalidation, since lyrics do not change: deleting the file is the only way to retry one track, and --force re-fetches the discography and re-classifies but still reuses cached lyrics. The data directory defaults to $XDG_CONFIG_HOME/discoprint rather than your working directory. The classifier definitions and their rubrics live in src/jev.ts and the README states that file is the source of truth. Copy reviewed against the repository README on 2026-10-04, not from running it.

Questions about this entry

Short answers drawn from the linked project or page.

More Jev resources like this

jev-reviewer

Browser app for systematic-review extraction that opens a trial report with supplements and returns verbatim quotes with file and place, stored locally as projects holding studies.