Open-Lyrics (openlrc): Whisper transcription plus LLM translation into LRC and SRT

The gap openlrc fills between a transcript and a usable subtitle file

Whisper-style models give you text with timestamps. That is not a subtitle file. A .lrc file needs timestamped lines a player will accept, and if you want a second language you need a translation that respects line boundaries rather than a single blob of prose. Open-Lyrics exists to close that gap in one call. The README describes it as a Python library that transcribes audio with faster-whisper, then translates or polishes the text into .lrc subtitles with LLMs such as OpenAI and Anthropic. The target user is a Python developer working with audio or video files locally, not someone looking for a web app or a batch service. The README's own examples pass paths like ./data/test.mp3 and ./data/test_video.mp4, which tells you the intended workflow: files on disk in, subtitle files on disk out, same directory. If your audio already has a good transcript from somewhere else, openlrc's transcription half is wasted work and you would be better served by calling an LLM directly on your existing text.

Transcription, audio preprocessing, then a concurrent translation pass

The pipeline has two distinct stages with different resource profiles. Stage one is local and GPU-bound: faster-whisper runs the speech recognition, and before that the library applies audio preprocessing, which the README lists as loudness normalization and optional noise suppression, with the stated purpose of reducing hallucinations. Stage two is remote and network-bound: the transcript goes to an LLM for translation or polishing. The README's multi-file example documents the scheduling decision explicitly: transcription runs sequentially, translation runs concurrently for each file. That is a sensible split, since one GPU cannot usefully run several Whisper jobs at once while an API can absorb parallel requests. Two mechanisms are worth calling out because they are not obvious from the one-line description. The first is context-aware translation, which the README says improves translation quality and points to openlrc/prompter.py for the prompt text; the prompt is inspectable, so you can read what context is actually being sent. The second is lean translation mode, described as token-efficient translation with mixed-model support, for example a cheap MT model paired with a larger CR model. That means you can split the translation work across two models by role rather than paying the large-model rate for every token. The README does not quantify the savings, so treat the token efficiency as a design intent rather than a measured figure.

The install is four external dependencies before pip install openlrc

This is the part that decides whether openlrc is practical for you. The README's installation steps are: install CUDA and cuDNN following the CTranslate2 installation page, since faster-whisper depends on them; note that faster-whisper also needs cuBLAS; set at least one LLM API key as an environment variable; install ffmpeg and put its bin directory on PATH; then run pip install openlrc. Windows users get a documented shortcut: Purfview's whisper-standalone-win repository publishes the required NVIDIA libraries in a single archive, which you decompress and place in a directory on PATH. The API key variables named in the README are OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_API_KEY and OPENROUTER_API_KEY, with OpenRouter called out as the recommended default for most users. Optional extras change what is available: pip install 'openlrc[full]' adds DPDFNet for noise suppression, and pip install 'openlrc[litellm]' routes translation through LiteLLM. The DPDFNet note is specific and worth reading before you enable noise suppression: the base install does not include dpdfnet, it downloads a model (default dpdfnet2_48khz_hr, roughly 10MB) to ~/.cache/dpdfnet/models on first use, and the README warns it consumes more time. There is also a deliberate import design: the README guarantees that import openlrc, LRCer, TranscriptionConfig, TranslationConfig, ModelConfig, ModelProvider and list_chatbot_models do not eagerly load dpdfnet, spacy, faster-whisper, tiktoken or lingua. Each of those loads only when its feature is first used. If you are building a tool that needs model metadata or config validation without starting a transcription, that guarantee is the reason the import stays cheap.

Configuring LRCer: what the README actually shows you setting

Configuration is object-based. You construct an LRCer, optionally passing TranscriptionConfig and TranslationConfig, then call run. The README's examples cover the settings you are most likely to touch. Target language is a run argument: lrcer.run('./data/test.mp3', target_lang='zh-cn'). To skip the LLM entirely, pass skip_trans=True, which the README shows with target_lang='en'. Whisper's own knobs go through TranscriptionConfig, and the README's example sets vad_options = {"threshold": 0.1} and points to openlrc.defaults for the full set of asr_options and vad_options. Model selection goes through ModelConfig with a provider and a name, for example ModelProvider.ANTHROPIC with name='claude-3-sonnet-20240229'. Custom endpoints are supported by supplying base_url and api_key alongside the provider, which the README demonstrates with a gpt-4.1-nano model name pointed at https://example.com/v1. Glossary support is a path: TranslationConfig(glossary='./data/aoe4-glossary.yaml'), intended to improve translation of domain terms. Two run-level flags matter for housekeeping: noise_suppress=True enables the DPDFNet preprocessing, and clear_temp=True removes the temp folder after processing. Output format follows the input: the README notes that a .mp3 input yields .lrc and a .mp4 input yields .srt. That is a real constraint if you need a specific container format regardless of source type.

