While driving today, I had a thought about Emphatic.

Okay... There is a lot to be said for making sure that the lyric tag is actually part of the MP3 file, and having Emphatic do a proper read of a proper lyric field of a proper V2 tag. This is the "right" way to do it. Currently, Emphatic Does The Right Thing in this respect.

But...

What if there were another way Emphatic could get its lyric data? Just as an extra feature, not really its main intended mode of operation. What if it could do this:

- Current FID playing is, let's say, fid number Fd30. (I never remember whether the *0 files or the *1 files are the actual MP3s or not, but it's not important for this example.)

- Emphatic checks that FID to see if it's got an embedded lyric tag. If it does, it reads that data out of the tag and uses it as its source for the lyric data.

- If the FID does not have an embedded lyric tag, then it does this new thing. Which is: Look for a file named Fd3L in the same folder with Emphatic. That file is a loose lyric file, just the ascii text and the time entries. Same file that you'd use as the source file for adding the lyrics to an MP3. It's just loose, it's not part of the MP3. If the file is there, Emphatic uses that as its source for the lyric data.

For those who don't have lyrics already on their player, then it just means renaming the files and FTP'ing them up to the folder with emphatic. It saves the step of tagging the songs and replacing them on the player.

Now, I see a problem here, which is... what if the FIDs change as you delete and shuffle songs around on the player. Yeah, that would be a problem, which is why the preferred method is still to actually tag the MP3 file The Right Way. But for just messing around, or for those who are willing to be careful about which files they've got lyrics for, it would be an easy way to add lyrics to the player quickly and easily.

Maybe there's an even better system that could be coordinated with Jemplode or something, better than having to look up FIDs and rename lyric files. But this was just the initial wild thought I had. Is this a good idea or a dumb idea?

You know, you could make the FID tag part of, but not all of, the file name. For ease of reference as you're messing with the files.

For instance, the file could be named:

"FD3L REM- It's the End of the World As We Know It"

Seems to me that Emphatic could find the file just as easily that way, as if it were just named "FD3L".

This sounds like a great way to assist people in debugging the way the lyric tags work (like the problem with the Simon and Garfunkel song reported earlier) because there'd be less re-uploading when there's trial and error involved.

For someone who's unlikely to code it I'd say that's a very good idea.

At the moment I'm not convinced [enough to get started with tagging stuff] that I want/am interested in lyrics. The custom info modes in emphatic looks much more interesting to me. But your idea would definately lower the barrier to start playing around with lyrics...

/Michael

For someone who's unlikely to code it

Actually, I don't think it would take that much extra coding, would it? In fact, I wouldn't be surprised if there was already code in emphatic that practically did this already... as test-case code to make sure the lyric display worked independently of the ID3V2 reading code. I know that if I were writing this app myself, the first thing I'd do is have it parse a loose data file before tackling the ID3V2 coding.

wouldn't be surprised if there was already code in emphatic

True - that's how I'd do it if had coded it. I'd imagine the content gets delivered to the program innards from the ID3 tag pretty much the same way as if you had read it from file...

/Michael

Well, you're both correct in that it's not a huge amount of code to make this happen. Though there isn't any "test case" code in emphatic to do this, I actually started out "Doing The Right Thing." The only code to read LRC-style lyrics is in lrc2sylt/lrctool, and they both are just there to convert it into ID3v2 tag data. Reading a timestamp in [xx:yy] (or possibly [xx:yy.zzz]) format isn't quite as neat as reading a 32-bit integer. I am using a Perl-style regular-expression library for this parsing these timestamps in lrctool, I would not want to absorb that kind of bloat if it were done on the player. But really, this could be done in less time than it took me to implement, say, custom info modes.

That being said, I'm not sure it's a great idea. It's actually one I thought about when I was dealing with all of this business with lrctool and such. There are drawbacks, though.

