(hey, i already posted this in the n00b s0z section. sorry for creating clutter, but i'm not exactly sure how often people wander into that section of the forums. i know i never do :x)

n00b s0z

I'm making my way through a 48k entry and keeping a close eye on the file size as I work, but windows is giving me two different numbers, "Size" and "Size on disk".

Which one is the number that the site looks at for the size cap?

Also, any tips for keeping the size down besides downsampling the samples?

And what affects file size more, the number of rows and commands or overall tick count?

Are there any resources on the details of this? I know greaser had made a lyceum article on this, but I can't seem to find it anymore.

Thanks!

Ignore the OS's kB count. What you really want is the raw byte size (49152 bytes).

GM did have a nice article on optimization, I'll see if I can find it...

Also, if you're using XM and not using envelopes, run that sucker through BoobieSqueezer to drop a kB or two, if using IT run it through munch.py.

just pay attention to both of them i guess.

if you hit the limit, 48k should be the size on disk but the size can be from 44k-48k.

you'll be fine either way but just make sure neither of them are over 48k. you'll know when you're over when size on disk becomes 52k (i don't know why size on disk makes 4 kb jumps, maybe someone can inform me on that?)

edit: yeah you should definitely pay attention more to the raw byte size as well but this was just my method and it seems to work well (because 48k isnt actually 48000 bytes)

goluigi:
"(i don't know why size on disk makes 4 kb jumps, maybe someone can inform me on that?)"

It's because size on disk counts in terms of disk sectors. On that partition, one sector is 4kB. Thus, size on disk will be in multiples of 4kB [it could be different on different size drives, it's based on how much space overhead the FAT table would incur vs how much space overhead unfilled sectors would incur, such as having lots of small files]. Even if the file doesn't use the entirety of that sector, it still belongs to the file, and counts towards the space it takes up on the drive.

'Size' is the only one that matters for uploads.

You are referring to cluster size, which can vary a lot. Sector size is the fixed 512 byte physical size. (or 4kB on much newer drives). But what is counted by the filesystem is actually cluster size, you can change cluster size to whatever the filesystem supports,
so technically you can make a 1kB file take 64kB if you want.

hey, thanks guys!

i found GM's article btw http://battleofthebits.com/lyceum/View/IT+Module+Optimisation/

kinda helps, kind doesn't since i'm using xm. maybe i should just finally Make The Switch

Maybe i will make an XM Optimization guide one day! but that would obviously ruin my "optimizing XM for boons" business..

how bout i give you all my boons to make one ???

always treated Size on disc is a Time to defrag! thing and gnothing more

youare tearing me apart, zanzan!


also strobe, i'm 100% srs, all b3763.28 if you say yes to a timely(within the next week or so) xm guide. hmmhmhmm?!!? hmmmmmmMM?!

This is taken under consideration!

if you're willing to do a bit of reading you could look at the XM file format specification ( http://sourceforge.net/projects/ufmod/files/XM%20file%20format%20specification/FastTracker%20II%2C%20ADPCM%20XM%20and%20Stripped%20XM/ )

[edited to fix URL]

oh, thank you!

i wondered if there was such a thing somewhere, but a bit too clueless to know what keywords to search with. will read.



(update for the sake of future forum reference seekers:

In the xm.doc, I went immediately to the section describing the pattern header. One useful thing to know about pattern optimization is that pattern data size is calculated by

(number of rows) * (number of channels)

The number of ticks per row apparently has no consequence, which is awesome. You can have smooth and detailed envelopes without paying for it with data(or so it seems).

So at least one aspect of pattern optimization involves using the least amount of rows the music can afford. It comes down to understanding which ticks certain musical details fall on and trying to use effect commands to achieve similar things with your limited rows. This or multiplying the speed just for sections where you need certain details that limited rows and effects can't give you.

It does free up quite a bit. I basically just halved the number of rows, which reduced my size from 53kb to 45kb.

idk if this was common knowledge already, but if anyone's got something to add, feel free! I'm sure there's some sample optimization voodoo out there. I'm currently looking through the sample stuff in the xm.doc. Will share whatever else I find if I think it's useful.)

If gyms want to i'm willing to take a look at the XM to see what i can
make out of it! (as in seeing what actual optimizations are possible)

there are two things really to take into consideration

1) more rows = bigger

2) most songs have a lot of redundant data

say i have made a little ode to joy module:

pattern 1: E E F G G F E D C C D E E DD
pattern 2: E E F G G F E D C C D E D CC
orderlist: 1, 2

there's a load of redundant data. to make it smaller you do something like

pattern 1: E E F G G F E D C C D E
pattern 2: E DD
pattern 3: D CC
orderlist: 1, 2, 1, 3

there was 30 notes of pattern data in the first one and only 18 in the second one. obviously that is an oversimplification but that is basically the most effective way to optimise pattern data

hey, thanks for the replies.

ant1, that does help a lot. it never really occurred to me to view my patterns like that.

strobe, i'll probably come knocking after a good go

Also columns per pattern makes things big too. If there is any pattern where you can collapse out a column towards the left, you'll save space there too. Another big one I noticed with Impulse Tracker is instruments take up a shitload of data compared to meer samples. I used to think that I could save space by reusing samples in multiple instruments with different envelopes, but at tiny module sizes the trade-offs can turn out to be a misnomer.

impulse tracker instruments are 554 bytes each no matter what they have in them. (plus the sample data)

you can collapse columns per pattern?

manually

basically don't use channel 5 if channel 1, 2, 3 or 4 is empty. even if you were using channel 5 before or you want to use a different instrument or it makes sense in your head or whatever