FAQ
From M:Robe 500i Development Wiki
Original Firmware
What audio format does it play?
WMA and MP3 are the only ones I've tried.
What audio formats are not supported?
OGG, FLAC, WAV. I haven't tested any others.
What type of tags does the player read?
None. All tag reading is done on the software end.
Where can audio files reside on the player?
Anywhere. The path tree must be less than 255 characters.
Do the audio files need to be renamed to 8 characters?
No. But it cannot contain illegal characters, Unicode, or special characters.
What is the maximum path length?
255 characters. This path limit is imposed by FAT32.
What are the known illegal filename characters?
"&" (ampersand) - doesn't work on my 500 but I believe works on the 100.
Are 2-byte filenames supported?
Yes, as long are they are encoded properly within the database.
=== What characters encoding must the tags be in? UTF-8. Anything else will give you a database error.
What characters must be escaped in the tags?
"&" (ampersand), "&apot" (apostrophe), "<" (less-than sign), ">" (greater-than sign), """ (quotation mark)
These characters are only escaped in the XML database files and not physically in the ID3 tag of the audio file.
How do I escape them?
When writing the tags to the XML db:
- & = &
- ' = '
- " = "
- < = <
- > = >
What is "System Error 900" and how do I fix it?
I don't know. It usually means that a filename has an illegal character. I often receive this error when I pull the player off the dock. A reboot will usually fix it.
Where is the database located?
It's a hidden folder under \System\List. There is one folder for each database: Music, Remix, Photo, Template.
Can I change the location of the database files?
No. The player will error out with a "Database Error".
What format are the database files in?
Plain text XML.
How is the database structured?
Here are the database files and functions:
- /index.mum - points to the location of the database for each function (music, remix, photo). This file can be omitted from the 500i and still work for music, I havn't tested any other function. But this file is required by the 100 and must be updated (access time/modification time) whenever the database has changed.
- /System/List/Music/albmxxxx.mum - index listing of all the audio files associated to an album as read by the ID3 tags. 1 file per album
- /System/List/Music/album.mum - a listing of all the albums as read by ID3 tag and a pointer to the location of the albmxxxx.mum file
- /System/List/Music/msic0001.mum - index listing of all the audio files and their related ID3 tags
- /System/List/Music/srchkey.xml - index listing of Artist, Genre, Composer, and Year
- /System/List/Music/music.mum -
- /System/List/Music/playlist.mum -
- /System/List/Music/recent.mum -
- /System/List/Music/toprate.mum -
What is "Database Error"?
Something in the database cannot be read. Or the something in the database structure is incorrect. Check your indexing.
What is "Search Failed"?
The database is correct, but the path to a file is wrong.
What is the CntrlFlag tag in the msic0001.mum?
It's used by the m:trip and the player to tag for lyrics, cover art, and favorites. Each value is incremented according to tag.
Firmware Modification
I want to compile mplayer/gstreamer/xmms/insert-your-favourite-media-player-here for the m:robe.
Don't bother. The m:robe's main CPU is an ARM running at 200 MHz, (see Hardware Information), which is incapable of decoding a video stream in realtime. mplayer's video decoding algorithms are too generic and oriented toward the architecture of desktop PC. The typical computer that runs mplayer or other popular media players (2400 MHz x86 with an FPU and SSE) contains comparatively much more processing power than the m:robe (200 MHz ARM with no FPU).
There is also a problem with audio playback in particular. The DAC is in a separate chip from the main chip. Its data interface (where the actual audio data goes) is only accessible from code running on the DSP core, because the interfaces is connected to one of the DSP's McBSPs. This makes sense, because audio codecs would run on the DSP, but it makes it impossible for us to simply compile an optimized MP3 codec for the ARM and run it without cooperating with the DSP.
Video playback *is* possible on the m:robe as a whole. Cowon has a player based on the same main chip as the m:robe (the TMS320DM320), and it is capable of playing WMV and MPEG-4 video in realtime. The key is leveraging the second core of the m:robe's main chip, the Texas Instruments C5409 DSP. A DSP is a processor designed for performing mathematical operations very quickly (which is exactly audio and video coding). There exists codecs for this specific series of DSP, but they are all commercial products and not viable for use in an open-source project. This is partly because of the very high level of skill in mathematics, computing and general understanding of all details of a system required of an engineer to successfully create a DSP codec.
Neuros Technology uses the TMS320DM320 in a set-top box that is capable of realtime MPEG-4 encoding and decoding. They license binary codecs from Ingenient Technologies.
The Archopen project may have a working audio player for yet another TMS320DM320-based player. See libdsp.
I want to try to write a codec for the DSP.
Okay, we need people who are capable and willing of doing this. Here are some starting points:
- Read about the architecture of the DSP.
- SPRU538 - TMS320C54x DSP Programmer's Guide
- SPRU131G - TMS320C54x DSP Reference Set - Volume 1: CPU and Peripherals
- SPRU172C - TMS320C54x DSP Reference Set - Volume 2: Mnemonic Instruction Set
- SPRU173 - TMS320C54x DSP Reference Set - Volume 4: Applications Guide
- SPRU302 - TMS320C54x DSP Reference Set - Volume 5: Enhanced Peripherals
- Compile code for the DSP.
- Coordinate between the DSP and the Linux kernel.
- Write an application that takes advantage of the DSP for playback.
My m:robe is bricked (bad flash). Can I use the remote control's serial port to recover it?
Short answer: Probably not.
Long answer: Indeed, the remote connector is hooked up to a serial port inside the m:robe. However, as far as reflashing the m:robe through the serial port *without* the help of the CPU, it is useless. The serial port is controlled by the CPU and, without a program running on the CPU that says "send me data, I will write it to flash", the serial port doesn't help you.
The only possible hope through the serial port would be if the bootloader of the m:robe expects some signal on the serial port while it's booting, to be put in some sort of "debug" mode. The firmware has been analyzed by a few developers and we haven't found any evidence of this.
My m:robe is bricked (bad flash). Can JTAG help me?
Short answer: Probably.
Long answer: JTAG bypasses the CPU's normal program execution. Using JTAG, you can instruct the CPU to perform certain memory accesses, in precisely the right pattern to write to the flash, regardless of what's in memory and flash (in particular, in case the flash in corrupted).
However, JTAG requires soldering 6 small wires to the mainboard of the m:robe and connecting it to the computer using that interface. This is in itself a risky procedure, but at least one developer has done it successfully and if it's your last hope, you have nothing to lose.
How does Olympus fix m:robes with bad flashes?
This is speculation only. No one knows for sure how they do it (if they even bother), but this is a pretty good guess. Olympus doesn't solder wires onto a customer's board. They have a special machine with sharp metallic probes that presses itself onto the m:robe's board at precisely the right positions. The contact is sufficient to conduct electricity, and so they can recover your m:robe. The rest of the process (connecting it to a computer and forcing the CPU to write to the flash) is probably the same as what we do.