1) If this were implemented, emphatic would need to do two different things to find the lyrics. First it's trying to pull the info out of the ID3v2 tag, which it also needs to open to get fields for the custom info display. So after it's done doing that, and it finds no lyrics, it's got to open another file, which is possibly on another filesystem. I'm thinking this can add a significant amount of delay to the process of reading lyrics. Since the player is already reading the file from disk at the same time, I thought that maybe having the lyric data in the file might be saving us some precious time. But, depending on how caching is working, this may not be the case. I just thought that reading one file instead of two would be quicker, and after all the complaints about speed (esp. when changing tracks) I kinda wanted to do everything I can to make things faster. I would at the very least have to provide an option to turn this off for those who don't use this lyrics-in-a-separate-file mechanism, and don't want to pay the performance penalty of trying to stat another file.

2) Is an MP3 file's FID number set in stone for the duration of that file's life on the player? Or are there conditions under which FID numbers change? I personally have no idea. Having the lyrics in the music FID itself isolates us from the possibility that the number changes. Though it'd certainly be amusing to have Cyndi Lauper lyrics popping up during Rage Against the Machine song.

3) Is this solution really any easier than tagging the MP3? You've got to go figure out what the FID number of your various songs is, which requires that you play the file and note its FID from the hijack vital signs screen, or find it on disk somehow. Then you need to name each LRC file with that FID. Is that any easier than just tagging the file? I'll give you that my command-line program sucks, but the idea was that we'd eventually have a WinAmp plugin (or, less ideally, a separate GUI program) to tag the files.

I dunno, I will think about this more, 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. If enough people can convince me it's a good idea, I could give it a shot.

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

Yes. Once a track is on the player, its FID will never change.

A FID can be recycled -- if you delete a tune or playlist, that FID will be reused. Gaps in the FID number space are a bad thing -- they waste space in the database, so we reuse them.

This could cause a problem. If we delete the old FID, we'll only delete the files that we know about. Then, when we reuse the FID, it'll get associated with the (left over) wrong lyrics file.

This could cause a problem. If we delete the old FID, we'll only delete the files that we know about. Then, when we reuse the FID, it'll get associated with the (left over) wrong lyrics file.

Yes. However, if, instead of FD3L, lyrics lived in, say, FD3A, then Emplode would delete them when deleting the fid -- Emplode passes (the default) mask of 0xFFFF to ProtocolClient::DeleteFid, which means that all sixteen files FD30..FD3F get deleted when FD30 goes away.

Now, such *A files are technically reserved for use by Empeg, but as we've only so far used *0, *1, and *2 (and the last only on Jupiter), plus *F which has a special meaning to the protocol, it seems likely to me that car-player people using *A will in practice be safe for the time being. This also means that Java mateys and so on don't need to add anything new to the protocol to be able to store or fetch these files.

Unfortunately, the current version of Emptool tries to be clever but isn't -- it passes a mask of 0x3 in what, judging from a nearby comment, is an attempt to delete *0 *1 *2 and *3. In fact this deletes only *0 and *1 and is thus already wrong on Jupiter -- I'll fix it for 2.0final to pass 0xFFFF, if I remember.

Peter

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.

Yes. However, if, instead of FD3L, lyrics lived in, say, FD3A, then Emplode would delete them when deleting the fid -- Emplode passes (the default) mask of 0xFFFF to ProtocolClient::DeleteFid, which means that all sixteen files FD30..FD3F get deleted when FD30 goes away.

Does this same deletion operation happen when one uses the "Replace Tune" option in Emplode?

I think that the idea is worth coding up and testing - a config.ini switch to enable either or both modes would obviously be useful. My biggest concerns about the idea was Emplode/JEmplode/emptool integration issue, but Roger and Peter seem to have addressed those.

I wonder whether reading a simple text file will be quicker than parsing the mp3 file with id3lib (or friends, can't remember which one you're currently using). If it is, then this idea surely has to be considered.

Of course, only the fact that the player already does something equivalent with tags and database gives this idea any merit at all. If the player started to use id3 tags from the mp3 file at playback time, then doing it the 'right' way would be a given.

Sheesh. Right when I'm trying to be lazy about a new feature request, the friggin' SWAT team comes in. Thanks a million, guys.

My responses:

->tfabris:

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.

Okay, anyone who currently has MP3 files *only* on your empeg, and doesn't have them on a hard disk or CDROM somewhere, raise your hand. Now, imagine that, as your hands are up, your empeg hard drives suddenly burst into flames. You now need to either re-rip your entire collection, or spend a couple months on KaZAA or the like. I kinda thought that, as smart empeg owners, we all kept backups of our MP3's on a more stable medium. Am I wrong?

