If that program is as sleak as it looks, I'd at least contribute a few albums if not simply for the wow factor.

/me considers the possibility of transcribing the entire Rush catalog...

And hell, if it was good enough maybe we could get Drakino to put in on Riocar

Well.. This might be something we might want to keep on the down low... Once a lyrics archive gets to a certain size, it's going to start attracting C&D (ceast and desist) letters. Even small to medium-sized lyrics sites occasionally get hit with them. If we do set something up, I think we should be careful about how much we publicize it.

Having said that... Tom, if you're listening, would you be willing to host it on the riocar.org server?

what we should do, is if tom is willing to do it, setup a secure members only database that only forum members can login to. Now that would be T&A

-oliver

Humm, I didn't know that sites got slammed with Cease and Desist letters for lyrics sites. I guess that would be somewhat obvious if you don't have permission from the owner of the copyright.

Kinda sad really.

He has a point about RIAA people getting on our case for posting lyrics. Last thing we want is "that" kind of attention.

And having to be a board-member to get to the site will NOT stop RIAA people from logging in, it just adds an extra step. And also doesn't protect the site owner from prosecution when they do get in.

And having to be a board-member to get to the site will NOT stop RIAA people from logging in, it just adds an extra step. And also doesn't protect the site owner from prosecution when they do get in.

Well really they don't waste the lawyer fees unless you refuse to "cease and desist." The negative attention isn't really going to kill the community, it'd just force us to take down the site. Really, if it was restricted to members, I'd be comfortable with it. Even if it was my ass on the line. Seriously, they just don't go after you as long as you do their bidding once they find it.

I think if it was restricted to members, they would have a tough time finding it.

Hi!!

