<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title><![CDATA[MMSGURU's Techno Blog]]></title>
    <link>http://www.mmsguru.com/blogger/</link>
    <description><![CDATA[MMSGURU's Techno Blog]]></description>
    <pubDate>Tue, 20 Apr 2010 11:06:57 -0700</pubDate>
    <lastBuildDate>Tue, 20 Apr 2010 11:06:57 -0700</lastBuildDate>
    <docs>http://blogs.law.harvard.edu/tech/rss</docs> 
    <generator>phpblogger</generator>     
<item>
  <title><![CDATA[Perfect shiny custom rounded rect buttons for iPhone/iPad]]></title>
  <link>http://www.mmsguru.com/blogger/?action=entry&amp;id=1271786817</link>
  <comments>http://www.mmsguru.com/blogger/?action=comments&amp;id=1271786817</comments>  
  <description><![CDATA[If you need to create rounded buttons with a glossy surface matching Apple's UI but with custom coloring, here comes a nice solution...<br/><br/>Add the following code to a dummy-app that you run within the simulator (note: this does not work on the device!). A good place to put this code would be a newly created UIVIew-Application's viewDidLoad method.<br/><br/>This snippet will render the button and export a PNG file of it to your desktop. Make sure you edit the path as it currently is adapted towards my own username.<br/><br/><pre><br/>	Class theClass = NSClassFromString(@"UIGlassButton");<br/>	UIButton *theButton = [[[theClass alloc] initWithFrame:CGRectMake(10, 10, 29, 52)] autorelease];<br/>	[theButton setValue:[UIColor colorWithHue:0.267 saturation:1.000 brightness:0.667 alpha:1.000] forKey:@"tintColor"];<br/>	[self.view addSubview:theButton];<br/>	<br/>	UIGraphicsBeginImageContext(theButton.frame.size);<br/>	<br/>	CGContextRef theContext = UIGraphicsGetCurrentContext();<br/>	[theButton.layer renderInContext:theContext];<br/>	UIImage *theImage = UIGraphicsGetImageFromCurrentImageContext();<br/>	NSData *theData = UIImagePNGRepresentation(theImage);<br/>	[theData writeToFile:@"/Users/till/Desktop/button_rendered.png" atomically:NO];<br/>	<br/>	UIGraphicsEndImageContext();<br/><br/></pre><br/><br/><br/>Now for using the image within you actual app, you simply create a custom button an use the rendered image as a background-image.<br/>Note that the displayed button is 44 pixels in height but the rendered button image is 52 pixels in height. This difference is introduced by the surrounding frame and dropshadow.<br/><pre><br/>	CGRect buttonFrame = CGRectMake(44.0f, 10.0f, 120.0f, 44.0f);<br/>	UIButton *button = [UIButton buttonWithType:UIButtonTypeCustom];<br/>	[button setBackgroundImage:[[UIImage imageNamed:@"button_rendered.png"] stretchableImageWithLeftCapWidth:12.0 topCapHeight:0.0] forState:UIControlStateNormal];<br/>	[button setFrame:buttonFrame];<br/>	[button setTitle:@"MMSGURU Rulez!" forState:UIControlStateNormal];<br/>	[button.titleLabel setFont:[UIFont boldSystemFontOfSize:20]];<br/>	[button setTitleColor:[UIColor whiteColor] forState:UIControlStateNormal];<br/>	[button addTarget:self action:@selector(dudeKnowsWhatsBestButtonPressed:) forControlEvents:UIControlEventTouchUpInside];<br/></pre><br/>]]></description>
  <pubDate>Tue, 20 Apr 2010 11:06:57 -0700</pubDate>
  <author>MMSGURU</author>
  <category>news</category>
  <guid>1271786817</guid>
</item>
<item>
  <title><![CDATA[Automatically generating a source documentation within Xcode]]></title>
  <link>http://www.mmsguru.com/blogger/?action=entry&amp;id=1242929521</link>
  <comments>http://www.mmsguru.com/blogger/?action=comments&amp;id=1242929521</comments>  
  <description><![CDATA[Xcode, being a very flexible IDE for application development offers embedding custom documentations for your own code. Such documentation should be organized as a so called docset. The best documentation generator available IMHO is Doxygen.<br/>Get a Doxygen well designed, binary Mac distribution of Doxygen at <a href="http://www.stack.nl/~dimitri/doxygen/download.html#latestsrc">Doxygen source and binary releases</a>. For the sake of simplicity, I would recommend downloading and installing the universal binary distribution for Mac OS X (.dmg).<br/>Now how to generate a docset using Doxygen? Apple, being a strong supporter of open-source software did release a nice and easy step-by-step tutorial for covering that job.<br/>You find that tutorial at <a href="http://developer.apple.com/tools/creatingdocsetswithdoxygen.html">Using Doxygen to Create Xcode Documentation Sets</a>.<br/>With those tools at hand, you can easily generate docsets automatically when compiling your code.<br/>One thing however that I found a little annoying was the fact that such documentation is always generated when building your code. If I was the lucky owner of a MacPro or a MacbookPro with solid state disk, I would most likely not care. Being a not so lucky user of a pretty dated Macbook, I do however feel the pain of waiting some additional seconds for the sake of getting a new docset generated from my code. But the solution was rather simple, all I needed to do was creating an additional Build-Configuration (named ReleaseDocumentation) and slightly modify the shell-script (Run Script) that Apple has generously provided in their tutorial.<br/><br/>Just add the folowing line at the start of the custom Run Script:<br/><pre><br/>#  Run the rest of the script only when ReleaseDocumentation is selected as the <br/>#  current active configuration <br/>if [ "$ {CONFIGURATION}" == "ReleaseDocumentation" ]<br/>then<br/></pre><br/>Note that you will have to remove the space between the dollar-sign and the brace - I had to introduce that for keeping this blog happy.<br/><br/>And do not forget to add the following line at the end of that script, just before "exit 0":<br/><pre><br/>fi<br/></pre><br/><br/>After those changes your code will only result into a re/build of the docset when the ReleaseDocumentation configuration is selected.<br/>]]></description>
  <pubDate>Thu, 21 May 2009 11:12:01 -0700</pubDate>
  <author>MMSGURU</author>
  <category>news</category>
  <guid>1242929521</guid>
</item>
<item>
  <title><![CDATA[CoreAnimation layers are full of Traps]]></title>
  <link>http://www.mmsguru.com/blogger/?action=entry&amp;id=1242656318</link>
  <comments>http://www.mmsguru.com/blogger/?action=comments&amp;id=1242656318</comments>  
  <description><![CDATA[Apple's beautifull SDK includes the nice and easy CoreAnimation API. CoreAnimation can be used for animating just about anything you can display on the screen. CoreAnimation appears to be an easy to use wrapper for OpenGL(ES). Well, basically anything you draw on the screen of an iPhone appears underneath to be handled by OpenGL(ES). CoreAnimation makes all those nifty display effects (fades, rotations, wiggles, etc.) really quick and comfortably to implement. And the way that works is definitely super close to what you do when animating directly via OpenGL(ES) - a fact that makes the transition from CoreAnimation towards OpenGL(ES) very straightforward in case you ever need to go that extra step.<br/><br/>BUT, be warned, there are drawbacks in CoreAnimation that are not really obvious in the first place. <br/><br/>CoreAnimation works on so called layers (CALayer). Those layers are compareable to a Canvas in HTML5. Such layer may have children (sublayers) resulting into a tree structure. <br/>Actions such as rotation, translation and scaling on a layer automatically affect its sublayers. That is not a trap but a great feature. However, when animating such actions, I found the first trap that really was annoying. When animating a rotation around some abritary point, you need to translate the layers' anchor point (origin) towards that custom point, rotate and reverse the translation again. This is common and done the exact same way when using OpenGL(ES). Trouble is, when doing all of that in an animation (CABAnimation), CoreAnimation will basically interpolate all the changes you do between the given start and end status. That will include your translation towards the custom point you intend to rotate around. As a result, you will see the rotation is done around a moving point - something you wont really expect or desire. I have not found a proper solution for that issue and learned to live with it. Still, I think there might be solitions, just I was too dumb to find em until today. So that was trap number one.<br/><br/>Trap number two is connected to three dimensional rendering... I needed to have two objects, each of them with plenty of sublayers displayed. Trouble came when I needed them to intersect each other with partial hiding. A CALayer can be translated with CoreAnimation into all three dimensions. Additionally a CALayer has a property called zPosition. Equipped with that knowledge I assumed that it should be a no-brainer to have a partial intersection with partial hiding. I guess I was wrong :). Turns out that CoreAnimation, even though it has all those attributes (z-coordinate through translation and z-position property) does not allow partial hiding of sublayers using the third dimension. The reason for that is that a all sublayers of a toplayer are, in the end, rendered onto the same layer. The zPosition (CALayer property) is only usefull for giving a display order of toplayers. The z-coordinate (CoreAnimation translate) is only used for perspectivic skewing. None of those attributes helps when you intend to achieve partial hiding of intersecting sublayers of two (or more) toplayers. As a consequence, whenever you need "proper" 3D, dont use CoreAnimation but immediately go to OpenGL(ES) - or, use foul workarounds with manual interventions. ]]></description>
  <pubDate>Mon, 18 May 2009 07:18:38 -0700</pubDate>
  <author>MMSGURU</author>
  <category>news</category>
  <guid>1242656318</guid>
</item>
<item>
  <title><![CDATA[Some Facts about the iPhone OpenGL Hardware]]></title>
  <link>http://www.mmsguru.com/blogger/?action=entry&amp;id=1241861917</link>
  <comments>http://www.mmsguru.com/blogger/?action=comments&amp;id=1241861917</comments>  
  <description><![CDATA[- There is no stencil or accumulation buffer.<br/>- There are only two texture units.<br/>- The maximum texture size is 1024×1024 (use power of two only).<br/>- The maximum space for textures and surfaces is 24MB.<br/>- Only 2D textures are supported.<br/>- There is no software rendering fallback.<br/><br/>More interesting facts and hints: <a href="http://www.ddj.com/mobile/209600498">http://www.ddj.com/mobile/209600498</a>]]></description>
  <pubDate>Sat, 09 May 2009 02:38:37 -0700</pubDate>
  <author>MMSGURU</author>
  <category>news</category>
  <guid>1241861917</guid>
</item>
<item>
  <title><![CDATA[Pretty 2D circles with fat outlines in OpenGL / ES]]></title>
  <link>http://www.mmsguru.com/blogger/?action=entry&amp;id=1241454718</link>
  <comments>http://www.mmsguru.com/blogger/?action=comments&amp;id=1241454718</comments>  
  <description><![CDATA[Today I was confronted with the problem that my unfilled circles, rendered with the function from my previous posting did look good only as long as I did not set the glLinewidth higher than 1. When using fat lines, the result looked bizarre - that is, it was missing some parts. When additionally using GL_LINE_SMOOTH the result was  perfectly round but had a moiree pattern inside the fat line.<br/>The solution was rather simple, just dont mess with glLinewidth and leave it at 1.0. <br/><br/>But then again, I still wanted to draw a circle with a thick outline. <br/><br/>Once again the solution was surprisingly simple. Instead of using a GL_LINE_LOOP, I used a GL_TRIANGLE_STRIP with the first point calced on the outer side of the circle (radius+lineWidth/2) and the second point on the inner side of the circle (radius-lineWidth/2). Et voila, a perfectly round circle drawn with a fat line.<br/><br/>Only downside is, I lost the smoothing that way. That I will have to implement now as well using a different technique (other than GL_LINE_SMOOTH). Read more about that in my next posting...]]></description>
  <pubDate>Mon, 04 May 2009 09:31:58 -0700</pubDate>
  <author>MMSGURU</author>
  <category>news</category>
  <guid>1241454718</guid>
</item>
<item>
  <title><![CDATA[Couple of efficient 2D graphix algorithms]]></title>
  <link>http://www.mmsguru.com/blogger/?action=entry&amp;id=1241259689</link>
  <comments>http://www.mmsguru.com/blogger/?action=comments&amp;id=1241259689</comments>  
  <description><![CDATA[When searching for the most efficient way to draw primitives on OpenGL ES I found the following two extremely elegant.<br/><br/>Circle / Circle Arc<br/><br/>Drawing a circle and a circle arc is usually done using the standard algorithm we learned from school. Well, as usual, that is not the most efficient way to do it.<br/><br/>Have a look at this page for a much more efficient implementation and its very easy to understand explanation:<br/><a href="/mirror/circle_cached.html">An Efficient Way to Draw Approximate Circles in OpenGL (mirrored version)</a><br/>Please note that this page is a mirrored version of the Google cached version of SiegeLord's Abode original page / article. A few days ago that page went down, hence I decided to mirror it as I found it really usefull. The original URL was: <a href="http://slabode.exofire.net/circle_draw.shtml">http://slabode.exofire.net/circle_draw.shtml</a> - if that page ever comes back up again (you should try that right now), please send me a note!<br/><br/>Curved Line (aka Bezier Curve aka Spline)<br/><br/>This one isn't usually something you learn at school but later at university. Well, I have to confess I never really grasped the common bezier algorithm during my studies at university, hence I usually copy-pasted it from other sources. Until yesterday, that is. A really good coder I met ages ago on some demo parties has released his implementation into public back in '99 but I didn't visit his site for about the same duration.<br/>The implementation is so simple, one really has to be mentally challenged to not understand it. So have a look at Nils Pipenbrinck's well documented way of drawing a cubic bezier curve:<br/><a href="http://www.cubic.org/docs/bezier.htm">http://www.cubic.org/docs/bezier.htm</a><br/>]]></description>
  <pubDate>Sat, 02 May 2009 03:21:29 -0700</pubDate>
  <author>MMSGURU</author>
  <category>news</category>
  <guid>1241259689</guid>
</item>
<item>
  <title><![CDATA[Debugging Macros on Cocoa (and Cocoa Touch)]]></title>
  <link>http://www.mmsguru.com/blogger/?action=entry&amp;id=1241123601</link>
  <comments>http://www.mmsguru.com/blogger/?action=comments&amp;id=1241123601</comments>  
  <description><![CDATA[Ahoi!<br/><br/>over the last 10 years I was coding a lot on Windows based systems using Visual C++. I grew  custom to using the convenient TRACE and ASSERT macros.<br/><br/>When starting to do more cross-platform coding, I simply implemented my own versions of those macros and kept using them as learned.<br/><br/>Now that I started doing Cocoa coding, I missed my former buddies TRACE and ASSERT. But not for long as I discovered that there actually were very similar macros/functions existing on that platform (NSLog and NSAssert). However, both dont work exactly the way I used my old pals. <br/><br/>The differences are:<br/>- NSLog and NSAssert are not strictly existing in DEBUG builds but in all versions of your code.<br/>- NSAssert does not take a variable number of arguments but exists in several versions depending on the amount of paramaters you want to supply.<br/><br/><br/>The first issue is a no brainer, all you need to do is create a wrapping macro an make sure it only exists when compiling your code in DEBUG mode. The second one isn't rocket science either as you can see below.<br/><br/>So once again, I wrote my own version of the good old friends from ancient (and possibly soon to be forgotten) times.<br/><br/>To use them as intended, add this header to your project and also make sure that you add the definition of _DEBUG to your DEBUG project settings: Project Info > Build > GCC_PREPROCESSOR_DEFINITIONS: _DEBUG=1<br/><br/><br/><pre><br/>/*<br/> *  DebugBase.h<br/> *<br/> *  Created by Till Toenshoff on 4/28/09.<br/> *  Copleft 2009 MMSGURU. No rights reserved.<br/> *<br/> */<br/>#include &lt;stdarg.h&gt;<br/>#import &lt;Foundation/Foundation.h&gt;<br/><br/>#ifdef _DEBUG<br/><br/>#define TRACE(format, ...) NSLog(format, ## __VA_ARGS__)<br/><br/>void MyAssertLog (NSString *fmt, ...)<br/>{<br/>	va_list ap;<br/>	va_start(ap, fmt);<br/>	NSString *varString = [[NSString alloc] initWithFormat: fmt arguments: ap]; <br/>	va_end(ap);<br/>	NSString *outputString = [[NSString alloc] initWithFormat: @"*** Assertion failure: %@", varString];<br/>	NSLog(outputString);<br/>}<br/><br/>#define ASSERT(condition, desc, ...)	    \<br/>if (!(condition)) {					   \	<br/>MyAssertLog(desc, ## __VA_ARGS__); \	<br/>}								   \	<br/>NSAssert(condition, @"see above");	<br/><br/>#else<br/><br/>#define TRACE(format, ...)<br/>#define ASSERT(condition, desc, ...)<br/><br/>#endif<br/></pre><br/><br/>Presto, the Windows coder feels much more at home on Mac OS as well as the new miraculous cash cow, the iPhone.<br/>]]></description>
  <pubDate>Thu, 30 Apr 2009 13:33:21 -0700</pubDate>
  <author>MMSGURU</author>
  <category>news</category>
  <guid>1241123601</guid>
</item>
<item>
  <title><![CDATA[Back and Alive]]></title>
  <link>http://www.mmsguru.com/blogger/?action=entry&amp;id=1210071544</link>
  <comments>http://www.mmsguru.com/blogger/?action=comments&amp;id=1210071544</comments>  
  <description><![CDATA[This one is just for letting you know that I am back in action. The last two years have been really slow. Most of my time I wasted with MMO's like WoW and LOTRO - quit both after realizing how consuming they were. Well, thing is, I am really keen for success and such games are really poison for me as I cant stop until I am *the best*. That goal was never reached in WoW, as the clever Blizzard guys did prepare for people like me. On the other side, LOTRO never really offered enough end-game-content to keep guys like me playing it. Actually I prefer PvP instead of PvE and the PvP part of LOTRO is a bad joke. Just to give you some ideas on why LOTRO PvP is ridiculous from the technical point of view:<br/>The number of players within the PvP area is unlimitted. At the first glance that looks sexy but anybody who is a bit technically savvy will notice that not capping the number of players in a certain area WILL lead to overcrowded areas. Anybody who played this game and ever tried to attack Tol Ascaren with 2-3 raids (meeting 2-3 MP raids in that keep) will have experienced those humongous lags (> 30 secs cast time for instant attacks). <br/><br/>Well, I had my share of that game - I had the best equipped hunter on that server and reached PvP rank eight rather early (number four on that server) even though I had paused playing LOTRO for about three months inbetween. I became well known for constantly flaming at noobs and hated by many of them. <br/>The final reason to quit that game for me was that the gamemasters forced me to rename my guild and also they did read private conversations (guild chat, private chat). That was a breach of my privacy and that is something that really aggrevates me. The ingame support of LOTRO is in no way compareable to what I had experienced with WoW. The european LOTRO support is plain rubbish. So, that was that...<br/>AoC coming in 11 days ;)]]></description>
  <pubDate>Tue, 06 May 2008 03:59:04 -0700</pubDate>
  <author>MMSGURU</author>
  <category>news</category>
  <guid>1210071544</guid>
</item>
<item>
  <title><![CDATA[SISyphus Labour]]></title>
  <link>http://www.mmsguru.com/blogger/?action=entry&amp;id=1151504679</link>
  <comments>http://www.mmsguru.com/blogger/?action=comments&amp;id=1151504679</comments>  
  <description><![CDATA[Some brief ideas and experiences with mobile themes/skins and their file formats, namely: Nokia Series 40 Theme NTH (1.0 and 2.1), Nokia Series 60 Theme SIS (2.6, 2.8 and 3.0), Sony-Ericsson Theme THM and Sony-Ericsson Theme UTZ. I enjoyed playing with those formats and implementing a parser/validator/extractor. It especially was a nice experience because these file-formats are mostly straight forward -> designed by people that know their job.<br/><br/><br/><b>Nokia NTH</b><br/><br/>The first theme I started playing with, was Nokia's Series40 Theme format (.nth). The tool for creating them is called "S40 Theme Studio", it is available through Nokia's developer forum and it is the worst piece of Java I ever had on my desktop. It is buggy, nightmarish slow and not intuitive at all. Well, but still i managed to create a few test themes for finding more details about that format.<br/><br/>NTH-files are ZIP-archives. The non-binary attributes of the theme is described in "theme_descriptor.xml". That descriptor has been revised only once; Version 1.0 and Version 2.1 have been released so far. Those themes run on a number of Nokia's Series 40 handsets starting from the 2nd edition.<br/><br/><br/><b>Sony-Ericsson THM</b><br/><br/>The Sony-Ericsson "Themes Creator" in contrast to Nokia's, does function perfectly fine, is very intuitive and stable. They have one tool to cover them all, so this baby actually produces two formats; THM and UTZ. First I looked at Sony-Ericsson's THM format. Most of the SE phones are "speaking" this format. <br/><br/>To my surprise, that format was pretty straight forward and really easy to parse. A THM-file actually is an uncompressed tar-file in the extended ustar-variant (http://en.wikipedia.org/wiki/Tgz). One little quirk is the way they encode the targeted device; it is shown as the "owner-user ID" of that tar-content (see TAR file-header on wickipedia). The first file within that tar-archive is always a file called "Theme.xml". That XML file, as usual, contains all non-binary theme data. Pictures are stored in common formats like PNG or JPEG. <br/><br/>"Theme.xml" has gone through seven public evolution steps, while remaining downward compatible (at least by that file's structure).<br/>Version 1.0: T68i, T300, T310, T230, T290<br/>Version 2.0: T610, T630, Z600, J210, Z300, J220, J230<br/>Version 3.0: Z1010, K700, S700, K500, Z500, K300, J300<br/>Version 3.1: V800, Z800<br/>Version 3.2: V800 Organic, Z800 Organic<br/>Version 4.0: K750, W800, W700, K600, Z520, Z525<br/>Version 4.5: K610, K800, K790, W850, Z710, W710<br/><br/><br/><b>Sony-Ericsson UTZ</b><br/><br/>The second format I received from Sony-Ericsson's "Theme Creator" was UTZ. UTZ-files are actually ZIP-archives. The first encoded file again is called "Theme.xml" and it defines all non binary attributes as well as linking binary data like JPEG-wallpapers and ringtones. Within the main-comment section of the ZIP file, Sony-Ericsson encodes the targeted device. Once again a bit quirky for my taste.<br/>Handsets that are listed to be compatible with the UTZ-format are: P900, P910, M600, W950, P990, M600, W950.<br/><br/><br/><b>EPOC SIS</b><br/><br/>This one turned out to be the toughest. For their Series 60 handset, Nokia uses the EPOC/Symbian installer packages (.sis). The tool for creating those themes is called "Series 60 Theme Studio" and it competes very well with the Series 40 tool mentioned above for a price called "worst software ever released". And I thought only the asians cant code...  <br/><br/>The SIS format has never been publicly documented, but there are some official tools for creating and even unpacking them manually (makesis and unsis). Those tools, written in perl, are already a great source for information on the file structure. The most valuable source however is the "SIS File Format" page http://homepage.ntlworld.com/thouky/software/psifs/sis.html created and maintained by Alexander Thoukydides. A super nice fellow, by the way - I had a question and he responded nice and quickly. <br/><br/>Packed with the knowledge found within the perl-tools and on Alexander's page, it became very easy to write a complete parser/deompressor for SIS-files. <br/>Within those SIS-files, Nokia's S60 themes contain the theme descriptor "THEMENAME.skn". This time, no plain XML is used. I decided not to attempt to parse the SKN-files as their existence was all I needed to know.<br/><br/>Nokia currently supports three different versions of those S60 Themes; 2.6, 2.8 and 3.0. The difference between 2.6 and 2.8 is the enhanced demands / enforced preconditions of the theme packages. Those demands or requisites are encoded using so called UID's. Unique Identifiers for products and platforms. Version 2.6 demands only UID 0x101F8582 (series 60 skinning support) whereas 2.8 also needs UID 0x10207113 (series 60 scalable skinning support).When using the format version 3.0, Nokia suddenly goes a totally different way; The SIS package has to be signed. <br/><br/>Signed SIS packages seem to have undergone another evolutionary step. These SIS files do not show the standard UID's in the header and don’t have any visible text-data when inspected with a hex-editor. Alexander's page does currently not cover those files. No SIS-tool that I have tried does support that format variant (unsis, unmakesis, viewsis, sistool, pdunsis). Most of those tools simply crash, some say "unsupported format". <br/><br/>I will call those Compressed Header SIS files or shortly chSIS.<br/><br/>Well, I didn’t find much but I sure want to share that with you.<br/><br/>chSIS Prefix Header:<br/><table cellspacing="4" cellpadding="0"><tr><td>00000000h:</td><td>4 byte</td><td>UID</td><td><b>0x10201A7A</b></td></tr><tr><td>00000004h:</td><td>4 byte</td><td>&nbsp;</td><td>0x00000000</td></tr><tr><td>00000008h:</td><td>4 byte</td><td>&nbsp;</td><td>0xA00000EB</td></tr><tr><td>0000000Ch:</td><td>4 byte</td><td>&nbsp;</td><td>0x2D360762</td></tr><tr><td>00000010h:</td><td>4 byte</td><td>&nbsp;</td><td>0x0000000C </td></tr><tr><td>00000014h:</td><td>2 byte</td><td>&nbsp;</td><td>0x000C</td></tr><tr><td>00000016h:</td><td>2 byte</td><td>&nbsp;</td><td>?</td></tr><tr><td>00000018h:</td><td>4 byte</td><td>&nbsp;</td><td>0x00000022</td></tr><tr><td>0000001Ch:</td><td>4 byte</td><td>&nbsp;</td><td>0x00000002</td></tr><tr><td>00000020h:</td><td>4 byte</td><td>&nbsp;</td><td>?</td></tr><tr><td>00000024h:</td><td>4 byte</td><td>&nbsp;</td><td>0x00000023</td></tr><tr><td>00000028h:</td><td>4 byte</td><td>&nbsp;</td><td>0x00000002 </td></tr><tr><td>0000002Ch:</td><td>4 byte</td><td>&nbsp;</td><td>?</td></tr><tr><td>00000030h:</td><td>4 byte</td><td>&nbsp;</td><td>0x00000003</td></tr><tr><td>00000034h:</td><td>4 byte</td><td>&nbsp;</td><td><b>compressed header size</b>: n</td></tr><tr><td>00000038h:</td><td>4 byte</td><td>&nbsp;</td><td>0x00000001</td></tr><tr><td>0000003Ch:</td><td>4 byte</td><td>&nbsp;</td><td><b>uncompressed header size</b></td></tr><tr><td>00000040h:</td><td>4 byte</td><td>&nbsp;</td><td>0x00000000</td></tr><tr><td>00000044h:</td><td><b>n byte</b></td><td>&nbsp;</td><td>compressed main header data</td></tr><tr><td colspan="4">[...]</td></tr><tr><td colspan="4">more compressed data records prefixed by short uncompressed headers.</td></tr></table><br/><br/>It appears that after that first block of compressed data (44h + n) more blocks with similar structures are concatenated. The compression used is compatible with zLib http://www.zlib.net. The compressed header data is not encoded like the usual, uncompressed SIS data records. Here comes a little example of such header after decompression.<br/><br/>Uncompressed main header example:<br/><pre><br/>00000000h: 0D 00 00 00 D0 09 00 00 0E 00 00 00 AE 00 00 00 ; ....Ð.......®...<br/>00000010h: 09 00 00 00 04 00 00 00 EB 00 00 A0 01 00 00 00 ; ........ë.. ....<br/>00000020h: 1C 00 00 00 55 00 6E 00 6B 00 6E 00 6F 00 77 00 ; ....U.n.k.n.o.w.<br/>00000030h: 6E 00 20 00 56 00 65 00 6E 00 64 00 6F 00 72 00 ; n. .V.e.n.d.o.r.<br/>00000040h: 02 00 00 00 1C 00 00 00 01 00 00 00 14 00 00 00 ; ................<br/>00000050h: 44 00 69 00 67 00 69 00 74 00 69 00 6C 00 65 00 ; D.i.g.i.t.i.l.e.<br/>00000060h: 73 00 32 00 02 00 00 00 1C 00 00 00 01 00 00 00 ; s.2.............<br/>[...]<br/></pre><br/>My first guesses and observations within that formerly compressed main header:<br/><pre><br/>00000000h:          4  byte 0x0000000D <br/>00000004h:          4  byte header size <br/>00000008h:          4  byte 0x0000000E<br/>0000000Ch:          4  byte ? (0xA6, 0xA3, ...)<br/>00000010h:          4  byte 0x00000009<br/>00000014h:          4  byte 0x00000004 <br/>00000018h:          4  byte 0xA00000EB<br/>---<br/>0000001Ch:          4  byte 0x00000001 = text data following<br/>00000020h:          4  byte vendor name size: n<br/>00000024h:          n  byte vendor name data<br/>---<br/>00000024h+n:        4  byte 0x00000002 <br/>00000028h+n:        4  byte record size: rm<br/>0000002Ch+n:        4  byte 0x00000001 = text data following<br/>00000030h+n:        4  byte component name size: m<br/>00000034h+n:        m  byte component name data<br/>                    rm-m byte padding 0x00<br/>---<br/>00000034h+n+rm:     4  byte 0x00000002 <br/>00000038h+n+rm:     4  byte record size ro<br/>0000003Ch+n+rm:     4  byte 0x00000001 = text data following<br/>00000040h+n+rm:     4  byte "Vendor-EN"-size: o<br/>00000044h+n+rm:     o  byte "Vendor-EN"-data<br/>                    ro-o byte padding 0x00<br/>---<br/>I stopped guessing at this point.<br/>[...]<br/></pre><br/>The way data is organized here and in some other locations make those compressed headers appear to be organized as WBXML data.<br/><br/>That is it, I did not drill any deeper as the demand simply isn’t there.<br/>]]></description>
  <pubDate>Wed, 28 Jun 2006 07:24:39 -0700</pubDate>
  <author>MMSGURU</author>
  <category>news</category>
  <guid>1151504679</guid>
</item>
<item>
  <title><![CDATA[A ringtone is a ringtone is a ringtone is a ringtone]]></title>
  <link>http://www.mmsguru.com/blogger/?action=entry&amp;id=1150907491</link>
  <comments>http://www.mmsguru.com/blogger/?action=comments&amp;id=1150907491</comments>  
  <description><![CDATA[Are reading news like: "the content market is going down", "mp3 handsets make ringtone sales superflous", ... ?<br/><br/>Well, here are my two pence:<br/><br/>That is male, wild cow excrement.<br/><br/>- Content sales are strongly connected to handset sales<br/>Especially true for games and applications, but also for ringtones etc. Currently the handset sales in europe are generally decreasing, hence also the content sales. Handset sales will dramatically increase again as soon as a new technology step is taken.<br/><br/>- The average MP3-song is not directly usable as a ringtone.<br/>A ringtone generally has a purpose!!! It alerts the user that somebody wants to talk to him. Many pop-tunes have intros that slowly build up and introduce the actual song theme. A proper ringtone catches only the most recognizable part of a song. The task of identifying, cutting and tweaking such part is definitely exceeding Joe Couch-Potatoe's abilities. <br/><br/>Rest assured, the market is not dying!]]></description>
  <pubDate>Wed, 21 Jun 2006 09:31:31 -0700</pubDate>
  <author>MMSGURU</author>
  <category>news</category>
  <guid>1150907491</guid>
</item>
<item>
  <title><![CDATA[Sagem's Rat Fake]]></title>
  <link>http://www.mmsguru.com/blogger/?action=entry&amp;id=1150304631</link>
  <comments>http://www.mmsguru.com/blogger/?action=comments&amp;id=1150304631</comments>  
  <description><![CDATA[Dont panic, this is gonna be a short one, promised...<br/><br/>Sagem, being a french cellphone manufacturer (among a zillion of other things), has "created" a custom format for their sample based ringtones. Well, to be precise, the file format is the well-known and documented WAVE-file-format (RIFF).<br/><br/>But the codec is not PCM. The wave-files are marked as being "BeCubed Software Inc. : Irat"-encoded (Format 101h).<br/><br/>One doesnt have to be particularly clever to suspect and prove that the used codec certainly is not the claimed one. <br/><br/>Actually, its almost a tradition to use that exact format identifier for self-defined codecs. Its wrong, but common. <br/><br/>Now, lets have a closer look at one of those files. You will notice that the filesize, when compared to the PCM template, has reduced roughly by factor four. Again, you will possibly guess, that is some kind of ADPCM, and you would be right.<br/><br/>When looking really close at those files, you will find out that they are actually super close to IMA ADPCM. Sagem has taken the original IMA ADPCM algorithm, changed some really minor things and claimed it to be a secure and high quality ringtone format. <br/><br/>It certainly is not - that is security by obfuscation; never worked, never will.]]></description>
  <pubDate>Wed, 14 Jun 2006 10:03:51 -0700</pubDate>
  <author>MMSGURU</author>
  <category>news</category>
  <guid>1150304631</guid>
</item>
    
  </channel>
</rss>