Having said all that, I still think that your strategy takes longer, despite my stupid one-file-per-pass utility. Especially with TheAmigo's script which I could probably package up for Windows as a standalone binary so you wouldn't need Perl on your system. Even without it, I'm thinking I could tag MP3's with LRC's faster than I could find FID numbers and rename the LRC's that way. I understand the thing with not having to use Emplode and transfer megabytes of files. That's a legitimate win with the separate file strategy.

->genixia:

I wonder whether reading a simple text file will be quicker than parsing the mp3 file with id3lib (or friends, can't remember which one you're currently using). If it is, then this idea surely has to be considered.

Regardless, we need to open up the ID3 tag so we can read comments and other custom ID3 fields (for the custom info screen) that will be supported in future releases. So this new file is an added step, not a replacement for reading the ID3 tag. That being said, I'm not sure it would be a devastating performance penalty, just one that I wasn't ready to consider because really, I think the process of manually shipping these "auxiliary FID" files over is no easier than tagging the files in the first place.

I think that the idea is worth coding up and testing

Probably. I'll see what I can do. Unless someone wants to write a patch for me...

I think I like my orginal sugestion better. since jemplode already includes everything but the kitchen sink (logo editor, animation editor, hijack updaters) why not teach it to add lrc files to mp3s? If you taught it to create lrc files, you could have all the functionality of seperate files for those who wanted them.

Worst case scenario, it's got to download the file, add the tag and reupload. So it might take a while, but things would be right. I have a hard enough time keeping my mp3s organized, and I don't think there's any hope of mp3 Tag Studio supporting lrc files anytime soon.

Matthew

I think I like my orginal sugestion better

Me too. That is exactly what I was thinking while reading this whole thread. I think tfabris is grasping to find a solution for adding lrcs in place to the empeg without having to find the file on your local drive, edit it, delete it on the empeg, and finally reupload it. I would agree that there is some merit to in place editing, but I don't think that a lot of manual ftping and fid searching is the right method. jEmplode could handle this in a much cleaner way. If your using hijack it could even do the uploads and downloads of the mp3 via ftp to avoid having to resync your whole database. Throw in the ability to query the upcoming lyrics site automatically and we have an automated tool that you could let run for a few hours to add lyrics to all your mp3s.

-Mike

[h1]I think tfabris is grasping to find a solution for adding lrcs in place to the empeg without having to find the file on your local drive, edit it, delete it on the empeg, and finally reupload it.[/h1]

Honestly, all of my material is mirrored in a distributed filesystem, so it was "pull out a copy, add lyrics, figure out the fid, ftp it to the player".

