lrcplayer: ignored prefixes and suffixes in file names

[GCRaistlin]

From the manual:

If the audio file currently playing is /Music/Artist/Album/Title.mp3, then the following files will be searched for ...:
...
/Music/Artist/Title.ext
...

In real life, the rule "Lyrics file should have the same name as music file" doesn't seem to be very convenient. In case of discographies, files are called usually as "<track_nr>. <title>.<ext>". Therefore, lyrics files names should also start with <track_nr>, which makes them hard to be found in the Lyrics directory (you don't remember track number). Besides that, if a song is present in multiple albums and has different track numbers there, there must be multiple instances of the same lyrics file.
It would be better if lrcplayer could ignore non-important prefixes and suffixes in file names. For example, if "Ignore prefix" is set to "^\d{1,2}\. " then lrcplayer would find lyrics for "01. Arnold Layne.mp3" in "Arnold Layne.txt" file.

[[Saint]]

I note that this is somewhat of a self-created issue.

There are multiple places where .lrc files can reside, the most obvious one, in my mind, being the album directory itself (where your naming collision issue cannot occur, at all - though there are multiple locations where this is true).

In the case of mp3 formats, we can read .lrc info from embedded id3v* tags (SYLT and USLT specifically).

To quote from our fine user manual directly:

Location of lyrics files
The plugin checks the following directories for lyrics files. If no lyrics file is found and
the audio file is a .mp3, it also checks for SYLT and USLT tags in the id3v2 tags.

1. The directory containing the audio file and its parent directories.
2. For each of the above directories, the plugin searches for a subdirectory named “Lyrics”.
3. Finally, the plugin will search as above, but within a directory called “/Lyrics”.
The name of this directory can be customized, see below.
If the audio file currently playing is /Music/Artist/Album/Title.mp3, then the following
files will be searched for, in this order. .ext is one of the supported extensions
from the list above, and will be searched for in the same order as in that list.

/Music/Artist/Album/Title.ext
/Music/Artist/Title.ext
/Music/Title.ext
/Title.ext
/Music/Artist/Album/Lyrics/Title.ext
/Music/Artist/Lyrics/Title.ext
/Music/Lyrics/Title.ext
/Lyrics/Title.ext
/Lyrics/Musics/Artist/Album/Title.ext
/Lyrics/Musics/Artist/Title.ext
/Lyrics/Musics/Title.ext
/Lyrics/Title.ext

I hope this assists you.


[Saint]

[GCRaistlin]

Music files are used to be downloaded from torrent trackers. Old torrents are being closed sometimes, new ones (with better quality) appears, or torrent dir structure is being changed. This makes placing lyrics files into album folders ineffective. Tags are good, but again, not all torrent creators bother to embed lyrics there.
The goal of the idea is to place lyrics files somewhere and forget about them, no matter how music files structure itself will be changed in the future.

[[Saint]]

As clearly stated in the manual, the plugin will search for given subdirectories above the album location until it either finds a hit, or gives up.

This leaves you with a great many possible directory structure combinations, the .lrc files need not reside inside the album directory (alongside the corresponding media) itself, this was just a single (the most obvious) example.

It is not for me to say who's use case is 'right' or 'wrong'. I will say, however, that your 'goal' seems highly error prone (at least as error prone as the case you just dismissed as invalid), and that it is still entirely possible to place the .lrc files in a structure that allows you to continue with your current use case.

The point of my prior statement wasn't to dismiss the perceived validity of your claim, that is for you to decide, but rather to point out that this behaviour is incredibly unlikely to change given that what you want to do is already possible, and highly flexible.


EDIT: As a side note, however you're getting your media, be it questionable origin or not (though we won't discuss that here), relying on someone else to tag your media is almost certainly going to end in tears at some stage. I have not yet once found a single uploader that cares about file metadata being even remotely correct, let alone one that puts as much care into the task as I do.

I might suggest MusicBrainz Picard, which is far and away the best free metadata tagger available.



[Saint]

[GCRaistlin]

How can directory structure combination help in the case when file naming scheme would change in a new torrent? This is the main issue, not the directory structure change.
If track numbers don't have a leading zero in the old torrent but do in the new one - yes, we can rename almost all lyrics files. If we have found an error in lyrics for the particular song, this song is included in a few albums of the artist and has different track numbers there - yes, we can search for all corresponding lyrics files and replace them with the new version. If another album of the artist will be added on next torrent update - yes, we can search if there is lyrics for every song of the album and make a copy with the proper track number if found.
Yes, we can do all this - but I can't say this is a very effective action scheme.

[[Saint]]

I must say I have a very hard time believing that anyone does this often enough, or on a large enough scale, for it to actually be a real world problem, and that if the metadata was correct and consistent - it wouldn't be.

