A clean LRC file is one in which every timed line uses the de-facto [mm:ss.xx] timestamp form, the optional title, artist, and album fields are written as ti, ar, and al tags without square brackets or control characters, and the file itself is saved as UTF-8 without a byte-order mark; the LRC File Generator enforces all three of those rules before it lets you download a file, which is why most "broken LRC" complaints trace back to inputs the tool never received correctly in the first place. The single most common mistake when you generate an LRC file from your own lyrics is treating the interval as if it were a precise audio alignment — it is not. The generator places one [mm:ss.xx] bracket before each preserved lyric line by adding a fixed centisecond gap between rows, and no listening, phoneme detection, or beat analysis happens. Real vocals almost never begin at perfectly equal spacing, so the file you download is a deterministic draft that you must retime against the actual recording in a dedicated editor. Knowing which inputs the generator rejects, which ones it silently cleans, and which ones it preserves exactly is the difference between a file that loads cleanly in your music player and one that gets ignored or mis-synced line by line.
The timestamp format that breaks a player before lyrics ever load
The LRC format is a de-facto family rather than an official standard, and the generator implements the conservative simple subset rather than promising universal compatibility. Per the QuickLRC LRC file format documentation, a timed line begins with a bracketed minutes, seconds, and centiseconds value immediately followed by the lyric text — for example, [01:23.45]Example line. The Subforge LRC time implementation confirms that minutes contribute sixty thousand milliseconds, seconds contribute one thousand, and two fractional digits represent centiseconds.
The generator accepts timestamps where the first field contains two or three minute digits, the seconds field contains exactly two digits from 00 through 59, a period, and exactly two centisecond digits. Valid examples include 00:00.00, 09:59.99, 10:00.00, and 123:45.67, and the tool supports timestamps through 999:59.99. It does not emit hour fields, colon-separated frames, three-digit milliseconds, or enhanced word-level angle-bracket timestamps, and it never silently upgrades your input.
| Input you might type | What the generator does | Resulting player behavior |
|---|---|---|
| 00:00.00 | Accepted; line emitted as [00:00.00]lyric | Loads at song start |
| 1:23.45 | Rejected at parse time | Generation fails or row is skipped |
| 01:23.4 | Rejected — needs two centisecond digits | File not produced |
| 01:60.00 | Rejected — seconds must be 00–59 | File not produced |
| 1:23:45 | Rejected — three time fields, no centiseconds | File not produced |
| 01:23.456 | Rejected — three fractional digits | File not produced |
The mistake to avoid is assuming the tool will "fix" a malformed start timestamp. It does not — a malformed first timestamp stops the entire generation rather than producing a file that misloads. Always double-check that your start time matches the [mm:ss.xx] pattern with two centisecond digits before you click generate.
Why the interval number is exact and your timing still isn't
The interval field accepts 0.01 through 600 seconds with no more than two decimal places. Before any rows are produced, the value is converted to an integer number of centiseconds, and that integer is added by line index. This conversion is the reason the generator does not accumulate binary floating-point drift on long files: 2.50 seconds becomes 250 centiseconds, and 250 + 250 + 250 is always exactly 750, not 749.999999.
The worked example: a start of 00:12.34 and an interval of 2.50 seconds produce 00:12.34, 00:14.84, and 00:17.34 for the first three lines. Each step is start + (line_index × 250 centiseconds), converted back into mm:ss.xx — line 0 at 1234 centiseconds, line 1 at 1234 + 250 = 1484 centiseconds, line 2 at 1484 + 250 = 1734 centiseconds. This determinism means that if you re-run the generator with the same inputs, you get the same file byte-for-byte, which is exactly what you want for a draft you intend to retime.
What the interval is not is a measurement of your song. It is a fixed gap. The generator does not listen to audio, detect speech, transcribe lyrics, align phonemes, identify beats, or estimate performance timing. Treating the interval as if it were a per-line alignment is the second most common mistake — the file will play, but the words will land in the wrong place relative to the vocalist. The fix is to open the file beside the actual recording in a dedicated editor and shift individual [mm:ss.xx] timestamps until the lines match the audio.
Inputs the generator cleans for you — and one it does not
Several input problems are handled silently and correctly. Windows (CRLF), old Mac (CR), and Unix (LF) line endings are all normalized before generation, so pasting lyrics from any source will not corrupt the file. Blank rows are removed, so accidental empty lines in your paste will not produce blank timestamp lines in the output. Disallowed control characters inside the lyric text are rejected rather than inserted into a file that a player may parse inconsistently. The generator preserves spelling, punctuation, capitalization, language, and any embedded copyright notices inside ordinary lyric text, so what you paste is what appears in the output, minus blank rows and control characters.
The single input the generator does not normalize is line ordering. Lines are timestamped in the order you enter them, and the tool does not sort, reorder, or de-duplicate them. If you paste the chorus in the middle of the verse by accident, the chorus will be timestamped in the middle of the verse. The mistake to avoid is assuming the tool will reflow your text — it does not, and reordering after generation means regenerating.
| Common input mistake | How the generator handles it | What you should do instead |
|---|---|---|
| Mixed line endings (CRLF, CR, LF) | Normalized before generation | Nothing — paste freely |
| Blank rows in the middle of lyrics | Removed before timestamp assignment | Nothing — blank rows are safe |
| Control characters in pasted text | Rejected; omitted from the output rather than inserted into it | Strip control chars from your source first |
| Out-of-order lines (chorus pasted in middle) | Preserved in entered order | Reorder lines before generating |
| More than 500 non-empty lines | Excess lines rejected at validation | Split the song into sections |
| More than 50,000 total input characters | Generation refuses the input | Trim repeated whitespace or split |
| Single line longer than 500 characters | Line rejected | Break very long lines manually |
Metadata tags and the encoding that travels with them
Optional metadata in the generator is deliberately narrow: title becomes [ti:value], artist becomes [ar:value], and album becomes [al:value], and each value is trimmed, limited to 120 characters, and cannot contain square brackets or control characters. This last rule exists to prevent one field from injecting an extra LRC tag or line — for example, a title that contains "]\n[ti:Hacked" would otherwise emit a second tag. Empty metadata fields are omitted entirely, so leaving the album blank does not produce an empty [al:] line.
The download is a UTF-8 text file without a byte-order mark. This matters because some legacy players and editors expect UTF-8 with BOM, while others interpret a BOM as printable garbage that appears before the first timestamp. The generator deliberately omits it. If your target player requires a BOM, you can add one in a text editor after download — but the file the tool produces is the safe default.
The filename is derived from the title when available; unsafe filename punctuation becomes hyphens, and a blank title uses synced-lyrics.lrc. If you intend to keep many LRC files in one folder, give each song a distinct title so the filenames do not collide.
The final-time cap that prevents silent truncation
The generator refuses to truncate. If your start timestamp and interval would produce a final calculated timestamp above 999:59.99, generation fails outright. This is a deliberate safety rule: silently capping the output would produce a file whose last lines appear to loop or vanish in the player without explanation. For most songs this cap is irrelevant, but very long DJ mixes, audiobooks, or podcast episodes with continuous lyric tracks can run into it.
The practical mistake is forgetting that line-count validation runs first. The generator caps lyrics at 500 non-empty lines, so any input above that limit is rejected at validation before any time-cap check happens. Within the 500-line limit, a long interval can still push the final calculated timestamp past 999:59.99 and cause the generator to refuse the file. If your song is genuinely long enough to hit the cap, split it into multiple LRC files or shorten the interval.
Generate a clean LRC file in the browser
The workflow is intentionally small so there is little room for error. Following the steps below produces a file you can download immediately and retime later.
- Open the LRC File Generator and paste one lyric line per row into the lyric input. Aim for one display event per row, with blank rows removed automatically and Windows, old Mac, and Unix line endings all accepted.
- Enter a first timestamp in MM:SS.xx form — exactly two or three minute digits, two second digits from 00 through 59, a period, and two centisecond digits. Examples that work include 00:00.00, 09:59.99, and 123:45.67.
- Set the interval in seconds between 0.01 and 600.00 with at most two decimal places. The value becomes an integer centisecond count, so 2.50 produces 250-centisecond gaps with no floating-point drift.
- Optionally fill in title, artist, and album. Each is trimmed, capped at 120 characters, and stripped of square brackets and control characters. Leave any field blank to skip its tag entirely.
- Click generate and inspect the exact preview. Verify the first and last [mm:ss.xx] values, confirm the metadata tags look right, and check that the lyric lines appear in the order you intended.
- Click download to save the file as a UTF-8 .lrc document without a byte-order mark. The filename comes from your title, with unsafe punctuation replaced by hyphens.
- Open the saved file beside your exact recording in a dedicated LRC editor and shift individual [mm:ss.xx] timestamps until each line matches the vocalist. Different music players support different metadata tags, timestamp precision, encodings, long minute values, and enhanced-LRC extensions, so the final test happens in the player you actually use.
What to verify after the file downloads
Three quick checks catch most post-download issues before you load the file into a player.
First, open the .lrc file in a plain text editor and confirm that every line that should be timed begins with [mm:ss.xx] in the exact two-digit centisecond form, and that the optional [ti:], [ar:], and [al:] tags sit above the timed lines, separated by a blank line. If you see [01:23.4] (one centisecond digit) or [01:23.456] (three centisecond digits), the file did not come from this generator — something else edited it.
Second, verify the encoding. The download is UTF-8 without a byte-order mark, which is the safest default across modern players. If your target player only reads UTF-8 with BOM, add the BOM in a text editor and re-save.
Third, retime against the recording. Walk through the file in the player you actually use, and for each line that lands early or late, adjust the [mm:ss.xx] value in your editor. The generator produces deterministic output that is easy to search-and-replace line by line because every timestamp has the same fixed length. For a deeper walkthrough of testing the file in a real player before retiming, the verification guide at LRC File Generator test online: a verification walkthrough walks through expected first-line and last-line behavior against several common players.
Permissions, privacy, and the limits the tool does not lift
The generator does not supply copyrighted lyrics, search a catalog, identify a song, confirm ownership, or grant a synchronization license. It simply formats user-provided text. If you do not have permission to reproduce and distribute the lyric text you paste in, the tool cannot make that permission exist — the output file inherits the rights status of its input.
All content and arithmetic stay in the current browser tab. No lyric text is uploaded to Lizely, stored in an account, or sent to an AI service, so the privacy profile is the same as opening a local text editor. The trade-off is that no server-side alignment, audio analysis, or auto-timing is available — fixed-interval output is the only mode, and post-download retiming is always your responsibility.
Related reading: How to Check an LRC File Result After Creation.