Pairing .lrc lyrics

[SAT-Oxford]

Hi,

I don't really know what I'm doing wrong here, but I'm having trouble getting Poweramp to sync my lyrics (lrc format) to my music files. Both types of file have the exact same names, but are on different folders, depending on the artist. Both are set to be scanned in the settings, and they do show up in the number of files scanned but the lyrics are still not showing up as, well, lyrics. The only way i've been able to solve this has been through dropping all .lrc files inside the folder with the music on it, but I'd like to avoid bloating it too much.

Is there some condition where LRC files won't be scanned if they're in a separate folder? How can I solve this?

Thanks

[maxmp]

@SAT-Oxford if LRC file is in different folder, it won't be matched by the track file name (this is to avoid matching Track 01.mp3-like named tracks). It will be matched based on track and lrc tags - title, album/artist, and duration +/-2sec.

[SAT-Oxford]

4 minutes ago, maxmp said:

@SAT-Oxford if LRC file is in different folder, it won't be matched by the track file name (this is to avoid matching Track 01.mp3-like named tracks). It will be matched based on track and lrc tags - title, album/artist, and duration +/-2sec.

Oh, alrighty. That's what I wanted to know. Thank you!

[andrewilley]

@maxmp Am I right in thinking that unsynced lyric files only work when they are in the same folder as the related audio file, and with an exact name match apart from the extender being replaced with '.LRC' ? 

With a lyric file named as "ELO - Hold on Tight.lrc" in the same folder as an audio file "ELO - Hold on Tight.mp3", the lyrics list is displayed correctly for that song. However if the same lyric file is named as "ELO - Hold on Tight.mp3.lrc" (which I thought was a valid naming permutation?) it does not work.

 If I place the same LRC file anywhere else - e.g. a parent folder - then the lyrics are not picked up at all, even if there are header lines present which exactly match with the ID3 tag data in the audio file, such as:

[ti:Hold on Tight]
[ar:Electric Light Orchestra]
[al:Time]
[length: 3:06]

Hold on tight to your dream
Hold on tight to your dream
When you see your ship go sailing
When you feel your heart is breaking
Hold on tight to your dream

With a LRC file containing synced lyrics though, it seems to behave more as expected - i.e. it can use any .LRC filename at all, and be stored in any scannable folder, just as long as the header tags match with the audio file ID3 data:

[ti:Hold on Tight]
[ar:Electric Light Orchestra]
[al:Time]
[length: 3:06]

[00:13.00]Hold on tight to your dream
[00:20.00]Hold on tight to your dream
[00:26.50]When you see your ship go sailing
[00:30.00]When you feel your heart is breaking
[00:33.00]Hold on tight to your dream

And finally, a synced LRC file located anywhere else will override a local but unsynced LRC file in the same folder as the audio file? 

Andre

[maxmp]

"ELO - Hold on Tight.mp3.lrc" results in "ELO - Hold on Tight.mp3" filename without extension, which won't match "ELO - Hold on Tight.mp3" filename (that is "ELO - Hold on Tight" without extension), but it may still match based on tags.

We don't know if given lrc is synced or plain text until we find it. It can be plain text, despite LRC extension.

[andrewilley]

@maxmp Yes, the ".mp3.lrc" style naming works fine with synced lyric files as they use tag/header matching and could actually be named anything and be located anywhere (so the base naming matching is irrelevant). I just thought that "basefilename.ext.lrc" was meant to work the same way as "basefilename.lrc". That would help in (rare) cases where a user has two versions of the same song, perhaps as a high-res FLAC and a basic MP3. Not worth worrying about anyway.

