Locally stored Lyrics not loading, ":" replacement in file name issue

[ngs428]

Edit: This issue seems to be present with album names which have a colon (may be other characters, not sure). When an album has a ":" in it OpenLyrics will save the lyric with a hyphen "-" in the file name in place of the colon ":". It will also search for a lyrics that has the hyphen, so if no hyphen in the file name, no match will be loaded form local files. LSP3 0.50 will save and search for lyrics using an underscore "_" in place of the colon ":". These differing philosophies make the 2 programs incompatible.

Is there a way around this?

[jacquesh]

It's just an arbitrary convention. If I'd been paying attention when I first implemented the character replacement then I probably would have used the an underscore for consistency with LSP3. That's unfortunate. At this point though, I'm not going to change it from one character to the other and break local file search for all users.

As a workaround, I've had many good experiences with https://www.bulkrenameutility.co.uk/ which you could use to change all the underscores to dashes in your filenames. Admittedly that would cause its own problems if you have files containing underscores as underscores (rather than as a replacement for some other character).

Theoretically I could make it try to load both and you're welcome to try convince me that it'd be worth the effort but I'm doubtful.

[ngs428]

Is it possible to add a option check box to choose what you want for character replacement/file lookup? Default could be the current method, but for those who have used LSP3 for a while, lyric lookup and saving does not work so well.

[jacquesh]

No because that has the potential to break loading for users who've been saving with the hyphen for a while. At which point I'm going to get confused and/or angry users coming and asking me why their lyrics aren't loading (and justifiably so, I would say).

Attempting to load both would be preferable to letting users choose which one to load I think. Although technically attempting to load both does have its own pitfalls (because now there's more potential for filename collisions e.g if you have 2 tracks "a:b" and "a_b", although technically the same is currently true for "a:b" and "a-b" so maybe it's fine).

[ngs428]

Thanks for the conversation on this one @jacquesh . I have found your component to be superior to the others I am using (LSP3 and ESLyric). In OpenLyrics, your searching capability, lyric preview, and especially the lyric editing capability (specifically applying an offset to the timestamps) are amazing and unmatched.

The contents of this issue, which is the lack of being able to open LSP3 naming convention lyrics, is a challenge. Many of us have 1,000s of lyrics named using the LSP standard "_" in place of the colon ":", so Open Lyrics won't find and open the lyric. Being able to save with this LSP3 naming convention is also critical for compatibility.

I also want to mention that the auto-editing for lyrics works great and having NetEase as a source is a great asset. They have some oddball lyrics from time to time. I only reach out because I and others have to use multiple lyric components to have all the required features and I think yours is the closest to having an all in one solution.

Again, thanks for your time, I hope all is well!

[jacquesh]

Eh, yeah maybe it'd be worth having a one-time prompt to convert to a compatible filename.

I don't know though, because it would be a bunch of effort and overhead and I specifically am not interested in maintaining ongoing compatibility with LSP3: I don't see any reason why you'd use that and openlyrics concurrently other than for a short transition period.

[ngs428]

Renaming lyrics is not a huge deal, but when you rename a lyric file, you will then have to rename the song file. That is the bigger deal. Playlists, media libraries, etc. are already setup, so it would be a pain to switch names on those files. Why does one have to rename the music files.. well that is the way may music players link the song and lyric file.

Plex is very common and the lyric files need to be named the same as the music file. See: https://support.plex.tv/articles/215916117-adding-local-lyrics/ Tip!: The lyric file must be in the same directory as the corresponding music track and must be named identically, aside from the file extension.

I was looking back to see how the "underscore" became so universally used. The popular MusicBrainz Picard program https://picard.musicbrainz.org/ has a Windows compatibility section in the program. The default character replacement is to use a "_" for 7 different characters. See the screenshot below. In the program, go to Options > Options > File Naming > Compatibility > Customize. Buried fairly deep, so nobody changes it......

So what we have are song files being named using "_" as the replacement character and music players needing to see song and lyric files as the same name.

Having a Windows compatibility box similar to the Picard screenshot above would allow the user to pick the characters they want for searching and saving. That would improve compatibility for users. Get some of the LSP3 users to convert over.

Thank you again for your work on this component. :)

[jacquesh]

I'm not renaming the media file. The point of swapping out characters is to produce a string that is a legal filename, if the lyrics file has the same name as the media file and had to have some characters replaced then presumably so did the media file and we don't have any reason to believe that whatever did that character replacement followed any particular strategy. Also as you say, it has all sorts of other complications.

I think the options at this point are either: 1) Just support loading files with any of a set of replacement characters (e.g try both dash and underscore replacements and just removing the character), or 2) Offer the user a one-time scan of their library to replace lyric files matching one replacement character with another (e.g to get everything over to using underscores).

[ngs428]

Yes, there are many strategies for replacing characters to get a legal filename. You are correct there, that is why we have some incompatibility. Picard uses an underscore and that is how most of my music is tagged. Then OpenLyrics uses a hyphen, so nothing matches and lyrics can't be opened by players such as Plexamp that need matching names. I think we are on the same page there.

For searching, I think your #1 option is a great option. This will provide the most compatibility for all users. Since there is no standard replacement character for legal file names being more flexible like you explain makes sense.

For saving, being able to specify the replacement character would also be key. Same option as the screenshot that I provided from Picard. If one needs and underscore rather than a hyphen to better match their exiting file set, it could then be done.

[ngs428]

HI @jacquesh I was saving a lyric file via OpenLyrics, the song title was "Where Do We Go From Here?". When saving I noticed that the "?" was not replaced with any charater. It was just completely removed from the lyric filename. Filename was "Līve - Songs From Black Mountain - 08 - Where Do We Go From Here.txt" Is this the expected behaviour? Thank you!

[jacquesh]

I can reproduce that locally. No it wasn't specifically intended. Arguably, we should treat all "path-illegal" characters in the same way, but this does slightly increase the complexity of supporting backward-compatibility.

[ngs428]

Hi @jacquesh, I tested all the "path illegal" characters in Windows and here are the varied results in OpenLyrics....

• < (less than) INSERTS underscore
• (greater than) INSERTS underscore
• : (colon) INSERTS hyphen
• " (double quote) INSERTS '' two single quotation marks, I think that is what they are
• / (forward slash), \ (backslash) and | (vertical bar or pipe) creates a folder named with the text before the forward slash, backslash or pipe, and a lyric file with what is after the forward slash, backslash or pipe.
• ? (question mark) INSERTS nothing, completely removes character
• • (asterisk) INSERTS the letter “x”
• Track name metadata ending in space or period INSERTS nothing, completely removes character

In contrast the most up to date versions LSP3 and ESLyrics both use the same replacement of "path illegal" characters as seen below.

• < (less than) INSERTS underscore
• (greater than) INSERTS underscore
• : (colon - sometimes works, but is actually NTFS Alternate Data Streams) INSERTS underscore
• " (double quote) INSERTS underscore
• \ (backslash) and creates a folder named with the text before the backslash and a lyric file with what is after the slash
• / (forward slash) INSERTS underscore
• | (vertical bar or pipe) INSERTS underscore
• ? (question mark) INSERTS underscore
• • (asterisk) INSERTS underscore
• Track name metadata ending in space Keeps the space
• Track name metadata ending in space Keeps the period

The "path illegal" character replacements in OpenLyrics are challenging. From what I have researched, an underscore is the standard method to replace the "path illegal" characters.