Sort of crappy, but if I cared (I don't) I'd write a tool to ftp it to the player, and not try to add other files. The ID3 tags are standard, at least.

For that matter, batching lrc2sylt on the empeg itself and nuking the lrc
files after that runs even seems more preferable than dropping an extra set of files onto it.

For that matter, batching lrc2sylt on the empeg itself and nuking the lrc
files after that runs even seems more preferable than dropping an extra set of files onto it.

Not sure this is a good idea. I believe emplode makes note of the offset where the ID3 tag ends and the real MP3 data begins (in the *1 FID), so that the player can more easily skip over the ID3 tag at the beginning of the file. If lrctool is run on the empeg, I think we'd have to manually adjust this offset in the *1 FID, or risk garbage data being fed into the MP3 decoder. If Roger/peter are still around, maybe they can confirm this suspicion.

Not that it'd be impossible for us to muck with the *1 files, but then again, the whole idea of batching on the empeg begins with knowing the FID of the mp3 file you're adding lyrics to, which is part of my problem with tfabris' solution.

Look, I will do whatever the general concensus is here, but the KISS principle really makes me want to pick one and only one mechanism and stick with it. I will support a second one if we all think it's a good idea, but two is my limit.

If lrctool is run on the empeg, I think we'd have to manually adjust this offset in the *1 FID, or risk garbage data being fed into the MP3 decoder.

Yes. The MP3 decoder is quite good at skipping garbage, but it's still not an ideal situation.

As with any other metadata editing, the Right Way to do it is to get the ID3v2 tags right before the *0 file goes on the player in the first place -- or, if the file is already on the player, to fix the PC side copy and use Replace Tune.

Peter

I think I like my orginal sugestion better. since jemplode already includes everything but the kitchen sink (logo editor, animation editor, hijack updaters) why not teach it to add lrc files to mp3s? If you taught it to create lrc files, you could have all the functionality of seperate files for those who wanted them.

Not a bad idea. I saw it when it came around the first time but hadn't thought much about it since. I am not plugged-in enough on jEmplode's innards to know whether it's equally capable of handling both the "tag then upload" and the "tag in place on the empeg" strategies, but if so, it'd be the ideal place to put it. I could probably port my code for building the SYLT binary data to Java, and I guess jEmplode already has an ID3 library of some sort inside.

Mike Schrag, you out there?

I've replaced fid files directly with no bad effects observed. Like, with a file of a different size entirely (but still id3v2 tagged).

Knowing the fid of the mp3 file isn't hard; Someone else already wrote a database parser. It involves the lrc file also being somehow tied to that fid, and I'd argue that's the uploader's problem.

or, if the file is already on the player, to fix the PC side copy and use Replace Tune.

I think Tony contends that there are situations where people don't have a PC side copy, so this wouldn't work for them. I'm not one of them, and I'm not really convinced this is a prevalent problem... But I don't want to shut anyone out, either, so I'm glad we're all throwing in our $0.02 to figure out the best way to do this. I kinda like the jEmplode strategy as of this very minute.

Regardless, we need to open up the ID3 tag so we can read comments and other custom ID3 fields (for the custom info screen) that will be supported in future releases.

I think that's ultimately the winner for me.

I suspect that if ever there was a chance for this to be integrated into the player software, then using the mp3 ID3 tags is going to be the better way to do it.

That sounds like a brilliant way to do it - currently I have all my empegged mp3's backed up on CDs in a cupboard. I could grab them, add lrc stuff and then replace tune, but what I actually do - as jemplode makes it so easy - is download an album, use lrctool and then upload them. It's pretty quick, but if the lrc tagging was part of jemplode it would be great if you could have an automated process:

grab file
tag with lrc info
upload file

where I guess the only bit in the middle which may be tricky is just ensuring the correct lrc file is attached to the correct mp3 file. As it goes through the album, maybe a proces where the app asks "track xxxxx, which lrc file to attach?" would work.

Nice idea if it's easy.

I like Tony's idea.

To address some issues raised, a config.ini parameter could be setup to define the search order (search mp3 for lyric or look for the file first).

Once the lrc file is saved on your pc/mac etc you could just put a tag into the mp3 file its filename.

Then (as I use mp3tofid/rsync), maybe Pim could modify mp3tofid to automatically symlink the .lrc file like he does the mp3 files.

Maybe it could with different options build the lrc file into the mp3 at that time..

The rather HUGE benefit of keeping the lyrics separate is that we can then distribute them amonst ourselves without having to trade massive mp3 files or reload our players -- that just ain't gonna happen for more than a few of us.

And for those of us who also use portable solid-state mp3 players, we don't want our tiny storage capacities further dwindled by lyrics, album covers, band bios, website links, artist profiles, and all of that other crap that is being tagged onto our "music" files.

id3v2: just say no, thanks.

Well, the idea was that we would trade files in LRC format regardless of whether the lyrics were embedded in our MP3s or not. The LRC file was a vehicle, then you'd embed it in the player. Nobody was going to be trading MP3's with lyrics in them just to get a couple kb of information into them.

I hadn't thought of solid state MP3 players with tiny storage capacities... But lyrics only add 2 or 3 kilobytes. I can't see this as being the difference between squeezing more music on your player or not.

What I guess you're saying is that some people will choose to use their MP3 files, some would rather have it separate, and I should give both parties the choice to do whichever. Fair enough of a statement. Not sure why you're so against ID3v2, I think as a specification, it's very good. It's just abused by dopes who put website links and crap into it. The spec itself isn't the problem. Besides, since we all rip our MP3's from music we already own on CD, we have full control of what's tagged onto our music files... right?