19 files changed, 1551 insertions, 0 deletions

diff --git a/doc/ADATFS.txt b/doc/ADATFS.txt
new file mode 100644
index 0000000..e373690
--- /dev/null
+++ b/doc/ADATFS.txt
@@ -0,0 +1,529 @@
+HD24 ADAT file system format
+
+Reading ADAT HD24 disks
+-----------------------
+In the ADAT FST file system, the part of the file system
+that contains directory and song info is grouped in 
+32-bit words. When read on a regular PC, each group of 
+4 bytes will appear reversed. As such, when
+a sector contains a string 'TADATSF ', we should read this
+as 'ADAT FST'. In this document, we will assume that
+doing the byte swapping needed to properly read the sectors
+has already been done.
+
+It should be noted that the actual audio data has not
+undergone such byte swapping. As such, WAV data
+retrieved from the HD24 by FTP is stored in the same
+byte order as the data on disk.
+
+The sector size used on HD24 disks is 512 bytes.
+ADAT FST boasts disk support for disks up to 2 Terabyte.
+This is achieved by using 32-bit pointers that point to
+sector numbers. We will refer to these pointers as 
+sectorpointers.
+
+Writing ADAT HD24 disks
+-----------------------
+Writing HD24 disks is slightly tricky, because FST 
+filesystems contain backup copies of file system 
+sectors to help guarantee data consistency. 
+As a result, when we make an alteration to only the
+first copy of the file system structure on disk, the
+disk is considered inconsistent and the backup copy will
+be written back by the HD24 recorder at the next use.
+
+The backup data is stored at the end of the disk,
+in block-reverse order.
+The original order is something like this:
+
+block 0 
+        sector 0
+block 1 
+        sector 1
+block 2 
+        sectors 2,3,4
+block 3 
+        sectors 5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
+block 4-102
+        1 sector of project info
+block 103-
+        song info block (2 sectors)
+        song allocation info block (5 sectors)
+
+The backup blocks are stored in reverse order,
+however each backup block maintains the original 
+sector ordering. That is, 
+
+block 0 has a backup at sector (end-0)
+        (where end=the last sector on disk)
+
+block 1 has a backup at sector (end-1)
+
+block 2, sectors 2,3,4 are backed up at sectors
+        end-4, end-3, end-2, respectively;
+
+block 3, sectors 5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
+        are backed up at sectors
+        end-19,end-18,end-17,end-16,end-15,...end-5,
+        respectively.
+
+The validity of a block is indicated by a checksum which
+is stored in the last 4 bytes of a block (bytes 0x1FC,
+0x1FD, 0x1FE, 0x1FF of the last sector of a block).
+
+The value of the checksum is such that sum of all 32-bit 
+words in the block (which may span several sectors) is 0. 
+When writing a block, we must make sure that the resulting 
+checksum of the block adds up to 0 again.
+
+A second check refers to bytes 0x1f8-0x1fb of the last
+sector of a block. Bytes 0x1F8 and 0x1F9 contain the
+least significant 16 bit of the sector number at which
+the block starts. Thus, a project block which contains
+1 sector and starts on sector 0x14 will contain the 
+values 0x14, 0x00 on bytes 0x1f8 and 0x1f9; a song entry
+2 sectors long, and ending on sector 0x78 will contain
+the byte values 0x77, 0x00 on offset 0x1f8 and 0x1f9,
+respectively (because the song entry starts on sector
+0x77). Bytes 0x1FA and 0x1FB of the last sector of the
+block contain the bit-inverted value of 0x1F8 and 0x1F9**.
+
+** This paragraph assumes the sector is not byte-swapped
+as described in the first paragraph of the document.
+ 
+When a block is not equal to its backup, the checksum
+of both is validated. If one is valid and the other is
+not, the valid copy is written over the invalid copy.
+
+General ADAT FST layout
+-----------------------
+The general ADAT FST layout is as follows:
+
+-----------------------------------------------------------
+Sector 0 / Offset 0000:0000h
+Superblock, identifies drive as an ADAT FST drive.
+Size=512 bytes/0200h
+-----------------------------------------------------------
+Sector 1 / Offset 0000:0200h
+Drive info
+Size=512 bytes/0200h
+-----------------------------------------------------------
+Offset 0000:0400h
+3 sectors, Song Entry Usage Table
+Size=600h
+-----------------------------------------------------------
+Offset 0800h
+15 sectors, Drive Usage Table
+size=1e00h
+-----------------------------------------------------------
+         / Offset 0000:2800h
+Project info, 1 sector (512 bytes) per project entry
+Size: 99*200h=c600h
+-----------------------------------------------------------
+         / Offset 0000:ee00h
+Song info, 7 sectors (3584 bytes) per song entry 
+-----------------------------------------------------------
+        Undo info
+-----------------------------------------------------------
+        Audio data
+-----------------------------------------------------------
+        File system backup
+-----------------------------------------------------------
+
+
+Superblock layout
+-----------------
+Offset 0-0fh    Header line:
+                Offset 0        'ADAT FST'
+                Offset 8        Version number, e.g. '110 '
+                Offset 12       signature bytes: 55h, aah, cch, 33h
+Offset 10h-13h  Size of audio block     (0x480)
+Offset 14h-17h  Number of audio blocks per allocation cluster
+Offset 18h-1fh  0 ?
+Offset 20h-23h  0 ?
+Offset 24h-27h  0 ?
+Offset 28h-2bh  1 ?     sectors in superblock?
+Offset 2ch-2fh  1 ?     sectors in drive info block
+
+Offset 30h-33h  2 ?     sectornum of song entry usage table?
+Offset 34h-37h  3 ?     sectors in song entry usage table?
+
+Offset 38h-3bh  5 ?     sectornum containing allocation info? 
+Offset 3ch-3fh  15/0fh  - Number of sectors in allocation table?
+
+Offset 40h-43h  042fh=1071 ?? (anything to do with undo buffer?)
+                --
+                        On 1.2gb drive this formats as 0x20 00 00 00
+                --
+Offset 44h-47h  Number of free audio clusters on disk
+Offset 48h-4bh  SectorPointer to project info
+Offset 4ch-4fh  1
+Offset 50h-53h  Max allowed no. of projects?
+Offset 54h-57h  Max allowed no. of songs per project?
+Offset 58h-5bh  SectorPointer to first song info entry
+
+Offset 5ch-5fh  2       (sectors of song info entry w/o alloc info?)
+Offset 60h-63h  5       (sectors of alloc info per song entry?)
+Offset 64h-67h  7       (number of sectors that song info entries are apart?)
+Offset 68h-6bh          current number of songs on disk
+Offset 78h-7bh  041fh   (number of audio blocks reserved for undo buffer).
+                        1055 audio blocks=72 track minutes at 48 khz
+                Multiply by contents of offset 14h-17h for number of sectors
+                in undo buffer.
+
+Offset 7ch-7fh  Sector pointer to audio data block on disk (0x1397f6).
+Offset 80h-83h  32-bit word
+                number almost as big as number of sectors on disk
+
+                This number is related to that on offset 0084h and
+                always seems to have a difference of 0x14a46B to 
+                the end of the disk.
+
+                                0084h        0080h
+                40 gb disk:
+                                0x04c92d7f - 0x04B48914 = 0x14A46B
+                120gb disk:
+                                0x0df94baf - 0x0de4a744 = 0x14A46B
+
+                Perhaps the value is the number of allocatable sectors
+                on disk?
+                (1397f6 used in the beginning; an undo buffer is not
+                needed at the end of the drive)
+
+                0x10C75 used for actual filesystem.?
+                0x1397f6 (first data sector on drive) - (0x41f(size of undo buffer in audio blocks) * 0x480(size of audio block in sectors)) = 0x10C76
+                first data sector is not part of FS so this makes sense.
+                
+offset 84h-87h  32-bit word, highest sector number on disk. 
+                A backup of the first sector can be found here.
+offset 88h-1F7  (empty, zero - reserved for future use?)
+offset 1f8-1FF  Checksum information.
+                
+Drive info layout
+-----------------
+Sector 1
+Offset 0        8 byte drive name (for compatibility with
+                older ADAT FST versions), should be considered
+                obsolete. Replaced by name at offset 01bh.
+Offset 8-9      null bytes
+Offset 0ah-0bh  2 more bytes for drive name. Should be considered
+                obsolete
+Offset 10h      SectorPointer to last active project.
+offset 20h      List of 32-bit sector pointers to all projects.
+Offset 01b8h    64-byte drive name. Null-byte terminated
+                when shorter than 64 chars.
+
+Song Entry Usage Table
+----------------------
+FST 1.10 allows for 99 projects of 99 songs each, giving for
+9801 song entries. Each song entry is not necessarily pre-
+allocated to any given project; song entry 0 may belong to 
+project 0, while song entry 1 may belong to another project.
+The Song Entry Usage Table provides a quick way to look up
+the next free song entry without having to go through all 
+projects to see which song entries are in use.
+
+Each bit in the Song Entry Usage Table represents a song.
+When 0, the song entry is not in use; when 1, it is.
+
+Drive Usage Table
+-----------------
+Each bit in the Drive Usage Table represents a cluster. When 0, the
+cluster is free; when 1, the cluster is in use.
+32-bit words are filled one by one, least-significant bit first, 
+until the entire word has the value 0xFFFFFFFF. In other words, the
+table starting with the following words have the meaning as described:
+
+0x1 contains 1 bit on -> first cluster allocated
+0x3 contains 2 bits on -> first 2 clusters allocated
+0x1f contains 5 bits on -> first 5 clusters allocated
+0x1ff contains 9 bits on -> first 9 clusters allocated.
+
+At the end of the drive usage table, some space seems to be reserved,
+possibly representing the backup of the file system info, or something
+along those lines. The last 32-bit word of the Drive Usage Table is a
+checksum. When all 32-bit words in the entire Drive Usage Table are
+summed, the result must be 0.
+
+Project info
+----------------------
+The project info consists of (by default) 99 entries of 512 bytes each.
+The actual number of projects is contained by the superblock.
+
+100 project entries would be 0xc800 bytes.
+As projects are numbered starting at 01, a maximum of 99 projects
+is possible, giving for 0xc600 bytes.
+
+How to distinguish between an empty project and an unused project entry?
+Answer: Sector 1 (Drive info) contains the project list. 
+
+Projects not mentioned in the drive info project list are empty projects.
+
+Each project entry has the following layout:
+
+Offset 0        8-byte project name (obsolete)
+Offset 8        4-byte (2 bytes of which are partial project name too)
+offset 0ch-0fh  Number of songs in use in project
+offset 10h-19bh Song info table (a list of 32-bit pointers to the
+                initial sectors of song info). Length of table should be
+                396 bytes for 99 songs per project.
+                First entry in the table is the last accessed song.
+                Zero char means unused entry.
+Offset 01b8h    64-byte project name. Null-byte terminated if project
+                name is less than 64 bytes long.
+
+Song info table
+---------------
+The song info table is part of a project entry. It is a list of 32-bit
+pointers to sectors containing song info.
+
+Song info
+------------------------
+Song info starts at disk offset 0xee00h, or at
+sector 119 (the 120th sector on disk) (depending on
+info in superblock).
+
+Each song entry has a length of 2 sectors and is immediately
+followed by 5 sectors of file allocation info.
+
+Locate points/loops and track slip info is included in the song
+entries.
+
+Offset 00h-03h          32-bit number indicating no. of audio blocks in song
+Offset 04h-07h          ?0
+Offset 08h-0bh          32-bit number related to audio track interlacing.
+                        
+                        1/512th of the number of samples per interlace block
+                        before the audio switches to the next track.
+
+                        Value of this field equals Cluster size/(tracks*3).
+
+Offset 0ch-0fh          32-bit number related to audio track interlacing.
+
+                        number of sectors per interlace block
+                        before the audio switches to the next track.
+                        
+                        Value of this field equals audio block size
+                        /no. of tracks.
+                        Default audio block size is defined in superblock
+                        (0x480 sectors)
+
+                        An audio block size of 0x480 and 2 tracks gives a
+                        block size of 0x240h sectors or 0x48000 bytes
+                        (=294912 bytes).
+
+Offset 10h-13h          Status flags????????????????????
+                        Offset 0x12h bit 0x10h -> write protect?????
+
+Offset 28h-2Fh          First 8 bytes of song name.
+                        (Maintained for compatibility
+                        with FST before 1.10- 
+                        Obsoleted by long filenames
+                        at offset 3b8h)
+
+Offset 30h              ?
+
+Offset 31h              Number of physical tracks used by song.
+
+                        Note: 
+                        The HD24 has a high sample rate
+                        mode (88200 and 96000 samples per
+                        second, respectively). 
+
+                        In high sample rate mode, two
+                        physical tracks are used for each
+                        logical track.
+
+                        That is, a 12-track song in high
+                        sample rate mode will use 24 tracks
+                        on the machine. The number 24 is
+                        then what is indicated.
+
+                        This allows interlacing samples between
+                        tracks for compatibility with systems
+                        running at half the sample rate.
+                        In high sample rate mode, the track layout
+                        is:
+                        physical track 0-1 -> samples of logical track 1
+                        physical track 2-3 -> samples of logical track 2
+                        physical track 4-5 -> samples of logical track 3
+                        .. and so on. Even numbered samples (0,....) 
+                        are on even numbered tracks. 
+
+Offset 32h-33h          Two more filename characters for short filename,
+                        used in obsolete FST 1.0 standard.
+
+Offset 34h-36h          Sample rate in samples/second
+
+                        Typical values are:
+
+                        00h ach 44h -> 44100 Samples/sec
+                        00h bbh 80b -> 48000 Samples/sec
+                        01h 58h 88h -> 88200 Samoles/sec
+                        01h 77h 00h -> 96000 Samples/sec
+
+Offset 37h              Bit depth (18h or 24 by default)
+
+offset 38h-3bh          Unsigned 32-bit number containing 
+                        number of samples in song.
+                        
+                        For high sample rates, 2 tracks
+                        are used for each sample;
+                        therefore, a song that according
+                        to this 32-bit number contains 44100
+                        samples has the same duration at both
+                        44100 and 88200 kHz.
+
+offset 3ch              Write protect byte.
+
+                        This byte contains 8 bits (0-7, where
+                        7 is the most significant bit and 0 the
+                        least significant bit. In other words
+                        bit 7 has value 128, bit 0 has value 1)
+                        
+                        Bit 2 is on when song is write protected
+                        (value of the byte is 0x4 then), off when
+                        song is write enabled.
+
+offset 58h-B7h          Track slip info for track 1-24
+
+                        Track slip is measured in number of samples.
+                        E.g. for a song recorded at 48 khz, a value
+                        of 480 decimal (0x1e0) means 1/100 second
+                        (10 ms) of track slip.
+                        Track slip is stored as a signed 32-bit number.
+                        Valid values for the HD24 are -170..170 msec
+
+Offset 0b8h-1e3h        Locate point block
+
+Offset 3b8h-3e7h        Full song name, max 64 bytes; 
+                        terminated by null byte when less
+                        than 64 bytes
+
+Offset 400h-????        File allocation info (see below)
+
+Locate point block
+------------------
+The locate point block consists of 24 locate point entries.s
+
+Locate point entry
+------------------
+Each locate point entry has the following layout:
+Offset 0-3      32-bit time code
+                The time code represents the sample number
+                within the song.
+Offset 4-11     The 8-byte locate point name
+
+Locate point 0 indicates the relative time offset of the
+song. This is usually 0, but may be set to other values for
+tape transfers.
+
+The locate point is a 32-bit unsigned integer which contains the
+sample number within the song. In other words, in a 44.1 khz 
+song, the locate point 0:0:1:0 (hours/minutes/seconds/frames)
+is encoded as the number 44100. Thus, the locate point furthest
+in the song is 2^32=4294967296 samples. 
+This is enough for 44.1khz songs with a length of 27 hours.
+
+File allocation info
+====================
+The file allocation info consists of file allocation entries.
+Each file allocation entry has the following format:
+
+Offset 00h-03h  Starting sector number for audio block
+Offset 04h-07h  Number of audio blocks in allocation block
+
+In a valid song, the the 32-bit word on offset 0 of the song
+info equals the total sum of the number of audio blocks in the 
+file allocation info. 
+
+In my disk image, I see songs that had been previously deleted; 
+the song length in audio blocks is zero for these. This also
+goes for songs that have no audio data yet.
+
+Audio data layout
+=================
+The audio data of a FST file system is stored in a raw, uncompressed
+format. Audio data that consists of multiple channels is interlaced
+blockwise (as opposed to sample-by-sample interlacing).
+
+The data is stored as 24-bit signed little endian integer data.
+
+The typical audio block size as indicated in the superblock is
+0x480 sectors. In stereo audio, each subblock is then 1/2 audio blocks 
+or 0x240 sectors per channel.
+
+As the number of tracks increases, the block size per track decreases
+proportionally. 
+
+The default audio block size of 0x480 sectors lets itself be divided
+into 2,4,6,8,12,16,24 tracks (with a sample size of 24 bit). Each channel
+then takes up 0x240, 0x120, 0xc0, 0x90, 0x60, 0x48, 0x30 sectors, 
+respectively assuming 0x480 blocks per sector. In high sample rate
+modes, channels are paired to accomodate for the doubled sample rate. 
+This is why in high sample rate mode a max of 12 channels are possible,
+while the maximum song length is still over 27 hours on 88.2 kHz.
+
+
+Not yet accounted for in this document
+======================================
+
+How the undo buffer is used (however, this is not relevant because the
+undo buffer is cleared after each power off. It might as well exist
+in RAM only).
+
+How pitch info is stored in the songs
+auto play
+auto rtn
+auto rec
+
+HD24tools extensions to FST
+===========================
+An extension is proposed where a song on a HD24 drive is used as data
+area, to store non-audio information associated with a song or project.
+This would allow HD24 owners to store track notes, mix settings,
+protools projects and so on along with their songs.
+
+A degree of compatibility with the HD24 is desired; although the HD24
+will not be able to use the information, it should also not corrupt it.
+
+The HD24 does not offer unique file names; moreover, the position of a
+file is not constant within the FS. As a result, songs have no unique
+identifier that allows other data to be associated with them.
+
+It is proposed to use bytes 0x3a0-0x3bf of each song entry as unique
+identifier. Testing shows that the HD24 recorder does not touch these
+bytes, even after a scandisk operation. Moreover, when a song is copied
+to another drive, these bytes are copied over as well.
+
+A single HD24 song would provide ample storage space for most purposes.
+Additionally, by using a single song only, the negative impact to the
+end user is minimal as no users have ever been registered to actually
+create 99 project of 99 songs. To prevent the HD24 from corrupting the
+contents of the song, it can be created as 0-track song; previous
+experiments have shown that the track count is flexible. Having a song
+marked as 0 track prevents the HD24 from arming tracks or playing back
+audio from the song, and will give a user some feedback about the nature
+of the song, without causing the HD24 to claim that the song is corrupt.
+A track count of 0 survives a scandisk command, and it seems that the
+HD24 permits copying such songs to other drives.
+
+A possible way to store data in the song is to have the data song 
+contain a FAT file system. The advantage of the FAT file system is
+that it is well documented, and probably there will be library code
+available that will ease the implementation of an embedded FAT 
+system on HD24 drives.
+
+The root directory of the file system shall contain a 'songdata' 
+dir. This data directory shall contain a subdirectory named after the
+ID of each song. Of course the file names need to be long enough; if 
+this is not possible, a map file may be created to contain mappings 
+from song ID to songname subdirectory ID.
+
+Data placed in the appropriate songname directory is automatically 
+associated with the song. Should we so desire, we can also create a 
+'projdata' directory.
+
+By keeping the songdata directory structure flat, songs can be moved 
+across projects without losing their associated files.
+
diff --git a/doc/COMPILING.txt b/doc/COMPILING.txt
new file mode 100644
index 0000000..f0abf5e
--- /dev/null
+++ b/doc/COMPILING.txt
@@ -0,0 +1,39 @@
+COMPILING HD24TOOLS
+
+Instructions for Linux (preferably Debian/Ubuntu based):
+
+Get the source code from svn on HD24tools.com
+
+sudo apt-get install fluid libfltk1.1 libfltk1.1-dev libsndfile1 libsndfile1-dev libportaudio0 libportaudio0-dev libjack0 libjack0.100.0-0 libjack0.100.0-0-dev libjack-dev libxft2 libxft-dev libxinerama libxinerama-dev
+
+Note: You may still need to install libflac.
+
+make clean
+./configure
+make
+
+mkdir ~/HD24tools
+cp hd24connect ~/HD24tools/
+cp hd24hexview ~/HD24tools/
+cp hd24info ~/HD24tools/
+cp hd24towav ~/HD24tools/
+cp hd24wavefix ~/HD24tools/
+ln -s /usr/lib/libsndfile.so.1 ~/HD24tools/
+ln -s /usr/lib/libportaudio.so ~/HD24tools/
+ln -s /usr/lib/libjack.so ~/HD24tools/
+
+For HD24tools to detect the drives (when being run as normal user),
+normal users need to have sufficient permissions to work with the
+drive device.
+
+To find out which drive device it is, run HD24connect as root,
+and select File->Recovery->Select device...
+
+This will show you the current device, which is the device
+that needs its permissions set.
+
+You can probably gain device permissions by adding your
+regular user to the proper group, making your user the
+owner of the device or by setting the device permissions
+in /etc/fstab.
+
diff --git a/doc/DEVELOPING.txt b/doc/DEVELOPING.txt
new file mode 100644
index 0000000..6c91747
--- /dev/null
+++ b/doc/DEVELOPING.txt
@@ -0,0 +1,270 @@
+Developing HD24tools
+====================
+
+To start on development of hd24tools, here are a few tips to get you started.
+
+Development environment
+=======================
+You will want libsndfile, libportaudio and the Fast Light Toolkit FLTK to be
+present on your system. On Linux you will also want the Jack Audio Connection
+Kit (optionally on Mac as well). The targeted compiler is gcc. 
+
+On Windows, development is based on a MSYS/MinGW environment.
+
+On Mac, XCode is needed, as well as portaudio, libsndfile and FLTK.
+
+Configuring and building
+========================
+Configuration is auto-detected by running
+
+        ./configure
+
+Building is done with 
+
+        make
+
+Installing is optional. You may want to run the following as root:
+
+        make install
+
+which will install common binaries to /usr/bin. More interestingly, 
+you can run 
+
+        make installer
+
+to create the installer for the current platform. Finally, with
+
+        make clean      
+
+you can work from a clean configuration. The configure script also
+calls make clean.
+
+Cross-compiling
+===============
+Cross compiling is highly experimental and will probably fail for
+most purposes. On linux, you can say 
+        
+        ./configure os=win32
+
+which will attempt to create windows .exe files. However, until
+now only hd24hexview.exe has been successfully built on Linux.
+
+
+
+./configure
+make
+
+Setup
+=====
+During configuration, the set of libraries, make files etc to
+use is decided by the files in the setup directory. The file
+Makefile.in which is located there contains the release number
+which must be bumped up for every version. Unless you build
+official releases, please add your name to the release number
+or make your personal releases otherwise distinguishable from
+official releases.
+
+To perform library detection etc, there are files called
+Makefile.setup.<platform> in the setup directory. These are
+called with various targets to figure out if libraries exist.
+
+Unless porting to a new platform or adding external libraries,
+you will probably rarely need to change most of the setup 
+scripts.
+
+File system documentation
+=========================
+Reverse-engineered information about the ADAT FST file system 
+can be found in doc/ADATFS.txt. Probably this file contains 
+enough info to not only allow reading ADAT drives but also to
+write them. The biggest obstacle in writing ADAT drives so
+far has been to get an accurate LBA sector count of non-
+formatted drives on all operating systems. Especially Windows
+seems to lack a reliable way to obtain this information.
+(Multiplying sectors/cylinders/heads isn't LBA accurate, 
+any other way known to me is limited to a specific version 
+of Windows). If you want to contribute to the ADATFS.txt
+file, figure out how the FST undo buffers work. To keep this
+software free, DO NOT obtain information from Alesis about 
+FST which might pollute the project with non-free 
+information.
+
+The HD24 library
+================
+Directory src/lib contains the HD24 library (and other
+library source code).
+
+common.cxx - some common string manipulation functions
+convertlib.cpp/.h - conversion between various data types
+countsectors.cpp - library to calculate drive size
+hd24connect.ico - HD24connect Icon for Windows
+hd24devicenamegenerator.cpp/.h - 
+        Library to generate device names that could be 
+        HD24 drives; contains alternatives for all
+        supported OS platforms
+hd24fs.cpp/.h
+        Library containing definition for HD24 file system
+        object.
+        Each file system contains drive info;
+        The drive info contains 1 or more projects;
+        Each project contains 0 or more songs;
+        Each song contains 25 locate points (START
+        +locate point 1-24) and track slip info for
+        each track.
+
+        Including hd24fs.h is sufficient to have access to
+        all of this.
+
+hd24project.cpp/.h
+        Library containing hd24 project decoding.
+
+hd24song.cpp/.h
+        Library containing hd24 song decoding;
+        this includes functionality to read audio, set
+        the song cursor, etc.
+ 
+hd24utils.cpp/.h
+        Library that contains useful routines, such as
+        printing the hd24 catalog, dumping a header, 
+        saving a drive image etc. that do not belong in
+        the file system decoding library,
+        but that multiple programs might have a use for.
+
+nojack.cpp/.h
+        Dummy library to replace jack on windows and other
+        platforms in case it is not present.
+
+src/lib/FL/
+        Native OS file dialog support.
+
+INSTALLER GENERATOR
+===================
+
+The code for the installer generator is found in 
+src/installer. 
+
+Essentially, it takes the compiled binaries of hd24tools,
+and converts those to hexdumps in c-source (using an 
+application called bin2c). This c source is then compiled
+and will be able to re-create the original binary 
+files. 
+
+While no complex registry magic is needed, this is
+sufficient for simple installations and probably less work 
+to figure out than other solutions.
+
+This was originally intended to create install wizards for Mac,
+but ended up being used for Windows only. Mac users seem 
+comfortable enough with the install-free .dmg images that they
+are presented with.
+
+The install wizard itself is basically implemented as a state
+machine.
+
+The installer for Linux installation could still be made a bit
+smoother, specifically in the libraries department- the right
+libraries are not always available at the right locations yet.
+
+THE ACTUAL HD24TOOLS
+====================
+
+Some tools only have a console/command line version. They are:
+
+hd24hexview     a hex editor
+hd24wavefix     a program that attempts to recover bit-distorted
+                audio to something remotely usable again
+hd24towav       a program that converts raw 24 bit hd24 audio to
+                wav files
+syx2bin         a program that converts the HD24 OS .syx files
+                to binary (not sure if the resulting binaries 
+                are valid)
+hd24info        a program that prints some info about the hd24
+                drives present in the system
+
+And finally, there is the graphical flagship program of the suite
+hd24connect. To start development, it would be recommended to 
+understand the library, then the command line utilities first.
+
+The command line tools are in src/ whereas hd24connect is in 
+src/frontend.
+
+Originally I intended hd24connect to have a frontend (GUI) and
+a backend. As it turned out, the whole thing ended up in the
+frontend. If you feel like creating a nice backend so that the
+frontend *really* *only* contains GUI stuff, feel free. Sorry.
+
+The entry point of hd24connect is src/frontend/hd24connect.cpp-
+this calls and opens the GUI.
+
+The main entrance for the GUI is in fluid file ui_hd24connect.fl
+(you *really* should use the 'fluid' user interface editor that
+comes with fltk to maintain the .fl files). Method make_window
+in class UserInterface starts it all.
+
+TEST SUITE
+==========
+There is a directory test/ which should at some point contain
+regression tests for hd24tools. To make it easier to perform
+such tests, it would need to be possible to control hd24tools
+entirely in batch-mode (using MIDI for this is may be a 
+possibile way).
+
+DOCUMENTATION
+=============
+
+The .pdf documentation may be slightly outdated. If you wish
+to update it, you can do so with OpenOffice Writer.
+
+TASKS
+=====
+If you want to contribute, here are some things left to do:
+
+- Write support (realtime vs copy mode)
+
+        Save altered drive/project/song info
+
+        Write support can initially be tested on 
+        drive image files.
+
+        Phase A1: Only overwriting existing audio, but
+        not allocating new space (copy mode)
+
+        Phase A2: Allocating new space (copy mode)
+
+        Phase B1: realtime write mode with JACK support
+
+- Wave preview
+
+  This would have to be awfully smart to be able to display
+  waves with zero active waiting time and without utilizing 
+  peak files. Use information such as screen width reso-
+  lution to limit the amount of data that needs to be read
+  from disk. Probably adding a special read mode in the 
+  library could help support this.
+
+- Figure out how to build (fat) Mac binaries with or without
+  Mac (but preferrably without requiring both intel and ppc
+  to build a release that works on either platform)
+
+- Figuring out a way to write wav header info/session
+  notes to HD24 songs, while maintaining HD24 compatibility
+
+- Adding MIDI support to the library (MMC, MTC)
+
+- Sync to real HD24 recorders? 
+
+- Special HD24tools distro containing ReWire support to 
+  allow streaming audio directly to protools/cubase?
+
+- Use real LRC to control HD24tools?
+
+- Figure out OS binary checksum algorithm
+
+- Create a test suite
+
+- Figure out how the HD24 performs Undo administration on 
+  the file system level
+
+- Improve realtime read mode performance for audio streaming
+
+
diff --git a/doc/HARDWARE.txt b/doc/HARDWARE.txt
new file mode 100644
index 0000000..8d4809e
--- /dev/null
+++ b/doc/HARDWARE.txt
@@ -0,0 +1,34 @@
+Inside the HD24
+
+The HD24 is powered by a Motorola Coldfire 
+
+MCF5206EFT54
+K36J
+QAJ0435)
+
+The Ethernet chip is a CrystalLan CS8900A-CQ3,
+a 10Base-T LAN chip.
+
+There is an empty, 26 pin port labelled 'Motorola BDM Port'.
+Motorola BDM stands for Motorola Background Debug Module,
+so we might speculate that this port allows us to perform
+debugging on the HD24 as it is running.
+
+There are to IC41LV16256 chips in the HD24: according to the
+data sheets, they are 256kx16 bit Dynamic RAM with EDO page mode,
+giving the HD24 a total of 1 megabyte of RAM.
+
+There is an ALTERA ACEX EP1K30QC208-2
+FPGA (Field Programmable Gate Array).
+
+There is a Texas Instruments AHCT16541
+AHCT16541 devices are noninverting 16-bit
+buffers composed of two 8-bit sections with
+separate output-enable signals. (possibly 
+used for communication to displays?)
+
+Analog Devices ADSP 21065L KS-264
+A digital signal processor.
+
+
+
diff --git a/doc/LIVERECOVERY.txt b/doc/LIVERECOVERY.txt
new file mode 100644
index 0000000..94782a0
--- /dev/null
+++ b/doc/LIVERECOVERY.txt
@@ -0,0 +1,25 @@
+Figuring out on which sector the next recording should start
+(or where a crashed live recording starts)
+============================================================
+1. Find the start offset of the drive usage table, e.g. 0xa00
+2. Find the suspected start offset of the live recording
+   in said table. This is the offset of the first 32-bit word
+   that is 0.
+   For instance the found offset is 0xe74
+3. This means the recording starts on cluster 
+   0xe74-0xa00=0x474
+4. The superblock states the number of audio blocks per cluster,
+   offset 0x14. For the sake of this example, lets assume 9
+   audio blocks per cluster. The size of each audio block is on
+   offset 0x10, usually 0x480.
+5. The first audio sector is mentioned on the superblock on
+   offset 0x7e. In most cases it is 0x1397f6.
+6. Each byte in the drive usage table represents 8 clusters.
+7. The audio should then start on
+   0x1397f6 + (0x480*9*8*(0xe74-0xa00)) = sector 0x5b667f6.
+
+---------------
+The other way around- calculating offset from sector number:
+(0x02e427f6 - 0x1397f6) / 0x480 / clusters /8 + 0xa00
+
+
diff --git a/doc/MAILING.txt b/doc/MAILING.txt
new file mode 100644
index 0000000..20e9de3
--- /dev/null
+++ b/doc/MAILING.txt
@@ -0,0 +1,28 @@
+Subject: HD24tools 0.9.0beta for Win32 released
+Hello, 
+  
+HD24tools version 0.9.0beta has been made available for 
+the following platforms:
+
+- Linux (i386)
+- Windows (All versions)
+
+Mac releases are expected to be released soon.
+
+The most important new features in this release are
+- Preliminary write support
+- New tabbed GUI
+- Several usability enhancements
+
+The release notes for this and previous release notes can be viewed on
+http://ringbreak.dnd.utwente.nl/~mrjb/hd24tools/RELEASE.txt
+
+As always, the release can be downloaded from:
+http://ringbreak.dnd.utwente.nl/~mrjb/hd24tools/download.html
+  
+Should you encounter any problems with this release, 
+please let me know. 
+ 
+Best, 
+Marc 
+
diff --git a/doc/RELEASE.txt b/doc/RELEASE.txt
new file mode 100644
index 0000000..ac0d723
--- /dev/null
+++ b/doc/RELEASE.txt
@@ -0,0 +1,474 @@
+HD24Connect revision history and roadmap
+========================================
+
+Implemented features are set in the past tense. A version is complete when all
+planned versions are implemented. Until then, sub-versions are used, e.g.
+0.3.1 already may have some (but not all) 0.4 features.
+
+This document ends with suggested features, but is in reverse chronological
+order otherwise, and as such starts with features planned for the next 
+release.
+
+Current status is somewhere in the middle, search for the text 
+'CURRENTLY IN PROGRESS' to find out what is being done right now.
+
+Version 1.1.0 => CURRENTLY IN PROGRESS
+
+- Added some unit tests to perform automated, scripted testing
+- Added frequency/gain display to mixer
+- Performed code cleanup:
+        - Moved recorder, mixer and HD24->PC file transfers
+          to their own modules
+        - permit various interfaces (X, Cocoa, Curses, etc)
+        - possibly permit recording macros?
+        - permit multi-window interface (show transport/time/mixer
+          simultaneously) and allow resizing those windows
+- Implement batch transports
+- Implement realtime recording 
+- Auto-detect feedback loops!
+- Change to multi-window interface to allow viewing multiple tabs at once
+  (for example both recorder and mixer at same time)
+- Implement MIDI control/control surfaces
+        - Control other MIDI devices with HD24tools
+        - Control HD24tools with other MIDI devices
+- Implement LADSPA support for mixer FX
+        - Add default GUI for common effects, allow them
+          to be controlled through control surfaces.
+- Implement keyboardless operation 
+- Add wave viewer for easier selection of export range
+- Add functionality to allow changing song naming convention for export
+- Simultaneous dual drive support. Benefits:
+  * allow copying songs between drives 
+  * copying songs/projects from/to drive images
+- Add drive images that are found in drive image dir to
+  drive image dropdown to make it easier to switch between
+  real and virtual drives
+- Implement functionality to signal falling out of record 
+  mode if needed (when drive is full, etc)
+- Create an interesting demo drive image to
+  allow people to play around with it
+  (low prio: people can download examples from raw-tracks.com
+  at a $5 fee)
+
+Version 1.0.0 => Will remain in alpha
+
+- Made source code available to the general public
+- Added recovery feature to deal with a specific class of
+  'unexpected end of song' error on fragmented drives
+- Added block checksum calculation to library
+- Implemented saving of changed project name/song name to disk
+- Added code for cluster allocation
+- Added code for converting orphan clusters to allocation entries
+- Compiling framework was changed to allow smoother Mac compiles
+- Added mixer tab with save/load mixer settings functionality
+- Finished up restructuring of mixer to make it work again
+- Added save functionality to allow renaming drive
+- Made detection of corrupted drives smoother to prevent need for
+  http://ringbreak.dnd.utwente.nl/~mrjb/hd24tools/drivenumber.html
+- Added Check for 'forbidden characters' in filenames
+  \ / : * ? " < > |
+  (HD24 accepts these but can have unpredictable effects on
+  OS side)
+- Added allocating functionality to allow lengthening songs
+  automatically during transfer
+- Altered layout of drive catalog to fit longer song names
+  and to have a bit larger margin on the left for printing
+- Added functionality to allow 1-click toggle between 
+  sample rates of 44.1 <=> 48 kHz and 88.2 <=> 96 kHz
+  (toggling between lower/higher sample rates is not possible
+   without conversion as higher sample rates use 2 recording
+   tracks per channel).
+- Added dialog for simpler 'headerless' live recording recovery
+- Implemented initial headerless live recovery scheme
+- Made headerless live recording recovery read-only
+- Added functionality to create empty drive images
+- Created dialog for setting song parameters
+- Implemented Mixer JACK support
+- Implemented framework for smarter library loading.
+  This should allow Mac (and even Windows) users to have
+  JACK functionality, and will no longer require Mac
+  users to startup HD24connect by running an AppleScript.
+- ... and made library smart loading even smarter by letting
+  it look in the program directory first, the PATH dir next, 
+  and all usual library directories next. This should result
+  in library loading that Just Works in most cases and
+  will allow JACK support on all platforms.
+- Wrote documentation explaining how to build HD24tools
+  from source (Linux, 64-bit Athlon)
+- Added functionality to create projects
+- Added functionality to create songs (incl. superblock 
+  song count update)
+- Made sure changes in song/drive/project names also reflect 
+  properly in FST 1.00 drives
+- Added functionality to automatically pre-record silence
+  in songs on creating them
+- Added functionality to update song usage list after 
+  song creation
+- Automatically select song as 'default' after creation
+- Implemented reload of drive list/catalog/project list/song list 
+  after major write operations
+- User interface settings reloaded as appropriate after writing
+  to drive
+- Added options dialog to allow (among other things) specifying
+  a filename pattern for file transfers to PC
+- Made write-protect checkbox work
+- Added drive format functionality
+- Added functionality to delete songs
+- Added functionality to delete projects
+- Made 'bypass' button for mixer work
+- Added timeout-style messages to alpha display
+- Implemented functionality to display song information
+  on alpha display
+- Implemented functionality for sorting songs inside a project.
+  This allows easily reordering songs by renaming them.
+- Implemented SMPTE timecode striping- for now limited to
+  30fps nondrop starting at 00:00:00.00. 
+  May not work on sample rates other than 48kHz. In fact, 
+  it may not work at all.
+- Made sure superblock is updated with number of free clusters
+  after song transfer to HD24 drive/creation of new song
+- Implemented write-protect to prevent writing to drives when
+  working with header files.
+- Implemented functionality to reduce number of sectors read
+  when transferring fewer tracks. The expected performance 
+  win is not very big as the number of drive seeks is about 
+  the same, but the weight of the added logic is minimal. 
+  Perhaps on some systems the difference is noticable. YMMV.
+- Implemented .wav writing without libsndfile. If it is missing, 
+  you'll still be able to transfer such files to your computer.
+- Made sure write functionality is disabled for drives found
+  not to be valid HD24 drives (due to corruption, or perhaps
+  they're simply OS drives which we DEFINITELY don't want to
+  overwrite)
+- Implemented locate point saving
+- Implemented (preliminary) transfer-time mixing of tracks
+- Made sure song/project are made default after selecting them
+- Fixed a non critical bug where closing the program during 
+  playback caused a crash.
+
+TODO: Bugs to fix:
+
+- After quickformat of a drive, catalog and related screens are
+  not updated.
+
+TO DO: Testing and packaging:
+
+- Fixme: update all of drive info page on refresh
+  (What's missing?)
+- Make sure that 'new folder' button works properly on 
+  all platforms! (Fixed on Windows, TO DO on mac)
+- Distribute Mac version as Universal Binary
+- Finally get .aif, .sd2 and .dig/.sd to work properly!
+- Check all FIXME and TODO comments in code
+- Get 16-bit export to work (low priority)
+- Documentation
+
+Version 0.9.0
+
+- Implemented tabbed interface
+- Added functionality to export drive images
+- Added time stamp to catalog
+- Added drive catalog display to drive inforrmation
+- Changed default time display to 30 frames per second instead of 1/100 sec
+
+- Added the 'Recorder' with various new features
+- Proper solo/mute buttons instead of solo/mute by channel selection
+- Track arm buttons
+- 24-channel display faithfully emulating what the HD24 would show
+- Peak modes: No peak hold, momentary peak hold, continuous peak hold
+- Added locate slider to rapidly jump to any point in the song
+- Added punch in/out locate points
+- Added visual clue to transport controls showing that clicking 'set' 
+  can set locate points
+- Added input monitoring (mainly Linux)
+- Added dropdown to map stereo inputs to channel pairs in various ways
+- Fancy 7-segment LED display
+- Equally fancy info display
+- Fancy, bigger graphical buttons with LED for transport control
+- Fixed a clipping bug in portaudio playback (playback only)
+
+- Added signal detection to track selection in transfer tab
+- Added dropdown to allow a flexible custom size limit for exported files
+- Added dropdown to stamp songs with a different sample rate
+
+- Added tab for transfer back to HD24
+- Added functionality that permits selecting many files at once
+- Added functionality to automatically spread multi-track files
+  across several HD24 tracks
+- Added functionality to automatically mix multi-track files to mono
+- Added functionality to allow erasing tracks
+- Added functionality to allow moving tracks (including track action)
+  up or down
+- Added functionality to clear filenames from tracks
+- Added functionality to overwrite existing audio with audio from a file.
+  Many file formats are supported (subject to what is supported by
+  libsndfile).
+- SD2 file format support (does this work now?)
+- Create new folder from file browse dialog (does this work now?)
+
+
+Version 0.8.2
+
+- Hardened the software in some places to be more crash-resistant 
+  in handling corrupt drives
+- Some compatibility enhancements
+- Fixed a bug in the calculation of the total number of bytes to export,
+  which caused the auto-split popup not to be displayed in some cases.
+
+Version 0.8.1
+
+- Fixed bug that caused auto-split popup to always appear for long recordings,
+  even if only a small fragment was being exported.
+  
+Version 0.8.0
+
+- Printing disk contents on paper and file
+- Entirely replaced export engine for faster exports
+- Created OS native installers.
+- Allow transferring multiple songs at once (song choice 'All Songs')
+- Added possibility to export to stereo and multi-track files.
+
+Version 0.7
+
+- This never-released version adds high samplerate support.
+
+Version 0.6.2
+
+- Fixed a bug that caused the Windows version to lock up when loading a header file
+- Initial release for MacOS/X 10.4
+
+Version 0.6.1
+
+- Fixed a bug in the drive name generation in Windows
+
+Version 0.6
+
+- Initial Macintosh OS/X port. Still flaky due to interesting behavior of packages that HD24connect depends on.
+- Relabeled button "Transfer to PC" as "Transfer to Mac" for OS/X version.
+- Fixed bug that cleared surface of cancel button during transfers.
+- Added warning dialog to improve user friendliness when no HD24 drive is detected on program startup
+- Added menu option 'File/Detect HD24 drives' to allow re-scanning for drives after program startup.
+- Project directory browser now uses OS native file dialog.
+- Added menu option to allow creating header files from within hd24connect
+- Removed portaudio dependency (this has no visible impact).
+- Added Estimated Time of Arrival in transfers
+- Removed dependency on command line options to enable recovery features
+- Added application (desktop) icon for Windows
+- Allow exporting to more different file formats (currently WAV and AIFF)
+- Altered file naming for export
+- Cleaned up code that deals with drive name generation
+- Version control is now in place, allowing multiple people to work 
+  on the project at the same time (Welcome, Randy!)
+
+Version 0.5
+
+- Added --force feature to allow using hd24 disks with invalid MBR.
+- Added --header feature which allows to use a fixed header file along with
+  a corrupt disk. This permits us to recover audio without need to modify
+  data on the corrupted disk. 
+- Added portaudio playback. For the Windows version this means that audio
+  preview is now supported, while under Linux the Jack Audio Connection Kit 
+  is no longer required for audio preview.
+- Fixed a bug in Linux audio preview. This minor bug affected exactly 
+  1 user (me).
+- Added dialog to allow renaming drives, projects and songs (in memory only)
+- Altered project handling to more easily allow in-memory edits of projects
+
+Version 0.4
+
+- Fixed a minor bug with the file write caching.
+- Added a button to allow the user to interrupt a transfer.
+- Fixed flakyness in audio playback
+- Added dialog to allow manually setting locate points
+- Fix bug which causes windows version not to display song names
+- Added feature to allow setting loop start/end during playback
+- Implemented export to wav (for now, instead of raw) using libsndfile
+- Implemented basic loop mode for audio playback. 
+
+Version 0.3
+
+- Added file write caching to speed up export under Windows. 
+- Added direct playing under Linux (still flaky)
+- Altered library to resolve issue with STL string memory leaks
+
+Version 0.2
+
+- Added support for locate points. 
+- Added backwards export.
+- Initial windows version.
+
+Version 0.1
+
+- First workable version.
+
+HD24hexview revision history and roadmap
+========================================
+
+Future
+
+- Verify/Fix any remaining issues with 4 GB limit on Windows
+- Correctly determine drive size
+- Allow multi-sector paste (from file).
+
+Version 1.4beta
+
+- Replaced code for windows drive size detection.
+
+Version 1.3beta
+
+- Added expert mode as safety switch to prevent accidentally writing to disk.
+- In expert mode, added a big fat warning for writing to the default boot 
+  disk (/dev/hda or \\.\PHYSICALDRIVE0) and a (not so big & fat, but still)
+  warning for writing to other devices.
+
+Version 1.2beta
+
+- Added d-<hex> feature to dump sector <hex> counting from end of disk
+  This allows dumping the last sector from disk without having to figure
+  out the number of sectors based on brand and model of the disk.
+  Unfortunately, this does not work properly yet for Windows devices.
+
+Version 1.1beta
+
+- Fixed a bug in windows version that required output file to already exist
+  before writing
+- Added single-sector checksum (no multi-sector checksum yet)
+
+Version 1.0beta
+
+- Implemented compare
+- Implemented write offset
+
+Version 0.3
+
+- Implemented edit and write back of sectors
+- Implemented single-sector paste
+- Ported to Windows
+- Resolved a 4 GB issue with windows version
+- Allowed using files as devices
+
+Version 0.2
+
+- Implemented support for setting blocks
+- Resolved 4 gigabyte limitation for linux
+- Implemented scan
+- Implemented write to file
+
+Version 0.1
+- Implemented code to autodetect HD24 disks
+- Implemented feature to navigate disks with +/-/o
+
+========================================================
+Version x.x
+
+Spare ideas/suggested future features:
+
+- Allow exporting audio based on a 'guide track'. If a nonempty audio track has been exported, after which the disk has gotten corrupted, this audio track can be used to find back the other tracks without allocation information.
+        
+        Will not be implemented anytime soon; this scenario is too
+        rare. Also, should recovery be needed, other ways exist to do so.
+
+- Allow the program to use installed audio encoders to
+  encode to mp3/flac/etc
+
+- Time line/draggable export locators
+
+        Proposed is a graphical display to allow 
+        visually setting locate points for export.
+        Alternatively, a 'scrub editor' style display would be
+        workable.
+        While interesting, it would be rather time consuming
+        to build such a time line. For now, a draggable slider
+        is made available to ease the pain a bit.
+
+- Check available drive size before export
+
+        I'm not sure if I already implemented this. Obviously,
+        it is a required feature.
+
+- Allow transferring multiple projects at once 
+  (project choice 'All projects')
+
+        Will probably be implemented at some point, but
+        custom song naming convention is then required first.
+
+- Allow automatic deletion of files when transfer is interrupted
+
+- Normalizing audio as it is being exported
+
+        This will require analyzing the entire export range
+        prior to export (possibly more, if the export is a
+        single song of an entire live performance; it is likely
+        that we'd want to normalize the whole performance 
+        equally.
+
+- Allow exporting to different bit depths
+- MIDI control (both controlling HD24tools via MIDI or
+  let HD24tools control HD24 recorder via MIDI).
+  
+        The benefit of allowing HD24tools control via MIDI
+        is that frequently requested functionality that the
+        HD24 does not support is a possibility; for instance,
+        the HD24 does not allow selecting songs via MIDI,
+        whereas such implementation in HD24tools would be
+        a fairly simple matter once it is MIDI enabled.
+        Someone also mentioned that possibily a recording
+        log could be kept by HD24tools when connected to
+        a HD24 via MIDI by simply keeping track of record
+        events. Unfortunately the HD24 does not send MIDI
+        for track record enable, even though it supports
+        track arming via MIDI (the good news is that some
+        MIDI functionality is supported even though the
+        HD24 itself does not send out MIDI for those actions).
+
+- Storing metadata on HD24 drives
+
+        There are some possibilities for this. One way is
+        to create a song contaning (for instance) a FAT
+        file system, and using some unused space in the
+        song entries to allow entries in that FAT file
+        system to uniquely point to them; this would allow
+        storing song-unique info (such as track data, etc)
+        in that file system.
+
+- Locate points in directory listing
+
+        This would make the catalog file a fair bit longer.
+        As such it would have to be an option that could
+        be turned on/off.
+
+- Virtual BRC application
+
+        This would be limited to whatever MMC supports.
+
+- Copying projects
+- Batch transfer
+- One click drive backup
+
+        These all come down to the same thing: find a 
+        way to not require user intervention while
+        transferring large amounts of data.
+        Perhaps a 2-click drive backup (with the possibility
+        to edit the batch before export) is more useful than
+        a 1-click backup.
+        The main benefit (not having to wait actively while
+        audio is being transferred) is the same.
+
+- Calculate approx. occupied drive space per song, and add
+  to catalog.
+
+- Display currently selected song/project on other tabs as
+  well 
+        - current song is now displayed on alpha display.
+
+- Allow different UIs (proposed is command line interface,
+  non-X interface, Cocoa interface, ...)
+
+- Control surface support, to allow using MIDI-enabled
+  consoles to control the HD24tools mixer/recorder
+
+- Add Vista tip to manual (regarding admin account for write
+  support)
+  Also add this info:
+  http://tech.groups.yahoo.com/group/hd24/message/12102
+
diff --git a/doc/SYXformat.txt b/doc/SYXformat.txt
new file mode 100644
index 0000000..9c02ccf
--- /dev/null
+++ b/doc/SYXformat.txt
@@ -0,0 +1,22 @@
+SYX file format
+===============
+The SYX file format packs every 7 8-bit bytes of a binary file 
+into 8 7-bit bytes, which allows for a MIDI compatible file.
+These files can be converted to true binary files using the
+hd24syx2bin utility.
+
+Once converted, the format seems to be as follows:
+
+byte 0x00-0x07: string 'HD24CODE'
+byte 0x08-0x0b: unknown (checksum?)
+byte 0x0c-0x0f: version number string (e.g. "1.20")
+byte 0x10-0x13: 32-bit word, value 0
+byte 0x14-0x1b: Release date string (MM/DD/YY)
+byte 0x1c-0x1f: 32-bit word, value 0
+byte 0x20-0x27: Build time (hh:mm:ss)
+byte 0x28-0x2b: 32-bit word, value 0
+byte 0x2c-0x2f: binary file length in byte.
+                for version 1.20, file length is
+                712736 so bytes 0x2c-0x2f are
+                0xae020 or 0x00, 0x0a, 0xe0, 0x20
+
diff --git a/doc/TESTPLAN.txt b/doc/TESTPLAN.txt
new file mode 100644
index 0000000..ceb4849
--- /dev/null
+++ b/doc/TESTPLAN.txt
@@ -0,0 +1,130 @@
+Testplan for HD24tools
+
+Hexview
+- startup without HD24 drive connected
+- startup with HD24 connected
+- startup with --dev option (dev=drive image file, dev=device file, dev=normal file): use either clean image or image know to have problems (unexpected end
+of song, corrupt header, etc)
+- startup with --dev and --force
+- Specific to hexview: d-1 (sectorcount relative to end of disk)
+  How much time does the detection take under windows?
+
+HD24connect:
+- startup without HD24 drive connected
+- startup with 1 HD24 drive connected
+- startup with multiple HD24 drives connected
+- startup with --dev option (device node and image file, respectively)
+- ... ditto, AND with/without an HD24 drive connected
+- startup with both --dev en --force options
+- As above, but by selecting these options from the GUI
+- And again. Any irregularities?
+- Irregularities with drives/images containing:
+   0, 1, more projects? 99 projects?
+- Irregularities with projects containing 
+   0, 1, more songs? 99 songs?
+- Irregularities when selecting songs with:
+   0 length?
+   0 tracks? (is this possible?)
+- Irregularities when selecting option '--All songs--' ?
+- Irregularities on renaming drive/project/song?
+- Does the 'new folder' button work while browsing the project directory?
+
+Exporting: 
+- HD24connect should detect when the exportdirectory does not (or no longer)
+  exist when the export transfer is started.
+
+Special cases:
+- Exporting a song with zero length
+- Exporting 0 samples
+- Exporting 1 sample
+- Exporting > 2GigaSamples 
+- Auto split enabled/disabled
+
+Test for all sample rates:
+- What name is being used (renamed or not?)
+- Full songs in all formats
+- Export all tracks
+- Export 0 tracks
+- Export only track 1, track 2, ... track N (n=number of tracks)
+- Songs > 2 GiB/track (to test automatic splitting)
+- Start locpoint=START, end locpoint=END
+- start locpoint=START, end locpoint=2 samples
+- start locpoint=START, end locpoint=10 sec
+- start locpoint=1 sec, end locpoint=10 sec
+- start locpoint=END, end locpoint=START
+- start locpoint=1 sample, end locpoint=END
+- start locpoint=1 sample, end locpoint=2 samples
+- start locpoint=1 sample, end locpoint=10 sec
+- start locpoint=1 sample, end locpoint=END
+- start locpoint=1 sec, end locpoint=END
+
+Select song 'All songs' on a drive not containing double songnames, 
+export to an empty directory.
+- No questions are asked regarding overwriting files.
+- Nothing is mentioned about double song names (or prefixing song names).
+- HD24connect correctly detects if any songs with those prefixes already exist.
+- Are existing filenames properly detected when exporting large files (that
+  need splitting)? e.g. files with suffix _part1, _part2.
+
+TRANSPORT CONTROL/audio preview
+- To be tested on songs of either high or low sample rates
+- All possible state changes: stop->play, play->stop, etc.
+- Set locatepoints
+- Loop mode
+- Drag locate bar
+- FF past end of song possible? (by changing songs? by using JACK?)
+- REW to negative time code possible? (by using Jack?)
+- Change song during playback, including the possibility of changing song
+  at a time code not present in both songs
+- Export audio during playback could cause audio to sound choppy but the exported audio should be OK.
+
+RECOVERY FEATURES
+- Creating a drive image:
+  - What happens if there isn't enough drive space to hold the image?
+- Load created drive image and use it as HD24 drive
+- If this drive image is opened (File->open drive image), and we select
+  file->recovery->select device, the filename of the current drive image
+  should be reported as current device.
+- Switch device
+- Loading longliverec header: Can audio be exported correctly? (is it similar/
+  equal to the audio of the audio preview?
+- For both high and low sample rates?
+- Selecting a non-HD24 drive as drive image (for instance a random file,
+  or windos drive) should not cause HD24tools to crash during playback or
+  export.
+
+Other features
+- Exporting and printing file index should work with any number of projects and any number of songs per project. It is especially important to test large number of songs as only this will reveal memory leaks.
+
+TRANSFER TO HD24 DRIVE
+Tests to run that do not perform allocation:
+- Start transfer without files
+- With 1 file (in first slot)
+- With 1 file (in 2nd slot, in last slot) (using a clean image)
+- With 1 file (in 2nd slot, in last slot) (using an image with track 1 in use)
+- 16 track song/24 track song
+- With multiple files, less than the number of tracks
+- With multiple files, equal to the number of tracks
+- with files smaller than the song size
+- with files equal to the song size
+- with files larger than the song size
+- with multi channel files
+- with files that have a different sample rate
+- with files that have a different bit depth
+- with several files of various formats at once
+
+Tests that do perform allocation:
+- Start with an empty song
+- Transfer a file with 0 length to HD24
+- Transfer a file with >0 length to HD24
+- Transfer a file with even greater length to HD24
+- Create another song, transfer some audio to it. 
+  Is start of song cluster word-aligned in usage table?
+- Extend the first song. Does this work right?
+  Is the continuation of the song word-aligned?
+- What happens if the file to transfer is longer than 
+  the remaining amount of drive space?
+  
+
+
+
diff --git a/doc/artwork/DMG_Background.png b/doc/artwork/DMG_Background.png
new file mode 100644
index 0000000..720305d
--- /dev/null
+++ b/doc/artwork/DMG_Background.png
diff --git a/doc/artwork/DMG_Background.psd b/doc/artwork/DMG_Background.psd
new file mode 100644
index 0000000..6c648b2
--- /dev/null
+++ b/doc/artwork/DMG_Background.psd
diff --git a/doc/artwork/HD24Connect.icns b/doc/artwork/HD24Connect.icns
new file mode 100644
index 0000000..17714bb
--- /dev/null
+++ b/doc/artwork/HD24Connect.icns
diff --git a/doc/artwork/HD24_vipower.jpg b/doc/artwork/HD24_vipower.jpg
new file mode 100644
index 0000000..b667e9d
--- /dev/null
+++ b/doc/artwork/HD24_vipower.jpg
diff --git a/doc/artwork/Icon.psd b/doc/artwork/Icon.psd
new file mode 100644
index 0000000..77f35a6
--- /dev/null
+++ b/doc/artwork/Icon.psd
diff --git a/doc/artwork/hd24connect.jpg b/doc/artwork/hd24connect.jpg
new file mode 100644
index 0000000..e6d0695
--- /dev/null
+++ b/doc/artwork/hd24connect.jpg
diff --git a/doc/artwork/hd24display.png b/doc/artwork/hd24display.png
new file mode 100644
index 0000000..c701008
--- /dev/null
+++ b/doc/artwork/hd24display.png
diff --git a/doc/artwork/hd24pc.jpg b/doc/artwork/hd24pc.jpg
new file mode 100644
index 0000000..70b0278
--- /dev/null
+++ b/doc/artwork/hd24pc.jpg
diff --git a/doc/hd24tools_manual.odt b/doc/hd24tools_manual.odt
new file mode 100644
index 0000000..691bd94
--- /dev/null
+++ b/doc/hd24tools_manual.odt
diff --git a/doc/hd24tools_manual.pdf b/doc/hd24tools_manual.pdf
new file mode 100644
index 0000000..cbb32ff
--- /dev/null
+++ b/doc/hd24tools_manual.pdf