Re: state of metadata?
- From: bob cs csoft net
- To: Antonio Campos <acampos ceronet com>
- cc: "gnome-devel-list gnome org" <gnome-devel-list gnome org>, recipient list not shown: ;
- Subject: Re: state of metadata?
- Date: Sat, 18 Dec 1999 16:04:33 -0600 (CST)
Well, recently I have become reinterested in bbs's. Looking through
some source, I found this textfile (attached). It describes a way of
tagging metadata safely into the files itself. Could one of the metadata
guru's have a look over it? Thanks.
On Sat, 18 Dec 1999, Antonio Campos wrote:
> What is the state of metadata?
> Does anybody know if EXT3 is going to bring some metadata support?
> The problem with metadata external to the filesystem is that not
> GUI tools (like mv, rm, etc.) could interfere with metadata. There has
> been a big issue on gnome-ui-list about a trash icon in Gnome, but many
> things are difficult to implement without metadata support in the
> filesystem. (above all, problems related to not GUI tools).
>
>
>
>
> --
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.
>
旼컴컴컴컴컴컴컴컴컴컴컴컴캠
� What is SAUCE? �
익袴袴袴袴袴袴袴袴袴袴袴袴暠
Recipe for SAUCE
Chef cuisinier : Tasmaniac / ACiD
Maitre d'h뱓el : RaD Man / ACiD
ANSi's used to be just ANSi's, pictures were just pictures,
loaders were just loaders and quite frankly, every file was just
as plain tasting as every other. This is about to change, how-
ever, because ACiD has decided to give their files an extra
"je-ne-sais-quoi." In reality, we'll be adding SAUCE to every
file you can imagine.
Now, before we thoroughly confuse you, let us explain what we
are doing here. SAUCE stands for "Standard Architecture for
Universal Comment Extensions." Although originally intended for
personal use in ANSi's and RIP screens, early in the developement
of EFI (Extended File Information) it was decided that EFI should
be extended to have support for more than just ANSi and RIP
screens. Our brainchild was born and the specs were designed.
The only aspect left undecided was the name, and after rejecting
some very funny candidates, SAUCE was unanimously chosen. This
leads us to the big question in the sky, "What is SAUCE ?" SAUCE
is a universal process to incorporate a full description for any
type of file. The most outstanding aspect of this concept is that
you have access to the complete file name, the file's title, the
creation date, the creator of the file, the group that the creator
is employed by, and much, much, more.
A full explanation on how you can implement SAUCE is
described at the end of this document in the PLATES (Programming
Language Architecture To Extract SAUCE) section. Although you can
create your own programs to implement SAUCE to your files, we
recommend that you use the SPOON.EXE program to ensure a greater
universal compatibility.
SAUCE already supports a plethora of filetypes (See PLATES).
If you have a need for the SAUCE specifications, please contact us
before you make the changes yourself. We will accomodate your
needs as soon as possible. After all, SAUCE is designed to become
a standard, and if people change the specs without allowing us to
make a complete update, there will be no standard. In the event
that we change SAUCE, we will quickly release a public update
which will most definately include an improved and updated
SPOON.EXE.
SAUCE has advantages over any other system in use. Each
description will be added to the file and will provide a file
description no matter what computer it is used for. SAUCE, how-
ever, also provides a back compatibility that uses a file with
descriptions for those files that do NOT already have a SAUCE
description. Processing in this manner is fully implemented in
SPOON.EXE and one can extract embedded SAUCE to this data file and
add SAUCE to files from this data file.
旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커
� �
� ! NOTICE ! �
� �
� SAUCE was initially created for supporting only the ANSi & RIP �
� screens. Since both ANSi and RIP are in effect text-based and �
� have no other form of control, SAUCE never interferes with the �
� workings of a program using either ANSi or RIP. If it does, �
� the program is not functioning the way it should. �
� This is _NOT_ true for the other types of file SAUCE supports �
� however. Adding SAUCE to some of the other filetypes supported �
� in the SAUCE specifications may have serious consequences on �
� the proper functioning of other programs using those files, �
� In the worst case, they'll simply refuse the file, stating it �
� is invalid. �
� �
� It's not up to us to decide whether or not adding SAUCE is a �
� bad thing. The one who added the SAUCE to the file should be �
� fully aware of any problems that can arise when 'SAUCEing' a �
� file other than the 'Character' or XBIN datatypes. �
� �
� You may have your own specialized viewing/editing tools and �
� simply not care about the file not being recognized in other �
� viewing/editing programs. �
� �
읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸
PLATES
------
Let us begin with a description of the record layouts used.
The record layouts and code examples are in a variated pascal
pseudo code, and should be transferrable enough to implement in
most other programming languages. For ease of reading, the
examples assume that the file is correct and that no error-
checking need be included. How rigorous you check for errors is
completely up to you, and will most likely depend on the file type
you are describing.
SAUCE RECORD
------------
This portion of the documentation is about the SAUCE record.
The SAUCE record describes the file in short, and provides other
information not included in the SAUCE record itself.
A sauce record is _EXACTLY_ 128 bytes in size.
Fieldname : Name of the field.
Size : Size of the field in BYTES
Type : Type of data. This can be :
BYTE : One byte unsigned numeric value (0 to 255)
WORD : Two byte unsigned numeric value (0 to 65535)
INTEGER : Two byte signed numeric value (-32768 to 32767)
LONG : Four byte signed numeric value (-2147483648 to 2147483647)
CHARACTER : One byte ASCII value. Longer character fields are
padded with spaces. It is _NOT_ a PASCAL string (with a
leading length byte), and it's _NOT_ a C-Style string
(with a trailing nul-byte). A 10 byte character field
holding the text 'ANSI' would look like this: 'ANSI '.
Numeric fields should be zero when not used, character fields
should be all spaces when not used.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
No fields are REQUIRED to be filled in except for ID, Version, FileSize,
DataType and FileType.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
V# : SAUCE Version number. This indicates the version of
SAUCE when the field was implemented.
Description : Complete description of the field.
FieldName Size Type V# Description
--------- ---- --------- -- -----------
ID 5 Character 00 SAUCE Identification. This should be equal to
'SAUCE' or the record is not a valid SAUCE
record.
Version 2 Character 00 Version number of SAUCE. Current version is
'00'. As new features are added to the
specifications of SAUCE, this version number
will change. Future versions SHOULD remain
compatible with version 00 only ADDING on
the specifications, it is however not unlikely
that this compatibility is impossible to
maintain, but this is of no concern now.
Title 35 Character 00 Title of the file.
Author 20 Character 00 Name or handle of the creator of the file.
Group 20 Character 00 Name of the group/company the creator is
employed by.
Date 8 Character 00 Date the file was created. This date is in
the format CCYYMMDD (Century, year, month,
day). By storing it in this way, it's very
easy to sort SAUCE records by date.
FileSize 4 Long 00 Original filesize NOT including any
information of SAUCE.
DataType 1 Byte 00 Type of Data. (See DATATYPES further on)
FileType 1 Byte 00 Type of File. (See DATATYPES further on)
TInfo1 2 Word 00 Numeric information field 1 (See DATATYPES)
When used, this field holds informative
values. Any program using SAUCE should not
rely on these values being correct or filled
in.
TInfo2 2 Word 00 Numeric information field 2 (See DATATYPES)
TInfo3 2 Word 00 Numeric information field 3 (See DATATYPES)
TInfo4 2 Word 00 Numeric information field 4 (See DATATYPES)
Comments 1 Byte 00 Number of Comment lines (See COMMENTS)
Flags 1 Byte * 00 Flags indication optional settings/switches
These flags have different meaning depending
on the datatype & filetype .
The flags weren't originally in the concept
for version 00 of SAUCE. But since the
specification of SAUCE expects all filler
bytes to be binary zero, the flags should be
set to ZERO in all previous files, and cause
no harm.
An Example PASCAL record looks like this:
TYPE SAUCERec = RECORD
ID : Array[1..5] of Char;
Version : Array[1..2] of Char;
Title : Array[1..35] of Char;
Author : Array[1..20] of Char;
Group : Array[1..20] of Char;
Date : Array[1..8] of Char;
FileSize : Longint;
DataType : Byte;
FileType : Byte;
TInfo1 : Word;
TInfo2 : Word;
TInfo3 : Word;
TInfo4 : Word;
Comments : Byte;
Flags : Byte;
Filler : Array[1..22] of Char;
END;
An Example C record looks like this:
typedef SAUCEREC {
char ID[5];
char Version[2];
char Title[35];
char Author[20];
char Group[20];
char Date[8];
signed long FileSize;
unsigned char DataType;
unsigned char FileType;
unsigned short TInfo1;
unsigned short TInfo2;
unsigned short TInfo3;
unsigned short TInfo4;
unsigned char Comments;
unsigned char Flags;
char Filler[22];
} SAUCEREC;
DATATYPES
---------
DataType and FileType hold the information needed to deter-
mine what type of file it is.
There are 5 DataTypes, these are (with their respective numeric values) :
0) None : Undefined filetype, you could use this to add SAUCE
information to personal datafiles needed by programs,
but not having any other meaning.
1) Character : Any character based file. Examples are ASCII, ANSi and
RIP.
2) Graphics : Any bitmap graphic file. Examples are GIF, LBM, and
PCX.
3) Vector : Any vector based graphic file. Examples are DXF and
CAD files.
4) Sound : Any sound related file. Examples are samples, MOD
files and MIDI.
5) BinaryText: This is RAW memory copy of a text screen. It's
basically the BIN format you can save from whitin
TheDraw. Each character is built up of two consecutive
bytes. The first is the character to be displayed. The
second is the Attribute byte.
6) XBIN : XBIN is the so called eXtended BIN format. It is
similar to the BinaryText, but provides for fonts,
palettes, and has built-in compression.
7) Archive : Any type of archive. Examples are ARC, ZIP, ARJ and
LZH.
8) Executable: Any file that is executable.
None
----
When using the 'None' datatype, you should have FileType set to
zero also. This is a compatibility issue as it's not unlikely,
the 'None' datatype will have filetypes in the future.
Character
---------
When using the 'Character' datatype, you have following filetypes
available :
0) ASCII : Plain text file with no formatting codes or color codes.
TInfo1 is used for the width of the file.
TInfo2 is used to hold the number of lines in the file.
1) ANSi : ANSi file. With ANSi color codes and cursor
positioning.
TInfo1 is used for the width of the file.
TInfo2 is used to hold the number of ANSi screen lines
in the file.
2) ANSiMation: ANSi Animation. With ANSi color codes and cursor
positioning. While an ANSi file can also have animated
sequences, there is a clear distinction. While an ANSi
may or may not have a beginning animated sequence
introducing the group or artist the rest is just a
sequence of colored characters. An ANSiMation on the
other hand is a more like a text mode cartoon.
TInfo1 is used for the width of the file.
TInfo2 is used to hold the number of ANSi screen lines
the ANSiMation was created for.
A program using SAUCE may use these two values to
switch to the appropriate video mode.
3) RIP : Remote Imaging Protocol (RIP) graphics file.
TInfo1 holds the width (should be 640)
TInfo2 holds the height (should be 350)
TInfo3 holds the number of colors (should be 16)
4) PCBoard : File with PCBoard style @X color codes and @ macro's
and ANSi codes.
TInfo1 is used for the width of the file.
TInfo2 is used to hold the number of ANSi screen lines
in the file.
5) AVATAR : A file with AVATAR and ANSi color codes and cursor
positioning.
6) HTML : HyperText Markup Language. The type of file used on
World Wide Web (WWW).
7) SOURCE : A piece of sourcecode for any type of programming
language. The file extention should determine the
programming language (.C=C, .PAS=Pascal, ...)
FLAGS for the Character Datatype.
-----
旼 7 컫� 6 컫� 5 컫� 4 컫� 3 컫� 2 컫� 1 컫� 0 커
� � � � � � � � �
� 0 � 0 � 0 � 0 � 0 � 0 � 0 � A �
� � � � � � � � �
읕컴컴좔컴컴좔컴컴좔컴컴좔컴컴좔컴컴좔컴컴좔컴컴�
All non-used bits should be ZERO.
A) Non-Blink mode (iCE Color).
When this bit is SET (equal to 1) The ANSi is created using iCE
color codes. This is a special mode where the blinking is
disabled, and you have 16 background colors available. Basically,
you have the same choice for background colors as for foreground
colors.
Please note:
When the picture does not make specific use of the iCE color, you
should NOT have this bit set. When you do not support the iCE
color mode, you should probably not display the file as it could
look pretty weird in normal mode.
Graphics
--------
旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커
� WARNING: Adding SAUCE to some of these files can make them �
� invalid. See the NOTICE at the start of this document. �
읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸
For all graphics types, TInfo1 holds width of the image, TInfo2
holds the Height of the image and TInfo3 holds the number of bits
per pixel (a 256 colour image would have 8 bits per pixel, a
TrueColour image would have 24);
Following Graphics filetypes are available :
0) GIF (CompuServe Graphics Interchange format)
1) PCX (ZSoft Paintbrush PCX format)
2) LBM/IFF (DeluxePaint LBM/IFF format)
3) TGA (Targa Truecolor)
4) FLI (Autodesk FLI animation file)
5) FLC (Autodesk FLC animation file)
6) BMP (Windows or OS/2 Bitmap)
7) GL (Grasp GL Animation)
8) DL (DL Animation)
9) WPG (Wordperfect Bitmap)
10) PNG (Portable Graphics)
11) JPG (JPeg compressed File)
12) MPG (MPeg compressed animation/video)
13) AVI (Audio Visual Interlace)
FLAGS
-----
Not used, should be all zeroes.
Vector
------
旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커
� WARNING: Adding SAUCE to some of these files will make them �
� invalid. See the NOTICE at the start of this document. �
읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸
Following Vector filetypes are available :
0) DXF (CAD Data eXchange File)
1) DWG (AutoCAD Drawing file)
2) WPG (WordPerfect/DrawPerfect vector graphics)
3) 3DS (3D Studio file).
FLAGS
-----
Not used, should be all zeroes.
Sound
-----
旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커
� WARNING: Adding SAUCE to some of these files will make them �
� invalid. See the NOTICE at the start of this document. �
읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸
Following sound filetypes are available :
0) MOD (4, 6 or 8 channel MOD/NST file)
1) 669 (Renaissance 8 channel 669 format)
2) STM (Future Crew 4 channel ScreamTracker format)
3) S3M (Future Crew variable channel ScreamTracker3 format)
4) MTM (Renaissance variable channel MultiTracker Module)
5) FAR (Farandole composer module)
6) ULT (UltraTracker module)
7) AMF (DMP/DSMI Advanced Module Format)
8) DMF (Delusion Digital Music Format (XTracker))
9) OKT (Oktalyser module)
10) ROL (AdLib ROL file (FM))
11) CMF (Creative Labs FM)
12) MIDI (MIDI file)
13) SADT (SAdT composer FM Module)
14) VOC (Creative Labs Sample)
15) WAV (Windows Wave file)
16) SMP8 (8 Bit Sample, TInfo1 holds sampling rate)
17) SMP8S (8 Bit sample stereo, TInfo1 holds sampling rate)
18) SMP16 (16 Bit sample, TInfo1 holds sampling rate)
19) SMP16S (16 Bit sample stereo, TInfo1 holds sampling rate)
20) PATCH8 (8 Bit patch-file)
21) PATCH16(16 Bit Patch-file)
22) XM (FastTracker ][ Module)
23) HSC (HSC Module)
FLAGS
-----
Not used, should be all zeroes.
BinaryText
----------
The Binary Text format, basically has no Filetype, since the datatype
has already defined how the file will look.
The FileType however specifies the WIDTH of the BinaryText screen.
Only the Width is required, as the Height can be calculated by dividing
the filesize by the Width.
In an attempt to provide as much WIDTH as possible in a possible 256
values of the Byte-sized FileType. The width is specified in Multiples
of 2. The fact that the Width is specified in multiples of 2 isn't
really a problem, since you also need to define the effective screen
size in multiples of 2.
An example : For normal 80*25 binary images as made with TheDraw the
FileType value would be 40 (since 2*40 equals 80 <g>)
All you need to do is divide the width of the binary text
image by 2. This gives a maximum width of 510 characters.
Although currently not supported, should there be a need
for even bigger images, this can be arranged.
Please note. BinaryText expects the character-attribute pairs to be
stored one row at a time. If you wanted to create a 80*100 Image, you
could do this by just copying 4 80*25 or 2 80*50 together to form one
bigger image.
If for example you wanted to create a 160*25 image from 2 80*25 images,
you would need to write a little program which would copy line 1 from
image 1, line 1 from image 2, Line 2 from Image 1, Line 2 from Image 2
and so on.
Basically, you should have all character-attribute pairs from one line
of the COMPLETE image one after the other, followed by all
char-attribute pairs from the next row, and so on.
If the picture does not fit this format. You should use the NONE
datatype. Besides, you'd probably want to have it in this format
anyway, as it seems to be the most logical approach to have these kind
of images.
FLAGS for the BinaryText Datatype.
-----
旼 7 컫� 6 컫� 5 컫� 4 컫� 3 컫� 2 컫� 1 컫� 0 커
� � � � � � � � �
� 0 � 0 � 0 � 0 � 0 � 0 � 0 � A �
� � � � � � � � �
읕컴컴좔컴컴좔컴컴좔컴컴좔컴컴좔컴컴좔컴컴좔컴컴�
All non-used bits should be ZERO.
A) Non-blink mode (iCE Color).
This bit has exactly the same meaning as for the Character
datatype. It indicates whether the picture uses iCE color.
XBIN
----
The XBIN datatype has no other filetypes. Further specification son
the XBIN format are available in the XBIN archive or on the XBIN Web
page.
The filetype should be zero.
TInfo1 holds width of the image, TInfo2 holds the Height of the image.
FLAGS
-----
Not used, should be all zeroes.
Archive
-------
旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커
� WARNING: Adding SAUCE to some of these files can make them �
� invalid. See the NOTICE at the start of this document. �
읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸
Following sound filetypes are available :
0) ZIP (PKWare)
1) ARJ (Robert K. Jung)
2) LZH (Haruyasu Yoshizaki (Yoshi))
3) ARC (SEA)
4) TAR (Unix TAR format)
5) ZOO
6) RAR
7) UC2
8) PAK
9) SQZ
FLAGS
-----
Not used, should be all zeroes.
Executable
----------
旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커
� WARNING: Adding SAUCE to some of these files can make them �
� invalid. See the NOTICE at the start of this document. �
읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸
The executable datatype has no other filetypes. Executables usually
have any of the following file extentions : BAT, COM, EXE, OVL, OVR,
DLL, ...
The filetype should be zero.
FLAGS
-----
Not used, should be all zeroes.
COMMENTS
--------
The comment block is an addition to the SAUCE record. It
holds up to 255 lines of additional information. Each line 64
characters wide.
When the Comments field is not zero, it holds the number of
additional comment lines available. A single comment line is 64
characters long. Like the character fields in the SAUCE record,
it is padded with spaces, and has no leading length byte or
trailing null-byte.
The comment block is preceded with a 5 character identifi-
cation mark. This identification mark is 'COMNT'.
SAUCE IN FILES
--------------
A file with SAUCE added to it. Will look like this:
旼컴컴컴컴컴컴컴�
� �
� FILE DATA � Actual file data. As if it would be without SAUCE.
� �
쳐컴컴컴컴컴컴컴�
� �
� EOF MARKER � EOF marker. This will assure character files can
� � easily determine the end of file.
쳐컴컴컴컴컴컴컴�
� �
� COMMENT BLOCK � Optional Comment block.
� �
쳐컴컴컴컴컴컴컴�
� �
� SAUCE RECORD � SAUCE record.
� �
읕컴컴컴컴컴컴컴�
The Comment block
旼컴컴컴컴컴컴컴�
� �
� 'COMNT' � Comment block ID bytes
� �
쳐컴컴컴컴컴컴컴�
� �
� COMMENTLINE 1 � First comment line
� �
쳐컴컴컴컴컴컴컴�
� �
� COMMENTLINE 2 � Second comment line
� �
쳐컴컴컴컴컴컴컴�
...
쳐컴컴컴컴컴컴컴�
� �
� COMMENTLINE N � n-th comment line, n equals the Comments field
� � in SAUCE record.
읕컴컴컴컴컴컴컴�
EXAMPLE CODE TO READ SAUCE
--------------------------
Variables:
Byte : Count;
Long : FileSize;
file : F;
Code:
Open_File(F); | Open the file for read access
FileSize = Size_of_file(F); | Determine filesize
Seek_file (F, FileSize-128); | Seek to start of SAUCE (Eof-128)
Read_File (F, SAUCE); | Read the SAUCE record
IF SAUCE.ID="SAUCE" THEN | ID bytes match "SAUCE" ?
IF SAUCE.Comments>0 THEN | Is there a comment block ?
Seek_File(F, FileSize-128-(SAUCE.Comments*64)-5);
| Seek to start of Comment block.
Read_File(F, CommentID); | Read Comment ID.
IF CommentID="COMNT" THEN | Comment ID matches "COMNT" ?
For Count=1 to SAUCE.Comments| \ Read all comment lines.
Read_File(F, CommentLine) | /
ENDFOR
ELSE
Invalid_Comment; | Non fatal, No comment present.
ENDIF
ENDIF
ELSE
Invalid_SAUCE; | No valid SAUCE record was found.
ENDIF
SOURCECODE AVAILABILITY
-----------------------
A fully working implementation for SAUCE extraction is available
as a PASCAL unit. The extraction code itself is implemented in
built-in Assembly. It should be fairly easy to port the source
code to C. SAUCE_.PAS should be available in the ACiD Acquisitions
and on the SAUCE Web page
INFORMATION OR UPGRADES
-----------------------
If you have a need for additional information on SAUCE, or
need modifications, you can contact me at these places...
email:
tas@acid.org
SAUCE Web Page :
http://uc2.unicall.be/tasmaniac/sauce.htm
(!) This page is still being constructed, it may not yet be
available at the time you are reading this. The page
will contain up to date information about the SAUCE
specifications and implementations of SAUCE.
BBS:
Leave a message to TASMANIAC on any of these boards :
Neo Tokyo +32-50-620112 USR 33600 Dual
+32-50-625717 ZyXEL 28800
Succotash +1-XXX-XXX-ACiD USR 33600 Dual
public comments may be mailed to acid-public@acid.org
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
