Amiga Music Preservation - Forum

Support / Feedback => Support / Feedback => Topic started by: Saga on October 16, 2011, 15:52:23

Title: ModInfo - IT Comments
Post by: Saga on October 16, 2011, 15:52:23
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.
Title: Re: ModInfo - IT Comments
Post by: Asle on October 16, 2011, 23:33:31
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 :)
Title: Re: ModInfo - IT Comments
Post by: Saga on October 17, 2011, 20:13:46
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.
Title: Re: ModInfo - IT Comments
Post by: Saga on August 03, 2012, 23:20:02
So... any news on this?
Title: Re: ModInfo - IT Comments
Post by: Asle on August 11, 2012, 21:36:05
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 !
Title: Re: ModInfo - IT Comments
Post by: Asle on June 30, 2013, 02:12:45
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 ...
Title: Re: ModInfo - IT Comments
Post by: Saga on June 30, 2013, 02:15:44
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.
Title: Re: ModInfo - IT Comments
Post by: Asle on June 30, 2013, 02:50:22
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
Title: Re: ModInfo - IT Comments
Post by: Saga on June 30, 2013, 02:52:39
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.
Title: Re: ModInfo - IT Comments
Post by: Asle on July 01, 2013, 20:04:06
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 :)
Title: Re: ModInfo - IT Comments
Post by: Saga on July 01, 2013, 20:58:45
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... :)
Title: Re: ModInfo - IT Comments
Post by: Asle on July 01, 2013, 22:37:00
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
Title: Re: ModInfo - IT Comments
Post by: Saga on July 01, 2013, 22:43:49
Quote
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.
Title: Re: ModInfo - IT Comments
Post by: Asle on July 02, 2013, 00:31:31
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.
Title: Re: ModInfo - IT Comments
Post by: Saga on July 02, 2013, 00:36:53
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 (http://schismtracker.org/hg/file/b8d881c4f665/fmt/compression.c) + my fix for stereo samples in this implementation (http://schismtracker.org/scdev/res/1705.html)) 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).
Title: Re: ModInfo - IT Comments
Post by: Asle on July 02, 2013, 21:53:05
sounds indeed complex. I don't think that I'll bother with PHP.
The idea is to calculate the correct size of the file. Basically, I'm browsing through the instruments, not caring much whether there's crunched samples ... until the last one. File size wise, that's really where it happens. So calculating the size of the last sample would do the trick.
Oh well, I'll keep this clean source handy and will see if there's something to do over the week-end, about that.

And with my thanks again :)
Title: Re: ModInfo - IT Comments
Post by: Saga on July 02, 2013, 23:31:40
I can understand how this feature is useful for old broken mods, especially if there are bad rips and such, but I think for IT files it's rather uesless - I think I've never really seen IT files that are too big or too small, apart from those which have extra chunks like those that MPT/BeRoTracker/UNMO3 write if plugins are being used.