I'm not convinced that loosening the already very flexible naming and positioning requirements of lrcplayer is a valid solution for poorly or improperly tagged media.


[Saint]

[GCRaistlin]

What makes this a real world problem isn't that at least one user does this often or on a large scale but that many users have to do this - maybe not often or not on a large scale, but anyway have to.
And it's not the question of correct metadata, because metadata has and will always have errors - in real life, yes. It's the question of how to decrease the trouble because of incorrect metadata.

[[Saint]]

What makes this a real world problem isn't that at least one user does this often or on a large scale but that many users have to do this - maybe not often or not on a large scale, but anyway have to.

Where is it that you are getting this estimation of 'many users' from?

My count puts the amount of people who have ever seen this as an issue at precisely one, yourself.

It seems as though you are deliberately making this a lot harder than it needs to be, take the following as an example:

I would posit that in most instances, in your stated use case of replacing a given low bitrate/quality album with a given high bitrate/quality album, that they would simply cut/copy and paste over the top of the original, which would leave any user generated files such as lyrics, bookmarks, playlists, album art etc. in place.

And it's not the question of correct metadata, because metadata has and will always have errors - in real life, yes. It's the question of how to decrease the trouble because of incorrect metadata.

That's a bold statement. My metadata is certainly correct. I posit that this is the case for a great many of our user base.

I don't know from which questionable place(s) you're getting your media from, but the metadata being incorrect certainly isn't Rockbox's problem, and relaxing the rules for lyric file detection in turn creating the possibility of naming collision (for example, self titled albums of which some artists have multiple) is not something I think is a valid solution.

The operating system shouldn't be relaxed to accommodate users who, for lack of a more subtle way of putting it, are too lazy to correctly tag their media. As I stated in a prior post, I highly recommend MusicBrainz Picard for all metadata creation/editing/removal/etc. It is an extremely easy to use tool with a truly massive bank of information from which to draw from (utilizing AcoustID audio fingerprinting), with multiple detection options.

In this day and age, there's pretty much no good reason to not have correct and consistently tagged media regardless of where said media originated.


[Saint]

[saratoga]

What makes this a real world problem isn't that at least one user does this often or on a large scale but that many users have to do this - maybe not often or not on a large scale, but anyway have to.

I think you're the first to mention it.  My impression is that very few people use lyrics. 

[GCRaistlin]

Where is it that you are getting this estimation of 'many users' from?

That's simply. Do many users get their media collections from torrent trackers? Yes. Would many users like to update their media collections with higher quality ones if possible? Yes. Are there uploaders who doesn't take trouble to fill Lyrics tag? Yes. Does every uploader have his/her own opinion of the ideal torrent file structure? Yes.
Summarizing all of the above gives the answer: many users (of those who bother about the lyrics, of course) should work somehow with their lyrics collections after updating their media collections.

My count puts the amount of people who have ever seen this as an issue at precisely one, yourself.

I'm just the one who took trouble to give the idea how to resolve the issue

I would posit that in most instances, in your stated use case of replacing a given low bitrate/quality album with a given high bitrate/quality album, that they would simply cut/copy and paste over the top of the original, which would leave any user generated files such as lyrics, bookmarks, playlists, album art etc. in place.

Yes - provided that file names and directory structure are the same. Do I have to say that it's not very likely scenario in case of different uploaders?

That's a bold statement. My metadata is certainly correct. I posit that this is the case for a great many of our user base.

We're still saying about lyrics, aren't we? The main issue here is that's hard to say is lyrics correct or not. For example, lyrics printed in CD booklets is used to lack punctuation marks. In this case, what lyrics is correct - "official" without commas or "literate" with them? Who guarantees that you won't change your mind about this one day? Who guarantees that you won't find a typo in your metadata one day? The correct lyrics isn't a state, but a process.

relaxing the rules for lyric file detection in turn creating the possibility of naming collision (for example, self titled albums of which some artists have multiple) is not something I think is a valid solution.

I didn't understand how self-titled albums could lead us to collisions while lyrics is being searched by track name. I thought about possible collisions and even has the real example (2 "In The Flesh" tracks in Pink Floyd's "The Wall"), but this could easily be eliminated by the rule: "First search by full track name, if not found, try to ignore specified prefixes/suffixes".
And I don't agree with "relaxing" term - it's not relaxing, it's flexibility. By default all things should remain the same - ignored prefixes/suffixes should be defined (or enabled - in case of pre-defined) by the user.

As I stated in a prior post, I highly recommend MusicBrainz Picard for all metadata creation/editing/removal/etc.

