LDDC: word by word lyrics downloading and matching for local music

A desktop tool built around the local music file

LDDC is a desktop application for downloading and matching precise lyrics, the kind with timing on every syllable, often called word by word lyrics or karaoke lyrics. The core interaction is drag and drop: you drop a song file onto the window and the tool searches for a matching lyric, then writes the result into the file's tags. It also does the reverse in a sense, offering a search interface where you can pick among candidates by hand rather than accepting the first hit. The feature list is long and specific. Search covers songs, albums and playlists on QQ Music, Kugou Music and NetEase Cloud Music, plus Lrclib. Output formats include word by word LRC, line by line LRC, enhanced LRC, SRT and ASS, and the original text, translation and romanisation can be combined in one file. There is a one click action to download lyrics for a whole album or playlist, a batch conversion between lyric formats, and a separate foobar2000 plugin named foo_lddc for desktop lyrics with karaoke styling, multi line display of the three text types, fade effects matched to the screen refresh rate, and a character cache to reduce resource use. The GUI is PySide6, and the project is packaged with hatchling from a pyproject.toml.

The dependency list tells you what the tool actually does

The runtime requirements are short and reveal the architecture. PySide6-Essentials provides the interface, httpx with brotli and http2 support does the network work, mutagen reads and writes the audio file tags, diskcache provides local caching, charset-normalizer handles text encoding, pyaes and psutil are there for encrypted lyric handling and process inspection, and pyobjc-framework-Cocoa is pulled in only on macOS through an environment marker.

dependencies = [
    "PySide6-Essentials>=6.8.0",
    "httpx[brotli,http2]",
    "mutagen",
    "diskcache",
    "charset-normalizer",
    "pyaes",
    "psutil",
    "pyobjc-framework-Cocoa; sys_platform == 'darwin'",
]
requires-python = ">= 3.10"

The presence of pyaes tells you that decryption is part of the pipeline, which the documentation confirms in a feature listed as support for opening local encrypted lyric files. The credits section points at two reference projects for lyric decryption, QQMusicDecoder and qmc-decode, so the technique is borrowed rather than invented here. The Python floor of 3.10 is declared, and the classifiers list support for Windows, macOS and Linux along with Python 3.10, 3.11 and 3.12. The project is licensed GPL-3.0, and the licence file is referenced from the pyproject metadata rather than spelled out as an SPDX identifier.

Multithreaded search is the reason matching feels fast

Every matching function in the tool is described as multithreaded, and that is the mechanism behind the speed claim in the feature list. The stated goal is automatic search with fast and precise matching of each lyric, applied both when you drag a file in and when you ask for a local match across a folder. It is worth being precise about what threading buys here and what it does not. The latency that matters in this workflow is network latency, because candidates come from several music platforms, and running those requests concurrently is exactly what threads help with. What it does not do is improve the quality of a match. The candidate set is still whatever the platforms return for a query built from the file's metadata, and the tool's job is then to pick among them. The README shows the matching surfaces rather than explaining the scoring, and the project documentation lives in the repository wiki rather than in the README, which points readers to the LDDC usage guide there. If the tool picks the wrong version of a song, that is a metadata and catalogue problem, not a concurrency one.

Translation through Bing, Google or an OpenAI compatible API

Beyond downloading, LDDC can translate lyrics, and the mechanism is worth noting because it defines the privacy surface. The documentation lists support for translating with Bing, Google, or an OpenAI compatible API, which means lyric text is sent to an external translation service when you use that feature. For a tool whose input is song lyrics that may include content you would rather keep local, that is a deliberate choice rather than a technical necessity, and it is the kind of setting you want to look at before turning it on. The composition feature is separate from this. The tool can combine original text, translation and romanisation in a single lyric file, which for Chinese and Japanese catalogues is often the difference between a usable and an unusable karaoke file. The three sources of text are also how the desktop lyrics plugin decides what to draw in multiple lines, since the plugin can show the original, the translation and the romanisation separately.

Path placeholders and tag writing decide where files end up

Two details determine whether the tool fits your library layout. The first is flexible save paths, implemented with placeholder tokens so a single rule can scatter lyric files across a directory tree based on the song metadata rather than dumping everything in one folder. That matters for large libraries, and it is the feature that makes the album and playlist download modes usable at scale rather than as one time curiosities. The second is that the tool writes lyrics into the song tags. The documentation describes previewing a lyric on double click and then saving it either as a standalone lyric file or directly into the song tags, and both paths are available. Writing into the file is convenient for players that read embedded lyrics, and it is also a modification of your media, so a library you care about deserves a backup before a batch run. The tool also supports opening local encrypted lyric files, which is how a lyric acquired through a decrypted download can be edited later.

Where LDDC is the wrong tool

The scope is narrow, and it is narrow on purpose. If you want plain line by line lyrics for a library, this is a heavyweight way to get them, since the whole premise is precise timing that most listeners will not notice. If you need an automated pipeline, a headless script or a server side tagger, this is the wrong shape, because the primary surface is a PySide6 window with a drag and drop interaction. There is no command line interface described in the documentation and no service mode, so automation means driving the GUI. The second limitation is the catalogue dependency. Search results come from three commercial music platforms plus Lrclib, and a tool built on top of those services inherits their availability, their coverage and their catalogue inconsistencies, so a track that is not in those catalogues cannot be matched no matter how good the matching logic is. The third limitation is the accuracy of the timing data itself, which comes from the platforms and is only as precise as the crowd sourced or label supplied timings they hold. The fourth is maintenance. The project is GPL-3.0, and the most recent tagged release listed is v0.9.2 from 2025-06-23 while the last push was on 2026-10-16, so the branch carries work that has not been cut into a release, and a packager who wants the released behaviour needs to check which version they are installing.

Editorial conclusion

LDDC suits a listener with a local library of Chinese or Japanese music who wants karaoke style word timing in their player, and who is happy to review the matched lyrics before they are written into the files. It does not suit someone who only wants plain text lyrics, since the whole design assumes precise timing, and it does not suit a headless server workflow, since the primary surface is a Qt desktop application. Before you rely on it, run the search on a handful of tracks and check the match against the audio, because the tool fetches candidates from several platforms and writes what it finds, and note that the most recent tagged release is v0.9.2 from 2025-06-23 while the last push was on 2026-10-16.

Frequently asked questions

Official sources

1. chenmozhijin/LDDC on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases