I use Cyotek Color Palette Editor version 18.104.22.1688 to create Microsoft RIFF
Palette. Examples with only 1 color like yellow.pal and also example
with more colors like col300.pal are OK.
When i try to create examples with more colors like black16387.pal and
col32767-data0.pal something went wrong. Maybe not really usable but
probably allowed by specifications. First program use a lot of time (some
minutes with sand glass like animation) and finally produce data inconsistent
As reference i use "Multimedia Programming Interface and Data Specifications
1.0" older than 1991 found for example at
www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/ as "riffmci.pdf"
and a more readable short interpretation found athttp://worms2d.info/Palette_file
At offset 16 data chunk size is stored as long value. The size should be
calculated by formula:
palVersion + palNumEntries + palPalEntry =
2 + 2 + palPalEntry
where palPalEntry is the raw palette or color vector which size is calculated
number of color entries * 4
But for bad examples this size is too low. For black16387.pal value is 16
and in col32767-data0.pal value is 0. In last case correct value should be
131072 like in col32767.pal.
This wrong data chunk size can be see in in output of patched file(1)
command (see appended output/file-new.txt). I verified sizes also by
using a riff editor like riffpad.exe.
On the other hand i found examples with a higher data size. Graphic tool
Xnview 2.40 produce such examples. I also found examples like
Protan(MS).pal (with 256 colors and data size 1032 instead 1028) on the net
. That means some pal files
contain some (found 4) extra bytes after color vector. This is not logical
but not explicitly forbidden by documentation.
At offset 4 riff size is stored as long value. Then the following
formula should be true:
file size = riff size + 8 = data size + 12 + 8
But when we compare real size mentioned in output/ls-la.txt with calculated
bytes based on riff size in output/file.txt we see in Xnview generated
examples like "iEditor.pal" real file size is 4 bytes lower.
This inconsistency in data apparently do not hurt, if graphic software just
reads number of colors, then calculate color vector size and then reads this
Used OS is Windows version 10.0.14393 inside Virtualbox 5.1.28r117968.
Some examples and output are stored in archive pal_cy.zip.
I hope that this minor bug can be fixed.
With best wishes