Finally came from work.. No internet connection at work ;-( so bad... Good to see all your replies!!

OK, here are a few answers to your questions:

Well, you're using a pretty big font

Yes, Medium font of vfdlib. I tried small, but characters are kind of malformed, so harder to read. There's a gain of speed, but it's negligeable....(text is more longer (time) on the display, but it's harder to read) The skip-2,3 or 4 pixels is currently in use and helps keep the lyrics in sync...



are you switching the scheduling policy to SCHED_RR

Sorry, don't know what it does.. could you explain what and how ;-)



full-screen mode which would scroll the lyrics vertically

Yep, that would be cool too, but "phrases" of majority of my already tagged songs are too wide to be displayed completly on the display. Thats mainly why I choosed horizontal scrooling.


...I realized that Hijack's menu binding system was getting in the way a little bit.

I face this problem too. I will allow left and right buttons, but all other will quit. I think it's the best I can do with my knowledge right now.



[00:37]but in the end it's right.
[00:39]I hope you had the time of your life.

[00:52]So take the photographs

that gap between :39 and :52 there is a solo (...) Is this going to be a problem?

No...
When I tag my lyrics, I set the time of the "empty" line to the beginning of the solo. The viewer, when it reads lyrics, fills that line with a number of spaces proportionnal to the lenght of the "solo". That is working pretty well.



I don't mean to be a naysayer, but the program you linked to, Lyrics 1.22, doesn't look like it uses the official lyrics tags, as you claim, but the crufty Lyrics3 spec.


Here comes the worst part....(maybe not)

OK, My program uses ONE of the MANY ways of adding synched text to a mp3 From what I know now, I guess it's called id3v2 lyrics3 v2.0. The main reason I choosed this standard is the ease of use of the winamp plugin used to sync the lyrics (just click when it is sang), and the ability to find documentation and it looked like official. But the more I dug into it, the more I saw there was no clear standard.

From what I can understand of id3v2 SYTL (Synched Lyrics or Text... is that right??) they are directly kind of "between" audio frames? Am I right? Is there any easy way to find which frame the player is? The way I sync with the player now is to watch the /proc/empeg_notify (By the way, could somebody confirm that this file is in the RAM of the player, and not anywhere on a HDD???). The viewer would have to include some sort of mp3 decoding library, which my current knowledge of C prevent using... Way too much complicated. And if the lyrics are "interlaced" in the frames, one would have ot read through the entire mp3 to find all the lyrics.

The way lyrics3 work is by placing creating news tags with "undefined" lenght just before id3 tags at the end of the mp3. Lyrics there are a lot easier to retreive.

The good (or maybe less bad) point now: The hardest part of the program is actually to display them. The "retreive" part of the code is actually quite small. There could be addition to the viewer to detect other types of synched lyrics if it doesn't find the first type. As long as the lyrics are passed in a " [00:01] Hello!! " format to the scroller part, everybody could be happy.


if it's lyrics3, those files aren't coming anywhere near my empeg

Is there any reason I should know not using this format (destroys mp3 by corrupting...) I've used them since 2 years know and had no problems...




Concerning lyrics database:

Just an idea: if website hosting isn't a good idea, maybe kazaalite or any file sharing could be used to shared lrc files. (which are by the way, the same format that is used by lyrics viewer, but simply saved into a separate file instead of in the mp3 itself). Using a special filename (beggining always with LFEGWLV (Lyrics For Empeg Guys With Lyrics Viewer, then with artist - title........ something like that...) it could be easier to search, and less complicated to maintain...

just my 2 cents on that...



So, back to coding..... I just learned today I would work Wed, Fri, Sat, Sun, Mon, Tues, Fri, Sat, Sun, 12 hours each day, so 0.1 release date could be a little later than first expected... Will keep you informed


Thanks for all good comments... I knew such a news would create reaction ;-)

Patrick

Ok, we could have a opt-in for only board members. And have the signup page pretty hidden so its very hard to find. I think that should by us a good year plus! It would also be a good idea to completely delete this thread in the bbs, so google doesn't pick up on it.

Lyrics3 is about as advanced a specification as ID3v1 was. It's a horrible kludge, and it's about the worst possible way to do it. (Okay, it's a little better than ID3v1 was. At least it didn't utilize fixed-length fields.)

The reason we don't like them is because they technically corrupt the mp3 files. As far as a decoder is concerned, it's trash at the end of the file, just like an ID3v1 tag is. While ID3v1 tags became a de facto standard and decoders learned to ignore them, Lyrics3 did not, and decoders did not learn to ignore them. If you're lucky, the decoder will throw it away as trash. If not, you might have the pleasure of squeaks and squawks. If you're terribly unlucky, you might end up blowing your speakers due to those squeaks.

ID3v2 avoids these problems by making itself look like an mp3 frame (or making sure it doesn't look like an mp3 frame -- I forget). Anyway, while the specification states that ID3v2 tags can appear anywhere in an mp3 file, in practice, they only ever appear at the beginning of the file, possibly following a VBR header.

However, if you want to implement the ID3v2 SYLT spec instead of (or in addition to) Lyrics3 (which, BTW, is not an ID3 spec), there exists a library you can use (id3lib), so you won't have to worry about all of that stuff.

Oh, and the Linux kernel dynamically generates all the stuff in /proc. It's not on the hard drive anywhere. Some of it can actually be written to in order to tweak parameters.

Sorry, don't know what it does.. could you explain what and how ;-)

On Linux (and most other UNIXes), processes have a scheduling policy and a scheduling priority. The policy determines what algorithm is used for choosing which processes to cycle between, and the priority determines within those policies, which ones are more important.

On the empeg, the player is generally (by default) the only process that runs using what's called realtime scheduling (SCHED_RR is one of the two available realtime scheduling policies.) This means that, for all intents and purposes, user apps get a tiny share of CPU, and they get it whenever the player or other apps which are using realtime scheduling feel like giving it up. (Sorta, it's a little more complicated than that on the micro level.)

So by default, programs use SCHED_OTHER, which is the non-realtime scheduler. To change the scheduling policy to realtime, you do the following in your program. The following is lifted directly from my emptriv source, so it might not look exactly like yours. You might not be forking off a new process to start off with, for instance, if you're not, take the if fork()... stuff out. Also, checkRC is just a macro which checks the return value of these calls (>0 is error.) Substitute in your own error checking.

// include section

#include <sched.h>



// define the process priority

#define PRIORITY 30



// variable declarations

struct sched_param  sched_param;

int old_policy;

int iPid;



// early on in your int main(), do the following:

  if ( fork( ) != 0 ) // Fork off the process, if parent, return

    return 0;

  else

  {

    iPid = getpid();



    old_policy = sched_getscheduler( iPid );

    rc  = sched_getparam(iPid, &sched_param);

    checkRC("sched_getparam()\n", rc);

    sched_param.sched_priority = PRIORITY;



    rc = sched_setscheduler(iPid, SCHED_RR, &sched_param);

    checkRC("sched_setscheduler()\n", rc);

    rc = sched_setparam(iPid, &sched_param);

    checkRC("sched_setparam()\n", rc);

   }

// continue on with your program

.

Basically what the above does is set the priority and scheduling policy of your process. I think if you add this code to your program, you'll definitely notice it's more responsive. You should be able to scroll a little faster, and get a slice of CPU more than every 20 ms. Give it a shot, or give me your source code so I can do it.

Oh, of course, the big problem with SYLT is that, AFAIK, there are no editors for it, so we'd have to write one ourselves. But it shouldn't be too hard to do. We could also write a translator for existing Lyrics3 tags.

From what I can understand of id3v2 SYTL (Synched Lyrics or Text... is that right??) they are directly kind of "between" audio frames? Am I right? Is there any easy way to find which frame the player is? The way I sync with the player now is to watch the /proc/empeg_notify (By the way, could somebody confirm that this file is in the RAM of the player, and not anywhere on a HDD???). The viewer would have to include some sort of mp3 decoding library, which my current knowledge of C prevent using... Way too much complicated. And if the lyrics are "interlaced" in the frames, one would have ot read through the entire mp3 to find all the lyrics.

As Bitt says above, we don't care where the SYLT frames are, they can appear anywhere. id3lib handles most of the mechanics of reading/writing ID3 frames, including the SYLT frame (though you need to format the timestamps and lines of text in a pretty strict way.)

Once you release your program with source, I'll be happy to give ID3v2 SYLT a shot. I made a bit of progress several months ago. Thing is, we need to do both reading and writing, because I've never found a tagger that's implementing SYLT frame writing, except in raw form, where you need to encode the timestamps and headers yourself anyway.

I realize why you chose the tag format you did, and that format is perfectly fine for testing it out and getting it running. But there are a lot of audiophiles around here (obviously!) who aren't going to want gaps in between our songs (which these tags create.) I think ID3v2 SYLT frame support would give this already awesome program a much wider audience.

If you want to make your source available now, I have some free time in the next week or two before my classwork gets really heavy... Don't worry about it being ugly or half-working, you haven't seen ugly, unfinished code until you've seen my emptriv or empwake code. If your program is in any working condition, I think a few hackers around here would love the chance to contribute.

I don't think a lyrics viewer qualifies for real-time scheduling on the Empeg.

Remember, if EVERYTHING ends up in real-time classes, then there effectively will be no real-time scheduling, and the player will "skip" every now and then.

Cheers

I don't think a lyrics viewer qualifies for real-time scheduling on the Empeg.

Remember, if EVERYTHING ends up in real-time classes, then there effectively will be no real-time scheduling, and the player will "skip" every now and then.


Well, I haven't seen the update speed except in the blurry video above, but the player REALLY starves user apps on occasion. I've had Emptriv's priority bumped up pretty high and have never had skips. Something like this might not need a high priority, but if it's updating the screen in the ~20ms neighborhood, I thought it might benefit from realtime scheduling at a low priority.

But you're the expert. I'm just recanting my experiences with emptriv, which was using some much less efficient graphics routines.

Hi again!

A week ago, I though erasing completly the program because it was a mess. I kept coding on it last week and finally got it to work. Now you'll see why I tough about trashing it... Functionnaly, it's not so bad, but what a mess of C code.... I think there's a contest for the most obscure C program somewhere... I should provide my program as contestant ;-)

So here it is: Lyrics_ Viewer Pre-beta 0.1 ;-)

