I am pleased to announce the release of emphatic v1.0, a lyrics viewer for your empeg. This program was based on elperepat's previous work, and I would like to again thank him for sharing his source with the community. I hope that I have improved on his work, and I hope you all enjoy the fruits of my labor.

Please read the README which is on my website and included in the archive for instructions on installation, etc. It should be straight-forward, providing you know how to use FTP and how to edit your config.ini to execute the program on startup.

I've also included a utility for tagging your MP3's with lyrics from LRC files. For Windows users, this is apparently the only game in town for adding lyrics in SYLT format. For *X users, I suggest using an XMMS plugin called SingIt which seems to write lyrics in ID3v2 SYLT format. Unix fans will take great amusement from the fact that they get a nice, pretty GUI to add lyrics in one step, while Windows users have to use a command-line utility, at least for the second step. I suggest that until someone writes a WinAMP plugin to do it, Windows users use one of the existing plugins which can write LRC format lyrics, and then use my utility to import those. Details are in the README file.

Anyway, head over to my empeg page at http://empeg.webhop.net/ and give it a whirl. Enjoy!

BRAVO!!

Great success!! Works like a charm! Just got my first real id3v2 SYLT mp3 on my empeg (guess which? The Old Black Rum, of course ;-), and it's scrolling!

Vertical scrolling is also a great addition!

Menu is great too!


Wow.. a must have!

Now i just need pass through the code to understand how you did it !!


Thanks a lot for this!

Patrick

Thanks, glad you like it!

Just as I was reading this post I already found the first post-release bug. When it's playing a song with no lyrics, the menu screen comes up blank. Oh well. I'll fix that soon, I suspect most people will just be trying this out for the next few days.

Hi Do you have any instructions for people(me) who dont know what this means:::::::?
" Installation:
Installation should be simple, there's only one file, a binary, which must be put somewhere on your empeg, and then executed when you want to run it.

The first part can be done via FTP. I have included a simple FTP install script which will do this for Windows users. You just need to edit the batch file "install-emphatic.bat" and change 192.168.0.1 to the IP address of your empeg, and edit the FTP install script "install-emphatic.ftp" changing the target directory (/usr/local/bin) to wherever you want the emphatic binary to live. Once that's done, run the batch file, and you should be all set.

After the binary is on your empeg, you can run it from a shell prompt, or add it to your Hijack menu by adding the following line to your config.ini:

;@EXEC /usr/local/bin/emphatic

Substituting /usr/local/bin with the path where you put your binary. That should be all you need."
I"d love to try this but I dont know what most of that means.How do i get this on my player please.

Sorry about that, I guess I expected that the first few people who tried this out would be a little more experienced with program installations. This is the problem with having no easy install mechanism...

Okay. There are two files. One ends with .BAT and one ends with .FTP. The .BAT file has a line which says "cd /usr/local/bin" You need to have a directory somewhere on your empeg where you want this program to live. In my example, that place is /usr/local/bin, but there is no one place on the empeg where everyone's programs live, so I had to have users edit their own script.

The FTP file has an IP address in it, 192.168.0.1. Your empeg's IP address is probably different, so you need to open the FTP file in notepad and change that address to your IP empeg's address. Your IP address is in the "About" menu on the player, a few lines down.

Once you do these two steps, you just need to double-click the install-emphatic.bat file, and it *should* put the program on your player. The thing is, now that it's there, you need a mechanism to run it.

Recent version of the Hijack kernel (I'm assuming you have that installed) have a mechanism for launching programs. That mechanism is to add a line as I mentioned in the readme:

;@EXEC /usr/local/bin/emphatic

This tells Hijack to start up the program when your player starts up. I cannot write an install to automate this part.

Does this help? Or is it more technical jargon? Installing these apps is not an easy task, I tried to make it easy, but I guess I failed.

Hi No it doesnt help me much .That doesnt mean you didnt explain it good it just means i dont understand it.The unzipped folder has 2 files one named lyrics and one named lyrics.c but nothing with .ftp or.bat.Are these connected to the player via the serial cable?I do have Hijack installed so thats a plus!Well its getting late so ill work on this another time .thanks maybe in the meantime someone could translate this into an"Empatic Lyrics Viewer for Dummies" for me/us.

Okay you're right, I'm stupid and forgot to include the batch files.

Fixing soon... Programmers can be "dummies" too!

Edit: v1.01 is up. Fixed the menu redraw bug and added the install stuff. Just goes to show you, don't run version X.0 of anything.

Cool, looking forward to testing it out. Is there a unix command line program or maybe a perl module available that will add the SYLT tags? I am hoping there is something I can get to compile on OS X (and I assume the command line program you include is windows only). XMMS is a bit overkill if all you want to do is add a lyrics tag that somebody else created.

-Mike

Bad assumption on the Windows-only part. I made lrc2sylt available for both Linux and Windows, and include the C source inside the distribution. I don't know enough about OS X to know whether it would compile, but my gut says it probably wouldn't.

There is a Perl module MP3::Tag I believe that might help you out, but because SYLT frames are binary data, it's not as simple as entering timestamps and lyrics.

Let me know how you fare in compiling my utility on OS X. Incidentally, I would caution you against using tags that someone else created though, a lot of the LRC files I've found on the net are pretty dodgy...

<cartman>Schweeet</cartman>

Congrats on creating another program that's motivating me to bring my player up to date. It's serial port has been languishing ever since empacman came out. (Wait, thanks to Mark I don't even need a serial cable, do I? Maybe i'll download the new jemplode and feel really up to date.

Matthew

I'm getting ready to try it now (excitement mounts!).

But it appears the lrc2sylt binary is only a Linux one, no .exe... guess I'll use it on Linux for now (don't have a Windows compiler installed).

[amigo@goofy temp]$ file lrc2sylt
lrc2sylt: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped

Um, download the "Windows support" ZIP file on my page. I distribute the Win32 utils as a separate file to reduce the size of the Linux archive... Was that a bad idea? : )

