Hmmm, paint me confused.. I got's two questions now

1) Does Singit spit out LRC lyrics or SYLT lyrics?

2) if SingIt does spit out SYLT lyrics, will lrc2sylt understand those SYLT lyrics? It looked like you were grepping for specific things in lrc2sylt.c

I just haven't been able to tag anything yet. I don't mind it being command line, I like it command line, I can script with command line

Thanks for these cool tools yn0t_!

SingIt's lyrics editor (you open it from one of the plugin Config tabs) saves LRC lyrics, but it can READ ID3v2 SYLT lyrics. I made the incorrect assumption that because they claim ID3v2 synced lyrics support, that the editor would actually WRITE those tags. Well, it don't.

So you could generate the lyrics in SingIT, save them as LRC format text files, and convert them with my command-line util. I haven't tried it, but if SingIT's LRC format isn't significantly different than the 10 or 12 LRC files I used in testing my program, then it will work.

Clear things up?

Thanks, Jim, we appreciate your hard work!

Well, thanks! I gotta say, it was a complete *bitch* trying to make out the words!!

Now that I have that under my belt, I'm thinking I may move on to something more substantial . I gotta say, though, I have been on a bit of an Ogg bender, and I have to wonder....what's the chances that Ogg support could magically (meaning it is not dependent on my ignoramus-level relationship with programming!) materialize? I was looking at GetID3() to see if there is a way to smoothly combine that with EasyTag and Grip, but I don't figure that will matter much if ultimately they are not viewable.

Anyhow, what you have done is great -- too cool. I look forward to exploding a few passengers' heads even *IF* I have to keep a few lowly MP3 files around.

(dang, though, I wish more liner notes were legible in a way that they would submit to OCR!!)

In the "bad ideas" department, is there a "from here to the end of the track is silence" tag? You could do "silence killing" by noticing one and skipping to the next track.

Thanks for the kind words, Jim. I don't know much about Ogg, don't they have their own non-ID3 tag format or something?

BTW, that has got to be the first circular dependency I've ever seen between two BBS posts...

. I don't know much about Ogg, don't they have their own non-ID3 tag format or something?

Yes, the Ogg "comment" format is (for both better and worse) more open-ended with no strict definitions as in ID3. In practice, though, with softwares like EasyTag, what I see is Ogg comment/tag support implemented in a way that mimics MP3/ID3. I do not know if there are any tools out there to build/read/write a custom Ogg comment format, but if there are, I don't think they have made it into any Tag editors. The notion appeals to me, though...dream up your own tags....multiple subgenres, mood fields, whatever. I was also thinking of things like all credited musicians on a track with instruments, recording studio, songwriter, etc. Perhaps these are getting into ID3 and I haven't been paying attention.

Anyhow, open-ended possibilities, but short on implementation for now. That GetID3() lib says it will write to Ogg, so when I get home in a few weeks and get some time I may have to add lyrics to an MP3, write its tags to Ogg and see what happens...see if that is a starting point.

Ok, I've been playing with this quite a bit today...Firstly, Wow...this is great.


Some usability observations;

1) ReseveCache=2 seems to work for me. At some point I'd somehow removed it, and emphatic wasn't very happy. Lot's of disk churning, and high CPU usage (ISTR that disk I/O is CPU bound on the empeg), resulting in a rather unresponsive empeg. I tried ReserveCache=4 too, but this seemed to have equally bad results - I guess that the player was being starved at this point.

2) Yes, the horizontal scrolling definately still needs some work - it goes in fits and spurts too much. This is most obvious with the large font. My test track appears to be good - the timings work well in vertical mode. I wonder whether horizontal scrolling will ever be as smooth as we like, give that we are bound by the 40Hz screen rate anyway. I also wonder whether looking another line into the future might help with timing.

3) emphatic needs to be better behaved with buttons. It really shouldn't keep the buttons bound during general use, and I have seen some quirkyness with the left and right buttons when lyrics have been active. (Typically a short press being translated as a long press). I know that you've mentioned wanting to make emphatic sit back more in the background. I think that the ideal solution would be to separate out the lyrics display and UI functions into 2 processes, ie emphaticd and emphatic_control. Then bind emphatic_control to the hijack menu, and bind all the buttons for menu use only. When you exit the menu (ie, emphatic_control), unbind all the buttons, and wait for selection from hijack again. I'm hoping that future versions of hijack will enable userland apps to be assigned to the Popup menus.
The question is whether hijack supports a process binding the screen *only* (as emphaticd would need to). Not sure.
Oh, I'm also trying to promote the idea that a long knob press should always quit back to the hijack menu (without making any changes)

