ModInfo - IT Comments

[Saga]

http://amp.dascene.net/analyzer2.php?idx=112446
Looking at the comments section of this IT module, it looks like all "0" characters are removed.
Also, the comments should definitely be presented using a monospace font.

[Asle]

Hi,

 Indeed, that's weird. the zero wouldn't display . Nice spot.
 I'll see if I can fix that.
 Regarding the font, I see your point and I'll check if we can have kind of universal monospace font. Anyone willing to give a hint, here would be welcome.

Cya
Sylvain
PS: it's a nice music by the way

[Saga]

PS: it's a nice music by the way

thanks

Are you looking for some kind of bitmap font? If that's the case, something cp437-ish should work, although there might be a way to obtain IT's original font from schism tracker or something. Otherwise, just using the font-family:monospace; and white-space:pre; CSS properties should suffice.

BTW, the Impulse Tracker version display is also a bit broken ("81.19"), because it doesn't take tracker IDs into account. For interpreting the version field correctly, see f.e. schism tracker's tracker detection code in http://schismtracker.org/hg/file/8a8ac76e23f9/fmt/it.c - the highest nibble in the version is the tracker ID (8 is OpenMPT) and the other three nibbles are the tracker version, so in this case it's OpenMPT 1.19.

"Size of pattern data" also seems to be kinda wrong (looks like one byte per pattern is counted).

Also, did you ever think about anti spam protection for email addresses in ModInfo? There are easy ways to obfuscate emails using CSS (so they are still readable when using a browser, but not when looking at the html code). If you're interested in a very simple solution for that, I can send you the details of my implementation.

[Saga]

So... any news on this?

[Asle]

Bah, none. Call it life.
*geee*, I'm on a lookout for spare time ...
I'll get over to this, eventually.

Just, thanks for your great informations !

[Asle]

ok, here's my code:

Code: [Select]

  $tmp_comment_addy = (ord($sp->Modhead[58])*256*256) + (ord($sp->Modhead[57])*256) + ord($sp->Modhead[56]);
  $tmp_comment_size = (ord($sp->Modhead[55])*256) + ord($sp->Modhead[54]);
  $sp->Modcomment = substr($sp->Modhead, $tmp_comment_addy, $tmp_comment_size);;
  $sp->Modcomment = str_replace(0x0d,'<BR />',$sp->Modcomment);
  $sp->Modcomment = str_replace(0x00,'',$sp->Modcomment);
If you can spot the problem ...

[Saga]

Knowing how horrible PHP is at reinterpreting all kinds of things into other things, I bet it's the last line. Try something like "\0" instead of 0x00, or remove it completely. It's not like NULs in a HTML file are as bad as NULs in a C string... Either way you're not doing the correct thing, because the only thing a NUL should do is terminating the message, if anything at all.

And while we're at it, you may also want to check for 0x0A in addition to 0x0D, as ChibiTracker uses UNIX style for line endings.

[Asle]

All right, seems to work now. Changed like this:

Code: [Select]

  $tmp_comment_addy = (ord($sp->Modhead[58])*256*256) + (ord($sp->Modhead[57])*256) + ord($sp->Modhead[56]);
  $tmp_comment_size = (ord($sp->Modhead[55])*256) + ord($sp->Modhead[54]);
  $sp->Modcomment = substr($sp->Modhead, $tmp_comment_addy, $tmp_comment_size);;
  $sp->Modcomment = str_replace(0x0d,'<BR />',$sp->Modcomment);
  $sp->Modcomment = str_replace(0x0a,'<BR />',$sp->Modcomment);
  $sp->Modcomment = str_replace(chr(00),'',$sp->Modcomment);I just hate these languages that assume they know what you want to do ...
Anyway

[Saga]

Much better, thanks!
Well, PHP is actually right here, it expects a string as a parameter, and 0x00 is not a string, so it converts it to something that is a string (0x00 is a pretty bad case because 0 has so many meanings...).
Generally I'd advice to use a fixed-width font and the CSS rule white-space:pre; for comments, not just in IT files. The CSS rule will make sure that multiple space characters are not condensed into a single one, effectively destroying any kind of ASCII art. In that case, you also don't have to replace 0x0A and 0x0D anymore, as the browser will take care of it.

So, for comments...

Code: [Select]

.comments
{
  white-space:pre;
  font-family: Consolas, monospace; /* Consolas is a nice monospace font on Windows */
} And apply that to the comments section.

[Asle]

done. Took some time and it involved the modification of several sources, but finally, comments should be displayed correctly now.
and thanks for the help

[Saga]

Thanks, that looks a lot better.
The next step would be to decode tracker versions correctly, so that it would display "OpenMPT 1.19" instead of "Impulse Tracker 81.19".
Here's some help on how to decode the "Cwtv" field correctly... http://wiki.openmpt.org/Development:_Formats/IT

Also, "size of pattern data :    33" in that particular example linked in the first post doesn't appear correct to me...

[Asle]

Very informative page about version/trackers ! Thanks for creating it !
Although I couldn't get every single case implemented, I trust I've handled the most frequent ones.

As for the size of pattern data, well, it's not retrieved at all. The figure displayed is the number of pattern saved.

There's also those compressed sample I have to handle, but, so far, I failed to understand such instrument headers.

Anyway, thanks again for your input. Much appreciated.
Sylvain

[Saga]

There's also those compressed sample I have to handle, but, so far, I failed to understand such instrument headers.

Which parts do you have problems with? I'm sure I can help there.
Sample flag 0x08 indicates that IT's compression is used... The sample's compressed length isn't stored anywhere in that case, it can only be really computed by decoding the sample, because you can't know which one is the last compressed chunk.

[Asle]

Sample flag 0x08 indicates that IT's compression is used... The sample's compressed length isn't stored anywhere in that case, it can only be really computed by decoding the sample, because you can't know which one is the last compressed chunk.

Identifying those samples is done. That's the size part where I'm in need for help.
I admit I've not searched too much, aside the usual docs, but I've found no way to decode those samples (so far), and thus, get the packed size.
So yes, any help (again) would be welcome.

[Saga]

I'm not really sure if you'd want to do that, especially on a server in PHP... But if you're really up for it, grabbing a pure C version of the decompression algorithm (such as SchismTracker's implementation + my fix for stereo samples in this implementation) would be the first thing to do...
If you don't want to decode the samples, another possible method to get the packed size would of course be to just subtract following sample pointers from each other and hope that trackers don't put any space in between (which they normally don't).