Offset value in LRC files and embedded synced lyrics is not respected

[HJicub Jiikol]

LRC files and the lyrics format have an option for offset which allows for syncing of lyrics by adding an offset value in milliseconds.

This value is not respected by Poweramp and thus LRC files with this value show the lyrics with wrong timings.

it looks like this in the LRC file:

[offset: -18500]

[00:38.05] I am fire I am damage in the making

[00:44.95]

[00:47.40] I am an army set out to control your every ticking

More details here:
https://en.wikipedia.org/wiki/LRC_(file_format)

Example attached, it works correctly in MusicBee

 

 

shadowshow - iamamiwhoami.lrc

Edited April 30 by HJicub Jiikol
i dont want copyright strike, let me know how to send privately if required for debugging

[andrewilley]

In this case, I think Poweramp wants the offset to be a positive value not a negative one, as you want the lyrics to appear onscreen approx 18.5 seconds (18500 milliseconds) later than the timecodes quoted in the text of the  LRC file.

For example, the timecode in the LRC file for the first line ("I am fire I am damage in the making") is quoted as [00:38.05], but the actual sung lyric occurs at 00:56.55, i.e. 18.5 seconds later rather than earlier.

I'm not sure whether Poweramp or MusicBee are correct in their interpretation of the spec, but I've just done some tests in foobar2000 and that seems to apply the same logic as MusicBee - i.e. a negative offset value delays the display of the lyrics, whereas a positive value makes the lyrics appear earlier than the timecode indicated in the file. The spec says "+ shifts time up, - shifts down".

@maxmp is it possible PA is applying this offset in the wrong direction?

Andre

[HJicub Jiikol]

@andrewilley I was confused on that same thing and after digging through, I found another android music player which was applying the offset in same way as music bee.

TBH even I am not sure in which way the offset should be applied?

Why not just have a button to toggle offset "polarity" for now?

[andrewilley]

@HJicub Jiikol Same here, the spec wording is somewhat ambiguous - in fact, when it comes to Lyrics in general, the word "spec" seems a little overrated; there are so many variations in the wild!

I initially read the spec description fairly literally, assuming that a positive offset should be ADDED to the timecodes provided in the text - thus making any lyrics appear at a later time during playback. But in the wild, most apps seem to apply it counter-intuitively the other way around, so a negative offset has its value added to the timecode thus making the words show later, while a positive offset brings the words forward and shows them earlier.

Andre

[HJicub Jiikol]

I've also checked MPV and AIMP on my PC and they also seem to apply the offset in same way as MusicBee, maybe Poweramp's implementation is an outlier.

[andrewilley]

@HJicub Jiikol Yes, I agree you could be right. I tested foobar2000 too, and that applies the logic the same way as MusicBee and the others (i.e. a negative offset value delays the display of lyrics).

@maxmp I think PA might be handling the [offset] field the wrong way round, it does seem at odds with everything else I've been able to test. As always with lyrics, it's finding examples in the wild though.

Andre

[andrewilley]

Quote

[offset:+/- Overall timestamp adjustment in milliseconds, + shifts time up, - shifts down i.e. a positive value causes lyrics to appear sooner, a negative value causes them to appear later]

Just noticed this edit occurred to the wiki today... so who did it then?? Presumably someone reading this thread, otherwise a huge coincidence.

Andre

[HJicub Jiikol]

LOL that was me testing Cunningham's Law, maybe some one with correct information pops up

[HJicub Jiikol]

Man! there really IS no consensus on this...

Consider this LRC file:

[offset: -5000]
[00:28.270]You’ve got the best of both worlds
[00:32.640]You’re the kind of girl who can take down a man,
[00:38.100]And lift him back up again
[offset: 0]
[00:40.830]You are strong but you’re needy,
[00:44.190]Humble but you’re greedy
[00:47.0]Based on your body language,
...

Musicbee: applies both offsets, first three lines are late to show but after that the rest show up correctly

AIMP: Only applies first offset and treats rest as text, all lines thus appear late:

foobar2000 (x64 with OpenLyrics 1.6 Plugin): only applies the last offset, so all the lines including first three, appear at correct time in our test.

MPV (with external LRC file, rest tests were with embedded as mpv fails to read internal lyrics): don't even know whats going on here, all lyrics appear late except the 4rth line, yes, not the third the fourth one: "Humble but you're greedy"

Poweramp: Applies only the first offset, and causes all lines to appear before they are actually sung

 

So when it comes to multiple offsets there is absolutely no common ground, however at least everyone seems to be applying the offset in the same direction, except Poweramp.

[andrewilley]

I think multiple offsets in one file is just one zany complication too far! Partly because it's possible to have timecodes occur out of order - e.g. the chorus can be repeated thee times by having three different timecode prefixes at the beginning of one line, or two language versions can be included in the same file as two complete blocks of text but with the same quoted timecode values. PA currently sorts and handles all duplicated timecodes appropriately before displaying them.

The only way I can think of to make it work would be to add or subtract the offset value individually, line by line, while initially reading through the lyric data, thus creating a modified version of the [timecode] content at the beginning of each line of text. If the [offset] value changes mid-file, subsequent lines would then be adjusted accordingly based on that latest value. Then, with all that revised content stored, PA could go through its re-sorting and re-organising of duplicates, based on the now-modified timecodes. But talk about convoluted!

But I do agree that PA currently appears to be applying the direction of the offset field in the opposite way to every other app's interpretation of the spec.

 Andre

[HJicub Jiikol]

I just found this is now fixed, thanks @maxmp