Nightingale: turning a local music library into a karaoke rig with WhisperX and UVR

The gap Nightingale fills: karaoke for songs that have no karaoke version

Most karaoke software assumes a catalogue of purpose-made tracks. You get a library of instrumentals with timed lyrics, and you sing those. Nightingale inverts the assumption. It scans a folder, a Plex library, a Jellyfin library, a Navidrome server or a self-hosted web library, and treats whatever audio and video is already there as source material. The vocals are removed by a separation model, the lyrics are transcribed and aligned automatically, and the result plays back with synchronized highlighting and pitch scoring. The README's own summary is "Karaoke from any song in your music library, powered by neural networks."

The audience is narrow but well defined. It is someone who has a music collection and a microphone, and who wants a party or a personal practice session without buying karaoke packs. It is also someone comfortable with a desktop app that downloads several gigabytes of tooling on first launch. This is not a phone-first sing-along app and it is not a streaming service. The self-hosted mode is aimed at a Linux box on a home network, opened from phones, laptops, tablets and TVs at `<hostname>.local`, which tells you the intended setting is a household with a server and a living room screen.

What happens between pressing Analyze and hearing an instrumental

The pipeline has four visible stages, and the repository layout and README make each one identifiable. First, ingestion: a track arrives from a folder scan, a Plex import, a Jellyfin library, a Navidrome library, or a USDX song folder. Second, stem separation: the UVR Karaoke model is the default, with Demucs as an alternative, and the README notes that the karaoke model keeps backing vocals inside the instrumental "for a more natural sound." That is a deliberate choice with a cost, since backing vocals are also something a singer may want removed.

Third, lyrics. Nightingale either fetches them from LRCLIB, or transcribes them with WhisperX and aligns them to word-level timestamps. A timed LRC file pasted through the song's Actions button is used as-is, and the README says that path can optionally skip stem separation entirely so you sing over the original mix. Plain lyrics instead go through alignment. Fourth, playback: Tauri front end, React and Tailwind and shadcn underneath, with key and tempo shifts applied after analysis and cached as separate playback variants so a retry is fast. Pitch scoring runs from real-time microphone input, and the README describes a beep-based latency test in Settings plus a mic monitor with gain from 0 to 200 percent, which exists because scoring is only as good as the alignment between what the microphone hears and what the player outputs.

ASR and alignment are pluggable, and the defaults are the conservative ones

Whisper is the default ASR engine and WhisperX's aligner is the default forced aligner. Both have experimental alternatives. Parakeet v3 covers roughly 25 European languages and runs on NeMo with CUDA or ONNX Runtime elsewhere. GPU forced alignment uses torchaudio's `forced_align` for faster word timestamps on CUDA and Apple Silicon, and the Qwen aligner (Qwen3-ForcedAligner-0.6B) timestamps 11 languages including CJK in a single pass on CUDA, MPS or CPU. The README states both experimental aligners fall back to WhisperX automatically, which is the right failure behaviour for a feature you are trying out on a party night.

CJK handling is the part that suggests real use rather than a demo. Japanese, Chinese, Cantonese and Korean songs get per-character forced alignment and romanized readings shown above each token, with Hepburn, pinyin, Jyutping and Revised Romanization named. Per-character alignment is a different problem from per-word alignment, and treating it as a separate mode is more honest than pretending one aligner covers every script. UltraStar Deluxe folders are also supported experimentally: drop a USDX song folder with its `.txt` or `.usdx` file and sibling audio, vocals, instrumental and video, and pitch and lyric data come straight from the file with no analyzer pass. That is the one path in the app that avoids the ML pipeline completely.

Getting it running: one binary, then a lot of downloading

The README's central claim is that Nightingale "Ships as a single binary" and that no manual installation of Python, ffmpeg or ML models is required, because everything is downloaded and bootstrapped on first launch. In practice the setup sequence is: choose the main data folder, and let the app fetch ffmpeg, uv, Python, PyTorch and the ML packages. Video backgrounds are pre-downloaded so the first session is ready. Settings then lets you split cache, models, videos and vendor tools into separate folders, which matters if your system drive is small and your models drive is not.

For the server route, the README points at `site/docs/src/self-hosted.md` for running on a Linux box and reaching it at `<hostname>.local`, and at `site/docs/src/docker.md` for Docker with either CPU or CUDA/GPU. A published image exists at `razzaru/nightingale` on Docker Hub, referenced by the README badge. Library connections are configured per source: Plex supports hosted sign-in for server discovery or an advanced PMS URL plus token flow that works without plex.tv during normal operation, Jellyfin caches songs locally on first play so playback matches a folder library, and Navidrome login details are stored encrypted on disk. Folder libraries also read `.m3u`, `.m3u8` and `.pls` playlists. USDX setup is documented separately at `site/docs/src/usdx.md`.