I do know where to get the metadata. But I prefer not to change downloaded files. Why? Well, there is no reliable media. Backup is good, but it's much easier to backup corrected lyrics in txt files than a lot of music files the only difference of which from the original (downloaded) ones is corrected embedded metadata. We can consider torrent trackers as a kind of backup, can't we? If you use original torrent files and someday your HDD dies suddenly, all you have to do is to buy a new one and to download torrent again. But if there were changed files on that HDD you've got the problem. And anyway, even you have a backup, you have to process all files again in case of appearing the torrent with the higher quality files.

[saratoga]

I think you vastly overestimate how many users have this problem.  But perhaps someone will take an interest in changing the lyrics plugin. In the meantime I suggest you take saints advice.

[[Saint]]

Where is it that you are getting this estimation of 'many users' from?

That's simply. Do many users get their media collections from torrent trackers? Yes. Would many users like to update their media collections with higher quality ones if possible? Yes. Are there uploaders who doesn't take trouble to fill Lyrics tag? Yes. Does every uploader have his/her own opinion of the ideal torrent file structure? Yes.
Summarizing all of the above gives the answer: many users (of those who bother about the lyrics, of course) should work somehow with their lyrics collections after updating their media collections.

I won't bother going into the reasons why its wrong to extrapolate in this fashion.

My count puts the amount of people who have ever seen this as an issue at precisely one, yourself.

I'm just the one who took trouble to give the idea how to resolve the issue

This in an indirect way of backing up my statement, not adding weight to yours. You and you alone (to my knowledge, and the knowledge of at least one other), in the 8 going on 9 years that this has been possible, are the only person who has bothered to put this much effort into thinking about this. Which honestly I don't find at all surprising, given your slightly weird use case.

I would posit that in most instances, in your stated use case of replacing a given low bitrate/quality album with a given high bitrate/quality album, that they would simply cut/copy and paste over the top of the original, which would leave any user generated files such as lyrics, bookmarks, playlists, album art etc. in place.

Yes - provided that file names and directory structure are the same. Do I have to say that it's not very likely scenario in case of different uploaders?

As stated prior, this would not be an issue at all if the user bothered to take what is quite literally a minute out of their time to run the media through any number of auto-taggers, such as the one I linked earlier.

Additionally I find it somewhat hard to believe that someone who would care about having lyrics files, would not care about their media collection having random and/or incorrect metadata, and/or various different file name and directory structure styles.

That's a bold statement. My metadata is certainly correct. I posit that this is the case for a great many of our user base.

We're still saying about lyrics, aren't we? The main issue here is that's hard to say is lyrics correct or not. For example, lyrics printed in CD booklets is used to lack punctuation marks. In this case, what lyrics is correct - "official" without commas or "literate" with them? Who guarantees that you won't change your mind about this one day? Who guarantees that you won't find a typo in your metadata one day? The correct lyrics isn't a state, but a process.

Why are you even talking about this?

For the sake of this conversation the contents of the lyrics file is completely irrelevant, I quite literally could not care less. This has absolutely nothing to do with the issue you presented initially.

Please, stop confusing the issue.

As I stated in a prior post, I highly recommend MusicBrainz Picard for all metadata creation/editing/removal/etc.

I do know where to get the metadata. But I prefer not to change downloaded files. Why? Well, there is no reliable media. Backup is good, but it's much easier to backup corrected lyrics in txt files than a lot of music files the only difference of which from the original (downloaded) ones is corrected embedded metadata. We can consider torrent trackers as a kind of backup, can't we? If you use original torrent files and someday your HDD dies suddenly, all you have to do is to buy a new one and to download torrent again. But if there were changed files on that HDD you've got the problem. And anyway, even you have a backup, you have to process all files again in case of appearing the torrent with the higher quality files.

I normally wouldn't expect to ever have to tell someone this, but that is an incredibly odd use case.

You honestly think that the fleeting, transient nature of torrent files, their associated trackers, and magnet links (which you haven't actually mentioned but I thought I would throw in anyway) are a more reliable "backup" (quoted to add sarcastic emphasis because it makes me almost physically ill thinking about it) solution than physical media?

Seriously?

...I...just...wow. I don't even know what to say to that.

I have a very hard time believing that anyone who thinks themselves to be even vaguely well informed could ever possibly believe that to be true. At this point I'm starting to think that you're just pulling my leg for the fun of it, or flailing around desperately moving the goal posts every time someone points out a portion of reality that invalidates your claims or use case.


[Saint]

Edited to add:

I should point out that no one is going to stop you from presenting a patch for review on our Rockbox Gerrit Code Review instance. I can't say as to whether or not it would be committed into the upstream code base of course, but there's nothing preventing you from doing so.

Doing so is likely the fastest way of you achieving the stated goal, as there is no sense of urgency for this task from anyone I'm aware of on our side of the fence.