Just ftp somehwere on the HDD, chomd755 it, then include in config.ini and bingo...

To quit, please use Knob Press then press cancel to quit hijack menu..... don't go back to hijack menu (Knob Press Long) while you see lyrics viewer or you'll have to reboot

Don't FF or REW in a track... viewer will be all mixed up... If it does, simply skip track and come back to previous and it will do the trick



Coders: Be advised...Serial port was used for extensive debugging.... You can see the usleep() delays there : REAL is what the lyrics needed,
ADJ is the offset from real time
SLEEP is the real sleep time that was needed to keep up.. if it gets to 1, it means that lyrics can't keep up with the song...
MEASURED: is what a measered value of usec (with timers functions)
MOV is the numbers of pixels shifted each program scan... eventually gets higher if SLEEP is 1 for too long



Todo list:

- Real id3v2 SYLT support (BTW, I looked at id3lib doc.... whew too much for me ;-) and can I include C++ lib in a C prog?
- Not enough comments in the code (
- Handle buttons more gracefully
- Pause, FF and REW support...
- Improve Sleep coding (don't seems to catch up easily if lyrics get late for whatever reason)



You've been warned: Not for public use; just for your own drooling ;-)



Enjoy!!!!!!!! (as much as I did when it first scrolled!!!!)

Patrick

right on, im going to test it tonite, about the website i can also host it here at my house and password protect it. I already did the whole Wezzer - Pinkerton album with the lyrics if anyone is interested. If you want to do the php programming please contact me at [email protected] so we can cordinate ideas about how we want it to work, and ill build up a flow diagram so we know we are on the same page.

The way I sync with the player now is to watch the /proc/empeg_notify (By the way, could somebody confirm that this file is in the RAM of the player, and not anywhere on a HDD???).

I'm no expert on empeg programming, but I think I understand vaguely how this works.

Normally, if you put [output] notify=1 into the config.ini file, the music player application will squirt FID data out on the serial port.

/proc/empeg_notify, if I understand it correctly, is a Hijack-only feature. Hijack intercepts the player's calls to the serial port and stores them in a memory buffer, then exposes this buffer to the filesystem as a file called /proc/empeg_notify.

So technically, yes, I think that file is only in the RAM of the player, and not actually anywhere on the hard disk. It's also only going to be available if you're using Hijack and if notify=1 is entered into your config.ini.

....So you can't believe it! You get the EOL2001 with illuminated buttons, the kernels, the logos, the fascia, the java, the lenses AND the optical interface AND THE FULLY VENTILATED SNEEZE-THROUGH WIND VENTS!

A 2000 dollar value ALL for just $699!! WE MUST BE CRAAAAAZY!!!

BUT WAIT!! That's Not ALL!!!

IF YOU ACT NOW, we'll throw in a Lyrics Viewer -- A 14,000 DOLLAR VALUE!! -- FOR FREEEE!!!

ACT NOW! DIAL 1-800-EXPLODE-MY-HEAD! YES, DIAL 1-800-EXPLODE-MY-HEAD!!!

Hmmm... Interesting situation regarding copyrights and a lyric database; the addition of the timing parameters could qualify the lyrics as a new work of art in their own right - and the fact that it would not be used as any kind of competition to anything that the music company publishes would also reinforce that.

As a non-perfect analogy, consider a phone book. You're not allowed to go through the Yellow Pages and copy it number for number, page for page, and then sell the resulting 'Green' Pages as your own creation. But you're perfectly entitled to recreate the works from scratch.

Another (perhaps better) analogy would be CDDB. Created from scratch, it contains a superset of the track listing that appears on the album cover. This would not be far different.

Yet another way to look at it - if you've legally bought that album, or anything containing the lyrics, you'd have the right to make a backup copy of the lyrics and to use any method you saw fit to backup and display those lyrics. And current copyright law gives you leeway to share that with friends - and I certainly count myself amongst friends here.

That all being said, you would definitely want to limit access and keep it hushed. If it got to a C&D letter stage, you'd have to comply - it'd just be too much hassle (and money) to try and defend a court case, and we know that the RIAA have deep pockets when it comes to lawyers.

Another reason to keep it hushed and protected - if it ever got well populated, then eventually through a friend of a friend of a brother of a wife of someone on this board (or something like that...), it's existence would probably end up being posted on a slow news day at Slashdot.

the addition of the timing parameters could qualify the lyrics as a new work of art in their own right - and the fact that it would not be used as any kind of competition...

A wonderful line of if/then reasoning and self-justification... but it's fantasy and wouldn't stand up in court.

I'm currently in the process of recoding all of my CD's in OGG and MP3 format, so I think I'll start adding synced lyrics fo them.

This really is *too* cool. I was actually thinking a few months ago just how cool this would be....

You say you'll add synched lyrics to Ogg...I just googled for a minute on "Ogg+lyrics" and came up empty, more or less. Are you actually doing this already? Any pointers?

Sweetness! Working well for me so far. Of course there are a couple bugs to work out, but your scrolling code is pretty damn smart about things. The right words were almost always on the screen in the couple files I tried out, and any errors were probably the result of poor time-tagging in the LRC file.

By the way, I don't think it's spaghetti code at all, I'm not having too many problems following the overall logic... Great stuff!

ROTFL.

It's about that time of night though

Can I get a Bowie Knife thrown in too?

Certainly, it would have been even harder to follow if I kept my first idea and coded in French, as it's my native language (and mabye not yours ;-) The few times I coded in French, variable name ended so long it was a pain to remember all their name... That's what got me code in English.. and also the though that you might like to look to the code;-)

Happy the program works for you.... should do because it did "fail" only with a few rapid songs when I can't even say all the words myself ;-) and fail is a large word.. lyrics were simply late...

Once 'we' get the 'correct' lyric tags working, would be it useful to page Magnus Brading? He seems to be fairly responsive to empeggers' needs.

That'd be fun to have a lyric editor in MP3 Tag Studio.

That is really cool! Great Job!

i haven't tested this yet, but have you tried to use a lyric tag thats longer than 255 characters? a while back, i encoutered a limitation w/ the comment field being expressed w/ 2 bytes... probably the same w/ all other fields.

Emplode keeps crashing for me when i try and replace a tune with a copy with lyrics tags. I'm using the version of the winamp plugin you linked to. Is there anything i'm missing?

The error i get is
An established connection was aborted by the software in your host machine (error 0x80072745)