What the README does not give is anything resembling a hardware baseline. There is no stated minimum GPU, no VRAM figure, no disk-space number for the model downloads, and no timing for an analysis pass. Given that the pipeline runs a separation model and an ASR model per song, that omission is the single biggest unknown for anyone planning a large import.

Where Nightingale is the wrong tool

The first limitation is the bootstrap itself. A single binary that downloads Python, PyTorch, ffmpeg and models on first launch is convenient only if the machine has network access, disk space and patience at that moment. On a locked-down corporate laptop, a machine behind a restrictive proxy, or a kiosk you want running in ten minutes, that first launch is the failure point rather than the install. The README does not describe an offline or pre-seeded setup path, so plan for the download to be part of the deployment.

The second is update handling, and the README is explicit rather than vague about it. In-app updates that check at launch, badge the sidebar avatar and install signed updates with one click exist on macOS and Windows. Linux is manual: the Update entry opens GitHub Releases for you to fetch the build yourself. If you run the self-hosted Linux mode, you are the update mechanism.

The third is scope. Nightingale is not a licensed karaoke catalogue and it does not make one. It works on audio you already have, which means lyric accuracy depends on WhisperX or LRCLIB rather than on a publisher's timed file, and separation quality depends on the model and the mix. The README's own hedge on the UVR Karaoke model, that it preserves backing vocals for a more natural sound, is exactly the trade-off a singer should test on their own material before trusting it. And if your goal is singing over a specific commercially released instrumental, a source that already ships one will beat a separated approximation.

How it differs from a plain Whisper transcription pipeline

The obvious comparison is to assembling the parts yourself: run Demucs or UVR Karaoke to split stems, run WhisperX for word-level timestamps, then write a player that highlights the current word and reads a microphone. Every component Nightingale uses is public and separately documented, and someone with Python experience can wire that together in an afternoon for a handful of songs.

The difference is everything around the models. Nightingale's value is in the plumbing: the source connectors for Plex, Jellyfin, Navidrome and `.m3u` playlists, the LRCLIB browser and LRC paste path, the per-character CJK alignment mode with romanization, the key and tempo variants cached after analysis, profiles that keep scores separate per singer, gamepad navigation, and the shader backgrounds. A hand-rolled script gives you stems and a timestamp file. It does not give you a library browser, a lyrics editor, a scoreboard, or a UI that scales to a 4K TV. The honest framing is that Nightingale is not competing with Demucs or WhisperX, it is competing with the weekend you would spend gluing them to a player. If you only need stems and timestamps as files, the underlying tools are the better fit and you skip the Tauri app entirely.

Maintenance, licence and what the release cadence suggests

The repository is not archived and the release history shows v1.0.0 in late July, v1.1.0 in mid August and v1.2.0 in early September, with the last push shortly after the v1.2.0 tag. That is a steady cadence over a short window, and it also means the project is young enough that interfaces and defaults can still move. The README labels several features experimental: Parakeet v3, the GPU and Qwen aligners, and UltraStar Deluxe support. Treat those as things to try, not things to depend on, and note that the two experimental aligners are documented to fall back to WhisperX.

On cost, the material supports one concrete point: the app downloads and manages its own runtime, so upgrading Nightingale can mean re-downloading or re-bootstrapping parts of the Python and PyTorch stack. The README's separate storage settings for cache, models, videos and vendor tools are the mechanism for keeping that churn off your main drive. Beyond that, the README does not describe a migration path between versions, so back up the data folder before a major bump.

The licence is GPL-3.0-or-later per the README badge and the repository's declared GPL-3.0. That is a copyleft licence, and it governs the whole application, not just a library you link against. If you intend to modify Nightingale and distribute the result, or ship it inside a product, the licence terms apply to what you distribute. I am not a lawyer and this is not legal advice; read the `LICENSE` file and get proper review if distribution is on the table. Running it at home for a party is a different situation from redistributing a modified build.

Editorial conclusion

Adopt Nightingale if you already own a sizeable music library or run Plex, Jellyfin or Navidrome, and you are willing to give a first run the disk space and time it needs to download Python, PyTorch, ffmpeg and the separation models. Do not adopt it if you need a hosted karaoke service with licensed commercial tracks, or if you are on Linux and want in-app updates, since the README states that path is manual and opens GitHub Releases instead. Verify three things before committing: that the setup step can write to the data folder you pick, that your GPU or CPU clears the analysis pass at a speed you tolerate, and that the GPL-3.0-or-later licence fits how you intend to use and possibly redistribute the build.

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. rzru/nightingale on GitHub