JPDstore allows you to save files into a store encrypted by a password. It provides "plausible deniability" since there is no way (at least I do not know any) to determine how many password protected "layers" are in a store. You can (and should) add random data to a store to make it impossible to use the store size (and its file's sizes) for guessing if there is another layer left.
Since JPDstore is written in Java and thus platform independent, it can be used well for putting data on CD-R media. In this case, first add all files to the store (in as many layers as your threat model requires; be sure to always add some "only lightly secret" data since no TLA will believe you burnt a CD-R full of garbage...) and then add garbage up to the media size (e.g. 650 MB). Then burn the resulting CD.
You can as well build a store and upload its files to some web server - JPDstore's import function allows to just download the files used by one of its layers)
The top level concept of jpdstore are stores. A store is a directory containing .jpds files. In the GUI you can switch stores by the Store -> Select store directory command. Stores are created automatically when selecting an empty directory.
Each store has a so called block count which determines the file size in that store - each block is 104k large and can hold 100k of payload. By setting a larger block count JPDstore will be faster, but on the other hand every file stored into that store will use up an integral number of chunks (or blocks or files), so if you want to store smaller files (or even smaller layers), use a smaller block count. So if you set block size to 10, you will have 1040k chunks which each 1000k payload.
Each store contains multiple layers - a store with only one layer or with no layers at all is useless. When creating a layer, you specify a password and the number of chunks it should have. This number is fixed, i. e. it is not possible to dynamically make that layer larger (at least not in this version). You have to use that password to open (i. e. unlock) that layer when you want to put files in it or out of it. You can as well create garbage layers - layers that look like normal ones but you cannot put data into them. This is useful for "plausible deniability" - nobody can know whether the remaining blocks contains more data (in one ore more other layers) or is just garbage). Note that layers can *not* be nested, i. e. to unlock one layer, one password is always sufficient.
Layers can also be deleted - and if you accidentally create garbage layers, you can open all non-garbage layers and delete the rest (double check first that you really opened all layers - JPDstore cannot determine if it deletes garbage or data layers).
Layers can be copied (imported) from one store to another as well. This even works (as long as you know the password) for stores accessible via web (the files need not be listable).
Files are most likely the most interesting thing for you :-) - since you want to store them. Files are always stored into layers and "eat up" an integral number of chunks. Note that there is no "fragmentation" concept in JPDstore - it is very well possible to have lots of single-chunk "holes" between your files, but cannot add any more files. In that case, export some files to some safe (encrypted) storage, delete them from the layer and add them again.
When looking at a store, it looks quite uninteresting - lots of same-size (and ideally equally well compressable) files with "random" file names. On the other hand, most modern filesystems keep some more metadata - when was a file created, when was it last modified, when accessed, or on a journalling filesystem it can be at least possible to determine which files have been accessed last (and maybe even the old contents of those files are available).
To avoid that journalling problem, store your stores on non-journalled filesystems - CDs are no problem anyway, and for USB thumb sticks you can use FAT32.
But another "problem" remains - all those dates in the filesystem metadata. To make stuff easier for you, jpdstore will set the "last modified date" (if the filesystem supports it) for all files to 1980-01-01 00:00 GMT. The other dates cannot be set directly from Java (since that is simply not needed - even an unzipper has to be able to set the last modified date but no other dates), so creation and access dates will always be "real". However that need not be the time when you really created that files - since there are a bunch of filesystem maintenance functions (which can either affect all files or random 10% of the files):
Access:Open each file and read a random byte from them
Modify:Open each file, read a random byte and write it again
Recreate:Load the file into memory, delete it and recreate it from scratch
Double-Copy:This is a feature specially for our "friends" from Redmond. If you know Windoze filesystems, you know they have created/modified/accessed timestamps. Modified is handled automatically, accessed is handled by the access method (just access all files when you are finished with using the store). Created should be handled by the recreate method, but is not. If a file is deleted and recreated (with same name, but possible different content) within 15 seconds (and without a reboot in between, of course), the new file will "inherit" the old file's timestamp. This is annoying - not only in our situation. But - here comes the solution: double-copy! This method copies all files to "temporary" filenames, waits for 15 seconds and just copies all of them back. This can take some time (15 seconds + x), but since you only have to do it whenever you create new layers, it should be feasable. Or use an operating system which is not made in Redmond.
That's it. Enjoy :-)