Where openlrc is the wrong tool

The CUDA requirement is the first hard boundary. The README's install instructions begin with installing CUDA, cuDNN and cuBLAS, and the Windows path depends on downloading prebuilt NVIDIA libraries from a third-party repository. If you are deploying to a CPU-only container or a machine without an NVIDIA GPU, the documented setup does not describe a supported path, and you should assume faster-whisper will not initialise until you have solved that yourself. The second boundary is the LLM dependency. Translation is not local; it needs one of the named API keys, which means audio content leaves your machine and you pay per token. For confidential recordings or for anyone who cannot send audio-derived text to a third party, the translation half of the pipeline is unusable as documented. Third, the GUI is not available. The README's GUI section is commented out with a note that the project is migrating from Streamlit to Gradio and that the GUI is still under development. Do not plan around a graphical interface. Fourth, the README does not state accuracy figures, supported language pairs beyond the examples, or throughput numbers, so any expectation about subtitle quality on your specific material is unverified until you run it on a sample. Finally, the material gives no guidance on long-form audio, memory ceilings, or what happens when a file exceeds what faster-whisper can handle in one pass. That is an open question, not a documented limitation.

How it compares to calling faster-whisper and an LLM yourself

The honest alternative is assembling the same two calls by hand: run faster-whisper for segments, then send the text to an LLM with your own prompt and write the subtitle file. That approach gives you full control over chunking, prompt shape and output formatting, and it removes a dependency from your project. The difference is everything openlrc adds around the two calls. It applies loudness normalization before transcription, which the README ties to hallucination reduction, and that is a step people skip when wiring Whisper up directly. It builds translation prompts with context, with the prompt text living in openlrc/prompter.py rather than being something you invent. It manages the sequential-transcription, concurrent-translation split across a list of files. It carries a glossary file into the translation step. It handles the LRC versus SRT output decision based on input type. And it keeps heavy imports lazy so that config-only code paths stay cheap. If you need a custom segment-merging rule, a non-LLM translation backend, or a specific subtitle format openlrc does not emit, the manual route is the better fit. If your needs match the README's examples, openlrc saves you from writing and maintaining that glue.

Maintenance, release cadence and the MIT licence

The project is not archived, the default branch is master, and the most recent push recorded is 2026-08-10, the same date as the 1.7.0a2 pre-release. The release history shows 1.7.0 tagged as v1.7.0a1 in May 2026, 1.6.3 in May 2026, and 1.7.0a2 in August 2026, so the project is active and currently shipping alpha builds on top of a stable line. The practical cost of upgrading is the dependency surface rather than the openlrc code itself. A version bump can pull a new faster-whisper, a new CTranslate2, or a new provider SDK, and each of those can interact with your CUDA, cuDNN and cuBLAS installation. The extras split means you can keep the base install thin and add openlrc[full] or openlrc[litellm] only where needed, which limits blast radius. If you pin openlrc, pin the transcription stack alongside it. On licensing: openlrc is MIT, which is permissive and imposes few obligations on your own code. That says nothing about the licences of faster-whisper, CTranslate2, DPDFNet, ffmpeg, or the models you point Whisper at, and nothing about the terms of the LLM provider you configure. Those are separate questions and this is not legal advice; check each dependency and each provider's terms against how you intend to distribute the output.

Editorial conclusion

Adopt openlrc if you already have an NVIDIA CUDA and cuDNN setup, ffmpeg on PATH, and an LLM API key, and you want one Python call that turns a folder of audio or video into translated .lrc or .srt files. Do not adopt it if you need a CPU-only pipeline, a hosted service with no local model download, or a GUI, since the README shows the GUI section commented out and still under development. Verify three things before committing: that faster-whisper actually initialises on your machine after the CTranslate2, cuDNN and cuBLAS install, that your chosen chatbot model name is accepted by the provider you configured in ModelConfig, and whether your audio needs noise_suppress, which pulls in the openlrc[full] extra and the DPDFNet model download.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. zh-plus/openlrc on GitHub