4) Slightly modified Menu options; On (exits menu leaving lyrics on), Off (exits with lyrics off), Mode, Font, Quit. Functionally I think it's identical to what you already have, but I think that it's marginally clearer - putting 'On' and 'Off' next to each other would help people to grasp the real effect that they have.


Now I just need to add lyric tags to all my music and I've got a ready made Karaoke-Business-in-a-Box.

Oh, a bugette.

Bottom Left. A block of 4hx2v pixels are sometimes artifacted.
When in horizontal, small font, Pixels 34hx9v and 34hx10v (measured from top left) are nearly always artifacted.

Oh, FFWDing to a track without lyric tags results in the last displayed line of lyrics being redisplayed. (Repeatedly for every FFWD)

1) ReseveCache=2 seems to work for me. At some point I'd somehow removed it, and emphatic wasn't very happy. Lot's of disk churning, and high CPU usage (ISTR that disk I/O is CPU bound on the empeg), resulting in a rather unresponsive empeg. I tried ReserveCache=4 too, but this seemed to have equally bad results - I guess that the player was being starved at this point.

ReserveCache=2??? I have my ReserveCache set to 64. Last I heard the player has 180 * 32k cache blocks, so I can't see how ReserveCache=2 or ReserveCache=4 does much for us. ReserveCache=64 Still seems to leave the player with enough to play with. Maybe this is your sluggishness problem? Let me know if it is so I can recommend that end users set their ReserveCache a little higher.

I do notice a little sluggishness when it first reads the lyrics, but after that things are fine on my player. In the future I may try out that libmad tag library, that might be a little less taxing than id3lib.


2) Yes, the horizontal scrolling definately still needs some work - it goes in fits and spurts too much. This is most obvious with the large font. My test track appears to be good - the timings work well in vertical mode. I wonder whether horizontal scrolling will ever be as smooth as we like, give that we are bound by the 40Hz screen rate anyway. I also wonder whether looking another line into the future might help with timing.

I think I know why you're seeing this one. There is an increment factor which gets calculated based on how long our calculated sleep time is. If it's really low, it means we need to cover a lot of screen real estate in a short amount of time. The only solution is to skip pixels, instead of moving one pixel at a time, move 2, or even 3 at a time. This only happens when things are REALLY tight, with fast lyrics or, as you mentioned, the large font. Basically, if our calculated sleep time is under 15000 microseconds, we're in trouble, so we skip two pixels per update. If the calculated sleep time is under 10000 microseconds, we skip 3.

Now, there IS a bug that I've fixed (but can't release right at this moment because I'm working on other things in the program) where that increment wasn't being reset when it should be. The result was (I think) as soon as one line in a song needed that correction, the rest of them were getting it because I wasn't resetting that increment. Well, that will be fixed in the next version. I'd be interested in hearing your subjective analysis of if this bug fix solves the problem you're seeing. (Patrick G found the bug, by the way. I need to invite him to my code reviews at work.)

emphatic needs to be better behaved with buttons. It really shouldn't keep the buttons bound during general use, and I have seen some quirkyness with the left and right buttons when lyrics have been active. (Typically a short press being translated as a long press). I know that you've mentioned wanting to make emphatic sit back more in the background. I think that the ideal solution would be to separate out the lyrics display and UI functions into 2 processes, ie emphaticd and emphatic_control. Then bind emphatic_control to the hijack menu, and bind all the buttons for menu use only. When you exit the menu (ie, emphatic_control), unbind all the buttons, and wait for selection from hijack again. I'm hoping that future versions of hijack will enable userland apps to be assigned to the Popup menus.

No can do. Reason? Fast forwards and rewinds. I need to detect them, and there's no other way except trapping the buttons. To be honest, unless I FF/REW at the very beginning of the song when disk activity is high and CPU is being taxed, I don't see too many of those short press being translated into long press problems.

If you can come up with a better way to detect FF/REW, I would be HAPPY to not bind to the player left/right buttons.

4) Slightly modified Menu options; On (exits menu leaving lyrics on), Off (exits with lyrics off), Mode, Font, Quit. Functionally I think it's identical to what you already have, but I think that it's marginally clearer - putting 'On' and 'Off' next to each other would help people to grasp the real effect that they have.

