Rockbox Development > Feature Ideas

lrcplayer: ignored prefixes and suffixes in file names

(1/3) > >>

GCRaistlin:
From the manual:

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

--- End quote ---
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:


--- Quote ---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
--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page