But it appears the lrc2sylt binary is only a Linux one, no .exe...

The windows .exe version is a separate download from his site.

Jinx!

I tried running it on my Linux box, but I didn't have id3lib. I just downloaded it, but it doesn't compiile for me:

frame_impl.h:76: instantiated from here
In file included from frame.cpp:34:
../include/id3/id3lib_bitset:791: `__STL_THROW' undeclared (first use this function)
../include/id3/id3lib_bitset:791: (Each undeclared identifier is reported only once
../include/id3/id3lib_bitset:791: for each function it appears in.)
../include/id3/id3lib_bitset: In method `bool bitset<24,long unsigned int>::_Unchecked_test<24, long unsigned int>(unsigned int) const':
../include/id3/id3lib_bitset:793: instantiated from `bitset<24,long unsigned int>::test<24, long unsigned int>(unsigned int) const'

I guess I'll have to wait until tomorrow to try lyrics as I don't yet have any tagged songs. I'd run XMMS, but my Linux box is just a file server, no X libs.

Eeep. Compiling ID3lib is yucky. If you want me to attach an ID3lib .so for x86 Linux I can do that.

Damn you, you're even stealing my thunder in my own thread! Get out of here!

For some reason I can't get this to work. I mean, it runs, but it doesn't display the lyrics, and I've tagged it with the windows program and reupdated it on my empeg. Can someone link to an mp3 that actually works with this program? Or try this one out : http://bertrand.servemp3.com/mp3/brown.mp3

Maybe tomorrow I'll practice on my reading skills

Checking it out now.. You're my first guinea pig for the Windows utility -- I built it and tested it with the id3info program, but never did actually send one of those MP3's over to my Empeg. Though if id3info says it's valid, I can't see why it wouldn't be valid...

Works for me...



You did select "emphatic" from the Hijack menu, didn't you? Sorry if you did, but it's my duty to ask...

Windows utility worked great for me, too!

My head has officially exploded, I'm now looking at "It's the End of the World as We Know It" scrolling by on my player. WOOOOOOOT!!!!

Now, I did do one particular thing which was: I made sure the file had a valid, good ID3V2 tag before running the Windows utility to merge the text file with the MP3.

Will the Windows utiliy add a V2 tag if one doesn't exist?

Bad assumption on the Windows-only part. I made lrc2sylt available for both Linux and Windows

Ahh, sweet. I should know better than to assume. Unfortunately I am getting link errors tryiing to link it against id3lib. I think I just need to figure out how to add the libraries id3lib installed to my linker path. Never had to do that for anything before. Gonna have to wait till tomorrow to do that unless someone has a quick tip. Don't you just need an environment variable name LD_LIBRARY or something like that?

-Mike

Will the Windows utiliy add a V2 tag if one doesn't exist?

Wow, I'm really not sure because none of my MP3's are without ID3v2 tags. The details of what it does to add that frame are kinda hidden behind id3lib API's. Would be interesting to find out, though...

Um, if you did id3lib installation then it should have put them in /usr/local/lib by default. It's LD_LIBRARY_PATH. Add /usr/local/lib to that and see if that helps you out.

Edit: I'm truly earning my forum rank tonight...

Tony, I have had tried multiple times to add SYLT format lyrics to multiple MP3's in WinXP.

I first tried with a LRC file from the internet. Nothing. I also tired by adding the lyrics into WinAmp Lyrics like you recommended, then clicking to add the time codes. Exported to LRC and again tried running lrc2sylt. Each file I tried I got the same results, the empty menu which you have discovered. Using my tag editor (Dr. Tag) in the other tab, it shows that there is SYLT added to the tag, however I cannot see what it contains. So I believe the SYLT lyrics are being added to the MP3's, but after uploading them to my empeg, and playing them with emphatic running, they are not showing up. Any ideas?

First, I fixed the empty menu thing in v1.01. But if you're getting that in 1.0, then it doesn't like your MP3 or the tags for some reason. Can you send me a short example MP3? my email addy is in my sig.

Um, if you did id3lib installation then it should have put them in /usr/local/lib by default. It's LD_LIBRARY_PATH. Add /usr/local/lib to that and see if that helps you out.

Huh, I tried that (and DYLD_LIBRARY_PATH which I think may be needed for OS X) and it didn't seem to make any difference. I definitely have id3lib installed in that location (I just compiled and installed it) but I am still getting the error below. Anything else I could be missing?

gcc lrc2sylt.c
ld: Undefined symbols:
_ID3Field_SetASCII
_ID3Field_SetBINARY
_ID3Field_SetINT
_ID3Field_Size
_ID3Frame_GetField
_ID3Frame_NewID
_ID3Tag_AddFrame
_ID3Tag_FindFrameWithID
_ID3Tag_Link
_ID3Tag_New
_ID3Tag_RemoveFrame
_ID3Tag_Update

gcc -lid3 -lz lrc2sylt.c

You need -lid3 and -lz. ID3lib has a dependency on ZLib (libz.so) if you don't already have that...

Hmm I guess I misspoke about XMMS. The XMMS plugin READS SYLT tags, but doesn't WRITE them.

Looks like my utilities are the only game in town.. for now... (*hint* *hint* to any budding WinAMP plugin developers out there...)

Really quick, I downloaded bertrandom's Brown Eyed Girl, and couldn't get that to show up. So there is something some of us are doing wrong.

Emphatic does show up on the hijack menu, I did chmod 755 the binary. In fact it still says ver 1.00 in 1.01...

So I have it running. I installed it in /drive0/var/emphatic.

Well it did say 1.00 in 1.01 for about 3 minutes, which must have been the 3 minutes you downloaded 1.01 during..

I don't know what you could be doing wrong... Not passing any arguments in are you? You get the menu to pop up, right? Have you tried to switch fonts or display modes?


Edit: No, I'm an idiot, it still says 1.00. Fixing... Fixed.

I put the emphatic file in /usr and I added the line ;@EXEC /usr/emphatic to the end of my config.ini show emphatic show up in the hijack menu or do I need to do something else.

And thanks to both of you guys for making this.

Once you reboot I think that should work. If not, take a look at your serial console output and look for any error messages...

If you didn't use my script, then you also need to make the file executable with:


chmod 755 /usr/emphatic

from a shell prompt

I'm not passing any arguments in my call in the config.ini. I have tried it both with and without the ;@DC before ;@EXEC /drive0/var/emphatic/emphatic. I get the menu to pop up now with v1.01, It shows me switching fonts, and display modes. But no text. Hijack v309 installed. Anything else special I should have installed?

I added the line ;@EXEC /usr/emphatic to the end of my config.ini

Point of precision: It needs to specifically be in the [hijack] section of config.ini, not at the end of the config.ini (unless the hijack section happens to be at the end of your config.ini).

Nah, that should work... Argh. Are you able to run the program from a shell prompt so I can see any kind of error messages that come out on the console?

Edit: Just thought of something. emphatic depends on /proc/empeg_notify being available. Can you check your config.ini to see if the following is in it:

[output]
notify=1

Anything else special I should have installed?

You did replace the tune on the player with the lyric-tagged version, right? And you don't have more than one copy of the same tune on the player (one lyric-tagged and one not)?

And doesn't notify=1 have to be on in order for this to work?

I couldn't get the script to work so I just uploaded the file. I tried setting the permissions to 755 but it still doesn't show up.


here's the log I don't see anything that sounds like it would be related to this but I am an expert by no means.


empeg-car bootstrap v1.02 20001106 ([email protected])
If there is anyone present who wants to upgrade the flash, let them speak now,
or forever hold their peace...it seems not. Let fly the Penguins of Linux!

e000 v1.04
Copying kernel...
Calling linux kernel...
Uncompressing Linux..................................... done, booting the kerne
l.
Linux version 2.2.17-rmk5-np17-empeg52-hijack-v312 (root@ibbm) (gcc version 2.95
.3 20010315 (release)) #2 Tue Feb 4 20:03:25 EST 2003
Processor: Intel StrongARM-1100 revisi
NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
empeg-car player (hardware revision 9, serial number 10101230)
Command line: mem=16m
Calibrating delay loop... 207.67 BogoMIPS
Memory: 14996k/16M available (992k code, 20k reserved, 372k data, 4k init)
Dentry hash table entries: 2048 (order 2, 16k)
Buffer cache hash table entries: 16384 (order 4, 64k)
Page cache hash table entries: 4096 (order 2, 16k)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea Universit
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 16384 bhash 16384)
IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
IrCOMM protocol (Dag Brattli)
Starting kswapd v 1.5
SA1100 serial driver version 4.27 with no serial options enabled
ttyS00 at 0xf8010000 (irq = 15) is a SA1100 UART
ttyS01 at 0xf8050000 (irq = 17) is a SA1100 UART
ttyS02 at 0xf8030000 (irq = 16) is a SA1100 UART
Signature is 20706d65 'emp '
Found custom animation at offset 0x99b78
empeg display initi
empeg dsp audio initialised
empeg dsp mixer initialised
empeg dsp initialised
empeg audio-in initialised, CS4231A revision a0
empeg remote control/panel button initialised.
empeg usb initialised, PDIUSBD12 id 1012
empeg state support initialised 0089/88c1 (save to d0005180).
empeg RDS driver initialised
empeg power-pic driver initialised (first boot)
RAM disk driver initialized: 16 RAM disks of 4096K size
empeg single channel IDE
Probing primary interface...
hda: IBM-DJSA-220, ATA DISK drive
ide0 at 0x000-0x007,0
hda: IBM-DJSA-220, 19077MB w/1874kB Cache, CHS=38760/16/63
empeg-flash driver initialized
smc chip id/revision 0x3349
smc9194.c:v0.12 03/06/96 by Erik Stahlman ([email protected])

SMC9194: SMC91C94(r:9) at 0x4008000 IRQ:7 INTF:TP MEM:6144b MAC 00:02:d7:22:04:c
e
Partition check:
hda: hda1 < hda5 hda6 > hda2 hda3 hda4
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 320 blocks [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.03 (19980601)
Press Ctrl-A to enter pump...hange_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 4k initempeg init 0.8
I see this is a developer image!
Mounting proc
Mounting first music partition
Tried to mount /dev/hda4 as reiserfs but got error 19
Mounting second music partition
Tried to mount /dev/hdc4 but got error 6
Error mounting partitions (possibly already mounted)
Remounting first music partition read-only
Remounting second music partition read-only
No secondary hard disk
Press 'q' now to go into development mode. You Have Zero Seconds To CompìStartin
g player

khttpd: listening on port 80
kftpd: listening on port 21
player.cpp : 385:empeg-car 2.00-beta13 2002/07/24.
Prolux 4 empeg car - 2.1434 Jul 24 2002
Vcb: 0x4086d000

emphatic prints a bunch of stuff on startup so I don't think it's being executed. Check the post by "Evil Tony" above.. Make sure the @EXEC line is in the [hijack] section of config.ini. Also, your Hijack kernel needs to be recent, the ;@EXEC stuff is new.

This stuff is all great material for an emphatic FAQ.

did you rw before you chmod and ro after?

That was it. I didn't know there was a hijack section oops.

Thanks

Now I need to figure out how to add the lyrics.

Yup that was it... I didn't have the notify=1 in my config.ini. Works great now! Good work!

Cool, I bet that's the problem with bertrandom too. I'll have to include this stuff in the README. Thanks for your patience in debugging my documentation, guys.

Sleepy time for me tonight... Hope everyone has better luck installing now that these common problems have been identified.

as im too lazy to repost, see here (url should work), yn0t_

Wow.. talk about support. Yup, it was the notify=1 for me, awesome program. Now I've just got to sit here and tag lyrics all day, we really need to get that lyrics database up and running. By the way, is there any way to get rid of the | character before the lyrics in that sample mp3 I linked to when viewing it in vertical mode?

COOL!, im still working on the lyrics site, so dont toss your lyrics keep them so we can get them posted. I would expect it to be almost done in a week or so, ive been kinda busy with real job.

Hmm.. the | character is actually a feature. I wanted to be able to tell when two or more lines on the screen were part of a single line of lyrics. So when that happens, there's a solid bar connecting them. I can add an option to turn that off for the next release.

Actually that URL isn't working for me...

But I think I figured out what post you were trying to link to... You're not seeing lyrics? Can you make sure that

[output]
notify=1

is in your config.ini? I neglected to mention that.

Glad to hear you're still on top of the lyrics site thing. If possible, make sure there's a mechanism to update or suggest corrections to existing lyrics. Also, in the database, make sure there's a field for "version" or "remix" or something so that a song with a given artist and title can have multiple versions, since there are extended mixes, etc. The lyrics might be the same, but the time tags would be different.

Until that's up, we can all build up our own personal library of tags... But creating them would be a lot easier with a nice WinAMP plugin. Anyone have experience writing one of those?

Because emphatic seems to run well in the background, even when there are no lyrics, I got to thinking that it might be neat to make it more than just a lyrics scroller. I have access to everything in /proc/empeg_notify, which includes the artist, title, genre, track number, etc. Furthermore, since I'm already reading from the ID3v2 tag, I could probably pull out the contents of *ANY* ID3v2 field you have in your MP3's, regardless of whether the player supports it.

I could then theoretically display these in some kind of configurable format, in kind of a special info mode. One of the sections of this could be the lyrics in a horizontal scroll area, but others could be the artist, title, track time, etc. This would almost be like a "skin" which would replace the Track Info screen.

Would anyone find this useful? Is anyone using non-standard ID3v2 fields and would want to view them? This kind of feature would take some time, and I'm not promising anything, but it's something I think might be kinda cool. I've seen posts in the past requesting user-definable fields on the Track Info screen, this might be the next best thing.

Thoughts?

Hmm... I was just about to register lrcdb.com (maybe a few others as well) and get started on coding a site. Since you're already working on a site, I'll be happy to still register the domain and host it, and help out with any coding as well.

What a great idea!

I've got quite a few tracks with stuff in the comments field, just for completeness rather than for any particular use, but it would be cool if we could display this information.

Bryan.

I've always wanted direct access to the id3v2 comments field tag to work around the 255 character limitation when that tag is importeted into the database. There was a thread about it some time ago. I store AMG review in the comment tag which can be quite long, so scrolling vertically through the file by rotating the knob (AboutBox like) would do the trick for me.

Great job you've done on the lyrics viewer btw. Simply awesome.
I think I might have found a bug: Going into standby (key sense) and back, while emphatic is active seems to confuse it a bit. Lyric scrolling is stopped, and the knob is bound to Popup0 again. The attempt to access the hijack menu results in the lyrics showing up, altough the menu seems to be active in the background allowing me to start breakout with a lyric-postered background. Quite cool, actually. Could be a feature.

....uh-oh, you asked for it...

Can you check for embedded cover-art, and then convert that to a 4bpp format and pass it to empan?

I think I might have found a bug: Going into standby (key sense) and back, while emphatic is active seems to confuse it a bit.
...
Quite cool, actually. Could be a feature.

Yeah, that's a feature of Hijack, nothing I can do about that. When mlord is freed up from making docking stations, I have a batch of Hijack improvements I would like to put into his queue, including fixing that particular problem, if possible (it may be a limitation we can't work around, who knows.) There are others that would make emphatic a little more elegant when running in the background, including the ability for user apps to bring up the PopUp0 menu on behalf of the user, and the ability for them to run completely in the background, perhaps updating a section of the display from the background.

For right now, the obvious workaround is to not go into standby, or if you do, first select "close" from the emphatic menu. Then you can go into standby and select it from the Hijack menu when you want it back

Interesting idea with scrolling long comment fields. I currently pass the knob left/right to the player so you can change volume, but I suppose I could let you select a menu option to scroll a particular field... Might take a little more work though.

I did think about doing covert art. Wouldn't be too hard. I wouldn't use empan because empan uses the old GD library. I'd just pan the bitmap around myself inside emphatic using vfdlib. There's an example of this built into emphatic, but it's a bit of an easter egg (not hard to find if you read the source code.)

heh, yeah but to really understand the joke you gotta read the post under the one you found. meh, its a dumb joke anyway.

Oh, the part about your VFD being broken... Sorry 'bout that. Maybe in a future version of emphatic I'll add support for broken VFD's.

heh, yeah. code in a universal fix, so even when im not viewing lyrics it affects it.

thanks

If hijack supports it someday, taking control of the Knob when entering the Scroll mode, and giving it back on exit would be cool. In the meantime you could just let it scroll at a fixed rate or steal the remote's volume buttons.

If hijack supports it someday, taking control of the Knob when entering the Scroll mode, and giving it back on exit would be cool.

I think I can do that, no Hijack improvements necessary. I'm already binding the knob press, knob left, and knob right buttons, and also the front-panel left and right buttons (so I can detect rewinds/fast-forwards.) When I want them to go to the player, I just use the INJECTBUTTONS call and the player acts just as if the user had pressed the buttons with the player active. Quite handy.

So, I'd have to tweak the menu a little, but I could have a menu option to do scrolling, and when that's selected, the left/right buttons would scroll a particular field. Then you'd have to go back and switch out of that mode somehow. Or, yes, I could have other remote buttons do it, but I'm not sure how useful that is unless I then allow user-definiable buttons, which opens up another can of worms...

Really, I think automatic scrolling might be a better solution, at least in the first incarnation. I see the interface for scrolling fields getting ugly, especially if one wants to be able to scroll two different fields.

BTW all of this stuff takes a back seat to getting the program's primary purpose (lyrics scrolling) perfected.

Awesomeness.

Pull out RVA2 tags and use them to adjust volume?

Nice idea! In my opinion, per-song volume adjustment is better than dynamic compression because it preserves the volumes within each song. But a few obstacles come to mind:

1) Getting the info into the tag. Do commonly used rippers/taggers add this info? If not, could I forego the ID3v2 thing altogether and maybe leverage the data Toby uses in the Info:Seek tool somehow? Maybe that's a better approach since it's automatically done by the player anyway? We'd just need to know how to glean the peak volume from his data, if that's possible.

2) Setting the volume. I can send VolUp and VolDown IR codes, but that's yucky. There might be an ioctl() somewhere for me to set it, but I'd have to set it as a percentage of the current volume, or relative to some baseline volume or something... Maybe re-use something that was provided with the volume boost stuff? Not sure if there were userland hooks to that stuff or not.

Otherwise, this might be doable!

Getting the info into the tag. Do commonly used rippers/taggers add this info?

The normalize package will calculate them afterward and add them to tracks. I have no idea if an equivalent exists for Windows.

Of course, this isn't "really" what we want either. Really, we want an ioctl to tweak voladj, and to do true dynamic range compression (or expansion as needed) based on the true intent of the RVA2 tag.

Of course, this isn't "really" what we want either. Really, we want an ioctl to tweak voladj, and to do true dynamic range compression (or expansion as needed) based on the true intent of the RVA2 tag.

Okay. either I'm misled on my definition of "dynamic range compression," I'm not understanding the RVA2 tag's purpose in life, or both.

My definition of "dynamic range compression" is that the amount of volume boost/cut changes as the music changes. This is what voladj does.

The other approach is finding the peak of a given track and normalizing to that peak. Thus, two tracks which each peak at different decibel levels could be normalized such that their peak volumes (not their average volumes) match.

The ID3v2 reference states that RVA2 frames contain nothing but a channel number (front left, front right, etc.) and a 16-bit number which specifies how much to boost/cut the volume. It mentions "identification strings" which I guess could be hacked to represent certain points in the song, but that's kind confusing, and the spec doesn't really tell you how to use them. I'd be interested to see how this normalize package writes these frames, and how it magically decides where to boost/lower volume. Could you enlighten me what you're going after here?

Edit: Okay, Google led me to the Normalize web page, and the readme:
Version 0.7 and up can operate directly on MPEG audio files. An mp3 file is decoded (using Robert Leslie's MAD library) and analyzed on the fly, without the need for large temporary WAV files. The mp3 file is then "adjusted" by setting its relative volume adjustment information (technically, an "RVA2" frame is set in its ID3v2 tag). The advantage of this method is that the audio data doesn't need to be touched, and you don't incur the cost of re-encoding. The disadvantage is that your mp3 player needs to read and use relative volume adjustment ID3 frames. The normalize distribution now includes a plugin for xmms that honors volume adjustment frames. If you use an mp3 player other than xmms, you'll have to bug the author to support RVA2 frames in ID3 tags.

I see nothing about dynamic compression in there, really, it seems like raising/lowering the volume per-song... Not really Voladj-like, but more of a fixed +/- factor per song.. or am I reading that wrong?

I see nothing about dynamic compression in there, really, it seems like raising/lowering the volume per-song... Not really Voladj-like, but more of a fixed +/- factor per song.. or am I reading that wrong?

Unless the tag somehow contains moment-to-moment volume data for the song (instead of a single field representing a single relative volume number), then your assesment is correct. It's a single volume adjustment, not dynamic compression.

However, some would argue that this is better than dynamic compression.

The two things solve two different (but similar) problems. I'd like to see both implemented, and choose between the two.

My only problem with doing relative volume adjustment on the empeg is that if a song gets played at much more than +5db beyond where I've set the volume control, I'll start to clip it because of where my amp gains are set. Dunno how the relative volume offset handles that, does it always attenuate or sometimes boost?

2) Setting the volume. I can send VolUp and VolDown IR codes, but that's yucky. There might be an ioctl() somewhere for me to set it, but I'd have to set it as a percentage of the current volume, or relative to some baseline volume or something... Maybe re-use something that was provided with the volume boost stuff? Not sure if there were userland hooks to that stuff or not.


arch/arm/special/empeg_mixer.c contains the volume ioctls (both read and write) that the player uses. If you use these, then the volume_boost code will continue to work transparently in the kernel.

The big question is really whether you try to attempt absolute or relative volumes...
Absolute values can be found by looking at volume_entry volume_table[101] in empeg_mixer.c. Notice that 0dB corresponds to the 90th row. But I can't see how to make absolute values work - people would want to change their volumes anyway.

Relative values would suffer from the same issue that the volboost code suffers from - the volume steps aren't a consistent size across the whole volume range. In practice I think that this gives acceptable results though since most people will use their empegs in the linear region.

You will obviously need to do something similar to the volboost code and keep tabs on what adjustment you are making at any time, and removing the current adjustment before re-reading the volume (in case the user changed it mid-song) and applying the new one. This keeping tabs is made harder by the fact that any adjustment you make has to be kept within the hard limits of 0 <= adj <= 100. You'll have to detect when this happens and calculate what adjustment you *really* make in order to be able to undo it;

Assuming that you'd call this after reading the ID3 tags for a new track...sorry about the lazy syntax;

int current_adjust =0;   // initialised globally



volume_change() {

    // remove previous adjustment first. 

    vol = read_vol();

    vol = vol - current_adjust;  //current_adjust = 0 first time.

    write_vol(vol);  

           

    if (ID3_vol_tag) {

       vol = vol + ID3_vol_tag;

       if  (vol > 100) {

           // Hit limit - have to calculate real adjusment.

           current_adjust = vol - 100;

           vol = 100;

       }

       else

       if (vol < 0) {

          // hit the other limit...

          current_adjust = ( 0 - ( vol - ID3_vol_tag));

          vol = 0;

       }

       else {

          current_adjust = ID3_vol_tag; }

       

       write_vol(vol);

}

The other thing you want to consider is whether to cap at 90 (0dB) or not. You could read the users current cap setting in config.ini.
On the one hand, capping at 90 will still leave headroom for the volboost code, although this isn't really a factor since most people don't boost in mp3 playback (although they *could* if they really wanted!). On the other hand, if people are listening at a loud level then the ID3 based tag could run out of headroom. I suspect that the best thing to do is to cap at 100.

You will obviously need to do something similar to the volboost code and keep tabs on what adjustment you are making at any time, and removing the current adjustment before re-reading the volume (in case the user changed it mid-song) and applying the new one. This keeping tabs is made harder by the fact that any adjustment you make has to be kept within the hard limits of 0 <= adj <= 100. You'll have to detect when this happens and calculate what adjustment you *really* make in order to be able to undo it;

Hmm... The strategy sounds like it would work. I may play around with this some in the coming days and weeks.

Unless the tag somehow contains moment-to-moment volume data for the song (instead of a single field representing a single relative volume number), then your assesment is correct. It's a single volume adjustment, not dynamic compression.

It doesn't need to. You only need to know:
1) the volume of what you're playing now. A volume adjuster inline in the kernel already does (e.g. voladj).
2) the maximum and minimum present in the track, e.g. the current range
3) the target range (at which point you can calculate an adjustment factor)

The range compression can be dynamic: you need only to plug the necessary factor into whatever equation you're running on the gain in the real time play path, and update said value on a song switch.

My only problem with doing relative volume adjustment on the empeg is that if a song gets played at much more than +5db beyond where I've set the volume control, I'll start to clip it because of where my amp gains are set. Dunno how the relative volume offset handles that, does it always attenuate or sometimes boost?


Shouldn't be a problem - if the track needs +5dB to change it's level to that of the rest of your collection, then it shouldn't clip unless the rest of your collection clips.... Of course, if it were tagged as needing +5dB when it didn't, that's another matter!

Hopefully this code and the voladj code would work well *together*, with no need to choose between one and the other. This code would in effect normalise between differing tracks, while voladj would compress the dynamic range raising softer passages within a track.

The real question is whether voladj achieves it's compression without affecting the overall level of the track - ie by attenuating loud passages as well as raising softer passages. If if does, then the 2 methods should coexist perfectly.

If voldadj only raises softer passages, then in effect it would be raising the overall level of a track - and this would mean that in a normalised collection, tracks with the widest dynamic range would appear loudest.

Whichever way, I'm confident that the 2 can be tweaked to get the best of both. Maybe by tweaking the voladj parameters a bit, and maybe by manually lowering (in the tag) tracks that then end up too loud.

Hmm. Well I don't see myself bothering to do this unless there's some more understanding of how the adjustments are to be used. I don't really like dynamic compression because passages in a song that were meant to be quiet end up being raised up. If this were some kind of factor which just specified a fixed adjustment per song ("this song is X decibels too quiet on average, this other song is X decibels too loud on average") then I might be more inclined to try it out. I don't really want my program raising and lowering the volume hundreds of times per song.

2) the maximum and minimum present in the track, e.g. the current range

And I will repeat the thing I've already repeated until I was blue in the face:

The vast majority of tracks in your collection will have the same minimums and maximums (0% and nearly-100%) even though they sound like they're at different volumes.

The vast majority of tracks in your collection will have the same minimums and maximums (0% and nearly-100%) even though they sound like they're at different volumes.

Yeah. So if the ripper/tagger could pick out the *average* volume (RMS?) and provide a single adjustment per song so that the *averages* are constant, that might be more along the lines of what I would want...

Your program wouldn't be in the kernel itself, it would poke one value into the kernel, and let the kernel do the volume adjustment, like voladj does now, but essentially providing the upper and lower bound instead of the limited lookahead of the current voladj.

On the other hand a reread of http://www.unixgods.org/~tilo/ID3/docs/id3v2.4.0-frames.html#RVA2 suggests I'm wrong anyway.

You need an avatar where you're blue in the face.

I mis-summarized, you need also a mean volume precomputed. Your point stands on the data I just posted, but doing dynamic range compression by simply having a small number of precomputed values is possible. You just need different data than what I shared.

Rereading suggests if you just pull the RVA2 tag data out and do a fixed adjust once per track based on it, it will do what you want assuming you place the RVA2 tags with (the) normalize (package).

Never mind all the complicated stuff I suggested. I was wrong.

Not sure what gave you the idea that I wanted to do anything extra in the kernel. We'd just need kernel calls to set the volume, and per genixia's volboost stuff, we've apparently got that.

Rereading suggests if you just pull the RVA2 tag data out and do a fixed adjust once per track based on it, it will do what you want assuming you place the RVA2 tags with (the) normalize (package).

In that case, I will probably investigate this soon. I've been meaning to do a re-rip and encode session anyway... Might as well look into this first.

and per genixia's volboost stuff, we've apparently got that.


I wish I could claim all the credit...but the ioctls already exist in the stock kernel, I just hacked them around a little.

You suggested an ioctl. Nothing said *you* needed to be the one to write whatever was on the other end of it.

for dbrashear:

Now we just need to get him to use it for his posts....

Heh, I look like Violet Beauregard. Feel like it, too, I've been over-eating this last weekend. Ick...

I've got to put up a new avatar sometime soon, I need a better pic of me. That one's a few years and about 30 pounds ago.

I think a pan of cover art would be awesome, I've had that idea for a while now but didn't want to code it.

In reply to:

---

You need an avatar where you're blue in the face.

---

ROFL... I've often thought you needed an animated avatar of you turning red for FAQ posts.

Hi Tony,
Wow, this is excellent! Works great, had to enable notify=1 in my config. Now a few things i've ran into while using emphatic.

I have rows set to 17, and when i turn on the large font, the top of my screen gets scrambled up.

If you don't set the end time of the track, the program will instantly hide itself right after the last time stamp, hiding that lyric line.

And i guess the last thing would be, what do we have to get the empeg guys to get this into 2.0? It would be really neat to add the lyrics right in the song properties in emplode! It would remove alot of steps that are needed to get the lyrics perfect

Adding this feature to Emplode would be awesome. Especially for those of us that are a little over our heads technically. NOTHING is worse than knowing just enough to realize something is really cool but having no clue how to implement it.

I have rows set to 17, and when i turn on the large font, the top of my screen gets scrambled up.

Checking....

Ah ha. Interesting... I am setting the Hijack screen geometry based on what font you've chosen, and at line 17, the large font extends past the bottom... Hijack complains about the geometry being too big, so the call fails, and the results on the screen are, well, unpredictable.

Temporary workaround if you REALLY want it on line 17 and REALLY want the large font is to start emphatic up with the following options:

emphatic -r 17 -f 2

This starts it off with the large font, which avoids me having to recalculate the screen geometry. I will add a check of the geometry for the next release, but this should get you by.

And i guess the last thing would be, what do we have to get the empeg guys to get this into 2.0? It would be really neat to add the lyrics right in the song properties in emplode! It would remove alot of steps that are needed to get the lyrics perfect

You're kidding, right? It'd take several kegs of beer, a crowbar, and a lifetime carte blanche at The Wrestlers. There's no way they'd hold up 2.0 (which is already in alpha.) Besides, my code is really specific to the Hijack API, which the player software obviously doesn't use. As much as it'd be nice to be able to contribute new things to the player software, there's no way it can happen.

Edit: Ouch, okay, I misread the original post... You were talking about just the tag editting aspect of it... Hmm. That's a little closer to reality than changing the player software... But I wouldn't hold my breath, unless Roger falls in love with this program for some reason.

The font size large i don't use, i like the small one. but i was just checking out the font sizes and saw that problem. I think i will move it up to line 16 and see if that fixes it, i just wanted the text under the track line.

As for the emplode software, i hidden registry tweak that enables id3 lyrics tag editing in emplode. That would be T&A!

Anyways, I have 2 beastie boys cds tagged up, working on getting all their songs done. Love this program, but I don’t really see myself using it that much. But the passengers in my car will probably like it quite a bit! Thanks!

Anyways, I have 2 beastie boys cds tagged up, working on getting all their songs done. Love this program, but I don’t really see myself using it that much. But the passengers in my car will probably like it quite a bit! Thanks!

Glad to hear it, I love the Beastie Boys, that'd be 2 less CD's I'd have to tag. As of right now I'm probably going to start off by adding lyrics to my entire Pink Floyd and Tori Amos collections, that's a good 30 or so CD's. It'll definitely be a long journey to get to where a large portion of my music library is tagged.. But I hope the online lyrics DB thingie will help us all out in that regard.

Yeah, I'd love a hidden option for tag editing, though the thing to keep in mind is you really want the lyrics editor to be a WinAMP plugin, or something that has access to the current track time in your MP3 player, so you can automatically insert the current time. Otherwise it's a pretty manual process, even if emplode lets you do it. Unless emplode gets an integrated mp3 player, and I just don't see that happening.

As for "I don't see myself using it much," stay tuned, once I can clean the code up a little bit, I think this could be a lot more than just a lyrics viewer, people have suggested some great ideas, and they all seem doable (at this early stage.)

Its not that i don't find it useful, But most of the time when i'm listening to music, i'm not staring directly at the empeg. Most of the time i'm driving in and out of traffic, and looking at the empeg trying to read the lyrics would probably get me killed.

Edit: I guess to solve this, we need to get going on the HUD project!

as for the emplode software, i guess then maybe get your "lrc2sylt.exe" program integrated into the hidden display the empeg guys could create, which just asks for the location of that tracks ".lrc" file, and on sync it would add those lyrics into the fids on the empeg! Now that doesn't sound too bad
I'd chip in on a keg or two if required

Its not that i don't find it useful, But most of the time when i'm listening to music, i'm not staring directly at the empeg. Most of the time i'm driving in and out of traffic, and looking at the empeg trying to read the lyrics would probably get me killed.

Nah, I gotcha. I was thinking about including a disclaimer against any damages if you're reading the words and get in an accident. Wouldn't want this little project to land me in a "federal pound-me-in-the-ass prison." Yeah, a HUD would be pretty damn sweet.

LMAO

That actually gives me a great idea for an avatar, since I have been without one for nearly 4 years of being on this BBS...



Eeeeeexcelent.

ive got the 4 weezer albums all tagged up. will be ont he site when its up.

Who's gonna tag all those electronic mixes? Oh I'm so funny!

vol = vol + ID3_vol_tag;
if (vol > 100) {
// Hit limit - have to calculate real adjusment.
current_adjust = vol - 100;

I'd expect that last line to read:
current_adjust = 100 + ID3_vol_tag - vol;

Oops....You're right

I paid a little bit *too* much attention to my volboost code when writing that example, and forgot to adapt that line properly.

Hey Tony,

Does emphatic support the new directory structure for fids? My guess (based on my experience so far), is that it doesn't...

Does emphatic support the new directory structure for fids? My guess (based on my experience so far), is that it doesn't...

And you would be correct... Since 99% of the empegs out there don't have that structure yet, I haven't really gotten to supporting it. I'll work that in for the next release though.

Wow, nice avatar!

I moved the fids of my songs with lyrics back to play with it. I only had them in the new structure in the first place to practice my shell scripting.


In my testing, I noticed one definite bug: The "--mode" command line option doesn't work. "-m" works fine. I've attached a diff that I think fixes it, but I didn't recompile to check. It's a simple little thing that I'm sure you'd find yourself anyway.


Another thing that I've noticed is that I can't get -o or --offset to have any apparent effect. Can you verify that it's working right? The readme seems to imply that the values entered are in seconds, but I noticed in the code that the default gets set to 250000. I didn't read further to see what that really meant. Is the value for the option microseconds? And if so, is the default not really one second like in the readme? (I haven't actually tried super high values for offset to see what happens.)

By the way, I haven't even started trying to figure out why synchronisation usually fails when emphatic is running.

Yeah thanks for the heads-up on the --mode thing, FITNR. Probably wouldn't have noticed it if you hadn't told me, but as soon as you explained the behavior, I knew it was the no_argument thing.

The offset thing... Yeah it's in microseconds. I changed the default at some point during testing because I was getting more accurate results. I will change the readme to reflect the fact that it's actually in microseconds. If you change it to like 5000000 you should definitely notice a difference.

Are you running it off of your music partition? I *believe* there's a known issue where if you have programs running on your music partition, fsck complains, or something else during the synchroni[sz]ation process fails.

Anyways, I have 2 beastie boys cds tagged up, [

I tagged this one John Cage tune:

Yeah, the sync issue definitely exists if it (or anything else) is running from the music partition. You can work around it by selecting emphatic in the hijack menu, and then telling emphatic to Quit. (Obviously 'Close' doesn't help).

[Edit]... and if you used EXEC (as suggested) rather than EXEC_ONCE, after you sync, emphatic will be running again which will mean that you will need to repeat the above for every sync.

Thanks, Jim, we appreciate your hard work!

Hmm maybe I should tell people to use EXEC_ONCE instead of EXEC in my install instructions.

Edit: Holy cow, I just hit 3,000 posts! I need a life!

Also, if emphatic is running and the empeg goes into standby, on resume, everything is all messed up and need to remove power and replace.

Known bug, mentioned earlier in this thread, in fact. Nothing I can do about it. I think Hijack could change the way it restores from a standby, but from my code, I can't fix this one. Workaround is to close out of emphatic before you go to standby. You don't need to actually quit, just close it and leave it in the background.

ok cool, just figured i would mention it, i didn't remember seeing anyone else say anything about it, but i missed the early part of the thread i think

I also just tagged up D12

Are you running it off of your music partition? I *believe* there's a known issue where if you have programs running on your music partition, fsck complains, or something else during the synchroni[sz]ation process fails.

Aha. I got into the habit of keeping things in my music partition, because I was shuffling some pretty big files in and out for a while. Now that it's settled down, I'll move everything over to /usr/bin/local, or something. Thanks!

Ok, so I downloaded the 1.01 version of emphatic. I am running B13 and Hijack 312. I followed all of the install steps (ran the FTP batch file successfully, modified my config.ini [hijack] and [output] sections) ... Rebooted the player and don't see emphatic on my hijack menu. Any ideas as to what I should check next??

---- I forgot to note that I didn't modify the directories in the FTP batch file at all ----

---- I forgot to note that I didn't modify the directories in the FTP batch file at all ----

Well, that could be a problem because most people don't have a directory named /usr/local/bin on their player. This is the frustration with having no standard install process/setup... The thing is, if I chose a path which already exists on peoples' players (/bin, /usr/bin, etc) those tend to get overwritten by an empeg software upgrade.

Anyway, best thing for you to do is probably to create a main directory off of the root directory. Fire up Hyperterminal or whatever terminal program you might have, quit out of the empeg player software with 'q' and then type the following:

rw

mkdir /programs

ro

.

Then you will have a /programs directory which won't get overwritten during an upgrade. Edit the FTP script, changing /usr/local/bin to /programs, then re-run it. You should be okay then, assuming you added the ;@EXEC entry properly. If not, start up the player with your terminal program logging the startup messages and post them here.

HTH.

That did the trick. Very nice work guys!!!

Since I've ben lurking for about the last year, I'll give a little intro on myself. I'm a Linux user. I hate booting into windows. I can move my way around in perl, and some C, C++..

With that outta the way, my problem is that SingIt doesn't seem to write any frames to the mp3 file, and lrc2sylt looks to be written to convert lrc files, so it wouldn't do any good trying to mind meld the sylt tag info into the mp3. Am I wrong? Is anyone else working on this? Will I need to hack together my own program? >:)

Yeah, I found out after I wrote the README that SingIT doesn't write SYLT lyrics.

If I'm understanding your second point there, I think you're saying that lrc2sylt just converts one format to another. That's not correct. I think I tried to mention in the README that lrc2sylt reads in LRC files and writes SYLT lyric frames *to the MP3 file.* So no "mind melding" of the SYLT tag into the MP3 is necessary -- id3lib takes care of that.

The thing is, it's just a command-line util, we'd all love something prettier. Oliver PM'ed me saying he's going to cut his teeth on a GUI-based tool to do the job, but he plans on using .NET technology to do it, so I'm afraid that won't help a Linux snob like yourself. That is, unless one of these .NET frameworks like Ximian or dotGNU actually work, which I doubt...

Anyway, the ideal situation for me would be having both WinAMP 2.x and XMMS plugins to do the job. I see myself focusing on emphatic development for now, so any kind of taggers/plugins/GUI's are going to have to be someone else's bag. I can get into those in the future, but I see emphatic doing other things in addition to just the lyrics, and I wanna develop that stuff first. That, and I'm woefully behind on grad school projects.

Anyway, just wanted to clear up the fact that lrc2sylt does indeed write tags to the MP3.

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.