I'll put that feature request in the queue.

Eh? Artifacted? What's that mean?

That's *around* the area I bind to when no lyrics are available for a song. There's no way to truely unbind from the display, so I take up a small portion of it with this:

hijack_geom_t corner_geom = { 30, 31, 0, 2 };

and just don't write anything to it. Or if I am, that would be a bug.

No idea where the other one with the horizontal/small font thing comes from... Can you post a screengrab?

Oh, FFWDing to a track without lyric tags results in the last displayed line of lyrics being redisplayed. (Repeatedly for every FFWD)

Found that one earlier this evening. It's in the queue!

If you can come up with a better way to detect FF/REW, I would be HAPPY to not bind to the player left/right buttons.


Don't bother detecting FF/REW. You're constantly playing catchup and as soon as someone decides to FF through 5 tracks at once, the game is over - the empeg grinds to a halt. It's even worse with RWD (I can kill emphatic..) It's probably better to watch the notify information to discover when the track changes, and to be a little late with the lyrics for the songs that have 'instant' lyrics. (How do you detect when the track changes usually?).

Well, I found out what I was doing wrong. I grabed the Devel version of SingIt, and it's changed the syntax from [05:05] to {05:05:456] , I just changed the regexp in lrc2sylt.c fto re2 = pcre_compile("\\s*\\[(\\d+):(\\d+):(\\d+)\\]\\s*", 0, &error2, &erroffset2, NULL); All works well now..

Thanks again! Sorry for being such a bonehead

Well, I got my first song to play, and I'm very impressed. I had to start with Barenaked Ladies one week, figuring that everyone else was starting with It's the End of the World as We Know It. Overall, it works great, and 90% of the lryics are readable. the 10% are no fault of emphatic. Great program, lots of fun.

There's got to be a better way to tag song. As it is now, it's going to remain a novelty for me. Is there any hope of being able to right click on a file in Jemplode and give it a lyrics file to associate with it? (download, rehash, upload is fine by me) I guess in the future lyrics can just be added to my ripping/uploaded process.

Matthew

Ahhh... Yeah, I guess SingIt uses milliseconds. I meant to support those in lrc2sylt but I forgot to throw that in... I will change the regexp in lrc2sylt for the next release.

There's got to be a better way to tag song. As it is now, it's going to remain a novelty for me. Is there any hope of being able to right click on a file in Jemplode and give it a lyrics file to associate with it? (download, rehash, upload is fine by me) I guess in the future lyrics can just be added to my ripping/uploaded process.


You know... I can't believe I didn't think of that... Mike? You around?

Don't bother detecting FF/REW. You're constantly playing catchup and as soon as someone decides to FF through 5 tracks at once, the game is over - the empeg grinds to a halt. It's even worse with RWD (I can kill emphatic..) It's probably better to watch the notify information to discover when the track changes, and to be a little late with the lyrics for the songs that have 'instant' lyrics. (How do you detect when the track changes usually?).

Okay, first, you didn't answer any of my other questions regarding ReserveCache... I think that might be your problem. Do you mean SKIP 5 tracks at once or FFWD through 5 tracks at once? Who fast forwards through 5 tracks? If you want to skip 5 tracks, you use the track skip, no?

Second, I AM using /proc/empeg_notify to detect track changes, and to tell track times. I'm only trapping the left/right buttons to detect rewinds and fast forwards. But I can't simply look at track times to know whether the user has fast-forwarded or rewound, I need to know that there's been an event (rewind/ff) and I need to re-calculate what line of the song I'm on, and when the next one is coming up.

These decisions were made for a reason, you know, I didn't just throw this thing together...

For what it's worth, this works fine on my player, and I've received no comments that peoples' players are grinding to a halt. Things *are* a little sluggish during the first few seconds of a track when it first tries to read the lyrics out of the ID3 tag, and as I've said, I'm going to look into an alternate ID3 library. But even with that, I'm not having any kind of behavior where my empeg grinds to a halt, and if I am, it has nothing to do with the fact that I'm trapping the left/right buttons.

Folks, if you're seeing the same behavior, with your empeg grinding to a halt, please share your experience. And if you don't mind, check the value of ReserveCache in your config.ini (if present) and try again after adding ReserveCache=32 or ReserveCache=64. I'd like to know more about this supposed "grinding to a halt."

Did everyone know about the Lyrics3 editor for Windows? It works fine for me and seems to put the lyric information right into the MP3 file no command line utility needed. I couldn't find Lyrics3 in the search.. so please no duhs..

