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, 2023 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

[Zyntaxys]

WAV files still not recognizing negative offset 😕

[andrewilley]

@Zyntaxys Not sure of the reason, but WAV files are not really suitable for use with media playback devices anyway due to their huge sizes. They are more suited to editing work. If you want lossless audio, try FLAC.

Are you trying to embed the lyric data into the WAV file, or using a separate sidecar LRC file?

Andre

[Zyntaxys]

Here my stats:

90% FLAC

7% M4A

3% WAV/MP3

80% of them use separate LRC files

95% have unsynced embedded lyrics (instrumental songs marked like "instrumental")

I tought the problem was the beta build but i tried with the latest stable build on another phone and I'm getting the same issue even with FLAC files. Musicbee, Foobar, Oto Music and Subtitle editor (Windows) negative offset works fine, so I don't know if this issue was really fixed.

[andrewilley]

Right, so not a WAV issue then. I'll have a check see if this issue is still present in the current builds.

Andre

[andrewilley]

From a quick test of an external LRC file, a positive value [offset:5000] causes the written lyrics to appear five seconds sooner than the sung audio content, while a negative value [offset:-5000] causes the written lyrics to appear five seconds later than the sung audio content.

Andre

[Zyntaxys]

Ok, I think I got it, the other apps can read this: [offset: -5000] with no problem but PA can't "process" that space, but if you want to, try with this one

 

113 - Just a Little Girl.lrc

Edited January 14 by Zyntaxys

[andrewilley]

On my test file, adding an extra space in [offset: -5000] works fine too, lyric display is delayed for five seconds after the words have been heard. And [offset: 5000] (with a space) works to show the lyrics sooner than the audio. I'll try your test file.

Andre

[Zyntaxys]

Yeah, I tried deleting that space and the issue still there. Then why the offset isn't working on my phone? I'm using a Redmi note MIUI 12.5, tested too on a Nokia 7.2 Android 11

[Zyntaxys]

Could you try with the song that I uploaded? Maybe in your phone works fine

[andrewilley]

I  just tested your file with the offset line edited to -7000, and then to 7000, so I could clearly notice the differences. Spaces are ignored.

-7000 caused the lyrics to be displayed later than the audio content (i.e. lyrics delayed) while 7000 caused the lyrics to be displayed sooner than the audio content (i.e. lyrics brought forward). This is the same as I observed with my own test files.

Andre

[Zyntaxys]

So, what should I do? I tried everything except test on a newest phone, I think I can get a moto later this day.. I don't know if this helps but I'm using a 256 gb Samsung microSD card (97% filled)

[andrewilley]

Try a Rescan, but the LRC file should be loaded at playback time. No other copies of that data elsewhere? (Maybe edit the first line of the lyrics so you can see that the correct content is being used)

What do you see if you edit the offset line to 7000 and then to -7000 ?

Andre

[maxmp]

@Zyntaxys there will be an additional global offset option (in additional to LRC [offset:] and Visualization/Lyrics delay options), but it won't make desync LRC file (which was generated for the different edition of the song, probably) to sync song properly. The LRC editor is planned as well for those who want to directly edit their LRCs.

[Zyntaxys]

@maxmp

@andrewilley

Thanks for the support guys, after try multiple files on multiple players on Android and Windows I've found something weird, PA always "inverts" the offset, negative and positive and vice versa (at least for me). Check this

A global offset option could fix this "invertion"? Maybe an advanced tweak to invert how PA reads LRC files