So (as I'm thinking of writing a Guide document on Lyrics use) the rules are:

• Plain text lyric files are not parsed for any header details, and so they must be located in the same folder as the corresponding audio file. They must use the same base filename but with the .MP3 or .FLAC extender replaced with .LRC (i.e. not appended to the end of the full audio filename.ext). Any header fields might be present are not parsed and will be treated as part of the lyric text.
• Synced lyric files (solely determined by the presence of at least one "[mm:ss.nn]" prefixed line) can follow the same naming rules, and if a suitably named LRC file is placed in the same folder as its corresponding audio file then header fields are not necessary (and even if present, are ignored and not validated). However, if the lyric file does have header data, it can also be placed into in any scannable folder, and with any filename, and PA will detect and match it using the header fields and ID3/etc tag data alone. Any lines that are not prefixed with a field name or a timecode will be ignored.

Andre

[maxmp]

@andrewilley that seems to be correct. There are priorities though, which I will try to outline here.

• lengthS == [length:] tag. +/-2s. difference is accepted. If no [length:] provided, it's not used for the matching, or, in other words, any track length matches such LRC
• "+" and "/" means "AND" here
• folder_path, title, artist, album, etc. here means folder path, title, artist, album etc. track tags should match exactly the LRC folder path, [ti:], [ar:], [al:] (case insensitive) etc.
• the list sorted by the priority (first number). The rules are processed in that order until match happens. Lower priority match won't override the higher priority match
• artist, album tags should not be "Unknown *"
• simpleFilename == filename without the last extension
• plain text in LRC file still may get title and artist tags from its filename, based on "title - artist.lrc" pattern with an optional track number prefix or suffix (the same way as track filenames are parsed)
  • otherwise, plain text in LRC is processed as LRC file without any tags, so it may be matched by the rule 600

- 1000 folder_path + title/artist/album + lengthS
- 900 folder_path + title/artist + lengthS
- 800 title/artist/album + lengthS
- 700 title/artist + lengthS
- 600 folder_path/(simpleFilename or name_without_number) + lengthS
- 500 folder_path + title_tag + lengthS
- -1 no match

 

 

[andrewilley]

@maxmp Thanks for that, if I do a guide I'll include a simplified overview of that.

One thing I've noticed in testing is that [length:] does not seem to be validated at all for me. For a non folder_path LRC file, as long as it contains the correct [ti:] and [ar:] header tags, but incorrect [al:] and [length:], the lyrics are still used.

For example, the following header info works to match with my test audio file in another folder (which is duration 3:06). I thought +/- 2s duration mismatches should trigger an instant fail?

[ti:Hold on Tight]
[ar:Electric Light Orchestra]
[al:Could be correct, but any wording works]
[length: 5:00]

Andre

[maxmp]

@andrewilley whitespace is not accepted after : in LRC [length:] tag

[andrewilley]

I'm sure I tried with and without the whitespace (whitespace is used in most of the examples in the wiki by the way, which is the probably nearest thing there is to a spec, so I guess it ought to be valid and the parsed strings could do with trimming before use) but I'll test again.

[Edit]

Yes, whitespace does not seem to be the issue. This test LRC file, which has a different base filename and is not saved in the same folder as the audio file, is still considered a match for "Hold on Tight" by "Electric Light Orchestra" from album "Time" with duration 3:06. In this case, exact matches with just the [ti:] and [ar:] headers seems to be sufficient for validation (modify either of those two fields and the match fails, which is as expected).

[ti:Hold on Tight]
[ar:Electric Light Orchestra]
[al:Any text here]
[length:4:40]

[00:13.00]Hold on tight to your dream
[00:20.00]Hold on tight to your dream
[00:26.50]When you see your ship go sailing
[00:30.00]When you feel your heart is breaking
[00:32.50]Hold on tight to your dream

Andre

[maxmp]

@andrewilley I'll add support for this. It's just no LRC in the wild from my collection has this. There is no real standard for this, so parsers are developed "by example".

[andrewilley]

@maxmp Did you see the edit I added after testing by the way? Whitespace in the field does not seem to make a difference anyway, PA is still allowing a match with a 3:06 audio file and a LRC file with a header showing [length:4:40]

Andre

[maxmp]

@andrewilley actually, I can see spaces are properly ignored in this place. They may not be ignored in the text lines, but [length:  2:30:15] should be properly parsed as 2:30:15.

[maxmp]

@andrewilley I can't reproduce this behavior. If I edit LRC file lengths so it differs for 3+ seconds, the next lyrics resolution results in no lyrics for the track. Changing length back makes lyrics appear for the next lyrics resolution (after normal rescan and track change).

[andrewilley]

I think I just found the problem. The [length:] field is being ignored if it does not included a hundredths of second portion.

So "[length:4:40.00]" is correctly rejected as not matching with my song duration of 3m 6s, while "[length:3:06.00]" works as a match. However "[length:4:40]"(without the dot portion) seems to be ignored and the LRC file is still considered a proper match based on [ti:] and [ar:] only. All examples I've found using the [length:] tag seem to be m:ss or mm:ss only, so I suspect that's where the problem lies.

Andre 

[maxmp]

@andrewilley that must be it. Will be fixed for the next beta. Thanks for the investigation!