Is an MP3 file's FID number set in stone for the duration of that file's life on the player?

Yeah, but it's not set in stone for a song's life on the player. So yeah, theoretically, I might delete that song someday and its FID might get re-used for another unrelated song.

But I really like what Peter said about how Emplode would delete FD3* from the FIDs if we we just named the files according to their scheme. That would be really cool because that would mean Emplode already takes care of this problem for us. Rock.

Although we'd have to drop the files into the FIDs folder instead of the emphatic folder.

Is this solution really any easier than tagging the MP3?

Depends on the situation. But sometimes it could be easier, yeah. If the songs are already on the player and I don't have them on my PC's hard disk. I can find the FIDs of all the files I want to lyric-tag just by looking at the "all tracks" list in Emplode. The operation to rename all the lyric files would take just a few minutes, and would be followed by a single quick FTP upload. Rather than multiple download/tag/re-upload passes with the full song file.

but I would never really use this, because I wouldn't want to have to first sync my MP3's, then go find the FID, then rename LRC files to that FID, and then FTP them over.

Agreed, you wouldn't use it in this situation. The only time you would use it is if the song was already on the player and you already had the lyric file sitting loose. Only then would it save time.

I agree this isn't the "right way" to do it. The right way is the way it works right now: tag the files. I was just thinking this could be an additional way.

Reading a timestamp in [xx:yy] (or possibly [xx:yy.zzz]) format isn't quite as neat as reading a 32-bit integer.

I'll agree with that. I didn't realize that you'd have to add a string parsing routine to get the job done. I'd suspected that the code to do this was already in place, but since it's not, I see your point about not adding more bloat.