I am a Chinese. I would like to see empeg can display Chinese mp3 name/ID3 tags correctly. I am a C/C++ developer, also consider myself a Linux power user. I am happy to find myself such task, some tips would help me on the right direction.
I have a Chinese font library, consist of ~5k common Chinese characters, each character's size is 16x16 pixels. The problem is when the player display the mp3's information, how can I replace them with these Chinese character? I know the player software is not open-source, which means I have to do it another way. Seems to me the player doesn't use a common interface to do display, otherwise, substitute the interface can solve the problem. Another idea in my head is to have a background program there, check the display buffer every couple seconds. If it determine the content contain Chinese encoded characters, it will replace them.
Any suggestions?

Unfortunately, you'd have to write your own player software from scratch in order to get full double-byte unicode character support.

You're welcome to give it a shot. The player's hardware specs and I/O details are fully available. But it's a big task. No one has attempted to completely rewrite the player software from scratch yet.

First off, you'd have to use Hijack unless the player gets upgraded to Unicode or something.

Using /proc/empeg_notify, you can find the current song playing. Then, a separate program (running in the background, possibly triggered with a button press or something) could use Hijack to take over the display where the text is displayed (or full screen) and display the ID3 tag info for the current playing FID using your Chinese fonts. I don't think you can map specific keys to programs right now, but I think it'd be possible.

This is all hypothetical, but would be interesting to see.

Or maybe not...

There is potentially enough code in Hijack right now to have a userland app see what is playing, and parse it into Chineese then put it onto the display over the existing screen. This would need a combination of reading the /proc entries that Hijack adds, and having some way of knowing what characters to display from the info there.

This would need a combination of reading the /proc entries that Hijack adds, and having some way of knowing what characters to display from the info there.

If you encoded the titles in Unicode or whatever (I don't know enough I18N stuff), you could pull it directly from /proc/empeg_notify, as it puts the title and such there. Only problem is that all searches, playlists, etc. wouldn't be in Chinese characters, but whatever encoding you have in the titles. Quite a big price to pay for Chinese display.

Yeah, this would only get you bare-minimum track titles on the screen and wouldn't help you when selecting playlists, etc.

However, taking the idea a step further, if you wanted to title your playlists with unicode, you could have a userland app for selecting playlists. It could use the Hijack serial-insert protocol to tell the player to start playing that FID.

Hmm, maybe it COULD work.... Searches would still be a pain, but if you could select playlists and see track titles, it might be enough...

Ummm... Creating an alternate or hacked front-end to the player software is the least of the problems. The most time-consuming portion of this type of effort will be getting a Chinese set of 5000+ characters into a couple of good-looking bitmaps. You'd have to have a new size, because I can say quite easily that it is IMPOSSIBLE to represent any useful number of Chinese characters in a 6-pixel font (especially while leaving the bottom row of pixels blank - it's hard enough squeezing a latin set into 5 pixels).

Using 9 pixels (the medium font size) is a little more helpful, but still a pain in the ass. And then, even if you decide on a suitable size, just getting the characters into readable bitmaps of this size using only 2 shades is going to be a monumental challenge. Try scaling a character lie this in Photoshop just for giggles.

Maybe the font could be divided up between many people. Each handling a handful of characters. A distributed effort. Still going to be a HUGE pain in the ass.

Bruno

He already has a font (format?), 16x16, although it probably would need to be anti-aliased WRT the empeg greyscales.

would suggest to read the screen "OCR" it and make your own screen wth oyr own font and your own info. You could probably do the same with the menus as well, but it would requre some OCR'ing.

You could also trap all button presses and pass on button presses and/or read (as other people have mentioned) from the /proc files.

Look at all the suggestions and combine them and see what you feel is the best solution

Marius (Escort Cab + Mark II)

He already has a font (format?), 16x16, although it probably would need to be anti-aliased WRT the empeg greyscales.

Hopefully with anti-aliasing the font could be reduced in size slightly and still be legible. The screen is only 128x32, after all, which is only two lines of text in a 16x16 font. Getting it down to 10x10 would be a big UI improvement. But yes, there's still the issue of integrating it into the player. CJKV support is hard, and with no native speakers on the team it's frankly not something we even thought about attempting on the car player. (How would the search screens work, for instance?)

Peter

Searches would still be a pain, but if you could select playlists and see track titles, it might be enough...

To see track titles in Chinese will be a good start to me, and with that experience, I could try to get playlists work. Consider search a luxury feature, 'coz it require Chinese input, a too heavy task.

He already has a font (format?), 16x16, although it probably would need to be anti-aliased WRT the empeg greyscales.

Yes, for each character, it's in 16x16 bitmap, two colors.

Using /proc/empeg_notify, you can find the current song playing.

Is there a better way to know /proc/empeg_notify file changed than keep checking it every couple seconds?

If he wants to do a simple convert of that 16 pixel font and leave it at 16 pixels, then that's about the easiest thing to be done (I missed the word "pixels" when he mentioned he already had a source font). If he wants to change the size, good luck. Batch processing isn't likely to give you the results you'll want. Doing it by hand is a pain in the ass. It's always worth a try though. Might need to make a few programs to put the characters into better formats for batch conversion with yet other software. Might need to make your own scaling software too. Commercial software might not be up to adequate scaling. I know Photoshop will make a mess without using its built-in anti-aliasing (using RGB colour-space). Then going back down to 1bit will make things look very bad.

If the 16 pixel font is 1bit, that's the best possible scenario to start from. If it's using 2bits or more of colour, see above...

I'm editing this post now, so I see from the replies that the font is 1bit - by 2 colours I take it to be 1 font color and 1 background color. But even if it's 2 colours in the font plus 1 background colour (2bit with one unused index), that will be fine.

Using the features of the next player beta and a Hijack-yet-to-come, someone could probably hack together an overlayed display using a userland app. The player would just display the double-byte data straight, which would look like crap.

Bruno

Using the features of the next player beta

I am sorry that I don't really understand what this mean.

Hi.

Well, let me put it this way:
If you (currently) knew what features he is referring to, they (guys@empeg and/or alpha testers) would probably have to kill you.

cu,
sven

PS: In other words: He is propably just teasing us about some new features in a yet unreleased new beta. And if you knew, it would be a violation of the NDAs the alpha testers signed.

Not at all. I'm not on the alpha team and don't have access to any insider information... I'm talking about serial support for something Mark asked for. To be able to insert and append FIDs to the current playlist. Someone could use these abilities to hack another front end on top of the current player.

Let's see what Mark does with the new functionality first and then everyone will have a better idea of what's possible.

Bruno