Conversion finally finished!

After considerable testing and bugfixing, I have finally finished converting from using file pointers to file descriptors.  Unfortunately, the change most likely breaks compilation on windows, but parallel I/O is likely not going to work in windows anyway so all I need to do is write another wrapper function. 

I've spent the last day or so testing the new code and so far everything seems to work properly.  During the conversion I also located several odd edge-case bugs and fixed them.  eg: if opening the output wav file succeeds but writing the RIFF headers to it fails, the program will continue trying to encode anyway.

The next commit or two will likely be cleaning up what I've changed a bit, then I will get back to the restructure, which is now ahead of schedule!

Further I/O issues

As part of changing how file I/O is handled, it turns out I also need to convert from file pointers to file descriptors.  Unfortunately, all of the RIFF validation code is dependent on using file pointers.  I have successfully converted the rest of the code to use file descriptors, but I wont commit it until i have the basic RIFF things working again.  As it stands, the code will compile but segfaults upon trying to read the RIFF data. (I used fdopen to try to get around the issue, but this has been highly unsuccessful.)

I/O issues

I've been doing a lot of work learning how boost::thread works and have started changing things around to allow for threading in general.  Unfortunately, in order to read data in anything resembling parallel, I need to change how files are opened entirely, which is posing a slight problem.  Currently I have separated the parts that can be executed in parallel from the normal encode and decode functions and started the process of changing how all file I/O is handled.

And We're Back

After a while of letting the project sit, I have returned to it to thread the program as much as possible.  This will speed up the already incredibly fast program, however its full benefit will be felt when the algorithm for better data hiding is fully implemented.  In these cases, the run time will be longer due to processing, which threading will assist in reducing.

Better Data Hiding

The addition of offsetting the data is proving to be a more difficult problem than expected due to the way addressing bits was optimized for speed. Turns out I need to rewrite a large number of the functions used to encode and decode data. This change is still a work in progress and wont be committed until it doesn't prevent compilation.

Changes in the works

Recent changes to the repository have included mostly small bug-fixes, corrections in debugging messages, and the prevention of possible double-frees. Also, the start of a GUI has been added to the repository.

I've been working on figuring out the structural changes I need to make to have the option to better hide a data stream, it is proving interesting.

Which is Which? - Answers

Here are the answers to the question from the last post:

• Clip 1 is the original sound file
• Clip 2 is encoded with AES-ECB and scrambled lower 1 bits
• Clip 3 is has nothing encoded, but scrambled lower 1 bits

If you look at the clips visually with a sound editing program they all appear the same even at extreme zooms:


The audio clips sound the same as well, so how can you tell them apart? As it turns out the original WAV file compresses better than the files with the scrambled lower bits (43% vs. 38%). After you narrow down the data to clips 2 and 3 you could then extract the lower 1 bits from each and perform an analysis on them. The AES encyption method that we used (and are replacing) is block based and leaves a detectable pattern. Once you figure out how big the block of data is you could then turn to traditional means of breaking AES.

From here on we are working on replacing AES ECB with a better AES algorithm in an effort to reduce detectability. We are also investigating ways to reduce the randomness of our random data padding so that the compression ratio is the same as or similar to the original file's ratio.

Which is which?

Last night I took an audio clip and I ran it through Awesome-WAV two times. Once was with a 80 byte data file, and once was without any data (to scramble the lower bits).

The clips

Is it possible to determine which clip is which? If you can figure it out, then send an email to awesomewav@gmail.com with your answer. In your email note which clip is the original, which contains data, and which contains no data. Also let us know how you figured it out.

*It is pretty easy to determine which file is the original

awesome-wav 1.1.0

I am pleased to announce the release of awesome-wav 1.1.0. This is an intermediary release that mostly adds new features and fixes a few small bugs in behavior.

There are two major changes in this release. The first is supporting compression with quicklz as well as zlib, with options to not include zlib compression. This decreases compression time, though increases file-size by a bit. The other significant change is allowing wav files with unknown wav chunks. The current implementation just discards the unknown chunks, something that will be changed by the next major release.

This release also fixes various behavior bugs and will allow the chunks of the riff file to be read in any order instead of a fixed order.

awesome-wav 1.0.1

I am pleased to announce the release of awesome-wav 1.0.1. This is primarily a bug-fix release, fixing issues with wav file validation and a few other random minor bugs. This release also includes the somehow forgotten --version argument.

the argument processor was also back-ported from the under-development 1.1/1.2/1.5 code as it is a little more flexible and includes some other various code modifications that have no effect on the actual operation of the program.