It uses an awful specification called, oddly, Lyrics3, which is, at the risk of being redundant, awful. It doesn't put them in the much nicer SYLT form.

oh I see.. it does allow you to export to LRC files though and it's a very nice editor. That does explains why I was having so much trouble getting empathic to work last night. Eventually when I put notify=1 and used the command line to apply the LRC file to the mp3 it worked.

Incidentally, rumor has it that id3lib actually will read Lyrics3 tag and report it back to my software when I go to get the SYLT tag. I haven't verified this, nor will I bother to. But for the truly lazy who don't care about messing up playback of their MP3's (I assume that's nobody) it's been told to me that Lyrics3 tags are supported by my program as well. That's not guaranteed for the future, especially if I decide to ditch id3lib in favor of another ID3 tag library.

I'm almost hesitant to mention this, but someone will try it and figure it out eventually anyway.

EDIT: DELETED...Everyone should have a second chance at perfection.

Damn, it.

Edit: Fixed.

Oh, how the mighty have fallen! Say it ain't so!

Guess what? There is indeed a program out there that writes synchronized lyrics using the ID3V2 SYLT frames. It was right under my nose the whole time. Which program, you may ask? Why Windows Media Player 9, of course. I never noticed what features it had because I try not to open it. It's a bigger piece of bloat than WinAmp 3, even.


Either way, it's got an Advanced Tag Editor, which, among other things, lets you add lyrics to a file. It can add unsynchronized lyrics using whatever that unsynchronized lyrics frame is. Plus, it's got a very unintuitive, complicated interface for taking those lyrics and synchronizing them to time points.


It definitely uses the SYLT frame, as I can verify in MP3/Tag Studio. But, it's files don't work in emphatic. And, files I've processed using lrc2sylt don't work in WMP. So, even though they're both using the same frame, someone's not doing it right.


Tony, any chance that lrc2sylt is writing the frame in some broken way that emphatic is also broken to expect? Or does your use of id3lib pretty much preclude that possibility? If so, I guess it comes down to either id3lib being broken, or Microsoft. It's too bad there's so little software using this spec, so that it would be easier to test for interoperability.


Here's an interesting observation: If I save the SYLT frames as raw data to a file (using that handy new feature of MP3/Tag Studio 3.05), the Microsoft one has the first byte as $01, meaning Unicode, and appears to be structured as such. The lrc2sylt file is $00 (not Unicode). Does emphatic (or id3lib) not handle Unicode? That wouldn't explain why WMP couldn't handle the non-unicode file...


Any thoughts?

Interesting observations. I do have WMP9 installed on my system. Where's the tag editor? I looked into it because when I googled for synchronized lyrics, WMP9 came up... But I couldn't find the thing. There was some 3rd party plugin tag editor that they told me only worked on Windows XP, and since I'm on 2K, I gave up on trying to track it down. Is there a tag editor built into it? I'm using the "compact" skin so maybe they're hiding it from me?

Umm, as for who's following the spec... Microsoft's record speaks for itself in that regard. Actually I bet it is just the text encoding that is different. I was trying to avoid dealing with things like unicode. If the WMP interface for adding time tags to lyrics is that unintuitive, then I won't bother with it. But I'll check it out... I guess.

ID3lib DOES handle unicode. My program is writting the data itself properly. But lrc2sylt is not using unicode text encoding in the data itself. So if it's just a matter of lrc2sylt and WMP9 using different text encodings, then we're both following the spec, yet still incompatible because we're using the frame differently. Or in other words, the great thing about standards is that there are so many to choose from.

I was having so much trouble getting empathic to work last night.

I didn't know anyone wrote empathic yet... isn't that the app that automatically picks a playlist to match your mood?

Well I was beginning to think emphatic only worked if I was in the right mood....

I didn't know anyone wrote empathic yet... isn't that the app that automatically picks a playlist to match your mood?

LOL. Yeah I could implement it the way the Office Assistant window works in Windows... You select a Marvin Gaye tune followed by a Sade tune and it pops up a little dialog:

"It looks like you're trying to get laid tonight!"
What should I do?
(a) build a playlist of your favorite "in the mood" songs
(b) start GPSapp to guide you to the nearest unpopulated parking lot
(c) dim the display so you won't disturb your neighbors in the next car
(d) nevermind, I'm not trying to get laid, the wife is in control of the music selection tonight

An interesting concept...