CSV to LRC
Or paste subtitle text
What this conversion changes
2 things are dropped or need a decision
- Timing
cue end times (the output format only records when a cue starts)
- Precision
timing precision — the output's clock is coarser, so every timestamp is rounded to the nearest 10 ms
This list comes from the capability matrix for these two formats, not from the particular file you loaded. A specific file may lose more if it uses features the format allows but the matrix does not model.
This page converts CSV to LRC. Drop a file in — or paste the text — and you get the LRC version back. The conversion runs entirely in your browser, so nothing is uploaded and no account is needed.
These two formats do not store the same things, and the difference is not cosmetic: timing and precision have nowhere to go in LRC. The list above comes from what the two formats can each express rather than from your file, so it is the same answer before you load anything.
One file is fine, and so is a whole season: the queue works through them in order and the results come down together as a single ZIP.
Examples
A typical CSV file, converted to LRC
Input
start,end,text
00:00:01.000,00:00:03.500,The quick brown fox.
00:00:04.000,00:00:06.250,"Jumps over, the lazy dog."
00:00:07.000,00:00:09.000,"Two lines here.
And a second one."
Output
[00:01.00]The quick brown fox.
[00:04.00]Jumps over, the lazy dog.
[00:07.00]Two lines here.
[00:07.00]And a second one.
Dropped in this output: timing and precision. Everything else matches line for line.
The same conversion on an awkward input
Input
id,start,end,note,text
1,00:00:01,000,00:00:04,000,cue one,"Hello there, friend."
2,00:00:05.000,00:00:07.000,cue two,Second line.
bad,notatime,00:00:09.000,cue three,Unreadable start.
4,00:00:10.000,00:00:09.000,cue four,End before start.
5,00:00:12.000,00:00:14.000,cue five,Unquoted comma in text, right here.
Output
[00:01.00]Hello there, friend.
[00:05.00]Second line.
[00:10.00]End before start.
[00:12.00]Unquoted comma in text, right here.
This is the kind of damage real files have — mixed line endings, stray whitespace, fields left empty. Compare it with the tidy example above to see what the parser forgives.
Frequently asked questions
What happens to the end time of each CSV cue?
LRC records when a line begins and nothing else — a lyrics player keeps a line up until the next one starts, so an end time would be redundant. Every end is dropped and every CSV start is untouched.
Why have the timestamps moved from CSV to LRC?
LRC stores time as `[00:04.12]` where CSV stores it as `00:00:04.126` — a hundredth of a second against a thousandth — so every timecode is rounded to the nearest 10 ms: 00:00:04,126 comes out as 4.13 seconds. Nothing is stretched or reordered and no cue moves by more than 5 ms, but if you are lining these subtitles up against another file, that is the one place this conversion stops being exact.
What does the output look like when CSV becomes LRC?
Like LRC: no cue numbers: every line carries its own bracketed timestamp. Every CSV cue becomes one LRC cue, in the same order, with the same text.
How does a two-line CSV cue come out in LRC?
As two timestamped lines carrying the same time, which is how LRC says 'these two belong together'. The pairing survives — the two CSV lines still belong to one subtitle in the LRC output, and a player shows them together.
Do CSV cues keep their order in the LRC output?
Yes, and they are sorted by start time on the way — earliest first, which is how every format here expects them and how players read them. If your CSV file listed its cues out of sequence, the LRC output puts them back in order; that is a change to the file's structure rather than its content, and it is deliberate.
Can I convert the LRC back to CSV?
Yes, and it has its own list: converting LRC to CSV drops timing. That list is different from the one above because the two formats keep different things.
Does the LRC output keep the CSV file's encoding?
No — the output is UTF-8, with Unix line endings and no byte-order mark, whatever the CSV file used. A file that arrives in UTF-16, or in a Windows single-byte encoding, is decoded on the way in (the result panel says so when that happens); what comes out is always the same UTF-8 LRC.