At 10:21 PM 4/28/2009, you wrote:
I personally have chosen IFF for such files. I'm sure there's a ton of
reasons why one is better than the other, but from my experience I
Right, you can make your own libraries to handle IFF stuff.
What Charles says is golden, make sure you include some format version
tags. My files include several, one for the file structure and one for
the data segments. This means I can change file structure whenever I
need to or I can change data structure when I need to.
Right, see below.
If you go down the binary route, make sure your code explicitly sets
the endianess, otherwise your files will be incompatible across
processors. binarystream.littleEndian = true
Very good point, all important. Some formats do little and big, some
do only big and some do only small. Most formats don't do both
though. I would choose little-only, because most processors are Intel
these days. There's less code burden that way.
Typically formats that do both have a byte-indicator of sorts, either
it's a single byte - the first byte in the file - that either 0 or 1,
or a long value of 1 where you check for 0001 or 1000.
I personally use a structure like below.
4 bytes String Document Type
4 bytes String Application ID
2 bytes Uint16 Version
<loop the following for as much data as you want to write>
4 bytes String Chunk ID
4 bytes Uint32 Chunk Length
.... ..... raw Chunk Data
Why not standard IFF?
4 bytes String Document Type ('RIFF' or 'FORM')
4 bytes Uint32 size of file, not including Document
Type or this length
4 bytes String Document ID
4 bytes String Document Header (anything, like 'mhdr')
4 bytes Uint32 size of header chunk (does not
include ID or length)
4 bytes Uint32 Version of Document
x bytes ------ other data
<loop the following for as much data as you want to write>
4 bytes String Chunk ID
4 bytes Uint32 Chunk Length (does not include Chunk
ID or length)
4 bytes Uint32 Version of chunk
....... ...... raw Chunk Data
(That 2 byte thing throws the format off of standard 4 bytes boundaries)
Also, remember that the IFF spec (usually RIFF) nests things this way:
LIST (4 bytes)
size of ALL chunks listed (4 bytes)
list Type string (4 bytes)
Then you do chunks, and categorically they all fall under the List
category. The nice thing about nests is that a parser can skip over
the whole thing without have to travel through all chunks internally.
Lastly, remember when you have a chunk that is of odd-numbered size,
the size should reflect that, but you need to add a pad byte to make
ALL chunks even. This is IFF spec, that was noted because of Mac's
have even-numbered 16-bit boundaries. Although these days 32-bits is
the understood boundary, historically formats always abide by at
least even boundaries, they rarely adhere to 4-byte boundaries. Most
good specs do not use 2-byte or 1-byte anything - they are totally
based on floats, doubles, Uint64, or 32-bit integers. When it comes
time for a byte or a bitfield, it sits in a 32-bit field. Most
programmers these days understand that the processor thinks is 32-bit
packets anyway and "saving space" isn't really saving space.
* * * * * * * * * * * * * * * * * * * * * * * * * * *
| Garth Hjelte |
| Customer Service Representative, President |
| Chicken Systems, Inc, Rubber Chicken Software Co. |
| 714 5th Street SE |
| Willmar, MN 56201 USA |
| |
| 800-8-PRO-EPS Toll Free Order Line (US Only) |
| 320-235-9798 Tech Support, Sampler Questions |
| International Line |
| 360-838-7689 Fax |
| Product Sales: sales@chickensys.com |
| Product Support: support@chickensys.com |
| Sampler Q+A: qa@chickensys.com |
| Web Page: www.chickensys.com |
* * * * * * * * * * * * * * * * * * * * * * * * * * *
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|