shamhi
pls help to improve the .env configuration
Hi everyone, I just discovered clickbots. I would like to ask for your help to find the most optimal and "safe" config, because I'm afraid that I can set it wrong and get banned.
As to not be invasive, it could be added as a new isrc column with NULL set for all existing entries. Then whenever /api/get is requested for a song where it's NULL and it's been X days/months since updated_at, LRCLIB could probe external providers to fetch the ISRC.
If ISRC is not available for the biggest sources, is there similar metadata which could be used for the same purpose @tranxuanthang? Even things like Spotify ID or MusixMatch ID would be useful as backup.
This should have more upvotes. It would allow for perfect links between other providers or streaming services and make API fetches 100% accurate. Any chance this will be tackled in an upcoming update ?
The problem for now would be where we would get the information from. I don't really prefer wiring LRCLIB to any external services, especially commercial ones (Spotify,...).
Something like MusicBrainz should be okay, but we would need to mind their rate limit and policies, since LRCLIB has quite high API request calls (maybe contact them for partnership?).
One way would be getting the ISRC and maybe MusicBrainzID from the song itself and send it together with /api/get request (if present). It is relatively easy to implement, might not need to ping external services, but would require support from clients and update (LRCGET, plugins for MusicBee, Jellyfin,...).
I will do more research and brainstorming regarding this, but if you have any ideas then feel free to bring them up!
The problem for now would be where we would get the information from. I don't really prefer wiring LRCLIB to any external services, especially commercial ones (Spotify,...).
Something like MusicBrainz should be okay, but we would need to mind their rate limit and policies, since LRCLIB has quite high API request calls (maybe contact them for partnership?).
One way would be getting the ISRC and maybe MusicBrainzID from the song itself and send it together with
/api/getrequest (if present). It is relatively easy to implement, might not need to ping external services, but would require support from clients and update (LRCGET, plugins for MusicBee, Jellyfin,...).I will do more research and brainstorming regarding this, but if you have any ideas then feel free to bring them up!
I'm not sure I understand what you mean. ISRCs are not proprietary so implementing it in your database doesn't have to be linked to another service.
I think the idea (for me however) would be to update the track database to add an ISRC column containing either a string or a list of strings. Then, implementing the option in the get route, users could fetch the tracks/lyrics they are looking for by fetching /api/get&isrc=<ISRC>.
It is worth noting that most commercial music services will allow you to get tracks based on their ISRCs (Deezer, Spotify, Musixmatch, etc.)
If wanted, I can give a hand making a simple script to fetch ISRCs for existing tracks in the database. Let me know !
Best,
As for the MusicBrainz limitations, you can easily run your own clone of the DB with no rate limit that syncs to the live database. Lrclib would be infinitely more useful with some ID system to actually tie it to known data. The isrc field would be left null by default and could be provided when submitting lyrics in addition to other metadata. There could also be an endpoint to update existing lyrics with ISRCs. I would probably set up a bot to go through and match Musicbrainz recordings with existing entries on the lrclib dB and automatically submit matching isrcs from a MBZ dB instance.
I created a second table called isrcs, instead of just adding an isrcs field to the tracks db because lookups were too slow. Entities in the isrcs db are stored as { isrc: *, track_id: *} so it can be indexed. Reason why I didn't just do with having 1 isrc is because of the rare case where a publisher screws up and there's two ISRCs for the exact same song, and the existing layout of the DB doesn't really support having two separate entities for seperate ISRCs. Plus, should this ever need to be rolled back or removed, just axe the isrcs DB and the main table isn't touched.
At the moment, the only ways to interact with ISRCs are to submit an array of ISRCs on lyrics publish &isrcs=["US1234567890"], or to use /api/find/isrc/US1234567890. Going to add /api/submit-isrcs which will accept track_id and the isrcs array. Only thing to consider is how rate limiting would work here.
Added /api/submit-isrcs endpoint! It uses the existing POW system for rate-limiting (Which is bad for so many reasons IMO), but I digress. It accepts isrcs and track_id as a payload with the publish_token as a header.